ce-skill-work

CE Skill Work

このリポジトリのスキルは、状態機械ではなく目標です。スキルは、目標、完了条件、安全な失敗の方向性、目の前のリポジトリからは導き出せない事実をエージェントに伝えたら、あとは介入しません。このスキルが行うことはすべて、作成、編集、レビュー、レビューへの対応のいずれであっても、異なる開始状態に同じ基準を適用することです。

成果： 変更するスキルファイルには、ケースの列挙ではなく条件を記述し、動作を変えないものは含めず、各仕組みをそれを担うレイヤーに配置します。また、リスクに見合った方法で変更を検証します。

完了： モードの完了レポートが作成され、検証が実行されています（または、正確なスキップ理由が記録されています）。文を一つ追加しただけでは完了ではありません。最小限の仕組みを、その責任を担うレイヤーに配置して、実証されたギャップを埋めることが完了です。

目標外： ファイルを短くすることです。簡潔さは条件を明記することの副産物です。語数ではなく、変更内容を報告してください。

基準（いずれのモードでも先に読むこと）

docs/solutions/skill-design/portable-agent-skill-authoring.md を規範とします。以下で指定するモードのセクションを読み、編集対象のスキルでガイドを言い換えないでください。プロジェクトで有効な指示のうち、常に読み込まれるルールはガイドを補足し、より具体的な場合はそちらが優先されます。

各ブロックは、同じ要素を次の順で検討します。成果と次の利用者、スキルレベルの基準では保護できないローカルな完了確認、安全な失敗の方向性、導き出せない事実、そして成果だけでは保護できない場合に限りプロトコルです。必要のない要素は省きます。代わりに置いてはならないのは、条件として記述できるのにケースの一覧で代用するものや、このスキルが委任する作業に仕組みを規定するものです。それが指摘事項です。このスキルが担う作業の手順や、省略した項目によって必須の網羅性がひそかに損なわれるメニューはプロトコルであり、そのまま残します。

すべてのモードで適用されるルール

