brewedops-e2e-developer

---

name: brewedops-e2e-developer description: Orchestrates the complete BrewedOps End-to-End workflow to develop, update, or implement a feature for an app. It takes your prompt and forces the agent through the strict pipeline: Knowledge Check -> Plan -> Build -> Clarity Pass -> Scan -> Greploop -> Verify -> Save.

BrewedOps E2E Developer

Overview

This skill is the master conductor for the BrewedOps development pipeline. When triggered, it orchestrates the entire lifecycle of a feature request, ensuring no step in the BrewedOps methodology (A through J) is skipped. It takes a raw user prompt or feature request and outputs fully implemented, verified, and safely committed code.

Dependencies

This workflow relies on several specialized emulator skills:

• brewedops-scanloop: For security and structural checks.
• brewedops-greploop: For rigorous code review diffing.
• brewedops-augustine-save: For atomic commits and session wrap-up.
• graphify: (Optional) To recall past project context.

Workflow

When the user asks you to implement a feature using this skill, you MUST follow these exact steps sequentially. Do not skip any phases.

1. Phase A & B: Knowledge Check & Entry

• Action: Before writing any code, consult AGENTS.md, the graphify knowledge graph (if available), and the existing real source code (opensrc).
• Rule: Never start by searching the web. Read the actual codebase first to understand the context.

2. Phase C: Plan & Scope

• Action: Create an implementation_plan.md detailing the goal, the specific files to be touched, and the success criteria.
• Rule: If the user's prompt is vague or ambiguous, pause and use the /grill-me protocol (via ask_question) to interview them and resolve dependencies before writing the plan.
• Wait: Ask the user for explicit approval on the plan.

3. Phase C: Build & Clarify

• Action: Build the piece in a small, focused chunk. Do not attempt massive rewrites.
• Action: Perform a "Clarity Pass" immediately after building. Tidy up the logic, de-duplicate, and remove dead variables. Do not change the core behavior during this pass.

4. Phase D: Check & Repeat (The Loops)

• Action: Run the brewedops-scanloop skill to check for leaked secrets, unbounded constraints, or security flaws.
• Action: Run the brewedops-greploop skill to strictly review the diff.
• Rule: If the greploop scores the chunk less than 5/5, loop back to Phase 3 (Build) to fix the issues. Do not proceed until it is perfect.

5. Phase D & E: Verify & Debug

• Action: Verify the code runs. Execute a real test command (e.g., npm run test, flutter test, or a specific verification script).
• Rule: Never claim a fix is verified based on reasoning alone. Evidence before assertions always.
• Rule: If a bug occurs (Phase E), rank the root causes, test the likeliest theory to confirm it, and apply a surgical fix. Re-verify.

6. Phase I & J: Save & Handoff

• Action: Invoke the brewedops-augustine-save skill to write a session note, create an atomic commit, and optionally push to origin.
• Action: Generate a final walkthrough.md for the user, summarizing the completed feature, what was tested, and the verification results. Stay out of the "dumb zone"—if context is degrading, suggest a fresh session.