Inline review

Skill claude-hangar/claude-hangar/core/skills/inline-review

Production-grade configuration management for Claude Code. Hooks, agents, skills, multi-project orchestration.

Install

npx -y skills add claude-hangar/claude-hangar --skill inline-review

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

One thing to look at

1 stars1 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.

What its author says it does

Copied from the file, not written here

Quick self-review checklist after code changes. Lightweight alternative to adversarial-review. Use when: "review my changes", "self-review", "quick review", "check my work", or automatically after significant edits.

SKILL.md

3.6 KB, as published. Nobody here has run it

/inline-review — Quick Self-Review

Fast, inline self-review checklist that runs after code changes. Catches the most common issues without the overhead of a full adversarial review.

Inspired by: Superpowers v5.0.6 removed subagent review loops (25 min overhead) and replaced them with an inline self-review checklist that produces identical quality scores.

When to Use

After completing a feature or fix, before committing
After a series of edits, to catch accumulated issues
When /adversarial-review feels like overkill for the change size
As a habit after every significant code change

The 8-Point Checklist

Run through these checks on the changed code. Each check takes ~5 seconds.

1. Placeholder Scan

Are there any TODO, FIXME, HACK, placeholder values, or stub implementations in the changes?

2. Internal Consistency

Do the changes contradict anything in the existing codebase? Do function signatures match their call sites? Do types match?

3. Scope Check

Did the changes stay within the original task scope? Were any "while we're at it" additions made that weren't requested?

4. Error Handling

Are error cases handled? Do new functions have appropriate error paths? Are errors logged or silenced?

5. Security Quick-Check

No secrets or PII in code?
User input validated at boundaries?
No eval(), innerHTML, or SQL concatenation with user data?

6. Edge Cases

What happens with: empty input, null/undefined, very large input, concurrent access, network failure?

7. Test Coverage

Do the changes need tests? If tests exist, do they still pass? Are new code paths covered?

8. Cleanup

No debug console.log or print statements left?
No commented-out code blocks?
No unused imports or variables?
File formatting consistent?

Modes

`/inline-review auto`

Self-review the most recent changes in this session:

Identify all files changed in this session (via git diff or session context)
Run the 8-point checklist against each changed file
Report findings or "All clear"

`/inline-review diff`

Review staged changes (git diff --cached):

Read the staged diff
Run the 8-point checklist
Report findings inline with diff context

`/inline-review file <path>`

Review a specific file:

Read the file
Run the 8-point checklist
Report findings with line numbers

Output Format

INLINE REVIEW — {n} file(s) checked

✓ Placeholders: None found
✓ Consistency: OK
⚠ Scope: Added error-retry logic that wasn't in the task → discuss with user
✓ Error handling: OK
✓ Security: OK
⚠ Edge cases: processItems() doesn't handle empty array
✓ Test coverage: Existing tests pass
✓ Cleanup: OK

Result: 2 items to address before committing

Key Principle

Speed over depth. This is a 30-second checklist, not a 25-minute subagent review. If something needs deep analysis, recommend /adversarial-review instead.