Back to Details

spec-driven-workflow

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

Spec-Driven Workflow — POWERFUL

规格驱动工作流 — 高效实用

Overview

概述

Spec-driven workflow enforces a single, non-negotiable rule: write the specification BEFORE you write any code. Not alongside. Not after. Before.
This is not documentation. This is a contract. A spec defines what the system MUST do, what it SHOULD do, and what it explicitly WILL NOT do. Every line of code you write traces back to a requirement in the spec. Every test traces back to an acceptance criterion. If it is not in the spec, it does not get built.
规格驱动工作流遵循一条不可协商的核心规则：在编写任何代码之前，先撰写规格说明。 不是并行，不是事后，而是提前。
这不是文档，而是一份契约。规格说明定义了系统必须做什么、应该做什么，以及明确不会做什么。你编写的每一行代码都能追溯到规格中的一项需求，每一个测试都对应一项验收标准。如果某项内容不在规格中，就不会被开发。

Why Spec-First Matters

先规格后开发的重要性

  1. Eliminates rework. 60-80% of defects originate from requirements, not implementation. Catching ambiguity in a spec costs minutes; catching it in production costs days.
  2. Forces clarity. If you cannot write what the system should do in plain language, you do not understand the problem well enough to write code.
  3. Enables parallelism. Once a spec is approved, frontend, backend, QA, and documentation can all start simultaneously.
  4. Creates accountability. The spec is the definition of done. No arguments about whether a feature is "complete" — either it satisfies the acceptance criteria or it does not.
  5. Feeds TDD directly. Acceptance criteria in Given/When/Then format translate 1:1 into test cases. The spec IS the test plan.
  1. 消除返工：60-80%的缺陷源于需求而非实现。在规格中发现歧义只需几分钟，而在生产环境中发现则需要数天时间修复。
  2. 确保清晰性：如果你无法用平实的语言写出系统应该做什么，说明你还没有足够理解问题，不足以编写代码。
  3. 支持并行工作：规格一旦获批，前端、后端、QA和文档团队都可以同时启动工作。
  4. 明确问责：规格就是“完成”的定义。无需争论功能是否“完成”——要么满足验收标准，要么不满足。
  5. 直接支持TDD：Given/When/Then格式的验收标准可以1:1转化为测试用例。规格本身就是测试计划。

The Iron Law

铁律

NO CODE WITHOUT AN APPROVED SPEC.
NO EXCEPTIONS. NO "QUICK PROTOTYPES." NO "I'LL DOCUMENT IT LATER."
If the spec is not written, reviewed, and approved, implementation does not begin. Period.
NO CODE WITHOUT AN APPROVED SPEC.
NO EXCEPTIONS. NO "QUICK PROTOTYPES." NO "I'LL DOCUMENT IT LATER."
如果规格未撰写、未审核、未获批，就不能开始实现。没有例外。

The Spec Format

规格格式

Every spec follows this structure. No sections are optional — if a section does not apply, write "N/A — [reason]" so reviewers know it was considered, not forgotten.
每份规格都遵循以下结构。所有部分均为必填项——如果某部分不适用，需写入“N/A — [原因]”，以便审核者知晓该部分已被考虑，而非遗漏。

Mandatory Sections

必填部分

#SectionKey Rules
1Title and MetadataAuthor, date, status (Draft/In Review/Approved/Superseded), reviewers
2ContextWhy this feature exists. 2-4 paragraphs with evidence (metrics, tickets).
3Functional RequirementsRFC 2119 keywords (MUST/SHOULD/MAY). Numbered FR-N. Each is atomic and testable.
4Non-Functional RequirementsPerformance, security, accessibility, scalability, reliability — all with measurable thresholds.
5Acceptance CriteriaGiven/When/Then format. Every AC references at least one FR-* or NFR-*.
6Edge CasesNumbered EC-N. Cover failure modes for every external dependency.
7API ContractsTypeScript-style interfaces. Cover success and error responses.
8Data ModelsTable format with field, type, constraints. Every entity from requirements must have a model.
9Out of ScopeExplicit exclusions with reasons. Prevents scope creep during implementation.
#章节核心规则
1标题与元数据作者、日期、状态（草稿/审核中/已批准/已取代）、审核人
2背景该功能存在的原因。2-4段内容，附带依据（指标、工单）。
3功能需求使用RFC 2119关键词（MUST/SHOULD/MAY）。编号为FR-N。每项需求需具备原子性和可测试性。
4非功能需求性能、安全、可访问性、可扩展性、可靠性——均需包含可衡量的阈值。
5验收标准Given/When/Then格式。每项验收标准至少关联一个FR-或NFR-。
6边缘场景编号为EC-N。覆盖所有外部依赖的故障模式。
7API契约TypeScript风格的接口。覆盖成功和错误响应。
8数据模型表格格式，包含字段、类型、约束。需求中提及的每个实体都必须有对应的模型。
9范围外内容明确列出排除项及原因。防止实现过程中出现范围蔓延。

