codepatrol-report

Security investigation of one area

Assigned by the codepatrol skill's commander, investigate the one specified area and output a report.

File structure

{このSKILL.mdがあるディレクトリ}/
  SKILL.md               ← この手順書
  REPORT-TEMPLATE.md     ← レポートテンプレート
  reinvestigation.md     ← 既存のレポートがある領域を再調査した時のレポートの書き方

.dev/codepatrol/
  config.md            ← レポートの書き出し先設定
  checklist.md         ← リポジトリ固有の機構と観点の補足。マスターのCHECKLIST.mdと一緒に読む
  targets.md           ← 調査対象リスト
  {領域名}-{YYYY-MM-DD}.md  ← 領域ごとの調査レポート（書き出し先がローカルの場合）

The responsibility boundary between the checklist and the report is in checklist-vs-report.md .

Prerequisites for running this skill

The conditions of the execution environment are the same as "Confirmation of the execution environment" in codepatrol skill . Confirm them yourself before starting the investigation, and if they are not met, do not perform the investigation or output a report; report the unmet conditions and exit
You cannot ask the user questions. Write anything you cannot determine in the final report
For the location to read the code for each repository and the location of.dev/codepatrol/ , follow the commander's instructions. Do not switch branches, pull, or commit
Subagents investigating other areas may be running in parallel in the same working tree

Keep existing issues away from the investigation

The investigation and the review via codex-consultation are performed without knowledge of existing issues. Reading them first would steer the investigation toward the locations of existing issues, causing you to miss again the issues that were missed last time. This is the same reason for not writing issues in the checklist.

Until the review is finished, do not read the body of existing reports, the list of issue names, fix PRs that fixed issues, or pages that summarize issues. This is not limited to those for the area being investigated. Reports for other areas also have issues in this area written as handover notes
Also ask the Codex you consult to not read existing reports
Even for an area that has existing reports, investigate it as an area seen for the first time. Do not do the work of rechecking existing issues one by one
Read existing reports when assembling the report

Procedure

Step 1: Executing the investigation

Read the master's CHECKLIST.md と、.dev/codepatrol/checklist.md . Refer to perspectives by the master's numbers, and refer to repository-specific perspectives by {カテゴリ記号}+{番号} indicated by
Read the code of the specified area:
- Start from the file paths listed in targets.md. Paths are relative to the root of the repository for that area. When there are related repositories,lifecycle-* the repository name is attached to the path of the area
- Explore related files as necessary. If needed to follow the data flow, such as for an area of another repository that forms a pair, read other repositories as well. Write the commits of all repositories read in the report's Source commit
- Follow the data flow in the order of entry point → internal logic → data layer
Apply each perspective of the checklist:
- Investigate only the applicable perspectives (not all perspectives apply to all areas)
- For each perspective, record whether there is a problem and the basis for that judgment
- If a problem is detected, identify the specific code location (file path:line number)

Investigation of areas originating from usage-end events:

lifecycle- In areas starting with , instead of tracing the data flow from the entry point, create a correspondence table of originating event × asset and investigate by filling in the blanks. The perspectives center on J3–J5, and other categories are applied to the entry point of the originating event. Leave the correspondence table in the report as a section of REPORT-TEMPLATE.

The rows of the correspondence table start from the "assets that may remain at usage end" section of the checklist, and are supplemented by finding the unit identifier and indirect assets that can be traced from it through ownership relationships or generation paths. If you trust the list, forgotten assets will also be missed from the correspondence table. For supplemented assets, follow the rules in "When you find an error" below and add them to the checklist as facts
When determining that there is no processing, record the terms and locations you searched. Since you cannot point to a line of code for absence, the record of the search serves as the basis

Depth of investigation:

For each perspective, actually read the code and verify. Do not conclude "no problem" by guesswork
However, balance comprehensiveness and depth. Do not spend excessive time on one perspective; prioritize going through all perspectives once
For simple problems (adding escaping, adding middleware, etc., where the fix is clear), describe the fix concretely in the report
For problems requiring design changes, state that in the report and recommend separate consideration

When you find errors in checklist.md and targets.md:

If you find a discrepancy between the description and the implementation regarding the area you are responsible for, fix it on the spot.

Fix only facts about mechanisms and specifications. Do not write detected problems in the checklist; write them in the report (seechecklist-vs-report.md )
Concurrently running subagents also edit the same file. Re-read immediately before editing, and fix with minimal replacements. Do not rewrite the entire file
Even if you notice perspectives or areas that should be added, do not add them yourself; write them in the final report

Step 2: Critical review via codex-consultation

Have Codex critically review the investigation results from Step 1 through codex-consultation, and detect omissions and gaps. Through a chain of critical thinking, problems that would be overlooked in an independent investigation can be detected. This step cannot be omitted or substituted. Investigation results that have not undergone review via codex-consultation must not be made into a report.

When consulting Codex, always call codex-consultation with the Skill tool.codex exec Do not settle for directly executing .

Divide the perspective categories into 2–4 groups, and call codex-consultation for each group. In areas where the investigation target is small and there are few applicable perspectives, you may combine them into one group and consult once. Guidelines for grouping:

Permission-related: Authorization, tokens/shared URLs, authentication/sessions, etc.
Input/output validation-related: SSRF, XSS, injection, etc.
Other: Files, DoS, information leakage, business logic, configuration, etc.

