using-creed

Creed の使用方法

出力言語： 回答と成果物は、ユーザー自身の言語で作成してください（リポジトリの履歴ではなく、ユーザーのメッセージに合わせてください）。

特定のタスクを実行するためにサブエージェントとして派遣された場合、このスキルは無視してください。

このスキルを使用するタイミング

• Creed ワークスペースでのセッション開始時
• どの Creed スキルを適用すべきか分からないとき
• 初めて使用するとき／コンパニオンスキルが不足している可能性があるとき
• 創作、テスト、デバッグ、リリースの作業に取りかかる前に、まず適切なスキルを選んでください

クイックスタート（インストール）

コンパニオンスキルが必要です。using-creed だけでは不十分です。

npx skills add Gusen1453/creed

インストールの確認

必須スキル：explore、grill、issue、write-spec、solid、write-plan、tdd、test-design、debug、review、commit-and-push。

ワークスペースのスキル一覧に不足しているスキルがある場合は、作業を始めず、上記のインストールコマンドを実行するようユーザーに依頼してください。記憶を頼りに Creed のワークフローを作り出さないでください。

インストール済みだが古い場合：リポジトリはソースにすぎません。インストールはスナップショットなので、リポジトリを編集しても再インストールするまでは反映されません。古いインストールを検出し、ユーザーの明示的な確認を得た場合に限り、更新してください。references/install-and-update.md を参照してください。

使用方法

1. 以下のマップからタスクに適したスキルを選びます。
2. Using <skill> to … と伝え、そのスキルを読み、手順に従います。
3. チェックリストがある場合は、項目ごとに 1 つの TODO を作成します。
4. 複数のスキルが該当する場合は、デフォルトのフローに従います。成果物を次のスキルへ渡す前に、以下の移行ゲートを実施してください。次のスキルへ自動的に進んだり、自動でレビューしたりしてはいけません。

using-creed
  → explore? → grill → [gate] → issue? → write-spec → [gate] → solid? → [gate]
  → write-plan → [gate] → tdd (+ test-design)
  → [gate] → debug? → [gate] → review → [gate] → commit-and-push

explore? = タスクで既存コードを変更または参照する場合（リファクタリング／レガシー／再利用）はゲートを実施し、グリーンフィールドの場合は省略します。

issue? = grill の終了ゲートでは、仕様作成の前に意図を追跡可能な Issue として記録する選択肢があります。その選択肢を選ぶと、同じゲートに戻ります。保留するものがない場合は省略します。

solid? = スライスにモジュール／ポート／I/O 境界を追加する場合に限りゲートを実施し、新しい境界がない場合は省略します。省略した場合、write-spec → solid と solid → write-plan のゲートを 1 つの write-spec → write-plan ゲートに統合します（レビュー対象は引き続き仕様です。「レビュー境界」オプションのみ削除されます）。

[gate] = 移行ゲートです。引き継ぎのたびに AskUserQuestion を 1 回実行してください。移行ゲートを参照してください。

移行ゲート

成果物を生成するスキルのほとんどには、引き継ぎ時に AskUserQuestion を1回だけ行う、独自の 移行ゲート セクションがあります。次のスキルへ自動で進んだり、自動レビューしたりすることはありません。選択肢はスキルごとに異なり、ゲートがないスキルもあります。 grill のゲートは「進む／設計を再検討する／先にイシューを登録する／その他」で、レビューの選択肢はありません（まだレビュー対象となるものが何も書かれていないためです）。issue には独自のゲートがありません。単独で開始した場合は報告だけを行い、パイプライン内では grill のゲートに制御を戻すため、質問は1回だけ行われます。それ以外のスキルは以下の形式に従います。思い込みで判断せず、スキルの Hand-off を確認してください。

A) Recommended: Proceed → <next skill>
B) Review first — run **review** on the just-finished <object>
   (its rubric in the review skill's `references/`), then return to this gate and re-ask
C) Adjust — go back to <producing skill>, revise the <object>, then re-gate
D) Something else (I will type it)

ルール（上記の形式に従うゲートが対象です。grill のゲートは異なり、issue にはゲートがありません）：

• B を選択 → そのオブジェクトを、対応するルーブリックで review します（直接の上流成果物と照合します。主張→ケースの表は必須です）。Critical と Important の指摘を修正するか、理由を添えてユーザーに保留してもらいます。その後、同じゲートに戻って再度質問します。ユーザーは A を選ぶ、別のレビューを依頼する、または調整することができます。
• C を選択 → 成果物を生成するスキルに戻り、修正してから、そのオブジェクトのゲートを再度実行します。
• ゲートをスキップできるのは、ユーザーが「このセッションではゲートをスキップして」と述べた場合、または特定のゲートを明示的に免除した場合に限ります。ゲートで行うのは簡単な質問1つだけであり、儀式ではありません。「尋ねるほどのことではない」という考え方はアンチパターンです。

特別なゲートが2つあります。grill → write-spec ではまだレビュー対象がありません（仕様はまだ書かれていないため、レビューの選択肢はありません。「進む／設計を再検討する／先にイシューを登録する」のみです）。review → commit-and-push ではレポートの判定を確認します（Critical／Important の指摘が修正または免除されてから進みます。確認せずに自動で公開することはありません）。

新しい境界がなく、solid? をスキップした場合、write-spec → solid と solid → write-plan のゲートは、1つの write-spec → write-plan ゲートに統合されます（レビュー対象は仕様のままです。「境界をレビューする」選択肢だけがなくなります）。