RFC 2119 Keywords

RFC 2119关键词

KeywordMeaning
MUSTAbsolute requirement. Non-conformant without it.
MUST NOTAbsolute prohibition.
SHOULDRecommended. Omit only with documented justification.
MAYOptional. Implementer's discretion.
See spec_format_guide.md for the complete template with section-by-section examples, good/bad requirement patterns, and feature-type templates (CRUD, Integration, Migration).
See acceptance_criteria_patterns.md for a full pattern library of Given/When/Then criteria across authentication, CRUD, search, file upload, payment, notification, and accessibility scenarios.
关键词含义
MUST绝对要求。不满足则不符合规范。
MUST NOT绝对禁止。
SHOULD推荐项。仅在有书面理由时可省略。
MAY可选项。由实现者自行决定。
完整模板及各章节示例、优劣需求模式、不同类型功能模板（CRUD、集成、迁移）请参考spec_format_guide.md。
关于在身份验证、CRUD、搜索、文件上传、支付、通知和可访问性场景下编写Given/When/Then标准的完整模式库，请参考acceptance_criteria_patterns.md。

Bounded Autonomy Rules

有限自主规则

These rules define when an agent (human or AI) MUST stop and ask for guidance vs. when they can proceed independently.
这些规则定义了智能体（人类或AI）必须停止并寻求指导的场景，以及可以独立推进的场景。

STOP and Ask When:

需停止并询问的场景：

  1. Scope creep detected. The implementation requires something not in the spec. Even if it seems obviously needed, STOP. The spec might have excluded it deliberately.
  2. Ambiguity exceeds 30%. If you cannot determine the correct behavior from the spec for more than 30% of a given requirement, the spec is incomplete. Do not guess.
  3. Breaking changes required. The implementation would change an existing API contract, database schema, or public interface. Always escalate.
  4. Security implications. Any change that touches authentication, authorization, encryption, or PII handling requires explicit approval.
  5. Performance characteristics unknown. If a requirement says "MUST complete in < 500ms" but you have no way to measure or guarantee that, escalate before implementing a guess.
  6. Cross-team dependencies. If the spec requires coordination with another team or service, confirm the dependency before building against it.
  1. 检测到范围蔓延：实现需要规格中未提及的内容。即使看起来明显需要，也要停止。规格可能故意排除了该内容。
  2. 歧义超过30%：如果对于某一需求，你无法从规格中确定正确行为的比例超过30%，说明规格不完整。不要猜测。
  3. 需要破坏性变更：实现会改变现有API契约、数据库架构或公共接口。必须上报。
  4. 涉及安全影响：任何触及身份验证、授权、加密或PII处理的变更都需要明确批准。
  5. 性能特征未知：如果需求要求“必须在<500ms内完成”，但你无法衡量或保证这一点，在实现猜测方案前需上报。
  6. 跨团队依赖：如果规格需要与其他团队或服务协作，在基于该依赖进行开发前需确认其可行性。

Continue Autonomously When:

可自主推进的场景：

  1. Spec is clear and unambiguous for the current task.
  2. All acceptance criteria have passing tests and you are refactoring internals.
  3. Changes are non-breaking — no public API, schema, or behavior changes.
  4. Implementation is a direct translation of a well-defined acceptance criterion.
  5. Error handling follows established patterns already documented in the codebase.
  1. 当前任务的规格清晰明确，无歧义。
  2. 所有验收标准对应的测试均已通过，且你正在重构内部代码。
  3. 变更为非破坏性——不涉及公共API、架构或行为变更。
  4. 实现是对明确定义的验收标准的直接转化。
  5. 错误处理遵循代码库中已记录的既定模式。

Escalation Protocol

上报流程

When you must stop, provide:
markdown
undefined
当你必须停止时，需提供以下内容：
markdown
undefined

Escalation: [Brief Title]

上报：[简短标题]

