メニュー
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コマンドは1行のまま表示されます。コピー前に横へスクロールして全体を確認してください。
ローカルで確認しますか？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