Requirements
- 1 installs
- Updated June 6, 2026
- ai-driven-school/aiki
requirements is a Claude Code skill that generates a requirements-definition document with user stories, acceptance criteria, and constraints from a feature name.
About
requirements is a Claude Code skill (documented in Japanese) that turns a feature name into a structured requirements document. A developer runs /requirements <feature> before implementation to produce user stories, acceptance criteria, non-functional requirements, constraints, and exclusions. It writes the result to docs/requirements/{feature}.md using a fixed template.
- Generates a requirements-definition document from a feature name
- Outputs user stories, testable acceptance criteria, and non-functional requirements
- Writes the spec to docs/requirements/{feature}.md before implementation
Requirements by the numbers
- 1 all-time installs (skills.sh)
- Ranked #2,476 of 3,282 Productivity & Planning skills by installs in the Skillselion catalog
- Data as of Jul 7, 2026 (Skillselion catalog sync)
requirements capabilities & compatibility
- Capabilities
- requirements generation · spec writing
- Use cases
- documentation · planning
What requirements says it does
Generate a requirements document with user stories, acceptance criteria, and constraints. Use when defining features, writing specs, or running /requirements before implementation.
以下の形式で `docs/requirements/{feature}.md` に出力:
npx skills add https://github.com/ai-driven-school/aiki --skill requirementsAdd your badge
Show developers this skill is listed on Skillselion. Paste this into your README.
| Installs | 1 |
|---|---|
| Last updated | June 6, 2026 |
| Repository | ai-driven-school/aiki ↗ |
What it does
Generate a structured requirements spec with user stories and acceptance criteria for a feature before building it.
Who is it for?
Writing a spec with testable acceptance criteria before starting implementation.
Skip if: Implementation, research, or generating code.
When should I use this skill?
When defining features, writing specs, or running /requirements before implementation.
What you get
A docs/requirements/{feature}.md file with stories, acceptance criteria, non-functional requirements, and exclusions.
- docs/requirements/{feature}.md spec document
By the numbers
- Template includes ~5 functional acceptance-criteria checkboxes plus UI/UX, data, and non-functional sections
Files
/requirements スキル
機能名から要件定義書を生成します。
使用方法
/requirements ユーザー認証
/requirements 商品検索機能
/requirements 決済システム出力テンプレート
以下の形式で docs/requirements/{feature}.md に出力:
# 要件定義: {機能名}
## 概要
{機能の概要を1-2文で説明}
## ユーザーストーリー
AS A {ユーザー種別}
I WANT TO {やりたいこと}
SO THAT {達成したい目的}
## 受入条件
### 機能要件
- [ ] {条件1: 具体的かつテスト可能な形式}
- [ ] {条件2}
- [ ] {条件3}
- [ ] {条件4}
- [ ] {条件5}
### UI/UX要件
- [ ] レスポンシブデザイン（モバイル対応）
- [ ] {UI要件1}
- [ ] {UI要件2}
### データ要件
- [ ] {データ要件1}
- [ ] {データ要件2}
## 非機能要件
| 項目 | 要件 |
|------|------|
| パフォーマンス | {具体的な数値目標} |
| セキュリティ | {セキュリティ要件} |
| アクセシビリティ | WCAG 2.1 AA準拠 |
## 制約事項
- フレームワーク: Next.js 14 (App Router)
- 言語: TypeScript
- スタイリング: Tailwind CSS
- 状態管理: React hooks / Zustand
- データベース: {DB種別}
## 除外事項
- {この機能に含まれないもの1}
- {この機能に含まれないもの2}
## 依存関係
- {依存する他の機能やシステム}
## 用語定義
| 用語 | 定義 |
|------|------|
| {用語1} | {定義} |
| {用語2} | {定義} |生成ガイドライン
1. 受入条件は具体的に: 「〜できる」ではなく「〜ボタンをクリックすると〜が表示される」 2. テスト可能な形式: 各条件はE2Eテストで検証可能な形式 3. 非機能要件は数値で: 「高速」ではなく「2秒以内」 4. 除外事項を明記: スコープクリープを防ぐ
出力例
> /requirements ユーザー認証
📝 要件定義を生成中... (Claude)
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
📄 docs/requirements/auth.md を作成しました
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
# 要件定義: ユーザー認証
## 概要
メールアドレスとパスワードによるユーザー認証機能を提供する。
## ユーザーストーリー
AS A 一般ユーザー
I WANT TO アカウントでログインしたい
SO THAT 自分のデータに安全にアクセスできる
## 受入条件
### 機能要件
- [ ] ログイン画面でメールとパスワードを入力できる
- [ ] ログインボタンをクリックすると認証が実行される
- [ ] 認証成功時、ダッシュボードにリダイレクトされる
- [ ] 認証失敗時、エラーメッセージが表示される
- [ ] ログアウトボタンでセッションが終了する
...
承認しますか？ [Y/n/reject 理由]Related skills
Grill MeHave an agent relentlessly pressure-test their plan or design until every decision branch is resolved and shared understanding is reached.691k196kGrill With DocsPressure-test architecture decisions against their live codebase and living documentation before writing production code.585k196k
Lark CalendarLet their coding agents read, create, and manage events inside Lark (Feishu) Calendar directly from natural language instructions.493kLark ImLet their coding agent send instant notifications, post updates, and receive commands directly inside Lark (Feishu) workspaces.493kLark ContactLet their AI coding agents read and write contacts, send messages, and manage user data inside Lark (Feishu).493kLark AttendanceAutomatically fetch and report daily attendance data from Lark (Feishu) into their own tools or agents.493kFAQ
Where does the requirements document get written?
To docs/requirements/{feature}.md using the skill's fixed template.
How should acceptance criteria be written?
Concretely and test-verifiably, e.g. 'clicking the button shows X', with non-functional targets given as numbers like 'within 2 seconds'.