Blocked on: [requirement ID, e.g., FR-3] Question: [Specific, answerable question — not "what should I do?"] Options considered: A. [Option] — Pros: [...] Cons: [...] B. [Option] — Pros: [...] Cons: [...] My recommendation: [A or B, with reasoning] Impact of waiting: [What is blocked until this is resolved?]

Never escalate without a recommendation. Never present an open-ended question. Always give options.

See `references/bounded_autonomy_rules.md` for the complete decision matrix.

---
阻塞点： [需求ID，例如FR-3] 问题： [具体、可回答的问题——不要问“我该怎么办？”] 考虑的选项： A. [选项] — 优点：[...] 缺点：[...] B. [选项] — 优点：[...] 缺点：[...] 我的建议： [A或B，附理由] 等待的影响： [此问题解决前，哪些工作会被阻塞？]

永远不要在没有建议的情况下上报。永远不要提出开放式问题。始终提供选项。

完整决策矩阵请参考`references/bounded_autonomy_rules.md`。

---

Workflow — 6 Phases

工作流 — 6个阶段

Phase 1: Gather Requirements

阶段1：收集需求

Goal: Understand what needs to be built and why.
  1. Interview the user. Ask:
    • What problem does this solve?
    • Who are the users?
    • What does success look like?
    • What explicitly should NOT be built?
  2. Read existing code. Understand the current system before proposing changes.
  3. Identify constraints. Performance budgets, security requirements, backward compatibility.
  4. List unknowns. Every unknown is a risk. Surface them now, not during implementation.
Exit criteria: You can explain the feature to someone unfamiliar with the project in 2 minutes.
目标： 理解需要开发什么以及原因。
  1. 访谈用户：询问：
    • 这解决了什么问题？
    • 用户是谁？
    • 成功的标准是什么？
    • 明确不应开发的内容是什么？
  2. 阅读现有代码：在提出变更前，先理解当前系统。
  3. 识别约束：性能预算、安全要求、向后兼容性。
  4. 列出未知项：每个未知项都是风险。现在就明确它们，不要等到实现阶段。
退出标准： 你可以在2分钟内向不熟悉项目的人解释该功能。

Phase 2: Write Spec

阶段2：撰写规格

Goal: Produce a complete spec document following The Spec Format above.
  1. Fill every section of the template. No section left blank.
  2. Number all requirements (FR-, NFR-, AC-, EC-, OS-*).
  3. Use RFC 2119 keywords precisely.
  4. Write acceptance criteria in Given/When/Then format.
  5. Define API contracts with TypeScript-style types.
  6. List explicit exclusions in Out of Scope.
Exit criteria: The spec can be handed to a developer who was not in the requirements meeting, and they can implement the feature without asking clarifying questions.
目标： 生成符合上述规格格式的完整规格文档。
  1. 填写模板的所有部分。不要留空。
  2. 为所有需求编号（FR-、NFR-、AC-、EC-、OS-*）。
  3. 准确使用RFC 2119关键词。
  4. 用Given/When/Then格式撰写验收标准。
  5. 用TypeScript风格的类型定义API契约。
  6. 在“范围外内容”中列出明确的排除项。
退出标准： 将规格交给未参与需求会议的开发者，他们无需询问澄清问题即可实现该功能。

Phase 3: Validate Spec

阶段3：验证规格

Goal: Verify the spec is complete, consistent, and implementable.
Run 
spec_validator.py
against the spec file:
bash
python spec_validator.py --file spec.md --strict
Manual validation checklist:
  • Every functional requirement has at least one acceptance criterion
  • Every acceptance criterion is testable (no subjective language)
  • API contracts cover all endpoints mentioned in requirements
  • Data models cover all entities mentioned in requirements
  • Edge cases cover failure modes for every external dependency
  • Out of scope is explicit about what was considered and rejected
  • Non-functional requirements have measurable thresholds
Exit criteria: Spec scores 80+ on validator, and all manual checklist items pass.
目标： 验证规格完整、一致且可实现。
运行
spec_validator.py
对规格文件进行验证：
bash
python spec_validator.py --file spec.md --strict
手动验证清单：
  • 每个功能需求至少对应一项验收标准
  • 每个验收标准均可测试（无主观语言）
  • API契约覆盖需求中提及的所有端点
  • 数据模型覆盖需求中提及的所有实体
  • 边缘场景覆盖所有外部依赖的故障模式
  • 范围外内容明确列出了已考虑并拒绝的内容
  • 非功能需求包含可衡量的阈值
退出标准： 规格在验证器中的得分≥80，且手动清单所有项均通过。

