feature-documentation

Topics in the source

• Feature Documentation Skill - 機能・サービス・知識ドキュメント化
• 目的
• 適用範囲（何を書くか）
• 発火タイミング（必須）
• 自動発火（AI 側で判断して実行）
• 手動発火
• 実行フロー
• Step 1: ドキュメント対象の特定

導入先の補足ファイル documents/development/project/feature-documentation.md があれば、その段で読む。補足ファイルは製品への当てはめ（コマンド・パス・ポート等）だけを持ち、本スキルの規則を緩めない。食い違えば本スキルが優先する。 プロジェクトに関する 「あとから読めば分かる」資産 を蓄積するためのスキル。 会話履歴・PR description・CHANGELOG はあくまで「いつ・誰が・何をしたか」の記録に過ぎず、「この機能は何で、なぜそうなっているのか」を後から再構築するのは難しい。 本スキルは、機能や前提条件などを 永続ドキュメント として残し、「次に触る人（人間でも AI でも）が単独で理解できる状態」を維持することを目的とする。 -- このスキルは「機能詳細だけ」のものではなく、以下のすべてを対象とする： | 種別 | 例 | |------|-----| | 機能 / サービス | 認証機能、決済サービス、通知バッチ など | | 業務要件 / ユースケース | ユーザー登録フロー、注文確定フロー など | | プロジェクト前提条件 | 想定ユーザー、対応ブラウザ、SLA、想定負荷 など | | 全体像 / README 的な内容 | システム構成、リポジトリ構成、用語集、ドメイン語彙 など | | 横断的なルール / 設計判断 | 例外設計方針、リトライ戦略、命名規約のうち本プロジェクト固有のもの | 開発プロセスや汎用的なコーディング規約は documents/development/ 配下のドキュメントを使う。本スキルが扱うのは「このプロジェクト固有の事実・判断」。 -- 以下のいずれかに該当する場合、本スキルを必ず実行する。 1. 新しい機能・サービスを実装したとき 例: 新しい API エンドポイント群、新しいバッチ、新しい画面 / 機能ブロック 2. 既存の機能・サービスの仕様 / 振る舞いを変更したとき 例: API レスポンス形式の変更、認可ルールの変更、外部サービス連携の変更 3. プロジェクトの前提条件 / 構成が変わったとき 例: 採用技術の変更、依存サービスの追加、対応ブラウザの更新 4. executing-plans / subagent-driven-development の各タスク完了時 タスクが「機能の追加・変更」を含むなら、本スキルを呼び出してから次のタスクに進む 5. quality-check 実行時の前提条件 quality-check は本スキルが完了している（または対象なしと判断されている）ことを前提とする ユーザーが feature-documentation スキルを明示的に呼び出した場合 ユーザーが「このプロジェクトの〜をドキュメントにまと

This is an excerpt. Refer to the complete source and its current requirements.