[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"project-80038":3},{"id":4,"name":5,"fullName":6,"owner":7,"repo":5,"description":8,"homepage":9,"htmlUrl":10,"language":11,"languages":10,"totalLinesOfCode":10,"stars":12,"forks":13,"watchers":14,"openIssues":15,"contributorsCount":16,"subscribersCount":16,"size":16,"stars1d":17,"stars7d":13,"stars30d":18,"stars90d":16,"forks30d":16,"starsTrendScore":19,"compositeScore":20,"rankGlobal":10,"rankLanguage":10,"license":21,"archived":22,"fork":22,"defaultBranch":23,"hasWiki":24,"hasPages":22,"topics":25,"createdAt":10,"pushedAt":10,"updatedAt":36,"readmeContent":37,"aiSummary":38,"trendingCount":16,"starSnapshotCount":16,"syncStatus":17,"lastSyncTime":39,"discoverSource":40},80038,"Spec-Driven-Development","FredAntB\u002FSpec-Driven-Development","FredAntB","A Claude skill that keeps your AI coding tools from contradicting  each other. Generates requirements.md, design.md, and tasks.md  before any code is written — then creates matching config files  for Claude Code, Cursor, Copilot, Windsurf, and Aider.","",null,"Python",87,5,64,8,0,2,22,6,2.33,"MIT License",false,"main",true,[26,27,28,29,30,31,32,33,34,35],"ai","claude","claude-code","copilot","cursor","developer-tools","llm","requirements","spec-driven-development","windsurf","2026-06-12 02:03:57","# spec-driven-development\n\n> Claude, Cursor, and Copilot all read the same plan before touching your code.\n\nA Claude skill that writes your specs before you write code — interviews you,\ngenerates `requirements.md`, `design.md`, and `tasks.md`, then creates matching\nconfig files for every AI tool you use so they can't contradict each other.\n\n[![Version](https:\u002F\u002Fimg.shields.io\u002Fbadge\u002Fversion-1.0--beta-blue)](https:\u002F\u002Fgithub.com\u002FFredAntB\u002Fspec-driven-development\u002Freleases\u002Ftag\u002Fv1.0-beta)\n[![CI](https:\u002F\u002Fgithub.com\u002FFredAntB\u002Fspec-driven-development\u002Factions\u002Fworkflows\u002Fci.yml\u002Fbadge.svg)](https:\u002F\u002Fgithub.com\u002FFredAntB\u002Fspec-driven-development\u002Factions\u002Fworkflows\u002Fci.yml)\n[![Phase 2A](https:\u002F\u002Fimg.shields.io\u002Fbadge\u002Fstatic%20assertions-67%2F67-brightgreen)](phase2a\u002Fassertions.md)\n[![Phase 2B](https:\u002F\u002Fimg.shields.io\u002Fbadge\u002Fbehavioral%20tests-15%2F15-brightgreen)](phase2b\u002Feval_session.md)\n[![Phase 2C](https:\u002F\u002Fimg.shields.io\u002Fbadge\u002Fgeneration%20quality-53%2F53-brightgreen)](phase2c\u002Feval_flows.md)\n[![License](https:\u002F\u002Fimg.shields.io\u002Fbadge\u002Flicense-MIT-green)](LICENSE)\n\n---\n\n## The problem this solves\n\nYou open Claude Code and ask it to build a feature. An hour later it's\ndone something technically impressive that isn't quite what you wanted.\nYou ask Cursor to fix it. It contradicts what Claude Code did. You ask\nCopilot to clean up. It invents a third interpretation.\n\nThe root cause is always the same: your AI agents have no shared source\nof truth. They fill every gap with their own assumptions.\n\nThis skill fixes that by creating three files before any code is written:\n\n| File | Answers |\n|---|---|\n| `requirements.md` | What the system must do |\n| `design.md` | How it will be built |\n| `tasks.md` | What to build next, in order |\n\nHere's what those files actually look like:\n\n**`requirements.md`** — every requirement is traceable and testable:\n```markdown\n- **REQ-001**: Users shall log time entries against a client project.\n  - _Acceptance_: POST \u002Fentries returns 201 with entry id, duration, and project_id\n- **REQ-002**: Users shall generate a monthly invoice from logged entries.\n  - _Acceptance_: GET \u002Finvoices\u002F:month returns PDF with line items summing to total\n```\n\n**`tasks.md`** — every task links back to its requirement:\n```markdown\n- [ ] **TASK-003** [REQ-001]: Implement POST \u002Fentries with validation\n  - _Output_: Route handler + duration schema validation\n  - _Verify_: POST \u002Fentries returns 201 with all required fields\n```\n\nEvery AI tool reads from these files before touching code. Drift stops.\n\n---\n\n## Quick start\n\nInstall the skill, then start a conversation with any of these:\n\n```\n\"I want to start a new project\"\n\"my AI keeps going off script, help\"\n\"I already have a codebase, no specs yet\"\n\"set up cursor and claude code for my team project\"\n```\n\nClaude will ask a few short questions and generate your spec files.\nNo configuration needed.\n\n---\n\n## Installation\n\n### Claude.ai \u002F Claude desktop app (Chat tab)\n\n1. Download [`spec-driven-development-v1.0.skill`](releases\u002Flatest)\n2. In Claude settings → Skills → Install from file\n\nOr via CLI:\n```bash\nclaude plugin install FredAntB\u002Fspec-driven-development\n```\n\n### Claude Code (Code tab)\n\n```bash\ngit clone https:\u002F\u002Fgithub.com\u002FFredAntB\u002Fspec-driven-development\n```\n\nOpen the folder in the Code tab. The `CLAUDE.md` file is auto-read\nat session start and bootstraps the skill.\n\n**Windows note:** Git must be installed for the Code tab to work\nwith local folders. Download from [git-scm.com](https:\u002F\u002Fgit-scm.com).\n\n---\n\n## What you get\n\n### For a new project (greenfield)\n\nClaude interviews you in 4 short questions — one at a time,\nconversationally — then generates:\n\n```\nyour-project\u002F\n├── requirements.md      ← what the system must do\n├── design.md            ← how it will be built\n├── tasks.md             ← atomic ordered implementation steps\n└── CLAUDE.md            ← Claude Code reads this automatically\n```\n\n**requirements.md** uses `shall` language and REQ-xxx IDs so every\nrequirement is traceable:\n\n```markdown\n## Functional Requirements\n\n### Tasks\n- **REQ-001**: Users shall create tasks with a title, description,\n  due date, and assignee.\n  - _Acceptance_: POST \u002Ftasks returns 201 with the created task object\n\n- **REQ-002**: Users shall update only tasks they created or are\n  assigned to.\n  - _Acceptance_: PATCH \u002Ftasks\u002F:id returns 403 for unauthorized users\n```\n\n**tasks.md** links every task back to its requirement inline:\n\n```markdown\n## Phase 2: Core endpoints\n\n- [ ] **TASK-007** [REQ-001]: Implement POST \u002Ftasks with validation\n  - _Output_: Route handler + request schema validation\n  - _Verify_: POST \u002Ftasks returns 201 with all fields present\n```\n\n### For an existing codebase (retrofit)\n\nSame result, reverse-engineered from what you describe:\n\n```\nyour-project\u002F\n├── requirements.md      ← v0-retrofit: discovered from existing code\n├── design.md            ← with [TO VERIFY] on every inferred field\n└── tasks.md             ← Phase 1 is spec verification, not new code\n```\n\n### For cross-AI teams\n\nGenerates identical instruction blocks across every tool your team uses:\n\n```\nyour-project\u002F\n├── CLAUDE.md                           ← Claude Code\n├── .cursorrules                        ← Cursor\n├── .windsurfrules                      ← Windsurf\n├── .github\u002Fcopilot-instructions.md    ← GitHub Copilot\n└── .aider.conf.yml                     ← Aider\n```\n\nEach file contains the same Universal Instruction Block — agents read\nthe same mandate, cite the same spec files, follow the same divergence\nprotocol. The only differences are tool-specific additions.\n\n---\n\n## Supported AI tools\n\n| Tool | Config file | Status |\n|---|---|---|\n| Claude Code | `CLAUDE.md` | ✓ Tested |\n| Cursor | `.cursorrules` | ✓ Tested |\n| Windsurf | `.windsurfrules` | ✓ Tested |\n| GitHub Copilot | `.github\u002Fcopilot-instructions.md` | ✓ Tested |\n| Aider | `.aider.conf.yml` | ✓ Generated |\n\n---\n\n## The Universal Instruction Block\n\nEvery AI config file contains this block, with only the project name\nand spec version filled in:\n\n```\n═══════════════════════════════════════════════════════════\nSPEC DRIVEN DEVELOPMENT — PROJECT CONSTITUTION\nProject: Your Project Name\nVersion: 1.0\n═══════════════════════════════════════════════════════════\n\nThis project uses Spec Driven Development. All work is\ngoverned by three source-of-truth files:\n\n  requirements.md  — What the system must do\n  design.md        — How the system is structured\n  tasks.md         — The ordered implementation plan\n\nMANDATORY BEFORE ANY ACTION:\n  1. Read requirements.md in full\n  2. Read design.md in full\n  3. Read tasks.md — identify the next incomplete [ ] task\n\nHARD CONSTRAINTS:\n  ✗ Never implement requirements not in requirements.md\n  ✗ Never alter the data model without updating design.md first\n  ✗ Never create files not listed or implied in design.md\n  ✗ Never mark a task [x] without verifying its acceptance criterion\n  ✗ Never guess when a requirement is ambiguous — ask instead\n\nDIVERGENCE PROTOCOL:\n  If implementation must deviate from design.md:\n    → Stop immediately\n    → Describe the conflict clearly\n    → Wait for explicit user approval\n    → Update design.md BEFORE writing code\n═══════════════════════════════════════════════════════════\n```\n\n---\n\n## Test suite & CI\n\nThis skill ships with a complete, runnable test suite — 135 assertions\nacross three phases. A GitHub Actions workflow runs the automatable\nchecks on every push and pull request.\n\n### GitHub Actions workflow (`.github\u002Fworkflows\u002Fci.yml`)\n\nFour jobs run on every push to `main`\u002F`master` and on every PR:\n\n| Job | What it does | Required to pass? |\n|---|---|---|\n| `phase2a` | Runs 67 static assertions via Python | Yes — hard gate |\n| `phase2c` | Runs 53 generation quality checks against committed fixtures | Yes if fixtures present |\n| `phase2b-notice` | Prints instructions for running behavioral tests manually | Informational only |\n| `all-checks` | Aggregates results — reference this in branch protection rules | Yes |\n\n**Branch protection setup** — in your repo settings, add `all-checks`\nas the single required status check. This means one rule covers all\nautomated phases now and any you add later.\n\n### Running locally\n\n```bash\n# Phase 2A — static assertions (67 checks)\npython3 phase2a\u002Frun_assertions.py\n\n# Windows — if python3 not on PATH or encoding errors occur\nPYTHONUTF8=1 python phase2a\u002Frun_assertions.py\n\n# Phase 2C — generation quality (53 checks, requires fixture files)\npython3 phase2c\u002Fcheck_outputs.py\n```\n\nOr paste the KICKOFF.md for each phase into the Claude Code tab\nfor a zero-setup run from any machine.\n\n### Running in Claude Code (Code tab)\n\n| Phase | Paste this | Output |\n|---|---|---|\n| 2A | `phase2a\u002FKICKOFF.md` | Runs script, explains any failures |\n| 2B | `phase2b\u002FKICKOFF.md` | 15 behavioral tests → `eval_report.md` |\n| 2C | `phase2c\u002FKICKOFF.md` | 3 flows → files → `eval_report_2c.md` |\n\n### Phase 2C fixtures\n\nPhase 2C requires Claude Code to generate real spec files, which are\nthen committed to the repo as fixtures that CI checks on every push.\n\nTo regenerate fixtures after a significant skill change:\n1. Open the repo folder in the Code tab\n2. Paste `phase2c\u002FKICKOFF.md`\n3. Commit the files Claude Code writes to `phase2c\u002Fflow_a\u002F`,\n   `phase2c\u002Fflow_b\u002F`, and `phase2c\u002Fflow_c\u002F`\n\nCI will automatically pick up the new fixtures on the next push.\n\n### Current test results\n\n| Phase | Type | Assertions | CI |\n|---|---|---|---|\n| 2A | Static file checks | 67 \u002F 67 ✓ | Automated |\n| 2B | Behavioral (live session) | 15 \u002F 15 ✓ | Manual |\n| 2C | Generation quality | 53 \u002F 53 ✓ | Automated (fixtures required) |\n\n---\n\n## Trigger phrases\n\nThe skill activates on a wide vocabulary. A sample:\n\n**Starting a project:**\n`\"I want to start a new project\"` · `\"help me plan before I code\"` ·\n`\"set up SDD for my project\"` · `\"I need a spec\"`\n\n**AI tool setup:**\n`\"set up cursor and claude code\"` · `\"make a cursorrules file\"` ·\n`\"my AI keeps going off script\"` · `\"keep my agents consistent\"`\n\n**Existing codebase:**\n`\"I already have a codebase, no specs yet\"` ·\n`\"help me document what my system does\"` ·\n`\"describe my architecture\"` · `\"add specs to existing project\"`\n\n**Feature requests:**\n`\"add dark mode\"` → triggers spec presence check before any code\n`\"just start coding\"` → triggers anti-pattern warning\n\n---\n\n## Anti-patterns the skill prevents\n\n| Anti-pattern | What the skill does |\n|---|---|\n| \"just start coding\" | Pushes back with concrete reasons, asks for spec |\n| Feature request without spec context | Checks for requirements.md before proceeding |\n| Generating config files before spec exists | Hard gate — interview required first |\n| AI guessing at ambiguous requirements | Asks for clarification, never fabricates |\n| Out of scope missing from requirements | Flags it and asks what won't be in v1 |\n\n---\n\n## Community beta — we need testers\n\nThis skill is in **public beta**. It has passed 135 automated\nassertions and 3 end-to-end generation flows, but it has not yet\nbeen tested by strangers using natural language.\n\nWe need 5 testers matching these profiles:\n\n- A complete beginner starting their first real project\n- A solo developer with an active side project (greenfield or partial)\n- A team lead whose team uses multiple AI tools\n- A developer with an existing codebase and no written specs\n- A developer who actively uses 3+ AI coding tools simultaneously\n\n**To volunteer:** Open an issue titled `[Beta] I'd like to test`\nand describe which profile fits you best.\n\nAll you need to do is use the skill naturally for your real work\nand file issues when something doesn't work. That's it.\n\n---\n\n## Contributing\n\n1. Fork the repo\n2. Make your change to `SKILL.md` or the reference files\n3. Run the Phase 2A assertion suite: `python3 phase2a\u002Frun_assertions.py`\n4. If assertions fail, fix them before filing a PR\n5. If your change adds new behavior, add a corresponding assertion\n\nNew assertions go in `phase2a\u002Fassertions.md` (human-readable spec)\nand `phase2a\u002Frun_assertions.py` (machine-executable check).\n\n---\n\n## Skill structure\n\n```\nspec-driven-development\u002F\n├── SKILL.md                                  ← the skill (install this)\n├── CLAUDE.md                                 ← Code tab bootstrap\n├── references\u002F\n│   ├── sdd-curriculum.md                     ← newbie-to-hero teaching guide\n│   ├── capabilities-and-cross-ai.md          ← Claude Code + cross-AI strategy\n│   └── templates.md                          ← spec file + UIB templates\n├── phase2a\u002F\n│   ├── assertions.md                         ← human-readable test spec\n│   └── run_assertions.py                     ← static assertion runner\n├── phase2b\u002F\n│   ├── eval_session.md                       ← behavioral test definitions\n│   └── KICKOFF.md                            ← Code tab eval kickoff\n├── phase2c\u002F\n│   ├── eval_flows.md                         ← end-to-end flow definitions\n│   ├── check_outputs.py                      ← generation quality checker\n│   └── KICKOFF.md                            ← Code tab eval kickoff\n└── beta\u002F\n    ├── BETA_PLAN.md                          ← 5-person beta plan\n    ├── TESTER_BRIEF.md                       ← tester onboarding guide\n    └── ISSUE_TEMPLATES.md                    ← feedback issue templates\n```\n\n---\n\n## License\n\nMIT — use freely, attribution appreciated.\n\n---\n\n## Acknowledgements\n\nBuilt and tested using the Claude skill framework. Test suite\nmethodology adapted from the skill-creator eval harness. All\n135 assertions were written before the corresponding fixes —\ntest-first, always.\n","该项目旨在通过生成统一的规范文件来防止不同的AI编码工具产生矛盾。其核心功能包括自动生成`requirements.md`、`design.md`和`tasks.md`，并在代码编写前创建与Claude Code、Cursor、Copilot等工具相匹配的配置文件，确保各工具遵循一致的设计思路。技术上采用Python实现，并支持多种流行的AI开发辅助工具。适用于需要多款AI编程助手协同工作的软件开发场景，尤其在项目初期定义需求、设计架构及任务分解时能够显著提高团队协作效率。","2026-06-11 03:59:00","CREATED_QUERY"]