Back to Details

sanity-review

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

PRレビュー報告書の作成手順書

PR Review Report Creation Procedure Manual

feature/bugfix/refactoring PRをレビューし、レビュー報告書を作成する。 通常のコードレビューを補助するだけでなく、実装者が自らPRをレビューするためのセルフレビューツールでもある。人間のレビュアーに見せられる正気なpull requestに仕上げる事を目的とする。
Reviews feature/bugfix/refactoring PRs and creates review reports. In addition to supporting regular code reviews, it also serves as a self-review tool for implementers to review their own PRs. The goal is to produce a sound pull request that can be presented to human reviewers.

対象外

Out of Scope

  • ライブラリ更新PR（dependabot/renovatebot等）は 
    library-update-review
    skillの対象であり、このスキルの対象外
  • Library update PRs (from dependabot/renovatebot, etc.) are covered by the 
    library-update-review
    skill and are out of scope for this skill

手順

Procedure

手順0: PR情報の取得と報告書の出力先の確認

Step 0: Retrieve PR Information and Confirm Report Output Destination

引数でPR番号またはURLが指定されている場合はそのPRを対象とする。 指定がない場合は、現在のブランチに紐づくPRを自動検出する。
いずれの場合も、以下のコマンドでPR情報を取得する:
gh pr view {PR番号またはURL} --json number,title,body,url,author,comments,headRefName
自動検出の場合は 
{PR番号またはURL}
を省略する。
PRが見つからない場合はユーザーに報告して終了する。
PRタイトル、PR番号、ブランチ名は報告書のヘッダーに使用する。Reviewed atには現在の日時（YYYY-MM-DD HH:mm:ss）を、Reviewerには自分のAgent名を記入する。
以下の情報を取得する:
  1. PR本文（概要欄）
  2. PRコメント: 
    gh pr view
    の comments
  3. インラインレビューコメント: 
    gh api repos/{owner}/{repo}/pulls/{number}/comments --paginate
  4. PRレビュー: 
    gh api repos/{owner}/{repo}/pulls/{number}/reviews --paginate
  5. 差分: 
    gh pr diff {number}
If a PR number or URL is specified as an argument, that PR will be the target. If no specification is provided, the PR associated with the current branch will be automatically detected.
In either case, retrieve PR information using the following command:
gh pr view {PR number or URL} --json number,title,body,url,author,comments,headRefName
For automatic detection, omit 
{PR number or URL}
.
If no PR is found, notify the user and terminate.
The PR title, PR number, and branch name will be used in the report header. Enter the current date and time (YYYY-MM-DD HH:mm:ss) in "Reviewed at", and your own Agent name in "Reviewer".
Retrieve the following information:
  1. PR body (description)
  2. PR comments: comments from 
    gh pr view
  3. Inline review comments: 
    gh api repos/{owner}/{repo}/pulls/{number}/comments --paginate
  4. PR reviews: 
    gh api repos/{owner}/{repo}/pulls/{number}/reviews --paginate
  5. Diff: 
    gh pr diff {number}

報告書の出力先の確認

Confirm Report Output Destination

レビュー作業を始める前に、AskUserQuestionツールで報告書の出力先を確認する:
  • チャットとpull request（推奨）: レビュー報告書を会話に出力し、同じ内容をPRにもコメントとして投稿する
  • チャット: レビュー報告書を会話にだけ出力する
ユーザーが明示的に出力先を指定している場合はこの確認を省略し、指定に従う。
Before starting the review work, confirm the report output destination using the AskUserQuestion tool:
  • Chat and pull request (recommended): Output the review report to the conversation, and post the same content as a comment on the PR
  • Chat: Output the review report only to the conversation
If the user has explicitly specified the output destination, skip this confirmation and follow the specification.

手順1: 対話コンテキストの読み込み

Step 1: Load Conversation Context

以下の順序で対話コンテキストを探す:
Search for conversation context in the following order:

1-1. PRコメント欄を確認

1-1. Check PR Comment Section

PRコメントの中に「対話コンテキスト」というタイトルを含むコメントがないか確認する。 見つかった場合はその内容を対話コンテキストとして使用する。
Check PR comments for any comment containing the title "Conversation Context". If found, use its content as the conversation context.

1-2. .dev/contexts/ を確認

1-2. Check .dev/contexts/

