onehammer-review

Reviews forged feature changes against a saved base SHA and records findings in a durable report.

28|7|Updated Mar 30, 2026
One-click install
npx skills add https://github.com/DK625/OneHammer --skill onehammer-review-dk625
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: onehammer-review
Source: https://github.com/DK625/OneHammer/tree/main/.claude/skills/onehammer-review
Command: npx skills add https://github.com/DK625/OneHammer --skill onehammer-review-dk625

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? After a feature is implemented, teams need a disciplined, read-only review that compares the work against a fixed baseline, tracks findings across multiple rounds, and hands off approved fixes without letting the reviewer accidentally modify code. ## Core Features & Use Cases - Baseline-anchored review: Reads the immutable base_sha from .planning/executions/<feature>/forge-state.json and reviews committed, staged, unstaged, and untracked changes since that point. - Iterative findings tracking: Maintains a durable report at .planning/reviews/<feature>.md with stable finding IDs (REV-001, ...), severity ordering, and verdicts (CHANGES_REQUIRED / OK). - Apply handoff workflow: A separate tab applies only user-approved findings and records changed files plus narrow test results in the same report. - Use Case: After forging a new checkout feature, invoke the review to get a prioritized list of blockers and regressions, approve two findings, and have a second tab apply and verify them while the report tracks resolution across rounds. ## Quick Start Ask the assistant to review the recently forged feature using the saved execution state and write the findings report.

Frequently Asked Questions about onehammer-review

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I review code changes against a specific base commit?

The review reads the immutable base_sha stored in the feature's forge-state.json and inspects everything since that point: committed range base_sha..HEAD, staged, unstaged, and relevant untracked files. You never need to specify the baseline manually.

How to track code review findings across multiple rounds?

Findings are recorded in a durable report at .planning/reviews/<feature>.md with stable IDs like REV-001. Later rounds mark old findings Resolved or keep them Open, never renumbering or deleting them, and add new IDs only for genuinely new issues.

Can the review skill modify or fix the code it reviews?

No. The review is strictly read-only for implementation files, tests, configuration, and migrations. It may only write its report under .planning/reviews/, and a separate apply tab implements only user-approved findings.

Does the review run end-to-end tests automatically?

No. Full E2E runs only when the current user request explicitly asks for it, using Chrome DevTools MCP and existing evidence conventions. By default the review inspects recorded test results and code rather than rerunning tests.

What happens when review findings are approved?

A separate apply tab edits only the approved findings, keeps changes scoped, runs narrow relevant tests, and records changed files, finding IDs addressed, and test results in the Apply Result section of the same report.