既存プロジェクトに新しいリポジトリを追加する。Workspaceにリポを追加した後、 CLAUDE.md・設計書・ドメイン構成を差分更新する。 「モバイルリポを追加した」「新しいリポを取り込んで」「リポを追加したので設計書を更新して」 「Workspaceにリポを足した」などのリクエストで使用する。 init-spec の移行モードではファイル存在チェックしか行わないため、 既存ドキュメントの内容を新リポに合わせて拡張するにはこのスキルを使う。
feedback-template
テンプレートへのフィードバック。開発中の問題や改善点をテンプレートリポにPRとして反映する。「テンプレートに反映して」「テンプレートを改善して」「テンプレートにフィードバックして」 「親テンプレートにPR作成して」「テンプレートリポにPRして」 「これをテンプレートに反映したい」などのリクエストで使用する。
sync-templateは取り込み(pull)、本スキルは反映(push/PR)。
含まれるファイル(1)
- SKILL.md4.9 KB
SKILL.md(原文)
インストールする前に、エージェントに与えられる指示の中身を確認できます。
テンプレートへのフィードバック
トリガー
以下のいずれかで起動する:
- ユーザーが明示的に「テンプレートに反映して」と指示した場合
- 実装中に以下のパターンに該当する問題を解決した場合、自動で提案する:
- ライブラリの非推奨APIを踏んで修正した
- CI設定の不備を修正した
- スキルの手順に不足があり、想定外の動きをした
- 環境固有の問題で、他プロジェクトでも再現しうるもの
提案の例: 「この問題は他のプロジェクトでも起きる可能性があります。テンプレートリポにフィードバックしますか?」
手順
1. 問題の分析
何が起きて、なぜ起きたのかを整理する:
## 問題
CIでsupabase status -o envの出力値にダブルクォートが含まれ、環境変数が不正な値になった
## 原因
Supabase CLIのバージョンアップで出力フォーマットが変わった
## プロジェクトでの修正
test.ymlのe2eジョブの環境変数取得に | tr -d '"' を追加
2. 汎用化の判断
以下を確認する:
- 他プロジェクトでも起きうるか? → No ならフィードバック不要。ユーザーに伝えて終了
- プロジェクト固有の情報を含んでいないか? → リポ名、URL、APIキー等を除去
3. テンプレートリポの修正対象を特定
問題の種類に応じて修正先を決める:
| 問題の種類 | 修正先 |
|---|---|
| 共通ルールの追加・修正(認証、ブランチ戦略等) | .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のコメント例示に追加してよい。
4. テンプレートリポをcloneしてブランチ作成
# .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/<問題を端的に表すスラッグ>
5. 修正を実施
- 修正はプロジェクト固有の情報を含めない
- コメント形式の例示として追加する場合は
<!-- 例: -->の中に書く - スキルに手順を追加する場合は、既存の手順の流れを壊さない位置に挿入
6. コミット&プッシュ&PR作成
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
)"
8. クリーンアップ
find /tmp/yamasaki -delete 2>/dev/null || true
ユーザーに報告:「テンプレートリポにPRを作成しました: <PR URL>」
ルール
- プロジェクト固有の情報(リポ名、URL、APIキー、ポート番号等)は絶対に含めない
- テンプレートリポの.claude/CLAUDE.mdは修正してよい(共通ルール)
- テンプレートリポのCLAUDE.mdはコメント内の例示のみ修正する(実値は書かない)
- 既存のスキルの構造を壊さない。手順の追加・修正のみ行う
- gh CLI が使えない環境では、コミット&プッシュまで行い、PR作成はユーザーに依頼する
- テンプレートリポのURLが.claude/CLAUDE.mdに記載されていない場合、ユーザーに確認する
レビュー
まだレビューはありません。使ってみた感想をお寄せください。
同じリポジトリのスキル
概要と使いどころ
既存プロジェクトをサブエージェントで並列分析し、 精度の高い overview.md を生成する。init-spec の前処理として使う。 「既存プロジェクトを分析して」「コードベースを理解して設計書を作って」 「overview.mdを作って」などのリクエストで使用する。 ファイル数が200を超えるプロジェクトで特に有効。 200以下の場合は単一エージェントで全体を読む方が精度が高いため、 init-spec をそのまま実行することを提案する。
デザインの差し替え。ロジックは一切触らず見た目(HTML/CSS/テンプレート)だけを更新する。 「このデザインに差し替えて」「UIをFigmaの通りに変えて」「見た目だけ変えて」 「デザインを更新して」「CSSだけ直して」などのリクエストで使用する。 ロジック変更を伴う場合はrevise-specを使う。
ブラウザで画面を確認する。agent-browser CLI を使って画面のスクリーンショット撮影、 アクセシビリティツリー取得、フォーム操作、画面遷移などを行う。 「画面見て」「ブラウザ確認して」「スクショ撮って」「現状把握して」「画面開いて」 「ログインして確認して」「画面の状態を教えて」「UIを確認して」などのリクエストで使用する。 E2Eテストの作成・実行には gen-tests(Playwright)を使うこと。本スキルはテスト実行ではなく 「AIの目」としてブラウザを操作し、画面状態を把握するためのもの。
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) 設計書ファーストモード: 要件定義書から詳細設計書を新規作成する(コードなし) 「詳細設計を作って」「設計書を完成させて」「実装に必要な設計書を全部作って」 「他のエンジニアに渡せる設計書にして」などのリクエストで使用する。