Comet Review

3. Establish the implementation diff

1. Run git status --short --untracked-files=all to list all staged, unstaged, and untracked files in the worktree.
2. Use the current change's requirements, workspace binding, Git history, and worktree state to establish the most reliable relevant scope. For Classic, prefer a valid plan base-ref; if it is absent or invalid, fall back to the state base_ref. The two values do not need to match. Only when both values are invalid is the Classic baseline missing. For Native, use the workspace relationships in state and the evidence defining the current candidate's implementation scope.
3. Inspect the complete diff from the reliable baseline to the current worktree, including committed, staged, and unstaged changes. Read all untracked files belonging to this change, including source, tests, documentation, configuration, and metadata such as SKILL.md and agents/openai.yaml. Clearly identify them as untracked.
4. Exclude changes clearly belonging to other changes or unrelated user work. Ask the user only when ambiguity would materially affect the review conclusions. Otherwise, continue with the available evidence and state your scope assumptions in the report.

If the available evidence still cannot establish a reliable, verifiable baseline, review the visible worktree diff and prominently label the review scope as incomplete.

4. Perform the review

Review the requirements, tasks, and current diff, focusing only on:

• Implementation correctness and clear logic errors.
• Security, permission, and path-boundary risks.
• Error handling, compatibility, and important edge cases.
• Missing tasks or implementation that contradicts explicit requirements for this change.
• Whether tests cover the changed behavior and whether the available test evidence supports the conclusions.

Do not report style preferences, unrelated refactoring, or speculation without a concrete impact. Each finding must identify a file and line number and explain the input or situation that triggers the error or risk. Lower its severity or place it under “Open questions” when evidence is insufficient.

Use only these severity levels:

• CRITICAL: security compromise, data loss, or an unusable core workflow.
• IMPORTANT: a clear correctness error, missing core acceptance requirement, or likely regression.
• WARNING: a real, non-blocking edge-case risk or test gap.
• SUGGESTION: a concrete improvement that does not affect current correctness.

5. Report the results

List findings first, ordered by severity. Use this format:

[IMPORTANT] Short title — path/to/file.ts:123
Impact: The input or situation and the resulting error.
Evidence: The specific relationship to the diff, task, spec, or verification record.

Then include:

• Review scope: workflow, change, phase, baseline, included diffs, and any scope limitations.
• Evidence status: the test, build, and verification records inspected and whether they still apply to the current changes. Do not rerun tests.
• Open questions: only questions that actually prevent a judgment.
• Conclusion: the finding count, or an explicit “No concrete findings.”

Even with no findings, state remaining risks and checks not performed. End with this reminder:

This was a read-only manual review. It does not advance the Comet phase and cannot replace /comet-verify or Native Verify.

If the user subsequently requests fixes, treat that as a new write task: leave this Skill and resume development under the repository's current workflow rules.