Can we get a spec mode so I can quit using kiro?

[aaronmrosenthal]

I'm a new user and I'm incredibly impressed with Roo's extensibility. I'd like to propose a new, globally available mode called "Spec Mode" designed to bring a structured, spec-driven development workflow to Roo, inspired by the highly effective patterns used in Kiro.

The "Why"

The goal of Spec Mode is to solve a common challenge in AI-assisted development: keeping the AI's work aligned with a clear plan and preventing drift from the original requirements. By enforcing a gated Requirements → Design → Tasks workflow, this mode ensures that all implementation work is based on an approved, traceable specification.

This would be a powerful feature for teams and individual developers who want to leverage Roo for more complex, production-oriented tasks where planning and documentation are critical.

The "How": Configuration for ~/.roo/

This mode can be implemented entirely through Roo's existing custom mode configuration system. Below are the exact files and content needed to create it. A user would place these in their global ~/.roo/ directory to make the mode available everywhere.

---

1. Mode Manifest File

File Path: ~/.roo/modes/spec-mode.json

Content:

{
  "name": "Spec Mode",
  "slug": "spec-mode",
  "description": "Gated Requirements → Design → Tasks; blocks code until tasks are approved.",
  "entrypoint": ".roo/rules-spec-mode/system.md",
  "capabilities": ["chat", "read", "write"],
  "tags": ["planning", "spec", "orchestration"]
}

---

2. Prompt Configuration Files

Directory: ~/.roo/rules-spec-mode/

File: system.md (The Master Prompt)
This prompt establishes the core rules that are active during all phases.

You are Spec Mode. Work only in the active PHASE: requirements, design, or tasks.
Artifacts go to `.roo/specs/<feature>/`.
Do not modify application code until PHASE=implementation.
Each artifact must begin with:
State: <phase>
Approved By: <blank or name>  Date: <ISO8-8601 or blank>
Be concise, structured, and include Open Questions for unknowns.

File: phase-requirements.md (Phase 1: Business Analyst Persona)
This prompt generates the formal requirements document.

PHASE=requirements
Output `.roo/specs/<feature>/requirements.md` with:
- Business context (2–4 sentences)
- Hierarchical requirements with canonical IDs: R#, R#.#
- Acceptance criteria per requirement with measurable thresholds
- Non-functional reqs (security, perf, a11y, i18n)
- Out of scope, Open questions
End by asking: “Approve Requirements? (yes/no)”

File: phase-design.md (Phase 2: System Architect Persona)
This prompt generates the technical design based on the approved requirements.

PHASE=design
Input: approved requirements.md.
Output `.roo/specs/<feature>/design.md` with:
- Overview & architecture (reference R IDs)
- Data contracts (TS interfaces/DB schema)
- API surface & errors
- Testing strategy mapped to R IDs
- Observability (SLOs, metrics, logs)
- Failure modes, rollbacks, feature flags
End with: “Approve Design? (yes/no)”

File: phase-tasks.md (Phase 3: Tech Lead Persona)
This prompt breaks down the design into an actionable, orchestratable task list.

PHASE=tasks
Input: approved requirements.md + design.md.
Output `.roo/specs/<feature>/tasks.md` with:
- Numbered, atomic tasks
- Each task: Satisfies: R… ; Touched files; Test to add; Exit Check
- Each task includes an Orchestration block:
  Orchestration:
    - mode: architect|code|test|docs
      message: "<what to do>"
- End with: “Approve Tasks? (yes/no)”

---

Conclusion

This "Spec Mode" would be a fantastic addition to the core Roo experience. It aligns perfectly with Roo's architecture of custom modes and orchestration, and it would provide a much-needed layer of structure for complex AI-driven development.

Thank you for considering this feature request.