メニュー
Write a PRD covering objectives, commands, structure, code style, testing, and boundaries before any code. Spec before code, always. Use when writeing a prd covering objectives, commands, structure, code style, testing,.
デフォルトでは、最初にソースを確認する Prompt が選択されています。直接コマンドに切り替えるか、ローカルコピーをダウンロードすることもできます。
インストールを決める前に、SKILL.md と SkillsMP に表示されている付属ファイルをお読みください。
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
直接コマンドでは確認用 Prompt が省略されます。実行前にソースを確認してください。
npx skills add https://github.com/oyi77/1ai-skills --skill spec-driven-developmentコマンドは1行のまま表示されます。コピー前に横へスクロールして全体を確認してください。
ローカルで確認しますか？SkillsMP が現在取得できるファイルをダウンロードできます。
Android and mobile application security testing — emulators, rooting, traffic interception, dynamic instrumentation. Use when testing mobile apps for vulnerabilities, reversing APKs, or bypassing security controls on Android.
Self-reflection + Self-criticism + Auto-learning from corrections + Self-organizing memory. Agent evaluates its own work, catches mistakes, and improves permanently. Use when working with self improving.
Plan and execute a comprehensive red team engagement covering reconnaissance through post-exploitation using MITRE ATT&CK-aligned TTPs to evaluate an organization's detection and response capabilities. Use when working with conducting full scope red team engagement.
SOC 職業分類に基づく
SKILL.md を表示中
| name | spec-driven-development |
| description | Write a PRD covering objectives, commands, structure, code style, testing, and boundaries before any code. Spec before code, always. Use when writeing a prd covering objectives, commands, structure, code style, testing,. |
| domain | development |
| author | oyi77 |
| license | Apache-2.0 |
| subdomain | software-development |
| tags | ["engineering","spec","prd","planning","requirements","design-doc"] |
| version | 1.0.0 |
Trigger phrases:
"spec driven development"
"Write a PRD covering objectives, commands, structure, code style, testing, and b"
When starting a new project, feature, or significant change
When the requirements are unclear or underspecified
When multiple people will work on the same feature
When you need to prevent scope creep during implementation
Spec-Driven Development (SDD) forces clarity before code. A spec is a living document that defines WHAT to build, WHY, and the acceptance criteria. It prevents the most common engineering failure: building the wrong thing fast.
| Rationalization | Reality |
|---|---|
| "I know what to build" | You know what you THINK the user wants. A spec forces validation. |
| "Specs slow me down" | Rework from unclear requirements costs 5-10x more than writing a spec |
| "I will document after" | You never do. Document before or accept technical debt. |
| "Agile means no specs" | Agile means iterating on specs, not skipping them. |
# Feature: [Name]
## Objective
What problem does this solve?
## User Stories
As a [role], I want [action] so that [benefit].
## Commands / API
- `command arg1 arg2` - Does X
- `POST /api/endpoint` - Creates Y
## Structure
- `src/module/file.ts` - Purpose
## Testing
- [ ] Unit: tests X
- [ ] Integration: tests Y
## Boundaries
- NOT doing: [explicit exclusions]
- Constraints: [performance, security]
## Acceptance Criteria
- [ ] Criterion 1
- [ ] Criterion 2