メニュー
Product Requirements Document (PRD) writing workflow. Use when the user wants to define a new feature, product area, or user journey before writing specs. Trigger phrases: "write prd", "product requirements", "new feature brief", "define feature", "/write-prd".
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
SOC 職業分類に基づく
Patterns and conventions for the Android (Jetpack Compose + Kotlin) app. Use when implementing or reviewing any screen, composable, ViewModel, repository, or service. Trigger phrases: "android pattern", "jetpack compose", "new screen", "new composable", "viewmodel", "/android".
arXiv Atom/XML API integration patterns. Use when implementing or reviewing any code in data/remote/ArxivApiService.kt or any file that calls the arXiv API. Trigger phrases: "arxiv api", "fetch papers", "query arxiv", "/arxiv-api", or when editing ArxivApiService.kt.
Debugging workflow for the Android (Kotlin + Jetpack Compose) app. Use when tracking down runtime errors, unexpected behavior, network issues, or state problems. Trigger phrases: "debug", "não está funcionando", "erro em runtime", "por que isso falha", "breakpoint", "/debug".
Unit testing patterns and conventions using JUnit5 + MockK + Turbine. Use when writing, reviewing, or debugging unit tests in this project. Trigger phrases: "write test", "unit test", "test this viewmodel", "test this repository", "/unit-test".
MADR (Markdown Any Decision Records) workflow. Use when recording an architecture or significant technical decision. Trigger phrases: "new adr", "architecture decision", "record decision", "write adr", "/madr".
Spec-Driven Development workflow. Use when user asks to "create spec", "new spec", "approve spec", "implement spec", "/spec", or when starting work on any non-trivial change in a repository that uses docs/specs/. Enforces immutable numbering, status lifecycle (Draft → Approved → In Progress → Implemented → Deprecated), and index synchronization.
| name | write-prd |
| description | Product Requirements Document (PRD) writing workflow. Use when the user wants to define a new feature, product area, or user journey before writing specs. Trigger phrases: "write prd", "product requirements", "new feature brief", "define feature", "/write-prd". |
A PRD defines what and why — not how. It is the input to the spec
(/spec) and, when a significant architecture choice is involved, to an ADR (/madr).
ALWAYS load this skill when:
DO NOT use for:
/spec/madr# PRD: [Feature Name]
## Status
Draft | Review | Approved
## Problem statement
[1–3 sentences. What user pain or opportunity does this address?]
## Goals
- [ ] Goal 1
- [ ] Goal 2
## Non-goals
- Not in scope: X
- Not in scope: Y
## User stories
As a [persona], I want to [action] so that [benefit].
1. As a reader, I want to filter papers by category so that I only see relevant content.
2. ...
## Proposed solution
[High-level description. No implementation details. Wireframe link if available.]
## Success metrics
| Metric | Target |
|--------|--------|
| ... | ... |
## Open questions
- [ ] Question 1?
- [ ] Question 2?
## References
- Related spec: [docs/specs/NNNN-slug](../specs/NNNN-slug/spec.md)
- Related ADR: [docs/adrs/NNNN-slug](../adrs/NNNN-slug/adr.md)
/spec that references this PRDdocs/prds/ if the file is worth keeping; otherwise inline in the spec's context section| PRD | Spec |
|---|---|
| Defines what & why | Defines the contract (how to verify) |
| Written by product owner | Written by implementer |
| Prose + user stories | Requirements + ACs + contracts |
| No AC or implementation | Binary ACs, specific contracts |
| Input to specs | Output drives code |