🛠️ 開発・MCP コミュニティ
devdocs-feature
既存のDevDocsプロジェクトに対し、ユーザーが新機能の追加や既存機能の改善を求めている場合に、関連キーワードを参考にしながら、新たな機能を追加したり、機能を改良したりするSkill。
📜 元の英語説明(参考)
Add new features to existing DevDocs projects. Use when users need to add new features, iterate on existing functionality, or mention keywords like "add feature", "new feature", "新功能", "迭代", "新增功能".
🇯🇵 日本人クリエイター向け解説
一言でいうと
既存のDevDocsプロジェクトに対し、ユーザーが新機能の追加や既存機能の改善を求めている場合に、関連キーワードを参考にしながら、新たな機能を追加したり、機能を改良したりするSkill。
※ jpskill.com 編集部が日本のビジネス現場向けに補足した解説です。Skill本体の挙動とは独立した参考情報です。
⚡ おすすめ: コマンド1行でインストール(60秒)
下記のコマンドをコピーしてターミナル(Mac/Linux)または PowerShell(Windows)に貼り付けてください。 ダウンロード → 解凍 → 配置まで全自動。
🍎 Mac / 🐧 Linux
mkdir -p ~/.claude/skills && cd ~/.claude/skills && curl -L -o devdocs-feature.zip https://jpskill.com/download/8771.zip && unzip -o devdocs-feature.zip && rm devdocs-feature.zip
🪟 Windows (PowerShell)
$d = "$env:USERPROFILE\.claude\skills"; ni -Force -ItemType Directory $d | Out-Null; iwr https://jpskill.com/download/8771.zip -OutFile "$d\devdocs-feature.zip"; Expand-Archive "$d\devdocs-feature.zip" -DestinationPath $d -Force; ri "$d\devdocs-feature.zip"完了後、Claude Code を再起動 → 普通に「動画プロンプト作って」のように話しかけるだけで自動発動します。
💾 手動でダウンロードしたい(コマンドが難しい人向け)
- 1. 下の青いボタンを押して
devdocs-feature.zipをダウンロード - 2. ZIPファイルをダブルクリックで解凍 →
devdocs-featureフォルダができる - 3. そのフォルダを
C:\Users\あなたの名前\.claude\skills\(Win)または~/.claude/skills/(Mac)へ移動 - 4. Claude Code を再起動
⚠️ ダウンロード・利用は自己責任でお願いします。当サイトは内容・動作・安全性について責任を負いません。
🎯 このSkillでできること
下記の説明文を読むと、このSkillがあなたに何をしてくれるかが分かります。Claudeにこの分野の依頼をすると、自動で発動します。
📦 インストール方法 (3ステップ)
- 1. 上の「ダウンロード」ボタンを押して .skill ファイルを取得
- 2. ファイル名の拡張子を .skill から .zip に変えて展開(macは自動展開可)
- 3. 展開してできたフォルダを、ホームフォルダの
.claude/skills/に置く- · macOS / Linux:
~/.claude/skills/ - · Windows:
%USERPROFILE%\.claude\skills\
- · macOS / Linux:
Claude Code を再起動すれば完了。「このSkillを使って…」と話しかけなくても、関連する依頼で自動的に呼び出されます。
詳しい使い方ガイドを見る →- 最終更新
- 2026-05-18
- 取得日時
- 2026-05-18
- 同梱ファイル
- 1
📖 Skill本文(日本語訳)
※ 原文(英語/中国語)を Gemini で日本語化したものです。Claude 自身は原文を読みます。誤訳がある場合は原文をご確認ください。
新機能
既存の DevDocs プロジェクトに新機能を追加する際、番号の連続性、ドキュメントの一貫性を確保します。
言語規則
- 日本語と英語での質問に対応
- 日本語での回答に統一
起動条件
- ユーザーが既存のプロジェクトに新機能を追加したい場合
- ユーザーが「増分」、「イテレーション」、「新規機能」、「追加要件」に言及した場合
- ユーザーが既存機能の拡張を要求した場合
前提条件
- DevDocs ドキュメントディレクトリ
docs/devdocs/が存在すること - 少なくとも
01-requirements.mdが存在すること
存在しない場合は、以下を推奨します。
- 新規プロジェクト →
/devdocs-requirements - 既存のコードにドキュメントがない →
/devdocs-retrofit
実行モード
モード選択
/devdocs-feature "機能の説明" → 自動検出モード
/devdocs-feature --lite "機能の説明" → 強制ライトモードモード比較
| モード | 適用場面 | 更新ドキュメント | コンテキスト負荷 |
|---|---|---|---|
| ライトモード | 設定変更、UI の微調整、単純なフィールド | 01 + 04 | 低 |
| フルモード | 新モジュール、新インターフェース、アーキテクチャ変更 | 01 + 02 + 03 + 04 | 高（段階的） |
自動モード検出
要求記述を分析し、以下が含まれるかどうかを検出します。
[ ] 新規 API インターフェース
[ ] データモデルの変更
[ ] コンポーネント間の依存関係の変化
[ ] サードパーティサービスの統合
[ ] 新規独立モジュール- 上記すべてに該当しない → ライトモード
- いずれかに該当 → フルモード（ユーザーに確認を促す）
アーキテクチャ変更の可能性が検出されました：
- 新規インターフェース: UserPreferenceAPI
フルモードの使用を推奨します。ライトモードを続行しますか？[はい/いいえ]コアコンセプト
新機能開発 = 番号の継続 + ドキュメントの追加 + 影響分析 + リグレッション保護ライトモードフロー (--lite)
1. 番号のスキャン
│
├── 01-requirements.md を読み込む → AC の最大番号を取得
└── 04-dev-tasks*.md を読み込む → T の最大番号を取得
│
▼
2. 要求の収集（簡略化）
│
└── 受け入れ基準（AC レベル）
│
▼
3. ドキュメントの追加（2 つのみ）
│
├── 01-requirements.md → AC を追加（既存の F/US にマウント）
└── 04-dev-tasks*.md → 1〜3 個のタスクを追加
│
▼
4. ユーザー確認ライトモードの制約
- F-XXX（機能ポイント）を新規作成せず、既存の機能に AC を追加するのみ
- 02-system-design を更新しない（アーキテクチャ変更なし）
- 03-test-cases を更新しない（
/devdocs-syncで後から補完） - タスク数は 1〜3 個に制限（直接追加可能、devdocs-dev-tasks を呼び出す必要なし）
- タスクは TAR 原則の形式に従う必要がある
フルモードフロー（段階的編成）
コア変更：4 つのドキュメントを一度に更新するのではなく、段階的に実行し、各ステップを確認してから次のステップに進みます。
┌─────────────────────────────────────────────────────────────┐
│ Step 0: 既存のドキュメントをスキャンし、番号とアーキテクチャの概要を取得します │
└─────────────────────────────────────────────────────────────┘
│
▼
┌─────────────────────────────────────────────────────────────┐
│ Step 1: 要求の追加 │
│ ├── 新機能の説明を収集 │
│ ├── 01-requirements.md を追加（F/US/AC） │
│ └── ✅ ユーザー確認 │
└─────────────────────────────────────────────────────────────┘
│
▼
┌─────────────────────────────────────────────────────────────┐
│ Step 2: 設計の追加 │
│ ├── 影響分析（モジュール/インターフェース/データ） │
│ ├── 02-system-design*.md を追加 │
│ └── ✅ ユーザー確認 │
└─────────────────────────────────────────────────────────────┘
│
▼
┌─────────────────────────────────────────────────────────────┐
│ Step 3: テストの追加 │
│ ├── 新規 AC に基づいてテストケースを設計 │
│ ├── 03-test-cases*.md を追加 + 追跡マトリックスを更新 │
│ └── ✅ ユーザー確認 │
└─────────────────────────────────────────────────────────────┘
│
▼
┌─────────────────────────────────────────────────────────────┐
│ Step 4: タスクの追加 │
│ ├── 設計とテストに基づいて開発タスクを分割 │
│ ├── 04-dev-tasks*.md を追加 │
│ └── ✅ ユーザー確認 │
└─────────────────────────────────────────────────────────────┘
│
▼
┌─────────────────────────────────────────────────────────────┐
│ Step 5: 機能ログの生成 │
│ └── 00-feature-log.md を更新 │
└─────────────────────────────────────────────────────────────┘段階的実行の利点
| 問題 | 従来の方法 | 段階的編成 |
|---|---|---|
| 番号の重複 | 4 つの番号を一度にメンテナンスするため、エラーが発生しやすい | 各ステップで現在のドキュメント番号のみに注目 |
| 更新漏れ | コンテキストが長すぎて、見落としやすい | 各ステップで確認し、見落としがない |
| 追跡の不完全性 | AC→テスト の完全性を保証するのが難しい | Step 3 で追跡マトリックスに集中 |
| ロールバックの困難さ | 全量変更はロールバックが難しい | 任意のステップで終了可能 |
Step 0: 既存のドキュメントのスキャン
番号の抽出
既存のドキュメントから最大番号を抽出します。
## 現在の状態
| タイプ | 現在の最大番号 | 次の番号 |
|------|-------------|----------|
| 機能ポイント (F) | F-003 | F-004 |
| ユーザーストーリー (US) | US-008 | US-009 |
| 受け入れ基準 (AC) | AC-015 | AC-016 |
| ユニットテスト (UT) | UT-012 | UT-013 |
| 統合テスト (IT) | IT-003 | IT-004 |
| E2E テスト (E2E) | E2E-002 | E2E-003 |
| 開発タスク (T) | T-10 | T-11 |アーキテクチャの概要（フルモード）
02-system-design*.md から抽出：
- 既存のモジュールリスト
- コアインターフェース
- データエンティティ
Step 1: 要求の追加
委託実行：このステップは
/devdocs-requirements --incrementalに委託する必要があり、増分要求を担当します。
委託入力
/devdocs-requirements に渡されるコンテキスト：
- ユーザーの新しい機能の説明
- Step 0 でスキャンされた既存の番号の状態
委託出力
/devdocs-requirements から取得：
- 新規の F-XXX、US-XXX、AC-XXX 番号リスト
- 更新された追跡マトリックス
✅ 確認ポイント
/devdocs-requirements が要求の追加を完了しました：
- [新規番号の概要は requirements から返されます]
Step 2（設計の追加）に進みますか？[確認/修正/終了]Step 2: 設計の追加（フルモード）
委託実行：このステップは
/devdocs-system-designに委託する必要があり、増分設計を担当します。
委託入力
/devdocs-system-design に渡されるコンテキスト：
- Step 1 で追加された F-XXX、US-XXX、AC-XXX 番号
- 既存のアーキテクチャの概要（Step 0 から）
- 影響分析の問題リスト
委託出力
/devdocs-system-design から取得：
- 新規/変更されたモジュールとインターフェース
- 影響の概要
- リグレッションリスクポイント
✅ 確認ポイント
/devdocs-system-design が設計の追加を完了しました：
- [設計変更の概要は system-design から返されます]
Step 3（テストの追加）に進みますか？[確認/修正/終了]Step 3: テストの追加（フルモード）
委託実行：このステップは
/devdocs-test-casesに委託する必要があり、増分テスト設計を担当します。
委託入力
/devdocs-test-cases に渡されるコンテキスト：
- Step 1 で追加された AC-XXX 番号
- Step 2 で追加されたインターフェースとモジュール（system-design から）
委託出力
/devdocs-test-cases から取得：
- 新規の UT/IT/E2E-XXX 番号
- 更新された追跡マトリックス
✅ 確認ポイント
/devdocs-test-cases がテストの追加を完了しました：
- [テスト番号の概要は test-cases から返されます]
- 追跡マトリックスが更新されました
Step 4（タスクの追加）に進みますか？[確認/修正/終了]Step 4: タスクの追加
devdocs-dev-tasks の呼び出し
重要：フルモードでは、タスクの分割は
/devdocs-dev-tasksが担当し、TAR 原則と階層化された TDD マークの一貫性を確保します。
devdocs-dev-tasks に渡されるコンテキスト：
- 新規の F-XXX、AC-XXX 番号
- 新規の UT/IT/E2E-XXX 番号
- 影響を受けるモジュールとインターフェース
/devdocs-dev-tasks を呼び出す：
- 入力：Step 1〜3 で生成された新規番号
- 出力：04-dev-tasks*.md に追加
- 準拠：TAR 原則、階層化された TDD✅ 確認ポイント
/devdocs-dev-tasks がタスクを追加しました：
- 新規 T-XX ~ T-XX（N 個のタスク）
- TDD 階層がマークされました（🔴🟡🟢⚪）
機能ログを生成しますか？[確認/修正/終了]Step 5: 機能ログの生成
出力ファイル
docs/devdocs/
└── 00-feature-log.md # 機能ログ（追加）レポートテンプレート
# 新機能開発ログ
## v2: <機能名> (2024-01-15)
### 新規コンテンツ
| タイプ | 番号 | 説明 |
|------|------|------|
| 機能ポイント | F-004 | <説明> |
| ユーザーストーリー | US-009, US-010 | <説明> |
| 受け入れ基準 | AC-016 ~ AC-020 | 5 件 |
| テストケース | UT-013 ~ U
(原文はここで切り捨てられています)📜 原文 SKILL.md(Claudeが読む英語/中国語)を展開
新功能
在已有 DevDocs 项目中追加新功能，确保编号延续、文档一致。
语言规则
- 支持中英文提问
- 统一中文回复
触发条件
- 用户要在已有项目中添加新功能
- 用户提到"增量"、"迭代"、"新增功能"、"追加需求"
- 用户要求扩展现有功能
前置条件
- 已存在 DevDocs 文档目录：
docs/devdocs/ - 至少存在
01-requirements.md
如不存在，建议：
- 新项目 →
/devdocs-requirements - 已有代码无文档 →
/devdocs-retrofit
运行模式
模式选择
/devdocs-feature "功能描述" → 自动检测模式
/devdocs-feature --lite "功能描述" → 强制轻量模式模式对比
| 模式 | 适用场景 | 更新文档 | 上下文负载 |
|---|---|---|---|
| 轻量模式 | 配置修改、UI 微调、简单字段 | 01 + 04 | 低 |
| 完整模式 | 新模块、新接口、架构变更 | 01 + 02 + 03 + 04 | 高（分步） |
自动模式检测
分析需求描述，检测是否涉及：
[ ] 新增 API 接口
[ ] 数据模型变更
[ ] 组件间依赖变化
[ ] 第三方服务集成
[ ] 新增独立模块- 以上均无 → 轻量模式
- 任一命中 → 完整模式（提示用户确认）
检测到可能涉及架构变更：
- 新增接口: UserPreferenceAPI
建议使用完整模式。是否继续轻量模式？[是/否]核心理念
新功能开发 = 延续编号 + 追加文档 + 影响分析 + 回归保护轻量模式流程 (--lite)
1. 扫描编号
│
├── 读取 01-requirements.md → 获取 AC 最大编号
└── 读取 04-dev-tasks*.md → 获取 T 最大编号
│
▼
2. 收集需求（简化）
│
└── 验收标准（AC 级别）
│
▼
3. 追加文档（仅两份）
│
├── 01-requirements.md → 追加 AC（挂载到现有 F/US）
└── 04-dev-tasks*.md → 追加 1-3 个任务
│
▼
4. 用户确认轻量模式约束
- 不新建 F-XXX（功能点），仅追加 AC 到现有功能
- 不更新 02-system-design（无架构变更）
- 不更新 03-test-cases（由
/devdocs-sync后续补齐） - 任务数量限制 1-3 个（可直接追加，无需调用 devdocs-dev-tasks）
- 任务必须遵循 TAR 原则格式
完整模式流程（分步编排）
核心变更：不再一次性更新 4 份文档，而是分步执行，每步确认后再进入下一步。
┌─────────────────────────────────────────────────────────────┐
│ Step 0: 扫描现有文档，获取编号和架构摘要 │
└─────────────────────────────────────────────────────────────┘
│
▼
┌─────────────────────────────────────────────────────────────┐
│ Step 1: 需求追加 │
│ ├── 收集新功能描述 │
│ ├── 追加 01-requirements.md（F/US/AC） │
│ └── ✅ 用户确认 │
└─────────────────────────────────────────────────────────────┘
│
▼
┌─────────────────────────────────────────────────────────────┐
│ Step 2: 设计追加 │
│ ├── 影响分析（模块/接口/数据） │
│ ├── 追加 02-system-design*.md │
│ └── ✅ 用户确认 │
└─────────────────────────────────────────────────────────────┘
│
▼
┌─────────────────────────────────────────────────────────────┐
│ Step 3: 测试追加 │
│ ├── 根据新增 AC 设计测试用例 │
│ ├── 追加 03-test-cases*.md + 更新追溯矩阵 │
│ └── ✅ 用户确认 │
└─────────────────────────────────────────────────────────────┘
│
▼
┌─────────────────────────────────────────────────────────────┐
│ Step 4: 任务追加 │
│ ├── 根据设计和测试拆分开发任务 │
│ ├── 追加 04-dev-tasks*.md │
│ └── ✅ 用户确认 │
└─────────────────────────────────────────────────────────────┘
│
▼
┌─────────────────────────────────────────────────────────────┐
│ Step 5: 生成功能日志 │
│ └── 更新 00-feature-log.md │
└─────────────────────────────────────────────────────────────┘分步执行优势
| 问题 | 传统方式 | 分步编排 |
|---|---|---|
| 编号重复 | 一次维护 4 份编号，易出错 | 每步只关注当前文档编号 |
| 漏更新 | 上下文过长，易遗漏 | 每步确认，不遗漏 |
| 追溯不完整 | 难以保证 AC→测试 完整性 | Step 3 专注追溯矩阵 |
| 回滚困难 | 全量修改难回滚 | 可在任意步骤终止 |
Step 0: 扫描现有文档
编号提取
从现有文档中提取最大编号：
## 当前状态
| 类型 | 当前最大编号 | 下一编号 |
|------|-------------|----------|
| 功能点 (F) | F-003 | F-004 |
| 用户故事 (US) | US-008 | US-009 |
| 验收标准 (AC) | AC-015 | AC-016 |
| 单元测试 (UT) | UT-012 | UT-013 |
| 集成测试 (IT) | IT-003 | IT-004 |
| E2E 测试 (E2E) | E2E-002 | E2E-003 |
| 开发任务 (T) | T-10 | T-11 |架构摘要（完整模式）
从 02-system-design*.md 提取：
- 现有模块列表
- 核心接口
- 数据实体
Step 1: 需求追加
委托执行：本步骤必须委托给
/devdocs-requirements --incremental，由其负责增量需求。
委托输入
传递给 /devdocs-requirements 的上下文：
- 用户的新功能描述
- Step 0 扫描到的现有编号状态
委托输出
从 /devdocs-requirements 获取：
- 新增的 F-XXX、US-XXX、AC-XXX 编号列表
- 更新后的追溯矩阵
✅ 确认点
/devdocs-requirements 已完成需求追加：
- [新增编号摘要由 requirements 返回]
是否确认并继续到 Step 2（设计追加）？[确认/修改/终止]Step 2: 设计追加（完整模式）
委托执行：本步骤必须委托给
/devdocs-system-design，由其负责增量设计。
委托输入
传递给 /devdocs-system-design 的上下文：
- Step 1 新增的 F-XXX、US-XXX、AC-XXX 编号
- 现有架构摘要（来自 Step 0）
- 影响分析问题清单
委托输出
从 /devdocs-system-design 获取：
- 新增/变更的模块和接口
- 影响摘要
- 回归风险点
✅ 确认点
/devdocs-system-design 已完成设计追加：
- [设计变更摘要由 system-design 返回]
是否确认并继续到 Step 3（测试追加）？[确认/修改/终止]Step 3: 测试追加（完整模式）
委托执行：本步骤必须委托给
/devdocs-test-cases，由其负责增量测试设计。
委托输入
传递给 /devdocs-test-cases 的上下文：
- Step 1 新增的 AC-XXX 编号
- Step 2 新增的接口和模块（来自 system-design）
委托输出
从 /devdocs-test-cases 获取：
- 新增的 UT/IT/E2E-XXX 编号
- 更新后的追溯矩阵
✅ 确认点
/devdocs-test-cases 已完成测试追加：
- [测试编号摘要由 test-cases 返回]
- 追溯矩阵已更新
是否确认并继续到 Step 4（任务追加）？[确认/修改/终止]Step 4: 任务追加
调用 devdocs-dev-tasks
重要：完整模式下，任务拆分由
/devdocs-dev-tasks负责，确保 TAR 原则和分层 TDD 标记的一致性。
传递给 devdocs-dev-tasks 的上下文：
- 新增的 F-XXX、AC-XXX 编号
- 新增的 UT/IT/E2E-XXX 编号
- 影响的模块和接口
调用 /devdocs-dev-tasks：
- 输入：Step 1-3 产生的新增编号
- 输出：追加到 04-dev-tasks*.md
- 遵循：TAR 原则、分层 TDD✅ 确认点
/devdocs-dev-tasks 已追加任务：
- 新增 T-XX ~ T-XX（N 个任务）
- 已标注 TDD 分层（🔴🟡🟢⚪）
是否确认并生成功能日志？[确认/修改/终止]Step 5: 生成功能日志
输出文件
docs/devdocs/
└── 00-feature-log.md # 功能日志（追加）报告模板
# 新功能开发日志
## v2: <功能名称> (2024-01-15)
### 新增内容
| 类型 | 编号 | 描述 |
|------|------|------|
| 功能点 | F-004 | <描述> |
| 用户故事 | US-009, US-010 | <描述> |
| 验收标准 | AC-016 ~ AC-020 | 5 条 |
| 测试用例 | UT-013 ~ UT-015, E2E-003 | 4 条 |
| 开发任务 | T-11 ~ T-14 | 4 个 |
### 影响范围
- 新增模块：PaymentModule
- 修改接口：IOrderService
- 回归风险：OrderService 测试
### 关联文档
- [01-requirements.md](01-requirements.md) - 已更新
- [02-system-design.md](02-system-design.md) - 已更新
- [03-test-cases.md](03-test-cases.md) - 已更新
- [04-dev-tasks.md](04-dev-tasks.md) - 已更新
---
## v1: 初始版本 (2024-01-01)
...Skill 协作
| 阶段 | 协作 Skill | 说明 |
|---|---|---|
| 需求追加 | /devdocs-requirements |
完整模式必须委托（增量更新） |
| 设计追加 | /devdocs-system-design |
完整模式必须委托（增量更新） |
| 测试追加 | /devdocs-test-cases |
完整模式必须委托（增量更新 + 矩阵） |
| 任务追加 | /devdocs-dev-tasks |
完整模式必须委托 |
| 开发实现 | /devdocs-dev-workflow |
执行单个任务 |
| 编码约束 | /code-quality, /testing-guide |
编码阶段 |
编排器边界：
devdocs-feature是纯编排器，负责步骤编排、确认流程、功能日志。 具体的需求、设计、测试、任务内容全部由对应的专项 Skill 负责，本 Skill 不复制其逻辑。
约束
编号约束
- [ ] 必须延续现有编号，不得重复
- [ ] 必须先扫描现有文档获取最大编号
- [ ] 编号格式保持一致（F-XXX, US-XXX, AC-XXX）
文档约束
- [ ] 追加内容必须标注功能版本和日期
- [ ] 不得删除或覆盖现有内容
- [ ] 追加位置必须正确（章节末尾）
- [ ] 格式必须与现有文档一致
分步编排约束（完整模式）
- [ ] 每步完成后必须等待用户确认
- [ ] 不得跳过步骤（除非用户明确要求）
- [ ] 用户可在任意步骤选择"终止"
- [ ] 每步只关注当前文档的编号和格式
- [ ] 步骤间传递的信息仅限：新增编号列表
轻量模式约束
- [ ] 仅更新 01-requirements.md 和 04-dev-tasks.md
- [ ] 不新建 F-XXX，仅追加 AC 到现有功能
- [ ] 任务数量限制 1-3 个
- [ ] 检测到架构影响时必须提示用户
影响分析约束
- [ ] 修改现有接口必须说明向后兼容性
- [ ] 必须列出回归风险点
- [ ] 高影响变更需用户确认
追溯约束（完整模式）
- [ ] 新增 F-XXX 必须有对应 US-XXX 和 AC-XXX
- [ ] 新增 AC-XXX 必须有对应测试用例
- [ ] 必须更新追溯矩阵
特殊情况
文档结构不完整
如果只有部分文档存在：
1. 提示用户缺失的文档
2. 建议先补全文档（使用 /devdocs-retrofit）
3. 或仅追加到已有文档大规模功能
如果新功能需求较大（超过 3 个功能点）：
建议拆分为多次迭代：
1. 按功能模块拆分
2. 每次迭代独立完成
3. 分别提交和验证需求变更（非新增）
如果是修改现有需求而非新增：
⚠️ 这是需求变更，不是新功能需求。
建议：
1. 在原 F-XXX 下标注变更
2. 更新相关 US/AC
3. 更新受影响的测试用例
4. 记录变更原因输出
- 更新
01-requirements.md（追加） - 更新
02-system-design*.md（追加/修改） - 更新
03-test-*.md（追加） - 更新
04-dev-tasks*.md（追加） - 更新/创建
00-feature-log.md（追加）