Phase 4: Generate Tests

阶段4：生成测试

Goal: Extract test cases from acceptance criteria before writing implementation code.
Run 
test_extractor.py
against the approved spec:
bash
python test_extractor.py --file spec.md --framework pytest --output tests/
  1. Each acceptance criterion becomes one or more test cases.
  2. Each edge case becomes a test case.
  3. Tests are stubs — they define the assertion but not the implementation.
  4. All tests MUST fail initially (red phase of TDD).
Exit criteria: You have a test file where every test fails with "not implemented" or equivalent.
目标： 在编写实现代码前，从验收标准中提取测试用例。
运行
test_extractor.py
对已获批的规格进行处理：
bash
python test_extractor.py --file spec.md --framework pytest --output tests/
  1. 每项验收标准转化为一个或多个测试用例。
  2. 每个边缘场景转化为一个测试用例。
  3. 测试为桩代码——定义断言但不包含实现。
  4. 所有测试初始状态必须失败（TDD的红阶段）。
退出标准： 你拥有一个测试文件，其中所有测试均因“未实现”或类似原因失败。

Phase 5: Implement

阶段5：实现

Goal: Write code that makes failing tests pass, one acceptance criterion at a time.
  1. Pick one acceptance criterion (start with the simplest).
  2. Make its test(s) pass with minimal code.
  3. Run the full test suite — no regressions.
  4. Commit.
  5. Pick the next acceptance criterion. Repeat.
Rules:
  • Do NOT implement anything not in the spec.
  • Do NOT optimize before all acceptance criteria pass.
  • Do NOT refactor before all acceptance criteria pass.
  • If you discover a missing requirement, STOP and update the spec first.
Exit criteria: All tests pass. All acceptance criteria satisfied.
目标： 编写代码使失败的测试通过，一次处理一项验收标准。
  1. 选择一项验收标准（从最简单的开始）。
  2. 用最少的代码使其测试通过。
  3. 运行完整测试套件——无回归问题。
  4. 提交代码。
  5. 选择下一项验收标准。重复上述步骤。
规则：
  • 不要实现规格中未提及的内容。
  • 在所有验收标准通过前不要进行优化。
  • 在所有验收标准通过前不要进行重构。
  • 如果发现遗漏的需求，停止并先更新规格。
退出标准： 所有测试通过。所有验收标准均已满足。

Phase 6: Self-Review

阶段6：自我审核

Goal: Verify implementation matches spec before marking done.
Run through the Self-Review Checklist below. If any item fails, fix it before declaring the task complete.
目标： 在标记完成前，验证实现是否符合规格。
完成以下自我审核清单。如果任何一项未通过，在宣布任务完成前进行修复。

Self-Review Checklist

自我审核清单

Before marking any implementation as done, verify ALL of the following:
  • Every acceptance criterion has a passing test. No exceptions. If AC-3 exists, a test for AC-3 exists and passes.
  • Every edge case has a test. EC-1 through EC-N all have corresponding test cases.
  • No scope creep. The implementation does not include features not in the spec. If you added something, either update the spec or remove it.
  • API contracts match implementation. Request/response shapes in code match the spec exactly. Field names, types, status codes — all of it.
  • Error scenarios tested. Every error response defined in the spec has a test that triggers it.
  • Non-functional requirements verified. If the spec says < 500ms, you have evidence (benchmark, load test, profiling) that it meets the threshold.
  • Data model matches. Database schema matches the spec. No extra columns, no missing constraints.
  • Out-of-scope items not built. Double-check that nothing from the Out of Scope section leaked into the implementation.
在标记任何实现为完成前，需验证以下所有内容：
  • 每项验收标准都有通过的测试。无例外。如果存在AC-3，就必须有对应的测试且已通过。
  • 每个边缘场景都有测试。EC-1至EC-N均有对应的测试用例。
  • 无范围蔓延。实现未包含规格中未提及的功能。如果添加了内容，要么更新规格，要么移除该内容。
  • API契约与实现匹配。代码中的请求/响应格式与规格完全一致。字段名、类型、状态码——所有内容都需匹配。
  • 错误场景已测试。规格中定义的每个错误响应都有对应的触发测试。
  • 非功能需求已验证。如果规格要求<500ms，你需有证据（基准测试、负载测试、性能分析）证明其满足阈值。
  • 数据模型匹配。数据库架构与规格一致。无额外列，无缺失约束。
  • 范围外内容未被开发。再次检查“范围外内容”部分的任何内容是否不慎进入实现。

