create-ai-project 1.21.0 → 1.22.1
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/.claude/agents-en/code-reviewer.md +1 -0
- package/.claude/agents-en/document-reviewer.md +13 -0
- package/.claude/agents-en/technical-designer-frontend.md +36 -2
- package/.claude/agents-en/technical-designer.md +37 -2
- package/.claude/agents-ja/code-reviewer.md +1 -0
- package/.claude/agents-ja/document-reviewer.md +13 -0
- package/.claude/agents-ja/technical-designer-frontend.md +36 -2
- package/.claude/agents-ja/technical-designer.md +37 -2
- package/.claude/commands-en/project-inject.md +84 -56
- package/.claude/commands-ja/project-inject.md +84 -56
- package/.claude/skills-en/coding-standards/SKILL.md +1 -0
- package/.claude/skills-en/documentation-criteria/SKILL.md +1 -0
- package/.claude/skills-en/documentation-criteria/references/design-template.md +53 -0
- package/.claude/skills-en/project-context/SKILL.md +2 -15
- package/.claude/skills-en/project-context/references/external-resources-api.md +76 -0
- package/.claude/skills-en/project-context/references/external-resources-backend.md +76 -0
- package/.claude/skills-en/project-context/references/external-resources-frontend.md +74 -0
- package/.claude/skills-en/project-context/references/external-resources-infra.md +76 -0
- package/.claude/skills-en/project-context/references/template.md +154 -0
- package/.claude/skills-en/task-analyzer/references/skills-index.yaml +0 -5
- package/.claude/skills-ja/coding-standards/SKILL.md +1 -0
- package/.claude/skills-ja/documentation-criteria/SKILL.md +1 -0
- package/.claude/skills-ja/documentation-criteria/references/design-template.md +53 -0
- package/.claude/skills-ja/project-context/SKILL.md +2 -15
- package/.claude/skills-ja/project-context/references/external-resources-api.md +76 -0
- package/.claude/skills-ja/project-context/references/external-resources-backend.md +76 -0
- package/.claude/skills-ja/project-context/references/external-resources-frontend.md +74 -0
- package/.claude/skills-ja/project-context/references/external-resources-infra.md +76 -0
- package/.claude/skills-ja/project-context/references/template.md +154 -0
- package/.claude/skills-ja/task-analyzer/references/skills-index.yaml +0 -5
- package/CHANGELOG.md +25 -0
- package/CLAUDE.en.md +10 -1
- package/CLAUDE.ja.md +12 -3
- package/CLAUDE.md +12 -3
- package/package.json +1 -1
- package/scripts/check-skills-index.mjs +1 -2
|
@@ -0,0 +1,154 @@
|
|
|
1
|
+
# Project Context Section Catalog
|
|
2
|
+
|
|
3
|
+
This file is the section catalog used by `/project-inject`. Consumer agents load `SKILL.md` only; this file is loaded only during update operations.
|
|
4
|
+
|
|
5
|
+
## Section Index
|
|
6
|
+
|
|
7
|
+
| Section | Inclusion Rule | Source of Hearing Questions |
|
|
8
|
+
|---------|----------------|-----------------------------|
|
|
9
|
+
| Project Overview | Always include | This file (below) |
|
|
10
|
+
| Domain Constraints | Include when at least one rule changes AI decisions | This file (below) |
|
|
11
|
+
| Development Phase | Include when phase materially changes AI behavior (e.g., suppresses test scaffolding for prototype) | This file (below) |
|
|
12
|
+
| Directory Conventions | Include when non-obvious file placement rules exist | This file (below) |
|
|
13
|
+
| External Resources | Include when the project depends on resources outside the repository (design source, schema source, secret store, IaC source, etc.) | `external-resources-{frontend,backend,api,infra}.md` (load only the domains relevant to the project) |
|
|
14
|
+
|
|
15
|
+
## Section Definitions
|
|
16
|
+
|
|
17
|
+
### Project Overview
|
|
18
|
+
|
|
19
|
+
**Inclusion**: Always.
|
|
20
|
+
|
|
21
|
+
**Hearing**:
|
|
22
|
+
- AskUserQuestion 1: "What does this project do? (1–2 sentences)"
|
|
23
|
+
- AskUserQuestion 2: "What domain does it belong to?" with concrete option examples drawn from common categories (e.g., developer tooling, fintech, healthcare, e-commerce, internal platform). Always include "Other".
|
|
24
|
+
|
|
25
|
+
**Output structure**:
|
|
26
|
+
```markdown
|
|
27
|
+
## Project Overview
|
|
28
|
+
- **What this project does**: <one to two sentences>
|
|
29
|
+
- **Domain**: <domain>
|
|
30
|
+
```
|
|
31
|
+
|
|
32
|
+
### Domain Constraints
|
|
33
|
+
|
|
34
|
+
**Inclusion**: Include when at least one constraint, if ignored, would cause a bug or compliance failure.
|
|
35
|
+
|
|
36
|
+
**Hearing**:
|
|
37
|
+
- AskUserQuestion: "Are there domain-specific rules that AI must follow when making decisions in this project?" Options: "Yes, I will list them" / "No, no domain constraints apply".
|
|
38
|
+
- When "Yes": for each rule (cap at 3), capture the rule statement plus a measurable check. Accept statements only when they evaluate as pass/fail; reframe subjective phrasings into measurable form (e.g., turn "be careful with PII" into "log output uses anonymized patient IDs").
|
|
39
|
+
- Adapt example phrasings to the domain captured in Project Overview (e.g., for fintech: "every monetary mutation appends an audit log entry"; for developer tooling: "generated code keeps lockfile commands invocable").
|
|
40
|
+
|
|
41
|
+
**Output structure** (omit the section entirely when zero constraints):
|
|
42
|
+
```markdown
|
|
43
|
+
## Domain Constraints
|
|
44
|
+
1. <measurable rule 1>
|
|
45
|
+
2. <measurable rule 2>
|
|
46
|
+
3. <measurable rule 3>
|
|
47
|
+
```
|
|
48
|
+
|
|
49
|
+
### Development Phase
|
|
50
|
+
|
|
51
|
+
**Inclusion**: Include when phase materially changes AI behavior. Skip when behavior is identical across phases.
|
|
52
|
+
|
|
53
|
+
**Hearing**:
|
|
54
|
+
- AskUserQuestion: "Which phase is this project in?" Options: "Prototype", "Production", "In operation", "No meaningful difference between phases".
|
|
55
|
+
- When "No meaningful difference": omit the section.
|
|
56
|
+
|
|
57
|
+
**Output structure**:
|
|
58
|
+
```markdown
|
|
59
|
+
## Development Phase
|
|
60
|
+
- **Phase**: <Prototype | Production | In operation>
|
|
61
|
+
```
|
|
62
|
+
|
|
63
|
+
### Directory Conventions
|
|
64
|
+
|
|
65
|
+
**Inclusion**: Include when at least one file placement rule is non-obvious from the repository structure (i.e., a contributor reading the tree would guess wrong).
|
|
66
|
+
|
|
67
|
+
**Hearing**:
|
|
68
|
+
- AskUserQuestion: "Are there file placement rules that AI should follow?" Options: "Yes" / "No".
|
|
69
|
+
- When "Yes": capture each rule as a single line stating the trigger and the destination (e.g., "Temporary working files: place under `./tmp/` and remove on completion").
|
|
70
|
+
|
|
71
|
+
**Output structure** (omit the section entirely when zero rules):
|
|
72
|
+
```markdown
|
|
73
|
+
## Directory Conventions
|
|
74
|
+
- <rule 1>
|
|
75
|
+
- <rule 2>
|
|
76
|
+
```
|
|
77
|
+
|
|
78
|
+
### External Resources
|
|
79
|
+
|
|
80
|
+
**Inclusion**: Include the section when at least one selected domain has a present axis OR a non-empty self-declaration. Otherwise omit the section.
|
|
81
|
+
|
|
82
|
+
**Hearing routing**:
|
|
83
|
+
- AskUserQuestion: "Which external-resource domains apply to this project?" Multi-select options:
|
|
84
|
+
- Frontend (design source, design system, guidelines, visual verification environment)
|
|
85
|
+
- Backend (database schema, migration history, secret store, background jobs)
|
|
86
|
+
- API contract (schema source, mocks, authentication, schema change process)
|
|
87
|
+
- Infrastructure (IaC source, environment configuration, infrastructure secrets, deployment trigger)
|
|
88
|
+
- None apply
|
|
89
|
+
- For each selected domain, load the matching reference file using the slug map below and run its hearing protocol.
|
|
90
|
+
|
|
91
|
+
**Domain to file slug mapping**:
|
|
92
|
+
| Domain (user-facing label) | Reference file |
|
|
93
|
+
|---------------------------|----------------|
|
|
94
|
+
| Frontend | `external-resources-frontend.md` |
|
|
95
|
+
| Backend | `external-resources-backend.md` |
|
|
96
|
+
| API contract | `external-resources-api.md` |
|
|
97
|
+
| Infrastructure | `external-resources-infra.md` |
|
|
98
|
+
|
|
99
|
+
**Hearing protocol** (per domain reference): each reference defines structured axes plus a self-declaration phase. The structured phase asks one AskUserQuestion per axis, offering "Not applicable" as one explicit choice. The self-declaration phase always runs once, asking for free-form additions, regardless of how the structured choices landed.
|
|
100
|
+
|
|
101
|
+
**Per-axis output schema** (3 fields):
|
|
102
|
+
```markdown
|
|
103
|
+
#### <Axis name>
|
|
104
|
+
- Source type: <verbatim text of the AskUserQuestion choice the user selected>
|
|
105
|
+
- Location: <URL | file path | service or package name>
|
|
106
|
+
- Access method: <WebFetch | file read | MCP server name | CLI command | manual procedure>
|
|
107
|
+
```
|
|
108
|
+
|
|
109
|
+
**Axis output rules**:
|
|
110
|
+
|
|
111
|
+
1. **Axis output is conditional on whether the schema can be filled.** Render the axis block when the user's choice points to an external resource with identifiable **Location** and **Access method** values. The following choices produce zero output lines for that axis:
|
|
112
|
+
- Listed absence-declaring choices: "Not applicable", "No <resource>", "No <resource> required", "No documented <resource>", "Ad-hoc <resource>", "Manual <process> (no <resource>)".
|
|
113
|
+
- Any other choice whose Location and Access method values resolve to blank.
|
|
114
|
+
|
|
115
|
+
2. **Multiple instances within one axis** (e.g., primary and analytics databases, separate guideline files for CSS and accessibility) — repeat the axis block with a disambiguating suffix:
|
|
116
|
+
```markdown
|
|
117
|
+
#### Database Schema Source — Primary
|
|
118
|
+
- Source type: Schema file in the repository
|
|
119
|
+
- Location: prisma/schema.prisma
|
|
120
|
+
- Access method: file read
|
|
121
|
+
|
|
122
|
+
#### Database Schema Source — Analytics
|
|
123
|
+
- Source type: Database MCP server that introspects a live database
|
|
124
|
+
- Location: bigquery-prod
|
|
125
|
+
- Access method: MCP server `bigquery`
|
|
126
|
+
```
|
|
127
|
+
|
|
128
|
+
3. **Cross-axis reference** (e.g., the same secret store appears under both Backend and Infrastructure) — the first occurrence carries the canonical fields; the second occurrence renders as a reference back to it:
|
|
129
|
+
```markdown
|
|
130
|
+
#### Secrets in Infrastructure
|
|
131
|
+
- Source type: Secrets sourced from a secret manager via IaC data lookup
|
|
132
|
+
- Reference: same store as Backend > Secret Store
|
|
133
|
+
- Access method: <inherited; record only differences if any>
|
|
134
|
+
```
|
|
135
|
+
|
|
136
|
+
**Domain block layout**:
|
|
137
|
+
```markdown
|
|
138
|
+
### <Domain>
|
|
139
|
+
|
|
140
|
+
<axis blocks in catalog order, each rendered per the rules above>
|
|
141
|
+
|
|
142
|
+
#### Additional Resources
|
|
143
|
+
|
|
144
|
+
<rendered only when self-declaration captured items; placed after the last present axis within the same domain>
|
|
145
|
+
- <free-form description from user>
|
|
146
|
+
```
|
|
147
|
+
|
|
148
|
+
## Output Assembly Rules
|
|
149
|
+
|
|
150
|
+
After hearing completes, the calling command (`/project-inject`) assembles the configured `SKILL.md` per the order it specifies. This file owns the per-section content shape (above) and these cross-section rules:
|
|
151
|
+
|
|
152
|
+
1. Sections marked for omission produce zero output lines. The rebuilt body advances directly to the next included section.
|
|
153
|
+
2. Domain blocks within External Resources appear in catalog order (Frontend → Backend → API contract → Infrastructure), regardless of the order in which the user selected them during hearing.
|
|
154
|
+
3. The Vagueness rejection rule (defined in `/project-inject` Step 3) is a hearing-time filter applied to every `add` and `update` section. The captured rules that pass the filter are written through normal section output; the filter contributes zero output lines of its own.
|
|
@@ -95,11 +95,6 @@ skills:
|
|
|
95
95
|
size: small
|
|
96
96
|
key-references:
|
|
97
97
|
- "Project-specific (empirical)"
|
|
98
|
-
sections:
|
|
99
|
-
- "Project Overview"
|
|
100
|
-
- "Domain Constraints"
|
|
101
|
-
- "Development Phase"
|
|
102
|
-
- "Directory Conventions"
|
|
103
98
|
|
|
104
99
|
documentation-criteria:
|
|
105
100
|
skill: "documentation-criteria"
|
|
@@ -29,6 +29,7 @@ description: コードの品質問題、アンチパターン、可読性を検
|
|
|
29
29
|
|
|
30
30
|
- **積極的なリファクタリング** - 技術的負債を防ぎ、健全性を維持
|
|
31
31
|
- **使われない「念のため」のコード禁止** - YAGNI原則(Kent Beck)に反する
|
|
32
|
+
- **Minimum Surface for Required Coverage** - 保守対象の要素(永続状態、公開コントラクト要素または境界を越えるフィールド/Props、振る舞いモード/フラグ/バリアント、再利用可能な抽象、コンポーネント分割)を導入する場合、現在のユーザー観察可能な要件と受容済み技術制約(監査、データ整合性、互換性、セキュリティ、パフォーマンス、アクセシビリティ)をカバーする最小の設計面を選ぶ。採用の正当化は「より小さい代替案では満たせない現要件・制約を名指す」形で行い、価値ベースの議論(再利用可能、将来対応、実装が楽)はタイブレーカーのみに用いる。YAGNI との違い: YAGNI は時間軸の判断(将来のためだけの作業はしない)、本原則は固定されたカバレッジ点での設計面を制約する。
|
|
32
33
|
|
|
33
34
|
## コメント記述ルール
|
|
34
35
|
|
|
@@ -120,6 +120,7 @@ description: PRD、ADR、Design Doc、UI Spec、作業計画書の作成を支
|
|
|
120
120
|
- **コード調査エビデンス**(調査時に確認したファイル/関数)
|
|
121
121
|
- **フィールド伝播マップ**(フィールドがコンポーネント境界を越える場合)
|
|
122
122
|
- **データ構造の採用判断**(新規構造導入時)
|
|
123
|
+
- **Minimal Surface Alternatives**(永続状態、公開コントラクト要素または境界を越えるフィールド、振る舞いモード/フラグ、再利用可能な抽象/コンポーネント分割を導入する場合 — design-template.md の5ステップ出力フォーマットを参照)
|
|
123
124
|
- **適用基準**(explicit/implicit分類)
|
|
124
125
|
- **前提となるADR**(共通ADR含む)
|
|
125
126
|
- **検証戦略**(必須)
|
|
@@ -185,6 +185,49 @@ unknowns:
|
|
|
185
185
|
|
|
186
186
|
**判断**: [再利用 / 拡張 / 新規] — [根拠]
|
|
187
187
|
|
|
188
|
+
### Minimal Surface Alternatives(保守対象の要素を導入する場合)
|
|
189
|
+
|
|
190
|
+
新規に導入する適用対象要素(永続状態 / 公開コントラクト要素または境界を越えるフィールド・Props / 振る舞いモード・フラグ・バリアント / 再利用可能な抽象またはコンポーネント分割)ごとに1エントリ。設計者エージェントが実行した5ステップの結果を記録する。参照: `coding-standards` スキル「Minimum Surface for Required Coverage」。
|
|
191
|
+
|
|
192
|
+
#### Element 1: [新規要素の名前]
|
|
193
|
+
|
|
194
|
+
**ステップ1 — 確定要件**
|
|
195
|
+
- [AC 参照 — AC ID、AC見出し、EARS節、または制約ID]: [要件・制約の文言]
|
|
196
|
+
- [AC 参照]: [要件・制約の文言]
|
|
197
|
+
|
|
198
|
+
参照先は Design Doc、参照 PRD、参照 UI Spec のいずれでもよい。
|
|
199
|
+
|
|
200
|
+
**ステップ2〜3 — 比較した代替案**
|
|
201
|
+
|
|
202
|
+
下記の列名は設計コンテキストに合わせて適用する。バックエンド Design Doc では「モジュール/サービス境界を越えるか」「新規の概念 / モード / フラグ」を使用、フロントエンド Design Doc では「コンポーネント境界を越えるか」「新規の Props / モード / バリアント」を使用(永続状態列には「クライアントまたはサーバー」の修飾を加える)。
|
|
203
|
+
|
|
204
|
+
| 代替案 | カバーする現要件(AC 参照) | 新規の永続状態(件数) | 新規の概念 / モード / フラグ / Props / バリアント(件数) | モジュール/サービスまたはコンポーネント境界を越えるか(はい/いいえ) | 破壊的変更または移行が必要か(はい/いいえ) | 主観的コストノート |
|
|
205
|
+
|---|---|---|---|---|---|---|
|
|
206
|
+
| [提案された追加要素そのもの] | | | | | | |
|
|
207
|
+
| [削減的代替案 — 既存から導出 / オンデマンド計算 / 呼び出し側に留める / 既存を再利用 / 新規状態を導入しない] | | | | | | |
|
|
208
|
+
| [任意の第3案] | | | | | | |
|
|
209
|
+
|
|
210
|
+
主観的コストノートに記載できる内容: 保守性の懸念、命名の分かりやすさ、体感的な実装労力、将来対応への期待、その他の判断レベルのコメント。
|
|
211
|
+
|
|
212
|
+
**「最小」選定のための解決優先順位**(左の列が同点のとき右の列でタイブレーク):
|
|
213
|
+
1. 新規の永続状態の件数(少ない=小さい)
|
|
214
|
+
2. モジュール/サービスまたはコンポーネント境界を越えるか(いいえ=小さい)
|
|
215
|
+
3. 新規の概念 / モード / フラグ / Props / バリアントの件数(少ない=小さい)
|
|
216
|
+
4. 破壊的変更または移行の要否(いいえ=小さい)
|
|
217
|
+
5. 主観的コストノート
|
|
218
|
+
|
|
219
|
+
**ステップ4 — 選定した代替案と根拠**
|
|
220
|
+
- **選定**: [代替案の名前]
|
|
221
|
+
- **根拠**:
|
|
222
|
+
- 選定が検討した中で最小の代替案である場合: 「検討した中で最小の代替案であり、これ以上の縮減余地なし」と記載
|
|
223
|
+
- 選定が最小でない場合: ステップ1から、より小さい代替案では満たせない現要件を名指す
|
|
224
|
+
|
|
225
|
+
**ステップ5 — 不採用案の記録**
|
|
226
|
+
- [代替案の名前]: [何だったか・なぜ不採用かを1〜2行]
|
|
227
|
+
- [代替案の名前]: [何だったか・なぜ不採用かを1〜2行]
|
|
228
|
+
|
|
229
|
+
新規に導入する各適用対象要素について上記のエレメントブロックを繰り返す。適用対象要素を導入しない場合は、本セクション全体を簡潔な理由とともに N/A とする。
|
|
230
|
+
|
|
188
231
|
### 型定義
|
|
189
232
|
|
|
190
233
|
```typescript
|
|
@@ -357,6 +400,16 @@ unknowns:
|
|
|
357
400
|
- **デメリット**: [欠点]
|
|
358
401
|
- **不採用理由**: [採用しなかった理由]
|
|
359
402
|
|
|
403
|
+
## 将来の拡張性
|
|
404
|
+
|
|
405
|
+
本セクションは現在の設計面から**除外した**機能・能力を記録する。エントリは現要件、現在のコンシューマー、または記録された制約に結び付くものに限定し、純粋な将来構想は別途の提案ドキュメントに送る。
|
|
406
|
+
|
|
407
|
+
「Minimal Surface Alternatives → ステップ5(不採用案)」との区別: ステップ5 は単一の適用対象要素内で比較・棄却した要素レベルの代替案を記録する。本セクションは個別の要素に結び付かない、より粒度の大きな能力レベルの項目(検討したが今回の設計面に含めなかった機能や能力)を記録する。
|
|
408
|
+
|
|
409
|
+
- **先送りした機能・能力**: [設計時に検討したが現在の設計面から明示的に除外した機能・能力。各エントリには、これが満たしたはずの現要件を名指して記載する]
|
|
410
|
+
- **意図的な限定**: [意図的に小さく抑えた範囲とその理由]
|
|
411
|
+
- **拡張ポイント(既存・現在のコンシューマーあり)**: [現在のコンシューマーがすでに利用している既存のインターフェースやフック。各エントリには現在のコンシューマーを名指して記載する]
|
|
412
|
+
|
|
360
413
|
## リスクと対策
|
|
361
414
|
|
|
362
415
|
| リスク | 影響度 | 発生確率 | 対策 |
|
|
@@ -1,21 +1,8 @@
|
|
|
1
1
|
---
|
|
2
2
|
name: project-context
|
|
3
|
-
description: AI
|
|
3
|
+
description: AIの実行精度に必要なプロジェクト固有の前提情報を提供 — ドメイン制約、開発フェーズ、ディレクトリ規約、外部リソースのアクセス方法。セッション開始時、プロジェクト構成確認時、またはタスクがドメインルールやリポジトリ外の外部リソースを参照する時に使用。
|
|
4
4
|
---
|
|
5
5
|
|
|
6
6
|
# プロジェクトコンテキスト
|
|
7
7
|
|
|
8
|
-
|
|
9
|
-
|
|
10
|
-
## プロジェクト概要
|
|
11
|
-
- **このプロジェクトが何をするか**: (要設定)
|
|
12
|
-
- **ドメイン**: (要設定)
|
|
13
|
-
|
|
14
|
-
## ドメイン制約
|
|
15
|
-
(AIの判断に影響するドメイン固有のルール)
|
|
16
|
-
|
|
17
|
-
## 開発フェーズ
|
|
18
|
-
- **フェーズ**: (プロトタイプ / 本番開発 / 運用中)
|
|
19
|
-
|
|
20
|
-
## ディレクトリ規約
|
|
21
|
-
(ファイル配置ルールがあれば記載)
|
|
8
|
+
`/project-inject` を実行してこのスキルを設定する。
|
|
@@ -0,0 +1,76 @@
|
|
|
1
|
+
# APIコントラクト外部リソース軸
|
|
2
|
+
|
|
3
|
+
API コントラクト設計、クライアント統合、サーバーエンドポイント実装に関する作業向けのヒアリング軸。`/project-inject` はユーザーが API ドメインを選択したときにこのファイルを読み込む。
|
|
4
|
+
|
|
5
|
+
## Axis 1: API スキーマソース
|
|
6
|
+
|
|
7
|
+
API コントラクト(リクエスト/レスポンス形状、エンドポイント、RPC メソッド)の正本となる取得元。
|
|
8
|
+
|
|
9
|
+
**AskUserQuestion 選択肢**:
|
|
10
|
+
- OpenAPI / Swagger 仕様(リポジトリ内ファイルまたはホストされた URL)
|
|
11
|
+
- Protobuf 定義(リポジトリ内ファイル)
|
|
12
|
+
- GraphQL スキーマ(SDL ファイルまたはイントロスペクションエンドポイント)
|
|
13
|
+
- リポジトリ内のコードファースト契約定義(例: クライアントとサーバー間で共有される TypeScript 型)
|
|
14
|
+
- アドホックな JSON(正式なコントラクトなし)
|
|
15
|
+
- 該当なし
|
|
16
|
+
|
|
17
|
+
**フォローアップ(軸が該当する場合)**: 2 つのフィールドを収集する:
|
|
18
|
+
- **場所**: ファイルパスまたは URL。
|
|
19
|
+
- **アクセス方法**: ファイル読み込みまたは WebFetch。
|
|
20
|
+
|
|
21
|
+
複数のコントラクトが併存する場合(公開 API、内部サービス等)、`template.md` の複数インスタンスルールに従ってコントラクトの用途を識別接尾辞として各エントリを収集する。
|
|
22
|
+
|
|
23
|
+
## Axis 2: モック環境
|
|
24
|
+
|
|
25
|
+
ライブサーバーから独立した状態でクライアントが API を実行する手段。
|
|
26
|
+
|
|
27
|
+
**AskUserQuestion 選択肢**:
|
|
28
|
+
- スキーマから生成されたモック(例: OpenAPI / Protobuf ツールチェーンから)
|
|
29
|
+
- リポジトリ内の手書きモックサーバー
|
|
30
|
+
- ホスト型モックサービス(URL)
|
|
31
|
+
- ライブ開発サーバー(独立したモックなし)
|
|
32
|
+
- 該当なし
|
|
33
|
+
|
|
34
|
+
**フォローアップ(軸が該当する場合)**: 2 つのフィールドを収集する:
|
|
35
|
+
- **場所**: モックの URL またはリポジトリパス。
|
|
36
|
+
- **アクセス方法**: CLI コマンド、WebFetch、または生成ステップ名。スキーマ変更時にモックが自動更新されるかも記録する(例: `commit 時に openapi.yaml から再生成`)。
|
|
37
|
+
|
|
38
|
+
## Axis 3: 認証方式
|
|
39
|
+
|
|
40
|
+
API がリクエストをどのように認証・認可するか。
|
|
41
|
+
|
|
42
|
+
**AskUserQuestion 選択肢**:
|
|
43
|
+
- 認証サービスが発行する Bearer トークン(例: JWT)
|
|
44
|
+
- ヘッダーまたはクエリパラメータの API キー
|
|
45
|
+
- 別途のログインフローで設定されるセッション Cookie
|
|
46
|
+
- 相互 TLS
|
|
47
|
+
- 認証なし
|
|
48
|
+
- 該当なし
|
|
49
|
+
|
|
50
|
+
**フォローアップ(軸が該当する場合)**: 2 つのフィールドを収集する:
|
|
51
|
+
- **場所**: 開発・テスト用の認証情報を取得する認証サービス URL、環境変数名、またはフィクスチャファイルパス。
|
|
52
|
+
- **アクセス方法**: SDK 呼び出し、CLI コマンド、またはファイル読み込み。
|
|
53
|
+
|
|
54
|
+
同一のシークレットがバックエンドのシークレットストアに格納されている場合、この軸は `template.md` で定義される軸間参照記法でそのストアへの参照として出力する。
|
|
55
|
+
|
|
56
|
+
## Axis 4: スキーマ変更プロセス
|
|
57
|
+
|
|
58
|
+
破壊的変更と非破壊的変更がどのようにレビュー・展開されるか。
|
|
59
|
+
|
|
60
|
+
**AskUserQuestion 選択肢**:
|
|
61
|
+
- 文書化されたコントラクトレビュープロセス(ドキュメントへのリンク)
|
|
62
|
+
- バージョン分けされたエンドポイント(例: `/v1/`、`/v2/`)
|
|
63
|
+
- 後方互換のある変更のみ、正式なバージョニングなし
|
|
64
|
+
- 該当なし
|
|
65
|
+
|
|
66
|
+
**フォローアップ(軸が該当する場合)**: 2 つのフィールドを収集する:
|
|
67
|
+
- **場所**: ドキュメントパスまたは URL。
|
|
68
|
+
- **アクセス方法**: ファイル読み込み、WebFetch、またはバージョン交渉ルールの記述(例: `破壊的変更には新しい /vN/ パスが必要`)。
|
|
69
|
+
|
|
70
|
+
## 自己申告フェーズ
|
|
71
|
+
|
|
72
|
+
4 つの構造化軸の後、1 回だけ尋ねる: 「構造化された質問の範囲を超えて、このプロジェクトが依存する API 外部リソースは何か? 該当する項目を次のメッセージで列挙、または 'none' と返答する。」
|
|
73
|
+
|
|
74
|
+
自由記述の回答は API ブロックの「追加リソース」サブセクションに収集する。このフェーズは構造化軸が全て「該当なし」となった場合でも実行する。
|
|
75
|
+
|
|
76
|
+
自己申告でのみ表面化するリソースの例: レートリミット設定、API 前段のゲートウェイ / プロキシ、コントラクトテストスイート(例: Pact ブローカー URL)、API ゲートウェイの管理コンソール、設計時に参照したサードパーティ API ドキュメント。
|
|
@@ -0,0 +1,76 @@
|
|
|
1
|
+
# バックエンド外部リソース軸
|
|
2
|
+
|
|
3
|
+
サーバーサイド、データ、ストレージに関する作業向けのヒアリング軸。`/project-inject` はユーザーがバックエンドドメインを選択したときにこのファイルを読み込む。
|
|
4
|
+
|
|
5
|
+
## Axis 1: データベーススキーマソース
|
|
6
|
+
|
|
7
|
+
データベーススキーマ(テーブル、カラム、インデックス、制約)の正本となる取得元。
|
|
8
|
+
|
|
9
|
+
**AskUserQuestion 選択肢**:
|
|
10
|
+
- リポジトリ内のマイグレーションファイル(例: `migrations/` ディレクトリ)
|
|
11
|
+
- リポジトリ内のスキーマファイル(例: `schema.sql`、`prisma/schema.prisma`)
|
|
12
|
+
- ライブ DB を introspect する DB MCP サーバー
|
|
13
|
+
- 外部のスキーマレジストリ(URL またはホスト型カタログ)
|
|
14
|
+
- 永続データベースなし
|
|
15
|
+
- 該当なし
|
|
16
|
+
|
|
17
|
+
**フォローアップ(軸が該当する場合)**: 2 つのフィールドを収集する:
|
|
18
|
+
- **場所**: ファイルパス、URL、または MCP の対象識別子。
|
|
19
|
+
- **アクセス方法**: ファイル読み込み、WebFetch、または MCP サーバー名。
|
|
20
|
+
|
|
21
|
+
複数の DB が併存する場合(primary、analytics、cache 等)、`template.md` の複数インスタンスルールに従って DB 用途を識別接尾辞として各エントリを収集する。
|
|
22
|
+
|
|
23
|
+
## Axis 2: マイグレーション履歴
|
|
24
|
+
|
|
25
|
+
スキーマ変更が時系列でどのように追跡されるか。
|
|
26
|
+
|
|
27
|
+
**AskUserQuestion 選択肢**:
|
|
28
|
+
- リポジトリ内のバージョン管理されたマイグレーションファイル
|
|
29
|
+
- ORM 管理のマイグレーションツール(例: Alembic、Flyway、Prisma Migrate)
|
|
30
|
+
- 手動の変更ログドキュメント
|
|
31
|
+
- マイグレーション追跡なし
|
|
32
|
+
- 該当なし
|
|
33
|
+
|
|
34
|
+
**フォローアップ(軸が該当する場合)**: 2 つのフィールドを収集する:
|
|
35
|
+
- **場所**: ディレクトリパスまたはマイグレーションツール名。
|
|
36
|
+
- **アクセス方法**: 手動実行の CLI コマンド、または自動適用される場合の CI ステップ名 / デプロイフック名。
|
|
37
|
+
|
|
38
|
+
## Axis 3: シークレットストア
|
|
39
|
+
|
|
40
|
+
認証情報、API キー、その他のシークレットの保存・アクセス先。
|
|
41
|
+
|
|
42
|
+
**AskUserQuestion 選択肢**:
|
|
43
|
+
- シークレットマネージャーサービス(例: AWS Secrets Manager、Vault、GCP Secret Manager)
|
|
44
|
+
- `.env` ファイルから読み込む環境変数(開発環境のみ)
|
|
45
|
+
- リポジトリ内の暗号化されたファイル
|
|
46
|
+
- シークレットは不要
|
|
47
|
+
- 該当なし
|
|
48
|
+
|
|
49
|
+
**フォローアップ(軸が該当する場合)**: 2 つのフィールドを収集する:
|
|
50
|
+
- **場所**: シークレットマネージャーのサービス名または MCP の対象。
|
|
51
|
+
- **アクセス方法**: シークレットを読むための MCP サーバー名、CLI コマンド、または SDK 呼び出し。
|
|
52
|
+
|
|
53
|
+
実際のシークレット値はストア内に存在し、ランタイムでそこから読み出す。収集対象は到達手段のみとする。
|
|
54
|
+
|
|
55
|
+
## Axis 4: バックグラウンドジョブ基盤
|
|
56
|
+
|
|
57
|
+
非同期処理がどのようにディスパッチ・観測されるか。
|
|
58
|
+
|
|
59
|
+
**AskUserQuestion 選択肢**:
|
|
60
|
+
- キューサービス(例: SQS、Pub/Sub、RabbitMQ)
|
|
61
|
+
- デプロイプラットフォームが管理する cron / スケジュールタスク
|
|
62
|
+
- プロセス内ワーカースレッド
|
|
63
|
+
- バックグラウンド処理なし
|
|
64
|
+
- 該当なし
|
|
65
|
+
|
|
66
|
+
**フォローアップ(軸が該当する場合)**: 2 つのフィールドを収集する:
|
|
67
|
+
- **場所**: キュー名またはスケジューラー識別子。
|
|
68
|
+
- **アクセス方法**: enqueue コマンド、ジョブ確認コマンド、またはプラットフォームのコンソール URL。
|
|
69
|
+
|
|
70
|
+
## 自己申告フェーズ
|
|
71
|
+
|
|
72
|
+
4 つの構造化軸の後、1 回だけ尋ねる: 「構造化された質問の範囲を超えて、このプロジェクトが依存するバックエンド外部リソースは何か? 該当する項目を次のメッセージで列挙、または 'none' と返答する。」
|
|
73
|
+
|
|
74
|
+
自由記述の回答はバックエンドブロックの「追加リソース」サブセクションに収集する。このフェーズは構造化軸が全て「該当なし」となった場合でも実行する。
|
|
75
|
+
|
|
76
|
+
自己申告でのみ表面化するリソースの例: サードパーティ SaaS API(決済、メール、検索インデックス)、分散キャッシュサービス(Redis、Memcached)、オブジェクトストレージ(S3、GCS)、サーバー側で消費されるフィーチャーフラグサービス、可観測性プラットフォーム(ログ、トレース、メトリクス)。
|
|
@@ -0,0 +1,74 @@
|
|
|
1
|
+
# フロントエンド外部リソース軸
|
|
2
|
+
|
|
3
|
+
フロントエンド作業(コンポーネント実装、画面設計、表示調整、デザインシステム移行)向けのヒアリング軸。`/project-inject` はユーザーがフロントエンドドメインを選択したときにこのファイルを読み込む。
|
|
4
|
+
|
|
5
|
+
## Axis 1: デザインソース
|
|
6
|
+
|
|
7
|
+
ビジュアル仕様の正本となる取得元。
|
|
8
|
+
|
|
9
|
+
**AskUserQuestion 選択肢**:
|
|
10
|
+
- デザインツール(ホスト型のデザインプラットフォーム)
|
|
11
|
+
- リポジトリ内の仕様ファイル(例: `DESIGN.md`、`docs/design/...`)
|
|
12
|
+
- 公開ドキュメントの URL
|
|
13
|
+
- 既存実装のみ(独立したデザインソースなし)
|
|
14
|
+
- 該当なし
|
|
15
|
+
|
|
16
|
+
**フォローアップ(軸が該当する場合)**: 2 つのフィールドを収集する(ソースタイプは上記の選択肢から自動取得):
|
|
17
|
+
- **場所**: 公開 URL、リポジトリ内ファイルパス、または MCP の対象識別子。
|
|
18
|
+
- **アクセス方法**: WebFetch、ファイル読み込み、MCP サーバー名、または手動スクリーンショット手順。
|
|
19
|
+
|
|
20
|
+
## Axis 2: デザインシステム
|
|
21
|
+
|
|
22
|
+
再利用可能なコンポーネントライブラリとデザイントークン。
|
|
23
|
+
|
|
24
|
+
**AskUserQuestion 選択肢**:
|
|
25
|
+
- MCP サーバー経由でアクセスするコンポーネントライブラリ
|
|
26
|
+
- ドキュメント URL を持つコンポーネントライブラリ
|
|
27
|
+
- Storybook 等価のコンポーネントカタログ
|
|
28
|
+
- チーム内ドキュメントのみを持つ社内パッケージ
|
|
29
|
+
- デザインシステムなし(アドホックなコンポーネント)
|
|
30
|
+
- 該当なし
|
|
31
|
+
|
|
32
|
+
**フォローアップ(軸が該当する場合)**: 2 つのフィールドを収集する:
|
|
33
|
+
- **場所**: Storybook URL、パッケージ名、または社内ドキュメントのパス。
|
|
34
|
+
- **アクセス方法**: WebFetch、ファイル読み込み、または MCP サーバー名。
|
|
35
|
+
|
|
36
|
+
## Axis 3: ガイドライン
|
|
37
|
+
|
|
38
|
+
UI 作業向けの利用ガイド、アクセシビリティルール、アンチパターン、命名規約。
|
|
39
|
+
|
|
40
|
+
**AskUserQuestion 選択肢**:
|
|
41
|
+
- プロジェクト層のガイドラインファイル(例: `DESIGN.md`、`docs/guidelines/...`)
|
|
42
|
+
- 外部のドキュメントサイト
|
|
43
|
+
- デザインシステムカタログ内のインライン記述
|
|
44
|
+
- 文書化されたガイドラインなし
|
|
45
|
+
- 該当なし
|
|
46
|
+
|
|
47
|
+
**フォローアップ(軸が該当する場合)**: 2 つのフィールドを収集する:
|
|
48
|
+
- **場所**: ファイルパスまたは URL。
|
|
49
|
+
- **アクセス方法**: ファイル読み込みまたは WebFetch。
|
|
50
|
+
|
|
51
|
+
複数のファイルが異なる関心領域を扱う場合(CSS、アクセシビリティ、i18n 等)、`template.md` の複数インスタンスルールに従って各ファイルを別エントリとして収集する。
|
|
52
|
+
|
|
53
|
+
## Axis 4: 表示検証環境
|
|
54
|
+
|
|
55
|
+
実装中にレンダリング結果を確認する手段。
|
|
56
|
+
|
|
57
|
+
**AskUserQuestion 選択肢**:
|
|
58
|
+
- スクリーンショット機能を持つ E2E テストランナー
|
|
59
|
+
- Storybook 等価の独立したコンポーネントプレビュー
|
|
60
|
+
- ブラウザ自動化ツール(専用 CLI または MCP サーバー)
|
|
61
|
+
- 手動でのブラウザ確認のみ
|
|
62
|
+
- 該当なし
|
|
63
|
+
|
|
64
|
+
**フォローアップ(軸が該当する場合)**: 2 つのフィールドを収集する:
|
|
65
|
+
- **場所**: プレビュー URL、MCP の対象、またはテストランナー識別子。
|
|
66
|
+
- **アクセス方法**: 起動コマンド、MCP サーバー名、またはブラウザ自動化ツール名。
|
|
67
|
+
|
|
68
|
+
## 自己申告フェーズ
|
|
69
|
+
|
|
70
|
+
4 つの構造化軸の後、1 回だけ尋ねる: 「構造化された質問の範囲を超えて、このプロジェクトが依存するフロントエンド外部リソースは何か? 該当する項目を次のメッセージで列挙、または 'none' と返答する。」
|
|
71
|
+
|
|
72
|
+
自由記述の回答はフロントエンドブロックの「追加リソース」サブセクションに収集する。このフェーズは構造化軸が全て「該当なし」となった場合でも実行する。
|
|
73
|
+
|
|
74
|
+
自己申告でのみ表面化するリソースの例: ブランド資産の CDN、フォントホスティングサービス、アイコンライブラリのサブスクリプション、ビジュアルバリアントを制御する A/B テストダッシュボード、ビジュアル KPI 確認用の分析ダッシュボード。
|
|
@@ -0,0 +1,76 @@
|
|
|
1
|
+
# インフラストラクチャ外部リソース軸
|
|
2
|
+
|
|
3
|
+
デプロイ、環境設定、Infrastructure as Code に関する作業向けのヒアリング軸。`/project-inject` はユーザーがインフラストラクチャドメインを選択したときにこのファイルを読み込む。
|
|
4
|
+
|
|
5
|
+
## Axis 1: IaC ソース
|
|
6
|
+
|
|
7
|
+
インフラ定義の正本となる取得元。
|
|
8
|
+
|
|
9
|
+
**AskUserQuestion 選択肢**:
|
|
10
|
+
- リポジトリ内の Terraform 構成
|
|
11
|
+
- リポジトリ内の Pulumi または CDK コード
|
|
12
|
+
- リポジトリ内の Kubernetes マニフェスト / Helm チャート
|
|
13
|
+
- クラウドプロバイダー固有のテンプレート(例: CloudFormation、Bicep、Deployment Manager)
|
|
14
|
+
- 手動コンソール設定(IaC なし)
|
|
15
|
+
- 該当なし
|
|
16
|
+
|
|
17
|
+
**フォローアップ(軸が該当する場合)**: 2 つのフィールドを収集する:
|
|
18
|
+
- **場所**: ディレクトリパス。
|
|
19
|
+
- **アクセス方法**: 自動で plan / apply が走る場合の CI パイプライン名、または手動実行の場合の CLI コマンド。
|
|
20
|
+
|
|
21
|
+
## Axis 2: 環境設定
|
|
22
|
+
|
|
23
|
+
環境ごとの設定(開発、ステージング、本番)の差分管理方法。
|
|
24
|
+
|
|
25
|
+
**AskUserQuestion 選択肢**:
|
|
26
|
+
- リポジトリ内の環境別設定ファイル(例: `terraform/envs/`、`config/staging.yaml`)
|
|
27
|
+
- デプロイプラットフォームが管理する環境変数
|
|
28
|
+
- IaC ツール自身のワークスペースまたはスタック抽象化
|
|
29
|
+
- 共通の単一設定(環境ごとの差分なし)
|
|
30
|
+
- 該当なし
|
|
31
|
+
|
|
32
|
+
**フォローアップ(軸が該当する場合)**: 2 つのフィールドを収集する:
|
|
33
|
+
- **場所**: 環境固有の値が格納されている設定ファイルのパス、プラットフォームの設定名、またはワークスペース識別子。
|
|
34
|
+
- **アクセス方法**: ファイル読み込み、プラットフォームのコンソール URL、または CLI コマンド。
|
|
35
|
+
|
|
36
|
+
複数の環境が個別に追跡される場合(開発、ステージング、本番)、`template.md` の複数インスタンスルールに従って環境名を識別接尾辞として各エントリを収集する。
|
|
37
|
+
|
|
38
|
+
## Axis 3: インフラのシークレット
|
|
39
|
+
|
|
40
|
+
インフラコードがシークレット値をソース管理に出さずに参照する方法。
|
|
41
|
+
|
|
42
|
+
**AskUserQuestion 選択肢**:
|
|
43
|
+
- IaC のデータルックアップでシークレットマネージャーから取得
|
|
44
|
+
- apply 時に環境変数経由で注入
|
|
45
|
+
- IaC コードと共に格納された暗号化済みシークレットファイル
|
|
46
|
+
- インフラにシークレットなし
|
|
47
|
+
- 該当なし
|
|
48
|
+
|
|
49
|
+
**フォローアップ(軸が該当する場合)**: 2 つのフィールドを収集する:
|
|
50
|
+
- **場所**: シークレットマネージャーのサービス名または IaC のデータソース識別子。
|
|
51
|
+
- **アクセス方法**: データルックアップの構文、環境変数名、または apply 時の注入機構。
|
|
52
|
+
|
|
53
|
+
同一のシークレットストアがバックエンドドメインに登場する場合、この軸は `template.md` で定義される軸間参照記法でそのストアへの参照として出力する。
|
|
54
|
+
|
|
55
|
+
## Axis 4: デプロイトリガー
|
|
56
|
+
|
|
57
|
+
インフラとアプリケーションの変更が各環境にどのように到達するか。
|
|
58
|
+
|
|
59
|
+
**AskUserQuestion 選択肢**:
|
|
60
|
+
- 特定ブランチへのマージで起動する CI パイプライン
|
|
61
|
+
- CI 内の手動承認ステップ
|
|
62
|
+
- オペレーターによるローカル apply
|
|
63
|
+
- デプロイプラットフォームの push 連動オートデプロイ
|
|
64
|
+
- 該当なし
|
|
65
|
+
|
|
66
|
+
**フォローアップ(軸が該当する場合)**: 2 つのフィールドを収集する:
|
|
67
|
+
- **場所**: CI パイプライン名またはデプロイプラットフォーム識別子。
|
|
68
|
+
- **アクセス方法**: 各環境を起動するブランチ / タグ規約と、必要な手動承認ステップ。
|
|
69
|
+
|
|
70
|
+
## 自己申告フェーズ
|
|
71
|
+
|
|
72
|
+
4 つの構造化軸の後、1 回だけ尋ねる: 「構造化された質問の範囲を超えて、このプロジェクトが依存するインフラストラクチャ外部リソースは何か? 該当する項目を次のメッセージで列挙、または 'none' と返答する。」
|
|
73
|
+
|
|
74
|
+
自由記述の回答はインフラストラクチャブロックの「追加リソース」サブセクションに収集する。このフェーズは構造化軸が全て「該当なし」となった場合でも実行する。
|
|
75
|
+
|
|
76
|
+
自己申告でのみ表面化するリソースの例: IaC ツールの state 保管バックエンド、インシデント対応の runbook ドキュメント、オンコールローテーション、可観測性ダッシュボード、コスト監視ツール、コンプライアンス / 監査ログ送信先。
|