Caseyharalson Orrery Orrery Review

Review Skill

When to Use

Use this skill after a step execution to review the changes and provide feedback to an editor agent.

Triggers:

• You are invoked by the orchestrator for a review phase.
• You receive step context, list of modified files, and a git diff.

Do not apply fixes yourself. Only review and report.

How to Do It

Step 1: Read Context

• Read the step description and requirements provided by the orchestrator.
• Read the git diff to understand the changes.

Step 2: Read Full Files (Required)

For every modified or added file, read the full file contents to understand broader context. Do not review only the diff.

Step 3: Review Criteria

Check the changes against these criteria:

• Correctness: Does the code do what it should? Any logic mistakes?
• Bug risks: Edge cases, null handling, off-by-one errors.
• Security: Injection, auth issues, data exposure, unsafe inputs.
• Performance: Obvious inefficiencies, N+1 patterns, memory leaks.
• Code quality: Readability, naming, complexity, maintainability.
• Architecture: Duplication, separation of concerns, module boundaries.
• Error handling: Errors handled gracefully, no silent failures.
• Testing: Test coverage gaps, testability, missing edge cases.

Step 4: Prioritize Feedback

• Mark blocking issues that must be fixed (bugs, security, correctness).
• Mark suggestions for improvements that are optional or non-critical.
• Keep feedback concise and actionable; avoid style-only nits.

Step 5: Decide Status

• approved if there are no blocking issues.
• needs_changes if any blocking issue exists.

Output Contract (CRITICAL)

Return a single JSON object to stdout.

{
  "status": "approved | needs_changes",
  "feedback": [
    {
      "file": "path/to/file.js",
      "line": 42,
      "severity": "blocking | suggestion",
      "comment": "Explain the issue and expected fix."
    }
  ]
}

Rules:

1. Output valid JSON on a single line.
2. No markdown code blocks in your final output.
3. line is optional if not applicable.
4. feedback may be empty only when status is approved.

Example

Scenario: Missing null check in src/service.js.

{
  "status": "needs_changes",
  "feedback": [
    {
      "file": "src/service.js",
      "line": 87,
      "severity": "blocking",
      "comment": "Guard against null `user` before accessing `user.id` to avoid runtime errors."
    }
  ]
}

Converted and distributed by TomeVault — claim your Tome and manage your conversions.