bd495be965
All checks were successful
Deploy to Production / Build and Deploy (push) Successful in 12s
- Sidebar: dynamic brand-accent colors, brainstorm section restyled - AI chat general: popup panel with expand/collapse, hides when contextual AI open - AI chat contextual: tabs reordered (Actions first), X close button, height fix - Settings: all tabs restyled, 6 new color presets (sage, terracotta, iron, etc.) - Global color cleanup: emerald/orange hardcoded → brand-accent dynamic - Brainstorm page: orange → brand-accent throughout - PageEntry animation component added to key pages - Floating AI button: bg-brand-accent instead of hardcoded black - i18n: all 15 locales updated with new AI/billing keys - Billing: freemium quota tracking, BYOK, stripe subscription scaffolding - Admin: integrated into new design - AGENTS.md + CLAUDE.md project rules added
90 lines
3.5 KiB
Markdown
90 lines
3.5 KiB
Markdown
---
|
|
name: development
|
|
description: Write production code from approved specifications
|
|
---
|
|
|
|
# [D] Development — Write Production Code
|
|
|
|
**Goal:** Write production-quality code from approved specifications using structured agent collaboration.
|
|
|
|
**When to use:**
|
|
- An approved specification exists (page spec, feature spec, or component spec)
|
|
- Prototype has been validated (if prototyping was part of the process)
|
|
- The codebase and tech stack are established (this is NOT for greenfield project setup)
|
|
- You need to turn a spec into committed, tested, production-ready code
|
|
|
|
**When NOT to use:**
|
|
- No approved spec exists yet — use [A] Analysis or spec writing first
|
|
- You need to explore or understand an existing codebase — use [R] Reverse Engineering
|
|
- You are fixing a bug in existing code — use [F] Bugfixing
|
|
- You need a throwaway prototype to validate ideas — use [P] Prototyping
|
|
|
|
---
|
|
|
|
## CORE PRINCIPLES
|
|
|
|
1. **Spec-driven.** The approved specification is the source of truth. Every implementation decision traces back to the spec. If the spec is ambiguous, clarify before coding — do not guess.
|
|
|
|
2. **Incremental.** Implement one feature or component at a time. Commit after each meaningful unit of work. Never let uncommitted changes grow large.
|
|
|
|
3. **Test as you go.** Run tests after each significant change. Do not batch all testing to the end. A failing test discovered early is cheap; discovered late it is expensive.
|
|
|
|
4. **Follow existing patterns.** Match the codebase's conventions for file structure, naming, styling, state management, and error handling. Consistency with the existing code matters more than personal preference.
|
|
|
|
5. **Document deviations.** If you must deviate from the spec (technical constraint, discovered issue), document what you changed and why before moving on.
|
|
|
|
---
|
|
|
|
## REFERENCE MATERIAL
|
|
|
|
Guides in `./data/guides/` support this workflow:
|
|
|
|
| Guide | Use When |
|
|
|-------|----------|
|
|
| EXECUTION-PRINCIPLES.md | Core execution discipline (document before acting, sketch fidelity, plan-then-execute) |
|
|
| INLINE-TESTING-GUIDE.md | Self-verifying implementation with Puppeteer before presenting to user |
|
|
| SEO-VALIDATION-GUIDE.md | Public-facing pages that need SEO compliance |
|
|
| SESSION-PROTOCOL.md | Managing agent sessions and handoffs |
|
|
| FEEDBACK-PROTOCOL.md | Handling user feedback during development |
|
|
|
|
---
|
|
|
|
## INITIALIZATION
|
|
|
|
### Design Log
|
|
Read `{output_folder}/_progress/00-design-log.md`. Check Current and Backlog for context.
|
|
|
|
---
|
|
|
|
## STEPS
|
|
|
|
Execute steps in `./steps-d/`:
|
|
|
|
| Step | File | Purpose |
|
|
|------|------|---------|
|
|
| 01 | step-01-scope-and-plan.md | Read spec, identify work items, create implementation order |
|
|
| 02 | step-02-setup-environment.md | Verify environment, install dependencies, establish baseline |
|
|
| 03 | step-03-implement.md | Build features one at a time from the plan |
|
|
| 04 | step-04-verify.md | Walk through every acceptance criterion |
|
|
| 05 | step-05-finalize.md | Clean up, test suite, PR preparation |
|
|
|
|
---
|
|
|
|
## DESIGN LOG REPORTING POINTS
|
|
|
|
Append to the Design Loop Status table in `{output_folder}/_progress/00-design-log.md`:
|
|
|
|
**On entry (step 01 complete):** `| [Scenario slug] | [NN.X] | [Page name] | building | [YYYY-MM-DD] |`
|
|
**On completion (step 05 approved):** `| [Scenario slug] | [NN.X] | [Page name] | built | [YYYY-MM-DD] |`
|
|
|
|
## AFTER COMPLETION
|
|
|
|
Design log updated with `built` status (see above). Present the transition:
|
|
|
|
<output>
|
|
**"[page name]" is built!**
|
|
|
|
1. **Run acceptance testing** — validate against the specification
|
|
2. **Explore the next scenario step** — [next page name]
|
|
</output>
|