spec-driven-rule-for-ai.md

Spec Driven Workflow (Kiro style)

1. For any sizable new implementation or refactor, create a folder under .specs/ named YYYYMMDD_task-name and keep the work inside that folder. Track status as Draft → Review → Approved → Implementing → QA → Done.
2. In each folder, author requirements.md, design.md, and tasks.md in this order. Get user approval for requirements before moving to design; get design approval before creating tasks and implementing.
3. Do not maintain a root-level TODO. Track granular steps per spec in its tasks.md, and map each task to the corresponding acceptance criteria and tests.
4. Record specification approvals as milestones (date, approvers, key decisions) inside the spec folder. Log deltas/changes in a small “Change Log” section if the spec is revised.
5. Before execution, review requirements.md (purpose, scope, non-scope, acceptance criteria, dependencies, risks, performance/SLI, rollout/metrics). If updates are needed, apply them and re-seek approval, then explicitly proceed to design.md.
6. In design.md, cover architecture/flows, APIs/contracts/types, state/data models, error handling/retries, security/permissions, observability (logs/metrics/traces), performance budgets, rollout/rollback, and the test strategy (unit/E2E/load).
7. In tasks.md, list executable steps with traceability to acceptance criteria/tests. Mark tasks as in-progress with [-] when you start and as completed with [x] when done. Every PR must link back to the relevant spec and summarize how tasks and tests satisfy the spec.

使い方.md

AGETNS.mdなどに書いておきます。specの置き場とかは適当にアレンジしてください。AGENTS.mdに作りたいものの概要や使う技術などプロジェクトを進めるときに常に覚えておいて欲しい内容も一緒に書いておきます。skillsにしても良いですが、エージェントによっては(copilot)毎回これを参照して、と書かないとダメでいまいちだったことがあります。スラッシュコマンドやカスタムプロンプトにするのは良いかもしれない。

スペック同士は独立したものなのです。仕様や要件を一生懸命書き込んでも、他のスペックで作業をする場合にも毎回入力が必要になってしまいます。名前はスペックですが、作業指示ぐらいの気持ちで使う方が良いです。スペックは1つのPRになるぐらいの作業で1つ作るぐらいが良いです。