85 lines
3.2 KiB
Markdown
85 lines
3.2 KiB
Markdown
# PhaseFlow Build Mode
|
|
|
|
Implement functionality from the plan, validate with tests, and commit.
|
|
|
|
## 0. Orient
|
|
|
|
0a. Study `specs/*` with parallel Sonnet subagents to learn the application specifications.
|
|
0b. Study @IMPLEMENTATION_PLAN.md to understand current priorities.
|
|
0c. Study @AGENTS.md to understand build/test commands and codebase patterns.
|
|
0d. For reference, the application source code is in `src/*`.
|
|
|
|
## 1. Select and Implement
|
|
|
|
Your task is to implement functionality per the specifications using parallel subagents.
|
|
|
|
Follow @IMPLEMENTATION_PLAN.md and choose the most important item to address.
|
|
|
|
Before making changes, search the codebase (don't assume not implemented) using Sonnet subagents. You may use up to 8 parallel Sonnet subagents for searches/reads and only 1 Sonnet subagent for build/tests. Use Opus subagents when complex reasoning is needed (debugging, architectural decisions).
|
|
|
|
## 2. TDD Workflow
|
|
|
|
Follow TDD per CLAUDE.md:
|
|
|
|
1. **Write a failing test** that defines the desired behavior
|
|
2. Run the test to confirm it fails: `pnpm test:run`
|
|
3. **Write minimal code** to make the test pass
|
|
4. Run tests to confirm success
|
|
5. **Refactor** while keeping tests green
|
|
6. Repeat for each piece of functionality
|
|
|
|
Ultrathink.
|
|
|
|
## 3. Update Plan
|
|
|
|
When you discover issues, immediately update @IMPLEMENTATION_PLAN.md with your findings using a subagent.
|
|
|
|
When resolved, update and remove the item.
|
|
|
|
## 4. Commit
|
|
|
|
When the tests pass:
|
|
1. Update @IMPLEMENTATION_PLAN.md
|
|
2. Run `pnpm lint` and fix any issues
|
|
3. `git add -A`
|
|
4. `git commit` with a descriptive message (NEVER use --no-verify)
|
|
5. `git push`
|
|
|
|
## 5. Documentation
|
|
|
|
When authoring documentation, capture the why — tests and implementation importance.
|
|
|
|
## 6. Quality Rules
|
|
|
|
- Single sources of truth, no migrations/adapters
|
|
- If tests unrelated to your work fail, resolve them as part of the increment
|
|
- Implement functionality completely. Placeholders and stubs waste efforts and time redoing the same work
|
|
- All files must start with 2-line ABOUTME comments
|
|
- No mock mode - use real data and APIs only
|
|
|
|
## 7. Maintenance
|
|
|
|
- Keep @IMPLEMENTATION_PLAN.md current with learnings using a subagent — future work depends on this to avoid duplicating efforts
|
|
- Update especially after finishing your turn
|
|
- When @IMPLEMENTATION_PLAN.md becomes large, periodically clean out completed items
|
|
|
|
## 8. Operational Learning
|
|
|
|
When you learn something new about how to run the application, update @AGENTS.md using a subagent but keep it brief. For example, if you run commands multiple times before learning the correct command, that file should be updated.
|
|
|
|
## 9. Bug Handling
|
|
|
|
For any bugs you notice, resolve them or document them in @IMPLEMENTATION_PLAN.md using a subagent, even if unrelated to the current piece of work.
|
|
|
|
## 10. Spec Consistency
|
|
|
|
If you find inconsistencies in the `specs/*` then use an Opus subagent with 'ultrathink' requested to update the specs.
|
|
|
|
## 11. Keep AGENTS.md Lean
|
|
|
|
IMPORTANT: Keep @AGENTS.md operational only — status updates and progress notes belong in @IMPLEMENTATION_PLAN.md. A bloated AGENTS.md pollutes every future loop's context.
|
|
|
|
## 12. Exit
|
|
|
|
After committing, exit cleanly. The loop will restart with fresh context.
|