ブランチ名をサニタイズ（
/ \ : * ? " < > |
を 
-
に置換）し、
.dev/contexts/{サニタイズ済みブランチ名}.md
を探す。 見つかった場合はReadツールで読み込む。
Sanitize the branch name (replace 
/ \ : * ? " < > |
with 
-
), and look for 
.dev/contexts/{sanitized-branch-name}.md
. If found, load it using the Read tool.

1-3. 両方見つからない場合

1-3. If Neither Is Found

AskUserQuestionツールで以下を確認する:
  • 対話コンテキストなしで続行: 手順6（考慮漏れの確認）はスキップする
  • 中断: ユーザーに対話コンテキストの準備を依頼する
Confirm the following using the AskUserQuestion tool:
  • Continue without conversation context: Skip Step 6 (Check for Oversights)
  • Abort: Ask the user to prepare the conversation context

手順2: pull request概要欄の品質評価

Step 2: Quality Assessment of Pull Request Description

この手順はコードを読む前に行う。 コードの整合性確認に引っ張られて概要欄の構造的問題を見落とすことを防ぐため。
実装者は正気ではないかもしれない。よくわからずにPR概要欄を書いたり、AIに生成させてそのまま貼っているかもしれない。 この手順では概要欄だけを読み、レビュアーがこの概要欄を読んで「変更の妥当性を判断できるか」を評価する。
Perform this step before reading the code. This is to prevent overlooking structural issues in the description due to being distracted by code consistency checks.
The implementer may not have fully thought through their work. They might have written the PR description without fully understanding it, or just pasted AI-generated content as-is. In this step, only the description field is read to evaluate whether a reviewer can "judge the validity of the changes" by reading this description.

PR概要欄チェックリスト

PR Description Checklist

以下の4項目を 必ず全て 評価し、結果をメモする。全項目を評価してから次の手順に進む:
  1. 変更前の動作・問題が説明されているか: レビュアーは変更の妥当性を判断するために、変更前の状態を知る必要がある。「何をやったか」だけでは「もしかしたら変更前の動作の方が正しかったのでは？」という疑問が残る
  2. 「問題→解決」や「現状→修正」のペアで書かれているか: 新機能の場合は目的・動機でも可。ただし「やったこと」だけの一方通行な説明は不十分
  3. 変更の範囲が明確か: 何を変えて、何を変えていないのかがわかるか
  4. 実装者自身の理解が見えるか: AIが生成した文章をそのまま貼っただけでなく、実装者が何を考えてこの変更をしたのかが伝わるか
Be sure to evaluate all four items below and note the results. Proceed to the next step only after evaluating all items:
  1. Is the pre-change behavior/problem described?: Reviewers need to know the state before the change to judge its validity. Only describing "what was done" leaves the question: "Wait, maybe the original behavior was more correct?"
  2. Is it written in pairs like "Problem → Solution" or "Current State → Fix"?: For new features, purpose/motivation is also acceptable. However, a one-sided description only listing "what was done" is insufficient.
  3. Is the scope of changes clear?: Can you tell what was changed and what was not changed?
  4. Is the implementer's own understanding visible?: Does it convey what the implementer was thinking when making this change, rather than just pasting AI-generated text as-is?

外部Agent相談の共通方針

Common Policy for Consulting External Agents

手順3・手順4・手順5では外部Agentにセカンドオピニオンを求める（ただし手順4の「長期視点で命名・設計を考察する」サブセクションは対象外）。手順6では疑わしい点がある場合に限り外部Agentへ相談する。以下のフォールバック順序に従い、推測で判断せず実際に呼び出して試すこと:
自分自身がCodex CLIの場合は2から開始する。そうでない場合は1から開始する。
  1. Skill toolで 
    codex-consultation
    を呼び出す。失敗した場合は2へ進む
  2. Skill toolで 
    subagent-consultation
    を呼び出す。失敗した場合は3へ進む
  3. main agentが単独で作業を実行する
