菜单
Create or update .spec files in docs/features/ using the established format. Use when a feature needs to be documented before Gherkin scenarios are written.
默认使用会先检查来源的 Prompt；你也可以切换为直接命令，或下载本地副本。
决定是否安装前，请先阅读 SKILL.md，以及 SkillsMP 当前展示的配套文件。
基于 SOC 职业分类
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
直接命令不会经过审查 Prompt；运行前请先检查来源。
npx skills add https://github.com/dimanu-py/instant-python-metrics --skill spec命令会保持在同一行。复制前请横向滚动并检查完整内容。
想先保存到本地？可下载 SkillsMP 当前能够提供的文件。
正在显示 SKILL.md
Create or improve convention documentation based on the current conversation. Use this when a feature's learnings should be captured as reusable conventions.
Breaks down ANY work into 1-3 hour micro-steps with zero downtime. Use for large refactorings, technical improvements, debugging, research, migrations, or any work that feels too big or risky. Automatically applies expand-contract pattern for risky changes. Forces smallest safe increments for all work types. Use when: - Work feels too big or risky (refactoring, migrations, performance fixes) - Database schema changes, API changes, service replacements - User asks "how do I implement" after deciding what to build - Work will take more than 1 day Do NOT use when: - User is still deciding WHAT to build (use story_splitting or hamburger_method first) - Work is already small (< 3 hours) - User asks for architectural review (use complexity_review instead)
| name | spec |
| description | Create or update .spec files in docs/features/ using the established format. Use when a feature needs to be documented before Gherkin scenarios are written. |
Creates or updates .spec files inside docs/features/. A .spec captures a feature's purpose, behavior, contract, edge cases, and decisions before any code is written.
Every .spec document MUST include these sections in order:
# Feature Name
## Purpose
One sentence describing what the feature does.
## Behavior
Precise prose describing what the feature does: inputs, processing, and outputs. No implementation details.
## Contract
- **Inputs**: request shape (path params, query params, body schema)
- **Outputs**: response shape (status codes, body schema)
## Edge Cases
Enumerated list of edge cases and how the system handles each:
- Case one: description
- Case two: description
## Decisions
Each decision with its rationale and the discarded alternative.
- **Decision**: what was chosen
- **Rationale**: why
- **Alternative**: what was rejected and why
## Open Questions
Unresolved items (mark as resolved or remove when decided).
.spec per feature, named docs/features/<name>.spec