• 条件であり、ケースではない。 ルールに「そして X の場合も」を追加したくなったら、X が代理している条件に名前を付け、その条件を述べてください。ケースを列挙しなければならないルールは、書き方が間違っています。
• メカニズムを規定するのは、このスキルがそれを所有している場合に限る。 コマンド、終了コード、状態遷移は、そのメカニズムを所有するスキル（PR 検出は ce-commit-push-pr が所有します）か、低コストで決定的な処理に属します。委譲するスキルは、条件、安全な方向、そして呼び出し先から導出できない事実を述べます。
• まず堆積物を取り除く。 ブロックに追加する前に、標準がそこにあるべきでないとしているものを削除してください。どれだけ厳しく調べるかは来歴が決めますが、何を残すかは決めません。その行を検証するテスト、それを記録した docs/solutions/ の学び、または名前の付いたバグを修正するためにその行を追加したコミットを探してください。来歴が見つかった場合 → その行は何かを守っています。その消費者がすでに存在しない場合を除き、残し、何を守っているかを引用してください。見つからなかった場合 → admission（反証可能な制約を述べているか、実証された傾向に対抗しているか、導出できない事実を提供しているか）を適用し、その行が弱いモデルや別のハーネスに対する保険である可能性が高い場合は、決めつけずに削除する前にそれを検証してください。どの削除が証拠の不在に基づくのかを明示してください。
• 削除するすべての義務について、何が決定するようになったのかを明示する。 その答えが「必須のステップが実行されるかどうかを、モデルがその裁量で決める」である場合、その義務は必須のゲートであり、残ります。「must」を削除しても、決定は削除されません。
• 1 行はその地位を得ます — 反証可能な制約を述べる、実証されたデフォルトの傾向に対抗する、またはエージェントが導出できない事実を提供することによって。単独で成立する指令の後の根拠、努力の言葉遣い、能力の再記述はそうではありません。
• ユーザー向けの呼び出しはハーネスごとにレンダリングされます — ルールとその配置はプロジェクトのアクティブな指示（「User-Facing Skill Invocations」）にあります。スキルが呼び出しを出力またはコピーするすべての場所に適用してください。
• 説明はコンテキストポインタです。 モデル呼び出し型のスキルでは、フロントマターは毎ターンウィンドウ内に存在し、本文よりも厳しく刈り込まれます。文 1 は、先頭のプロンプト語を最初に置いて、特徴的なメカニズム（兄弟スキルが生み出さないもの）に名前を付けます。次に、「Use when...」または「Use for...」の形式で、真に異なる分岐ごとに 1 つの肯定的なトリガーを、観察可能な作業状態として記述します。「Use for 」を優先し、「Not for」は同じ語が両方のスキルを発火させる場合にのみ残してください。スキルが誤った仕事で有害である場合は、「Use only when」/「Skip when」を説明に記述してください。アイデンティティの定型文、1 つの分岐に対するサイト・同義語・能力のカタログ、モデル呼び出し型スキルへの引用発話やスラッシュ名の詰め込み、ワークフロー、フラグ、フェーズ一覧は除外します。特徴的な how は残してもかまいません。引用フレーズと /name エイリアスは、ユーザー呼び出し型または disable-model-invocation スキルにのみ、メカニズムの後に置きます。
• 完了基準は最初に 1 つ。 すべてのスキルにはスキルレベルの完了条件が必要です。ローカルの完了チェックは、それを省略すると安全でないアクション、壊れやすい遷移、スコープの拡大、変更、認証の誤り、またはサイレントなハンドオフの失敗を生む可能性がある場所にのみ追加してください。
• 現行の強力なモデル向けにプロンプトを簡潔に。 各指示は一度だけ述べてください。短い指示が一連の振る舞いを決定するなら、振る舞いを列挙する代わりにそれを使ってください。2 つのレシピが同じコマンドの骨格を共有するなら、パラメータまたは差分を付けた 1 つのレシピを書いてください。骨格が同じなら、完全なコマンドの繰り返しは欠陥です。
• 平易な文。節約は構文ではなく構造から生まれます。 1 文に 1 つのアイデアを、普通の英語で書いてください。誰が行動するのか、何をするのか、そしてその情報が必要なときになぜ重要かを明示してください。発明されたラベルや内部ワークフローの専門用語は、それが意味する行動や結果に置き換えてください。必要な技術用語は残し、読者が必要とする場所で馴染みのない用語を説明してください。注意深いエンジニアが二度読むような文 — ダッシュで節をつなげたもの、冠詞や接続詞を省いたもの、3 つのルールを 1 つに詰め込んだもの — は、バイト数を節約しても欠陥であり、エージェントのユーザー向けトーンにも漏れ出します。本文を小さくしなければならないときは、まとまりのあるブロックを使用箇所で名前を付けた参照へ移すか、真の重複を削除してください。決して収めるために文言を圧縮してはいけません。また、次の修正でそれをしなくて済むよう余裕を残してください。
• この組織のマルチモデルスキルにおける Sol 優先のポータビリティ。 手順を削除したり簡潔さブロックを追加したりする Fable のガイダンスが、既知の良好なコマンド、必要なレポート内容、または一律の簡潔さスローガンの禁止を保持する Sol のガイダンスと衝突する場合は、Sol の形式を保ってください。少し厚くても明確な指示は Fable にとって許容されますが、Sol にとって重要な決定性を省くことは許されません。真のノイズは依然として削除されます。
• ポータブルな長さ制御は内容を保持します。 クロスモデルスキルに一律の「be concise」/「keep it short」スローガンを決して入れないでください。短いレポートが何を含まなければならないか、何を省略してよいかを述べてください。CLI ラッパーでは、コマンド、終了ステータス、出力パス/サイズ、および stderr またはブロッカーを保持してください。
• 長時間実行するスキルはそのペーシングを述べます。 長いループを所有するスキル、またはワーカーをディスパッチするスキルは、バッチ処理（独立した呼び出しとディスパッチは 1 つの応答で発行し、本当の依存関係のみを直列化する）、ナレーション（ユーザーが前・最中・終了時に何を聞くか）、および完了の誠実さ（ステップは実際に実行されたときにのみ完了する。ターンは記述されたが未完了の作業で終わらない）を指示します。少数の呼び出しを実行して返すスキルは、この 3 つすべてを省略します — ガイドの長時間実行セクションを参照してください。
• 自律性は 1 つのコンパクトなポリシーです。 安全なローカルアクションに名前を付け、ユーザーの要求から導かれるスコープ内の作業を進めさせてください。これには、要求された仕事である、またはスキルの権限範囲で名前が挙げられている外部書き込みも含まれます。確認するのは、外部書き込み、破壊的なアクション、購入、または重大なスコープ拡大がその範囲外である場合、またはユーザーだけが入力を提供できる場合に限ります。各ステップで「ask first」「do not mutate」「wait for approval」を繰り返さないでください。
• 自由度を脆さに合わせる。 多くの有効なアプローチがある場合は高い自由度、好ましいパターンやパラメータ化されたコマンドがある場合は中程度の自由度、既知の良好なコマンドやシーケンスが 1 つ存在しエージェントがそれを発明すると失敗する場合は低い自由度とします。脆いコマンドは一度だけ書いてください。簡単なバリアントは 1 つの骨格と差分にまとめてください。
• リスクに応じて検証する。 編集後は必ず、bun run test:skill-guards が機械的なガードを約 1 秒で実行します。これには tests/codex-skill-prompt-budget.test.ts の 8,000 バイトの SKILL.md 予算も含まれます。機械的な契約（フロントマター、パス、grep 可能な不変条件）は bun test に入れます。振る舞いを伴う散文の変更には、references/evaluate.md に従った的を絞った eval を Claude と Codex で行うか、レポートに明示的なスキップ理由を記します。テストされていない振る舞いの変更を「参考」として決して出荷しないでください。