スキルマップ（シナリオ）

状況	スキル
既存コードのリファクタリング／作り直し — タスクで変更または参照するメソッド／クラス／テーブルが指定されている	explore → grill → write-spec → …
新機能／動作変更／アーキテクチャ／「grill me」／ブレインストーミング — コードを書く前	grill
後で追跡するために何かを記録／登録する — 「このバグをメモして」、「issue を作って」、「これはいったん保留」、バグ報告または機能リクエスト	issue
承認済みの設計 → 長期的に参照できるプロダクト仕様（シナリオ、スコープ、決定ログ）	write-spec
仕様の作成後：パッケージ／ポート／依存関係の矢印を確定する、またはモックが多すぎる／結合のにおいがある	solid
承認済みの仕様（必要に応じて solid も） → 複数ステップの作業を TDD タスクに分割する	write-plan
本番コードを書く（機能／バグ修正／リファクタリング）	tdd
テストを書く、またはレビューする：テストする価値があるか？ 単体テストと結合テストのどちらか？ 何をアサート／モックするか？	test-design
バグ、テスト／CI の失敗、予期しない動作、または「修正済み」と報告しようとしている	debug
タスクの一部を完了した後／PR を作成または更新する前	review
ステージ間の引き継ぎ — 次に何をするかはユーザーが決める	作業を行ったスキルの Hand-off セクション（選択肢はスキルにより異なります。issue にはありません）
仕様／計画／構造に関する決定を、それ自体の対象としてレビューする（コードではない）	review（references/{spec,plan,solid}.md に振り分けられます）
ユーザーがコミット／プッシュ／PR の作成を依頼する（PR にはテスト計画が必要）	commit-and-push

よくある組み合わせ：

• explore → grill — explore はリポジトリの事実（根拠、アサーションの確認、競合）を収集し、続いて grill が判断を要する点だけを尋ねます。
• grill → write-spec — grill で決定事項をすり合わせ、write-spec でメンタリングと引き継ぎに必要な内容／理由を確定します。
• write-spec と write-plan の違い — spec はプロダクトのシナリオとトレードオフ、plan はファイル、順序、RED→GREEN です。
• write-spec → solid? → write-plan — 境界が新しい場合、solid はゲートとして使います。毎回必須のステップではありません。
• tdd + test-design — tdd は進め方（まずテストを書き、失敗することを確認する）、test-design は何を入力し、何をアサートし、何をモックするかを決めます。実装時は両方を使います。
• debug → tdd — バグ修正では、まず根本原因を証拠に基づいて特定し、その後、失敗する回帰テストを書きます。
• grill と solid — grill の最中は、選択肢に含まれる境界の におい だけを記録します。内容／理由が確定するまでは、メインスキルを solid に切り替えないでください。

最小限のタスクプロンプトテンプレート（人間向け）

3 つのブロックを指定します。エージェントが残りを調べ、リポジトリから答えられないことだけを質問します。

Task: <one-line intent, name the method/class to change>
Hard constraints: <numbers, policies, red lines — only you know these>
Explore hints (optional): <class/method names to reference; the agent reads them itself — no need to describe>
Acceptance (optional): <one line of demo language: how we'll know it works>

Let the agent explore the repo for the rest; grill it only on judgment calls. Run /grill

ハード制約欄のルール：

• ソフト制約の表現（「できるだけ避ける」／好みの表現）は、禁止ではなく優先事項です。リポジトリの現状と矛盾する場合（例：再実行の冪等性）、explore は事実チェックリストでその矛盾を指摘し、grill はあなたが判断するトレードオフの質問に変換します。
• SQL、フィールド名、メソッドシグネチャ、アセンブリの詳細は書かないでください。これらはリポジトリから回答できる事実であり、記載するとコードとの矛盾を招くおそれがあります。

例（変更前 → 変更後）— 同じタスク：約 600 文字 → 約 150 文字。削ったものはすべてリポジトリから回答できる内容（SQL、フィールド名、メソッドシグネチャ、アセンブリの詳細）で、残したものはすべて人間にしか決められない内容（並行処理、再試行ポリシー、譲れない条件）です。

Before: 6-step flow + 3 SQL snippets + thread-pool/retry/Redis details + "the response format needs to be
List<ImageEmbeddingUpdateRequest.ContentItem> batchContentList" (a guess about the code)

After: Refactor RagRecoverPushJob#imageRecover to re-push dp_research_report_structure_info
(data_source in ('2','3'), id 111~2000) to the vector DB.
Hard constraints: descending pagination, 1000 per batch; 40-concurrency thread pool; on push failure retry
once, then enqueue to Redis for retry; try not to update dp_research_report_image_search.
Explore hints: SecAnnouncementThreadPoolManager, PushImageChunkService#buildReportChunkDto/#sendListToRag.
Let the agent explore the repo for the rest; grill it only on judgment calls. Run /grill

チェックリスト

• Companion Creed スキルがインストールされている（未インストールの場合 → Quick Start）
• 関連する Creed スキルを特定している（または N/A とすることを意識的に決めている）
• スキルを読み、指示に従い、実施することを伝えている
• 各 [gate] で移行ゲートを実行している — ユーザーがそのスキルの選択肢（続行／レビュー／調整、または grill の再オープン／issue の登録）のいずれかを選択した、または明示的に免除した