Chapter 06 | The System's First Pipeline (Workflow)

4 MIN READ | UPDATED: 2026-05-15

You already have the legal constraints of GEMINI.md, the interception mechanism of using-superpowers, and have expanded the system's brain with planning-with-files.

But if you say to the Agent right now: "Create the user table and make an API for it." Even knowing the rules, the Agent will still lack a "sense of rhythm" in its work—it might still dump a single 3,000-line file full of errors on your lap.

In professional tech companies, every task follows a Standard Operating Procedure (SOP). In the hands of an Agent, this is called a Workflow.

1. The Workflow File .agents/workflows/feature-development.md

We will create the first standardized process checklist in our project. Place it in the project's workflow directory. This file acts as an executable script that guides behavior.

---
description: T-Block Core New Feature Development Standard Process
---

# Feature Development Workflow

1. **Analysis Phase**: Read `docs/frd.md` and check if the requested feature contradicts existing architecture.
2. **Planning Phase**: Write a detailed step-by-step plan in `task_plan.md`.
3. **TDD Phase**: Write failing tests FIRST. Run the tests to confirm they fail.
4. **Implementation Phase**: Write the minimum code required to make the tests pass.
5. **Verification Phase**: Run tests. If they fail, trigger the `systematic-debugging` skill. Do NOT claim completion until tests pass.

2. From Ask-and-Answer to Autonomous Loop

With workflows, the interaction model changes. You no longer tell the Agent "write code." You tell the Agent "Execute the feature-development workflow for the login module." The Agent then acts as a self-driving machine, executing steps 1 through 5, only returning to you when it hits a severe blocker or successfully finishes the entire pipeline.