フォールバックが発生した場合や、外部Agentが利用できなかった場合は、報告書の「レビュー作業において発生した問題」セクションに記載する。
3（main agent単独実行）にフォールバックした場合は、このスキルのコアである批判的思考の連鎖（互いの主張を検討・反論しあい、正確性と網羅性を向上するプロトコル）が機能していないことを意味する。往復検証が欠落した状態でのレビューは本来の精度を持たないため、報告書の「レビュー作業において発生した問題」セクション冒頭に、以下の文言をそのままbold段落として記載すること:
⚠ 警告: 批判的思考の連鎖が機能していません、実行環境が正気である事を疑ってください
各手順では、外部Agentに渡すArgsの内容と、結果の扱い方を記載する。
In Steps 3, 4, and 5, seek a second opinion from external Agents (however, the subsection "Consider Naming and Design from a Long-Term Perspective" in Step 4 is excluded). In Step 6, consult external Agents only if there are questionable points. Follow the fallback order below, and actually call and test instead of judging by speculation:
If you yourself are Codex CLI, start from 2. Otherwise, start from 1.
  1. Call 
    codex-consultation
    using the Skill tool. If it fails, proceed to 2.
  2. Call 
    subagent-consultation
    using the Skill tool. If it fails, proceed to 3.
  3. The main agent performs the work alone.