モード

依頼内容に応じてモードを選択してください。依頼によっては複数のモードを連続して行う場合があります（レビューから編集に移行する場合など）。

あなたの役割	読むもの	完了条件
新しいスキルを作成する	references/new-skill.md	ワークフローを作成する前に成果の骨子があり、発動ケースが記述され、リポジトリの一覧が更新され、評価を実行したか、実行を省略した正確な理由が記録されている
既存のスキルを変更する	references/edit-skill.md	変更したブロックが基準を満たし、変更と矛盾する記述が残っておらず、検証が実行されている
スキルの変更をレビューする	references/review-skill.md	すべての指摘が、必要な根拠を添えて「変更」「確認」「検討」のいずれかに分類され、各「変更」指摘に条件または担当レイヤーへの移動が明記されている
スキルのレビューコメントに対応する	references/respond-to-review.md	各項目に判定があり、各「変更」項目で担当レイヤーにある課題が解消され、同じブロックが二重に修正されていない

完了報告

各モードの内容に沿った報告で、必ず締めくくってください。変更を伴うモード（新規作成、編集、レビュー対応）では、変更したブロックごとに、現在そのブロックが示す目標、削除した内容とその出典確認の結果、基準に満たないまま意図的に残した点とその範囲外である理由、実施した検証とその結果または省略した正確な理由、スキルの契約内容を大きく変える可能性があり判断しなかった点を報告します。レビューモードでは、分類ごとの指摘と、それぞれに付随する根拠を報告します。呼び出し元に要約用のチャンネルがある場合は、再記述が引き続き役立つかを確認したパスと、確認できなかった事項も報告します。この報告は呼び出し元が指定するチャンネルに出力します。指摘一覧のみを受け付ける場合は、その一覧自体が報告となり、完了条件を満たします。レビューでは何も変更しないため、変更したブロックの項目は含めません。