lifecycle-* In the area, you may divide by the events or asset categories in the correspondence table rather than by perspective category.

Args should include the following:

Args: よく相談して。このリポジトリの開発チームが、自分たちのコードの問題を検出して修正するために{領域名}のセキュリティ調査をしている。
{グループの観点カテゴリ名}について以下の調査結果と修正案を得た。防御側のレビューとして次の点を批判的に見てほしい。

- 調査結果に漏れ抜けはないか、修正案は十分か
- 修正によって壊れる正規の利用フローはないか
- 追加すべき回帰テストは何か。テストフレームワークのテストケース単位で挙げてほしい

観点はマスター {CHECKLIST.mdの絶対パス} と、リポジトリ固有の層 {.dev/codepatrol/ の絶対パス}/checklist.md にある。載っていない観点も積極的に指摘してほしい。
コードは {リポジトリごとの絶対パス} にある。
既存の調査レポートは読まずにレビューしてほしい。
検証でコードを動かす場合は、リポジトリ外の一時ディレクトリで行い、外部サービスには接続しないでほしい。

{該当グループの調査結果と修正案の要約}

Request framing: Codex's provider security filter makes judgments based on the vocabulary of the request. If you make a request using attacker-side vocabulary such as "Are there any attack vectors we are overlooking?", Codex may refuse the investigation, or only the generation of the final answer after completing the investigation may be blocked, causing an abnormal termination. As in the template above, first explain that the purpose of the investigation is to fix our own code, and make the request in a form that asks for a review of the proposed fixes and regression test proposals. In the summary of the investigation results as well, avoid words such as "attack," "exploit," and "forgery," and describe them as issues and their fixes. Carry this framing over into the prompts assembled by codex-consultation and the prompt for the second round as well.

If the final answer is still blocked, pick up the findings from the verification commands and their output left in Codex's execution log. Then, make the request again with a clearer defender-side framing.

Preserve Codex's output: Preserve Codex's output in the working directory passed from the commander. The commander uses it to confirm that the consultation completed through to the end.

If Codex stops: If Codex exits without returning a final answer due to a usage limit, spend cap, authentication error, communication failure, etc.,subagent-consultation do not substitute it with your own reconsideration, and stop the work without outputting a report either.

If it is a temporary error such as a communication failure, you may wait a few minutes and retry once or twice. Usage limits and spend caps will not be resolved immediately, so do not retry
When stopping, write out the investigation results from step 1 and the completed groups' Codex findings and their verification results to the working directory. Report up to which group was completed and what error caused the stop, then exit
When asked to resume, start from the written-out investigation results and continue from the remaining groups

When receiving Codex findings:

Verify the content of the findings yourself by reading the code
Reflect valid findings in the investigation results. In the checklist, reflect only the facts of mechanisms and assets that you have verified yourself, and do not reflect definitive assertions of issues
If there are differing views, describe the reasons for both in the report

Step 3: Report output

REPORT-TEMPLATE.md Read in, and create the report according to its structure. For Investigator, enter your own Agent name and model name, and also include the Codex execution environment obtained by codex-consultation.

Cross-checking with existing reports:

Before assembling the report, read the existing reports and compare them against the current issue.

Check the issue names in the latest reports from other areas. This is to avoid giving different names to the same issue. If you have been given a list of issue names by the coordinator, use it. If the same issue as yours already has a name, write it according to "References to issues in other areas" in REPORT-TEMPLATE.
If there is an existing report in the area you are responsible for,reinvestigation.md and follow it.

If the output destination is Cosense:

Assemble the entire report as a single text:

Line 1: config.md The page name following the title convention. The date is the date the page is created. If a page with the same name already exists, do not overwrite it; create a separate page by appending the time to the date.
Line 2: [{hubページ名}] — link to the hub page. This aggregates it as a backlink.
Line 3 onward: the body in Cosense notation representing the structure of REPORT-TEMPLATE, with headings expressed by indentation hierarchy (notation follows the cosense skill). Do not output HTML comments in the template or {プレースホルダ} and do not write "Investigated at" because it is held by the title's date and the page metadata.

Create a new page with the assembled body (write operations follow the cosense skill).

If writing fails, write the report to the working directory and report that fact.

If the output destination is local:

.dev/codepatrol/{領域名}-{YYYY-MM-DD}.md Write to. The date is the date the report is written. If a file with the same name already exists, do not overwrite it;{領域名}-{YYYY-MM-DD}-{HHmm}.md create a separate file by appending the time to the date as in.

Report to the coordinator

The location and title of the created report, and the commit for each repository read
List of issues. Severity, name, one-line summary. In the case of a re-investigation, whether it is an issue that was also reported last time or a new issue this time
In the case of a re-investigation, the items fixed since last time and the previous issues not detected this time
Names of issues likely to overlap with other areas, and their files
Items requiring verification in the actual environment
The number of times consulted Codex and the groups of perspectives, the adopted and non-adopted points, and the location of Codex's output
checklist.md と targets.md The locations fixed and the perspectives/areas that were not fixed but should be added
Ambiguous points and difficult points in procedures and rules
If interrupted, the reason for the interruption and the location of the intermediate results