If a fallback occurs or external Agents are unavailable, document this in the "Issues Encountered During Review Work" section of the report.
If fallback to 3 (main agent solo execution) occurs, it means the chain of critical thinking that is the core of this skill (a protocol where parties examine and refute each other's claims to improve accuracy and comprehensiveness) is not functioning. A review without reciprocal verification does not have its intended accuracy, so be sure to include the following text as a bold paragraph at the beginning of the "Issues Encountered During Review Work" section of the report:
⚠ Warning: The chain of critical thinking is not functioning. Question whether the execution environment is sound.
Each step describes the content of Args passed to external Agents and how to handle the results.

手順3: 実装者の説明と実装の整合性確認

Step 3: Verify Consistency Between Implementer's Description and Implementation

この手順の目的は、概要欄やコメントでの説明と実際のコードが一致しているかを確認する、ドキュメントとコードの読み合わせ である。
The purpose of this step is cross-referencing documentation and code to confirm that the descriptions in the PR description and comments match the actual code.

重要: 実装者の発言のみを拾う

Important: Only Collect Statements from the Implementer

PR概要欄の author と、各コメントの author を照合し、実装者本人の発言のみを実装の説明として扱う。 他の人が書いた応援コメント、機能に対する期待を込めたコメント、質問等は、実装の説明ではない。 これらを実装の説明と混同すると、整合性の判断を誤る。
Cross-reference the author of the PR description with the author of each comment, and treat only the implementer's own statements as descriptions of the implementation. Supportive comments written by others, comments expressing expectations for features, questions, etc., are not descriptions of the implementation. Confusing these with implementation descriptions will lead to incorrect consistency judgments.

確認事項

Check Items

  1. PR概要欄の説明と、実際の差分が一致しているか
  2. インラインレビューコメントでの実装者の説明と、実際のコードが一致しているか
  3. PRレビューの本文（top-level review comment）での実装者の説明と、実装が一致しているか
  4. 対話コンテキストの内容と、実装が一致しているか（対話コンテキストがある場合）
齟齬を発見した場合は具体的に記録する。
  1. Does the description in the PR match the actual diff?
  2. Do the implementer's explanations in inline review comments match the actual code?
  3. Do the implementer's explanations in the PR review body (top-level review comment) match the implementation?
  4. Does the content of the conversation context match the implementation? (if conversation context exists)
If discrepancies are found, record them specifically.

外部Agentによる整合性確認

Consistency Check by External Agents

Agent自身の確認に加えて、外部Agentにも差分と概要欄の整合性を確認させる。 別の視点でコードを読むため、Agentが見落とした齟齬を発見できる可能性がある。
「外部Agent相談の共通方針」に従い、以下のArgsで呼び出す:
Args: よく相談して。PR #{番号} の概要欄の説明と実際の差分に齟齬がないか確認してほしい。{概要欄の要約と確認ポイント}
外部Agentの指摘を受け取ったら、自分の確認結果と照合し、見落としがなかったか確認する。
In addition to the Agent's own checks, have external Agents also verify the consistency between the diff and the description. Having another perspective on the code may uncover discrepancies that the Agent missed.
Follow the "Common Policy for Consulting External Agents" and call with the following Args:
Args: Please consult thoroughly. I want you to check if there are any discrepancies between the description in PR #{number} and the actual diff. {summary of description and check points}
After receiving the external Agent's feedback, cross-reference it with your own check results to confirm if there were any oversights.

手順4: 命名・設計パターンの一貫性

Step 4: Consistency of Naming and Design Patterns

この手順の目的は、実装が既存のコードベースの慣習と一致しているかを確認する、コードベースの読み解き である。 バグ・脆弱性を調べる前にコードベースを理解することで、後続の調査の精度が上がる。
The purpose of this step is understanding the codebase by confirming that the implementation matches the conventions of the existing codebase. Understanding the codebase before investigating bugs and vulnerabilities improves the accuracy of subsequent investigations.

確認事項

Check Items

  1. 命名規則の一致
    • ファイル名・関数名・変数名・クラス名が、既存コードの命名パターンと揃っているか
    • 機能の正式名称を歯抜けに省略した名前が導入されていないか
  2. 設計パターンの一致
    • 構造・module分割・責務の切り方が、既存の類似機能と揃っているか
    • 既存の抽象化を活用しているか、重複した実装を作っていないか
齟齬を発見した場合は具体的に記録する。
  1. Consistency of Naming Conventions
    • Do file names, function names, variable names, and class names match the naming patterns of existing code?
    • Have names that omit parts of the official feature name been introduced?
  2. Consistency of Design Patterns
    • Do the structure, module division, and responsibility allocation match those of existing similar features?
    • Are existing abstractions utilized, or is there duplicate implementation?
If discrepancies are found, record them specifically.

外部Agentによる確認

Verification by External Agents

Agent自身の確認に加えて、外部Agentにも命名・設計パターンの一貫性を確認させる。
「外部Agent相談の共通方針」に従い、以下のArgsで呼び出す:
Args: よく相談して。PR #{番号} で追加・変更された命名と設計パターンが、既存のコードベースの慣習と一致しているか確認してほしい。{変更概要}
外部Agentの指摘を受け取ったら、自分の確認結果と照合し、見落としがなかったか確認する。
In addition to the Agent's own checks, have external Agents also verify the consistency of naming and design patterns.
Follow the "Common Policy for Consulting External Agents" and call with the following Args:
Args: Please consult thoroughly. I want you to check if the naming and design patterns added/modified in PR #{number} match the conventions of the existing codebase. {change summary}
After receiving the external Agent's feedback, cross-reference it with your own check results to confirm if there were any oversights.

長期視点で命名・設計を考察する

Consider Naming and Design from a Long-Term Perspective

将来、コードベースが拡張されたときに、現在の命名・設計が禍根となりうるかを考察する。 既存コードとの一致（事実判定）とは異なり、これは議論のタネを提供して人間の想像力を掻き立てるための作業である。
気になった点があれば、「懸念・反証・結論または保留」を押さえた自問自答形式で書き出す。 これはAgent自身の見解なので、通常の段落として記載する。1論点につき2〜3段落程度でよい。 無理に結論を出さなくてよい。気になる点がなければ「特になし」と記載する。 この考察セクションは外部Agentには振らず、skill実行元のAgentが自分で考える。
出力例:
markdown
「access-token」という名前は、現状はユーザーとサービス間のtokenしか指さないため問題はない。
ただ今後、外部サービスとの接続用のtokenが登場した場合は、概念衝突が起きる可能性がある。

そうなったら `user-access-token` のように主体を名前に含める必要が出るかもしれない。
もっとも、現時点で外部サービス連携を近い将来に追加する計画は見えていないため、今すぐ修正すべき問題ではないと判断する。

「member-metrics」という名前についても、将来 project member 以外の member 概念が増えた場合には曖昧になる余地がある。
一方で既存コードでは `Member` は project member を指す語として定着しており、短期的には大きな問題はなさそうである。

したがって現時点では問題なしと判断する。
ただし、将来 organization member など別種の member 概念を導入するなら、命名の見直しは必要になる。
Consider whether the current naming and design could become a source of problems when the codebase is expanded in the future. Unlike consistency with existing code (a factual judgment), this is an exercise to provide seeds for discussion and stimulate human imagination.
If there are points of concern, write them out in a self-questioning format that covers "concerns, counterarguments, conclusion or reservation". Since this is the Agent's own opinion, it should be written as regular paragraphs. About 2-3 paragraphs per point is sufficient. You don't have to force a conclusion. If there are no points of concern, write "None in particular". This consideration section is not assigned to external Agents; the Agent executing the skill thinks about it themselves.
Output example:
markdown
The name "access-token" is not a problem currently because it only refers to tokens between users and services.
However, if tokens for connecting with external services are introduced in the future, there is a possibility of conceptual conflict.

When that happens, it may become necessary to include the subject in the name, like `user-access-token`.
However, since there are currently no visible plans to add external service integrations in the near future, I judge that this is not an issue that needs to be fixed immediately.

The name "member-metrics" also has room for ambiguity if the concept of "member" expands beyond project members in the future.
On the other hand, in existing code, `Member` is established as a term referring to project members, so it seems unlikely to be a major problem in the short term.

Therefore, I judge that there is no problem at this time.
However, if other types of member concepts such as organization members are introduced in the future, a review of the naming will be necessary.

手順5: バグ・脆弱性の調査

Step 5: Investigation of Bugs and Vulnerabilities

「外部Agent相談の共通方針」に従い、外部Agentにコードレビューを依頼する。 引数には、PRの変更概要、差分の要約、確認してほしいポイントを含める。
深さの指定を引数に含めること。consultation系スキルは深さが未指定だとユーザーに聞き返すため、レビューの流れが中断される:
Args: よく相談して。PR #{番号} のコードレビューをお願いします。{変更概要と確認ポイント}
Follow the "Common Policy for Consulting External Agents" and request a code review from external Agents. Include the PR change summary, diff summary, and points to check in the arguments.
Be sure to include a depth specification in the arguments. Consultation skills will ask the user back if the depth is not specified, which interrupts the review flow:
Args: Please consult thoroughly. Please conduct a code review of PR #{number}. {change summary and check points}

結果の検証

Result Verification

外部Agentの指摘を鵜呑みにしない。以下を行う:
  • 外部Agentが指摘したポイントを、自分でコードを読んで検証する
  • 外部Agentが見落としている可能性がある領域を意識的に探す
  • 外部Agentの指摘と自分の見解が食い違う場合は、両方の理由を記録する
Do not blindly accept the external Agent's feedback. Do the following:
  • Verify the points raised by the external Agent by reading the code yourself
  • Consciously look for areas that the external Agent may have overlooked
  • If the external Agent's feedback differs from your own opinion, record the reasons for both

手順6: 対話コンテキストの再読み・考慮漏れ確認

Step 6: Re-read Conversation Context and Check for Oversights

対話コンテキストがない場合はこの手順をスキップする。
コードレビューは作業結果のダブルチェックではない。結果ではなくプロセスをレビューする。
やった事はコードを読めばわかる。検討した上でやらなかった事こそ、設計のレビューに必要な情報である。 対話コンテキストに書かれた設計判断・却下理由・意図的な非対応の「プロセス」が正しいかを検証する。
対話コンテキストを改めて精読し、以下を検証する:
If there is no conversation context, skip this step.
Code review is not a double-check of work results. Review the process, not just the result.
What was done can be understood by reading the code. What was not done after consideration is the information necessary for design review. Verify whether the "process" of design decisions, rejection reasons, and intentional non-implementation written in the conversation context is correct.
Re-read the conversation context carefully and verify the following:

6-1. 設計判断の根拠

6-1. Basis for Design Decisions

対話コンテキストに書かれた設計判断の理由が、コードの実態と一致しているか。
Do the reasons for design decisions written in the conversation context match the actual state of the code?

6-2. 却下した代替案の再評価

6-2. Re-evaluation of Rejected Alternatives

対話コンテキストの「却下した代替案」セクションから、各代替案を1つずつ抜き出して再評価する:
  • 不採用の理由は妥当か。本当に公平に比較したか
  • 見落とした利点や、過大評価したデメリットはないか
  • 採用案と却下案の比較に使われた前提条件は正しいか
Extract each alternative one by one from the "Rejected Alternatives" section of the conversation context and re-evaluate them:
  • Is the reason for rejection valid? Was the comparison truly fair?
  • Are there any overlooked advantages or overestimated disadvantages?
  • Are the prerequisites used to compare the adopted and rejected proposals correct?

6-3. 失敗した試行のプロセス検証

6-3. Process Verification of Failed Attempts

「試したがダメだった」と記載されているものについて、結果だけでなく試し方自体を疑う:
  • 前提条件は正しかったか
  • 実行手順に見落としはなかったか
  • 判断基準（「ダメ」と判定した根拠）は妥当だったか
  • 別の条件で試せば結果が変わる可能性はないか
For items described as "tried but didn't work", question not just the result but the way it was tried itself:
  • Were the prerequisites correct?
  • Were there any oversights in the execution procedure?
  • Was the judgment criterion (the basis for determining "it didn't work") valid?
  • Is there a possibility that the result would change if tried under different conditions?

6-4. 意図的に対応しない事項の妥当性

6-4. Validity of Intentionally Unaddressed Items

「やらない」と決めたものについて:
  • 「やらない」理由は、今の実装を踏まえても妥当か
  • 実装の結果、前提が変わって「やるべき」に変わっていないか
For items decided to "not do":
  • Is the reason for "not doing" still valid considering the current implementation?
  • Has the premise changed as a result of the implementation, making it something that "should be done"?

6-5. 記載されている事実の正確性

6-5. Accuracy of Stated Facts

対話コンテキストに書かれた「事実」が本当に正しいか、コードを読んで検証する。
疑わしい点がある場合は、「外部Agent相談の共通方針」に従い外部Agentにも相談する。Argsに「よく相談して」を含めること。
Verify whether the "facts" written in the conversation context are truly correct by reading the code.
If there are questionable points, consult external Agents according to the "Common Policy for Consulting External Agents". Be sure to include "Please consult thoroughly" in the Args.

手順7: レビュー報告書の作成

Step 7: Create the Review Report

このSKILL.mdと同じディレクトリにある TEMPLATE.md を読み込み、その形式に従って報告書を作成する。
報告書は会話に出力する。 手順0でPRへのコメント投稿を行うと決めた場合は、同じ内容をPRにもコメントとして投稿する。
Load TEMPLATE.md located in the same directory as this SKILL.md, and create the report according to its format.
The report will be output to the conversation. If it was decided in Step 0 to post a comment to the PR, post the same content as a comment on the PR.

報告書作成のガイドライン

Report Creation Guidelines

  • pull request概要欄 > サマリー: 実装者の説明を引用・抜粋してbefore-afterで整理する。想像で補って勝手に書かない。実装者の説明が不十分な場合は素直にその旨を指摘する
  • pull request概要欄 > 品質評価: 手順2のチェックリスト結果をOK/NG/該当なしで記入する。NGの場合は具体的に何が不足しているかを記載する
  • レビュー作業において発生した問題セクション: レビュー手順をスキップした場合は、外的要因（ツールが利用できなかった等）かAgentの判断かを区別して記載する。問題がない場合は「特になし」と記載する
  • 結論セクション: 全体の総合判断と推奨アクションを記載する
  • 全体を通じて、レビュアーが「この変更は妥当か」を判断するための材料を提供することを意識する
  • pull request description > Summary: Organize the implementer's explanations in a before-after format by quoting and excerpting. Do not make up content based on imagination. If the implementer's explanation is insufficient, point that out honestly.
  • pull request description > Quality Assessment: Fill in the checklist results from Step 2 as OK/NG/Not applicable. If NG, specify what is insufficient.
  • Issues Encountered During Review Work section: If review steps were skipped, document whether it was due to external factors (e.g., tools unavailable) or an Agent decision. If there are no issues, write "None in particular".
  • Conclusion section: Describe the overall comprehensive judgment and recommended actions.
  • Throughout the report, keep in mind that the goal is to provide materials for reviewers to judge "whether this change is valid".

関連スキル

Related Skills

  • codex-consultation: Codex CLIと相談するスキル。手順3・手順4・手順5・手順6で外部Agentの第一候補として使用する
  • subagent-consultation: Agentツール（subagent）と相談するスキル。codex-consultationが利用できない場合のフォールバック先
  • conversation-context-import: 対話コンテキストを読み込むスキル。手順1の背景知識
  • conversation-context-export: 対話コンテキストを書き出すスキル。対話コンテキストの形式の背景知識
  • library-update-review: ライブラリ更新PRのレビュースキル。このスキルの対象外であるPRの種類
  • codex-consultation: Skill for consulting with Codex CLI. Used as the first choice for external Agents in Steps 3, 4, 5, and 6.
  • subagent-consultation: Skill for consulting with Agent tools (subagents). Fallback destination when codex-consultation is unavailable.
  • conversation-context-import: Skill for loading conversation context. Background knowledge for Step 1.
  • conversation-context-export: Skill for exporting conversation context. Background knowledge for conversation context format.
  • library-library: library for library library library?