RPD - Requirements, Planning, and Development Workflow

A concise command-driven workflow for software development.

Command Detection

• •Match keywords case-insensitively.
• •Prioritize clear user intent over strict formatting.
• •Multi-line prompts are valid.
• •If multiple commands appear, execute the first clearly intended command.
• •Ignore keywords in fenced code blocks and inline code unless explicitly requested.

Command Keywords

• •RPD: Run the full end-to-end workflow.
  • •Sequence: REQ → AP → AR (loop) → SS → TT → CR (loop) → DD → GC.
  • •Stop for approval after REQ/AP/AR before continuing to implementation/testing/commit steps.
• •REQ: Create or update requirements in .docs/reqs/{yyyy-mm-dd}/req-{name}.md.
  • •Focus on WHAT, not HOW, not optimization.
  • •REQ is documentation-only: create/update the requirement doc and do not implement code.
  • •Do not modify source code, tests, configs, or non-REQ docs when executing REQ.
• •AP: Create architecture/implementation plan in .docs/plans/{yyyy-mm-dd}/plan-{name}.md.
  • •Use markdown checkboxes for phased tasks.
  • •Use Mermaid for complex structures or flows.
• •AR: Review architecture and assumptions.
  • •Ensure no major flaws.
  • •Provide options and tradeoffs.
  • •Update existing REQ/AP docs in place (no separate review doc).
  • •Automatically fix high priority issues before reporting.
• •SS: Implement step-by-step from the plan.
  • •Update plan progress (- [x]) as tasks complete.
  • •Wait for approval gate before starting.
• •CC: Consolidate code/comments and remove redundancy.
• •DF: Debug and fix root cause.
  • •Explain the issue clearly.
  • •Provide fix options when useful.
• •DD: Document completed work in .docs/done/{yyyy-mm-dd}/{name}.md.
• •TT: Run tests and fix failures.
  • •Default command: npm test.
  • •If project uses another test command, use that instead.
• •CR: Review uncommitted changes with git.
  • •Check architecture, quality, performance, maintainability, and security.
  • •Automatically fix high priority issues before reporting.
• •GC: Commit changes with a clear conventional commit message.
  • •If requested as a standalone command, run CR first.

Automatic Triggers

• •REQ → AR loop (auto)
• •AP → AR loop (auto)
• •SS → CR loop (auto)
• •GC → CR (auto)
• •RPD orchestrates the full flow (REQ → AP → AR (loop) → SS → TT → CR (loop) → DD → GC).

What loop Means

• •AR (loop): Repeat architecture review/update until no major flaws remain or explicit user approval is given.
• •CR (loop): Repeat code review/fixes until no high-priority issues remain.
• •A loop is not infinite: stop when the exit condition is met, then continue to the next step.

Core Rules

• •Requirements work (REQ/AR) must focus on WHAT, not HOW.
• •REQ must only create/update .docs/reqs/{yyyy-mm-dd}/req-{name}.md and then stop for approval.
• •For large changes or AP requests, create/update plan first and get approval before implementation.
• •Be truthful about execution: only claim tests/build/lint ran if actually run.
• •If blocked by ambiguity or tradeoffs, ask targeted clarification questions.

Naming and Paths

• •{name} must be short kebab-case (for example: user-auth, offline-sync).

Documentation Structure

.docs/
├── reqs/{yyyy-mm-dd}/req-{name}.md
├── plans/{yyyy-mm-dd}/plan-{name}.md
└── done/{yyyy-mm-dd}/{name}.md