# Caseyharalson Orrery Orrery Review

> Review Skill

- Skill: `tomevault-io/caseyharalson-orrery-orrery-review` (Agent Skill, multi-file: 2 files)
- Install (CLI): `npx skillmds@latest add tomevault-io/caseyharalson-orrery-orrery-review`
- Raw SKILL.md: https://api.skillmd.com/api/skills/tomevault-io/caseyharalson-orrery-orrery-review/raw
- Safety review: pending (external: skill-scanner PASS, skillspector PASS)
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: tomevault-io (https://skillmd.com/u/tomevault-io)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/tomevault-io/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.

```json
{
  "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`.

```json
{
  "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](https://tomevault.io/claim/caseyharalson) — claim your Tome and manage your conversions.
<!-- tomevault:4.0:skill_md:2026-04-11 -->