Integration with TDD Guide

与TDD指南的集成

Spec-driven workflow and TDD are complementary, not competing:
Spec-Driven Workflow          TDD (Red-Green-Refactor)
─────────────────────         ──────────────────────────
Phase 1: Gather Requirements
Phase 2: Write Spec
Phase 3: Validate Spec
Phase 4: Generate Tests  ──→  RED: Tests exist and fail
Phase 5: Implement       ──→  GREEN: Minimal code to pass
Phase 6: Self-Review     ──→  REFACTOR: Clean up internals
The handoff: Spec-driven workflow produces the test stubs (Phase 4). TDD takes over from there. The spec tells you WHAT to test. TDD tells you HOW to implement.
Use 
engineering-team/tdd-guide
for:
  • Red-green-refactor cycle discipline
  • Coverage analysis and gap detection
  • Framework-specific test patterns (Jest, Pytest, JUnit)
Use 
engineering/spec-driven-workflow
for:
  • Defining what to build before building it
  • Acceptance criteria authoring
  • Completeness validation
  • Scope control
规格驱动工作流与TDD相辅相成，而非相互竞争：
规格驱动工作流          TDD（红-绿-重构）
─────────────────────         ──────────────────────────
阶段1：收集需求
阶段2：撰写规格
阶段3：验证规格
阶段4：生成测试  ──→  红阶段：测试已存在且失败
阶段5：实现       ──→  绿阶段：用最少代码通过测试
阶段6：自我审核     ──→  重构阶段：清理内部代码
交接点： 规格驱动工作流生成测试桩（阶段4）。TDD从这里接手。规格告诉你要测试什么，TDD告诉你如何实现。
请使用
engineering-team/tdd-guide
获取：
  • 红-绿-重构循环规范
  • 覆盖率分析与差距检测
  • 框架特定测试模式（Jest、Pytest、JUnit）
请使用
engineering/spec-driven-workflow
获取：
  • 在开发前定义要构建的内容
  • 验收标准撰写
  • 完整性验证
  • 范围控制

Examples

示例

A complete worked example (Password Reset spec with extracted test cases) is available in spec_format_guide.md. It demonstrates all 9 sections, requirement numbering, acceptance criteria, edge cases, and the corresponding pytest stubs generated by 
test_extractor.py
.
完整的实战示例（包含提取测试用例的密码重置规格）可在spec_format_guide.md中查看。它展示了所有9个章节、需求编号、验收标准、边缘场景，以及由
test_extractor.py
生成的对应pytest桩代码。

Anti-Patterns

反模式

1. Coding Before Spec Approval

1. 规格获批前编码

Symptom: "I'll start coding while the spec is being reviewed." Problem: The review will surface changes. Now you have code that implements a rejected design. Rule: Implementation does not begin until spec status is "Approved."
症状： “我会在规格审核期间开始编码。” 问题： 审核会提出变更。现在你编写的代码实现的是已被否决的设计。 规则： 只有当规格状态为“已批准”时，才能开始实现。

2. Vague Acceptance Criteria

2. 模糊的验收标准

Symptom: "The system should work well" or "The UI should be responsive." Problem: Untestable. What does "well" mean? What does "responsive" mean? Rule: Every acceptance criterion must be verifiable by a machine. If you cannot write a test for it, rewrite the criterion.
症状： “系统应运行良好”或“UI应响应迅速。” 问题： 不可测试。“良好”是什么意思？“响应迅速”是什么意思？ 规则： 每项验收标准必须可被机器验证。如果你无法为其编写测试，就重写该标准。

3. Missing Edge Cases

3. 遗漏边缘场景

Symptom: Happy path is specified, error paths are not. Problem: Developers invent error handling on the fly, leading to inconsistent behavior. Rule: For every external dependency (API, database, file system, user input), specify at least one failure scenario.
症状： 仅指定了正常路径，未指定错误路径。 问题： 开发者会自行设计错误处理，导致行为不一致。 规则： 对于每个外部依赖（API、数据库、文件系统、用户输入），至少指定一个故障场景。

4. Spec as Post-Hoc Documentation

4. 规格作为事后文档

Symptom: "Let me write the spec now that the feature is done." Problem: This is documentation, not specification. It describes what was built, not what should have been built. It cannot catch design errors because the design is already frozen. Rule: If the spec was written after the code, it is not a spec. Relabel it as documentation.
症状： “功能完成后我再写规格。” 问题： 这是文档，不是规格。它描述的是已构建的内容，而非应该构建的内容。由于设计已固化，它无法发现设计错误。 规则： 如果规格是在代码完成后编写的，它就不是规格。将其重新标记为文档。

