菜单
テンプレートへのフィードバック。開発中の問題や改善点をテンプレートリポにPRとして反映する。 「テンプレートに反映して」「テンプレートを改善して」「テンプレートにフィードバックして」 「親テンプレートにPR作成して」「テンプレートリポにPRして」 「これをテンプレートに反映したい」などのリクエストで使用する。 sync-templateは取り込み（pull）、本スキルは反映（push/PR）。
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
ClaudeDesign（claude.ai/design）とClaude Codeの連携。DesignSyncツールで デザインプロジェクトからプロトタイプHTML等を取得（インポート）、または ローカルのコンポーネントをデザインシステムプロジェクトへ同期（プッシュ）する。 「ClaudeDesignからデザインを取得して」「claude.ai/design のURLを取り込んで」 「デザインプロジェクトに同期して」「デザインシステムをプッシュして」 などのリクエスト、または claude.ai/design のURLが渡されたときに使用する。 取得したデザインのコード実装への適用は apply-design を使う。
詳細設計書の一括生成。2つのモードを自動判定する: (A) コード分析モード: 既存コードから詳細設計書を逆生成する（init-spec + spec-all 完了後） (B) 設計書ファーストモード: 要件定義書から詳細設計書を新規作成する（コードなし） 「詳細設計を作って」「設計書を完成させて」「実装に必要な設計書を全部作って」 「他のエンジニアに渡せる設計書にして」などのリクエストで使用する。
既存プロジェクトの初期セットアップ（初回のみ）。コードリポジトリを分析してCLAUDE.md、要件概要、 基本設計書（アーキテクチャ、DB設計、API設計）、OpenAPI仕様、MkDocs設定を自動生成する。 「このプロジェクトをセットアップして」「既存コードを分析して」「設計書を初期化して」 「プロジェクトの構造を把握して」などのリクエストで使用する。 既にドキュメントがある場合は移行モードで差分だけ補完する。 ※ 既存Specの全更新・再生成には spec-all を使う。
全機能の一括Spec化・一括更新。PM として並列サブエージェントにコード分析を委任し、 結果を統合して全機能の要件定義書を一括生成・更新する。 「全部のSpecを作って」「設計書を全部作って」「全機能をドキュメント化して」 「要件定義を全て更新して」「Specを全部更新して」などのリクエストで使用する。 個別のSpec化には spec-feature を使う。init-specは初期セットアップ専用。
既存機能のSpec化。実装済みコードを分析して要件定義書を逆生成する。 spec-map.yml にコードとSpecの対応関係を記録する（コード変更なし）。 「ツイート機能のSpecを作って」「認証周りをドキュメント化して」「既存の○○機能を設計書にして」 「この機能の要件を整理して」「○○の仕様を分析して」などのリクエストで使用する。 既に動いているコードからドキュメントを起こすときに使う。新規機能にはdraft-specを使う。 コード変更後のドキュメント追従にはupdate-docsを使う。
コード変更からドキュメントを追従更新する。設計書ファースト原則の例外措置。 やむを得ず先にコードを変更した場合にのみ使用する。 「さっきの変更をドキュメントに反映して」「設計書を最新にして」 「コードと設計書がズレてるから直して」「ドキュメントを最新化して」 「ドキュメント更新して」「設計書を現状に合わせて」などのリクエストで使用する。 通常はドキュメントを先に更新してからコードを修正すること（revise-specを使う）。
| name | feedback-template |
| description | テンプレートへのフィードバック。開発中の問題や改善点をテンプレートリポにPRとして反映する。 「テンプレートに反映して」「テンプレートを改善して」「テンプレートにフィードバックして」 「親テンプレートにPR作成して」「テンプレートリポにPRして」 「これをテンプレートに反映したい」などのリクエストで使用する。 sync-templateは取り込み（pull）、本スキルは反映（push/PR）。 |
以下のいずれかで起動する：
提案の例： 「この問題は他のプロジェクトでも起きる可能性があります。テンプレートリポにフィードバックしますか？」
何が起きて、なぜ起きたのかを整理する：
## 問題
CIでsupabase status -o envの出力値にダブルクォートが含まれ、環境変数が不正な値になった
## 原因
Supabase CLIのバージョンアップで出力フォーマットが変わった
## プロジェクトでの修正
test.ymlのe2eジョブの環境変数取得に | tr -d '"' を追加
以下を確認する：
問題の種類に応じて修正先を決める：
| 問題の種類 | 修正先 |
|---|---|
| 共通ルールの追加・修正（認証、ブランチ戦略等） | .claude/CLAUDE.md |
| CIの設定不備 | ci-templates/ |
| スキルの手順不足・誤り | .claude/skills/ の該当SKILL.md |
| テスト生成の品質問題 | gen-tests/SKILL.md または implement-spec/SKILL.md |
| ドキュメント生成の問題 | 該当スキルのSKILL.md |
注意: 「技術制約」はプロジェクト固有（ルートCLAUDE.md）なのでテンプレートには反映しない。ただし、共通で踏みやすい制約は.claude/CLAUDE.mdのコメント例示に追加してよい。
# .claude/CLAUDE.mdの「テンプレートリポ」セクションからURLを取得
# URLからオーナー/リポ名を抽出（git@github.com:owner/repo.git → owner/repo）
TEMPLATE_REPO="<CLAUDE.mdに記載のURL>"
OWNER_REPO=$(echo "$TEMPLATE_REPO" | sed -E 's#.+[:/]([^/]+/[^/]+?)(\.git)?$#\1#')
# gh CLI経由でHTTPS clone（サンドボックス環境でSSHが使えないため）
gh repo clone "$OWNER_REPO" /tmp/yamasaki
cd /tmp/yamasaki
git checkout -b fix/<問題を端的に表すスラッグ>
<!-- 例: --> の中に書くcd /tmp/yamasaki
git add -A
git commit -m "fix: <問題の要約>"
git push origin fix/<スラッグ>
gh pr create \
--title "fix: <問題の要約>" \
--body "$(cat <<'EOF'
## 何が起きたか
<問題の説明>
## 原因
<原因の説明>
## 修正内容
<変更内容の説明>
## 汎用化チェック
- [x] プロジェクト固有の情報を含んでいない
- [x] 他のプロジェクトでも同じ問題が起きうる
- [x] 手元のプロジェクトで検証済み
EOF
)"
find /tmp/yamasaki -delete 2>/dev/null || true
ユーザーに報告：「テンプレートリポにPRを作成しました: 」