5. Gold-Plating Beyond Spec

5. 超出规格的镀金功能

Symptom: "While I was in there, I also added..." Problem: Untested code. Unreviewed design. Potential for subtle bugs in the "bonus" feature. Rule: If it is not in the spec, it does not get built. File a new spec for additional features.
症状： “我在开发时顺便添加了...” 问题： 未测试的代码。未审核的设计。“额外”功能可能存在潜在的细微bug。 规则： 不在规格中的内容不得开发。如需添加额外功能，请提交新的规格。

6. Acceptance Criteria Without Requirement Traceability

6. 无需求追溯的验收标准

Symptom: AC-7 exists but does not reference any FR-* or NFR-. Problem: Orphaned criteria mean either a requirement is missing or the criterion is unnecessary. Rule: Every AC- MUST reference at least one FR-* or NFR-*.
症状： AC-7存在，但未关联任何FR-或NFR-。 问题： 孤立的标准意味着要么遗漏了需求，要么该标准不必要。 规则： 每个AC-*必须至少关联一个FR-或NFR-。

7. Skipping Validation

7. 跳过验证

Symptom: "The spec looks fine, let's just start." Problem: Missing sections discovered during implementation cause blocking delays. Rule: Always run 
spec_validator.py --strict
before starting implementation. Fix all warnings.
症状： “规格看起来没问题，我们直接开始吧。” 问题： 实现期间发现缺失的章节会导致阻塞延迟。 规则： 开始实现前，务必运行
spec_validator.py --strict
。修复所有警告。

Cross-References

交叉引用

  • engineering-team/tdd-guide
     — Red-green-refactor cycle, test generation, coverage analysis. Use after Phase 4 of this workflow.
  • engineering/focused-fix
     — Deep-dive feature repair. When a spec-driven implementation has systemic issues, use focused-fix for diagnosis.
  • engineering/rag-architect
     — If the feature involves retrieval or knowledge systems, use rag-architect for the technical design within the spec.
  • references/spec_format_guide.md
     — Complete template with section-by-section explanations.
  • references/bounded_autonomy_rules.md
     — Full decision matrix for when to stop vs. continue.
  • references/acceptance_criteria_patterns.md
     — Pattern library for writing Given/When/Then criteria.
  • engineering-team/tdd-guide
     — 红-绿-重构循环、测试生成、覆盖率分析。在本工作流的阶段4后使用。
  • engineering/focused-fix
     — 深度修复功能。当规格驱动的实现存在系统性问题时，使用focused-fix进行诊断。
  • engineering/rag-architect
     — 如果功能涉及检索或知识系统，在规格中使用rag-architect进行技术设计。
  • references/spec_format_guide.md
     — 完整模板及各章节说明。
  • references/bounded_autonomy_rules.md
     — 停止/继续决策的完整矩阵。
  • references/acceptance_criteria_patterns.md
     — 撰写Given/When/Then标准的模式库。

Tools

工具

ScriptPurposeKey Flags
spec_generator.py
Generate spec template from feature name/description
--name
, 
--description
, 
--format
, 
--json
spec_validator.py
Validate spec completeness (0-100 score)
--file
, 
--strict
, 
--json
test_extractor.py
Extract test stubs from acceptance criteria
--file
, 
--framework
, 
--output
, 
--json
bash
undefined
脚本用途核心参数
spec_generator.py
根据功能名称/描述生成规格模板
--name
, 
--description
, 
--format
, 
--json
spec_validator.py
验证规格完整性（0-100分）
--file
, 
--strict
, 
--json
test_extractor.py
从验收标准中提取测试桩
--file
, 
--framework
, 
--output
, 
--json
bash
undefined

Generate a spec template

生成规格模板

python spec_generator.py --name "User Authentication" --description "OAuth 2.0 login flow"
python spec_generator.py --name "User Authentication" --description "OAuth 2.0 login flow"

Validate a spec

验证规格

python spec_validator.py --file specs/auth.md --strict
python spec_validator.py --file specs/auth.md --strict

Extract test cases

提取测试用例

python test_extractor.py --file specs/auth.md --framework pytest --output tests/test_auth.py
undefined
python test_extractor.py --file specs/auth.md --framework pytest --output tests/test_auth.py
undefined