Run any Skill in Manus with one click

review-plan

Stars27

Forks2

UpdatedJune 28, 2026 at 13:09

Stress-test a plan file before committing to implementation. Catches architectural mistakes, convention violations, and missing dependencies while changes are still cheap. Invoked directly, not routed from coding-process.

Installation

Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.

Run Skill in Manus

Source

hawkyre

hawkyre/hawk-skills

View GitHub Repository View Creator Repositories

Download

Run Skill in Manus

Related occupationsSOC

Based on SOC occupation classification

Software DevelopersComputer and Mathematical Occupations·SOC 15-1252

SKILL.md

readonly

name	review-plan
description	Stress-test a plan file before committing to implementation. Catches architectural mistakes, convention violations, and missing dependencies while changes are still cheap. Invoked directly, not routed from coding-process.

Review a Plan

Process

Load the plan and its context: Read the plan file(s) and any siblings. Plans are HTML — .plans/<slug>/plan.html (single-PR) or the overview.html / data-model.html / plan.html / decisions.html / verification.html / contracts.html set (multi-PR), plus inc-<N>-notes.md. Legacy plans may still be Markdown (*.md) — read whichever exists. Machine fields live on data-* attributes (increments: data-inc, data-size, data-depends, data-files, data-done); read those when checking dependency ordering and done-criteria. Read the relevant .agents/standards/ files that apply to the planned work.
Review for technical soundness:
- Are the architectural decisions correct given the codebase?
- Are the dependencies between increments properly ordered?
- Are there missing increments or gaps in the sequence?
- Will each increment actually pass CI independently?
Review for convention compliance:
- Does the plan follow the project's standards?
- Are files placed in the right directories?
- Does the naming follow conventions?
- Are there patterns in .agents/common-mistakes/ that the plan risks repeating?
Review for conversation fidelity: If reviewing a plan produced during an active conversation, check whether all decisions, constraints, and answered questions from the discussion are captured in the plan. A correct plan that doesn't match what was agreed is worse than a slightly imperfect plan that does. Skip this step if reviewing a plan file without conversation context.
Review for implementability:
- Is each increment scoped tightly enough to implement in one session?
- Are the "done criteria" specific and verifiable?
- Are there ambiguities that will force the implementer to make undocumented decisions?
Summarize findings:
- MUST FIX — Issues that would cause implementation failure or architectural problems
- SHOULD FIX — Issues that would cause friction or technical debt
- CONSIDER — Suggestions for improvement

Rules

Reviewing a plan is 10x cheaper than fixing a bad implementation
The best time to catch a missing dependency is before any code exists
Convention compliance in the plan prevents convention violations in the code
An adversarial reviewer should argue against the plan — not just validate it
Big-output discipline. Heavy command output (project check, full git diff, repo-wide search, long log, large fetch) goes to /tmp/hawk-<skill>-<step>.log, then rg -n '<pattern>' /tmp/hawk-<skill>-<step>.log | head -50 extracts what you need. Read the file only with offset/limit. See README → Big-output discipline.

More from this repository

same repository

plan-large

hawkyre/hawk-skills

Plan a multi-PR feature, migration, or architectural change before writing code. Writes a `.plans/<slug>/` directory of HTML documents (with inline UI mockups and a review-tracking layer) — a 1-page `overview.html` for human review, a mandatory `data-model.html` that locks the schema before anything else, a terse `plan.html` of dependency-ordered increments, an ADR-style `decisions.html`, and a `verification.html` acceptance script. Use whenever the user says "plan this feature", "scope out the migration", "/plan-large", "architect this rollout", "I need a plan covering schema and API", "design this across multiple PRs", or "break this work up". Also use whenever the work touches a database migration, even if it's only two PRs — schema-first is the gate. Runs a blind self-review subagent before presenting. Do NOT use for single-PR changes — bail to `plan-small` at Step 0. Do NOT use to start implementing — that's `/implement-plan` after the plan is approved.

2026-06-2828

plan-small

hawkyre/hawk-skills

Plan a single-PR change end-to-end before writing code. Writes a terse `.plans/<slug>/plan.html` (HTML, with inline UI mockups where a screen changes, rendered through the shared design system) covering files to touch, data-model changes, edge cases, verification, and decisions/assumptions sourced to code or user. Use whenever the user says "plan this", "scope this out", "write up a plan for X", "/plan-small", "let's plan the new flag", or "plan before we start". Also use whenever the user describes a small feature without explicitly asking to plan — propose a plan before coding. Asks only what code can't answer (in-repo PRDs count), surfaces planned assumptions alongside questions, then runs a blind self-review subagent before presenting. Do NOT use for multi-PR work, schema migrations beyond adding a nullable column, or sequenced increments — bail to `plan-large` at Step 0. Do NOT use to start implementing — that's `/implement-plan` after the plan is approved.

2026-06-2828

code-audit-hardcore

hawkyre/hawk-skills

Aggressive cleanup audit scoped to the user's specified changes plus tangibly-relevant surrounding code. Same blind audit-* specialists as code-audit, with a maximum-improvement posture — any code in the expanded review scope that can be cleaner WILL be made cleaner. Small fixes applied inline; big fixes (>5 files, schema, public API, redesigns) routed through `/plan-small` or `/plan-large`. Plan-overrides — when the audit reveals the original plan was wrong — route through `/plan-large` by default. Always improve over preserve.

2026-06-2828

implement-plan-audited

hawkyre/hawk-skills

Execute a plan increment-by-increment with the audit-* specialists running independently at strategic checkpoints. Use whenever the user says "implement the plan with audits", "audited implementation", "run with audits", "implement with cleanup checkpoints", "audit as you go", or invokes /implement-plan-audited. Inherits the full per-increment verification loop from `implement-plan` (done-criteria evidence, layered retry ladder, file-divergence check, outcome records) and adds checkpoint annotation, blind parallel audits, audit-fix verification (each FIX closes its own loop), plan-override propagation, and BEHAVIOR_CHANGE.md artifacts. Two modes — `manual` stops between increments for user review; `auto` applies audit fixes and proceeds without interruption, designed for hours of unattended execution. Specialists are blind to the plan and the goal. Do NOT use for unaudited plan execution — use `implement-plan`. Do NOT use for one-shot audits of existing code — use `code-audit`. Do NOT use for planning or repl

2026-06-2828

implement-plan

hawkyre/hawk-skills

Execute an approved plan increment-by-increment with deterministic verification at each step. Use whenever the user says "implement the plan", "run the plan", "execute the plan", "work through the increments", "do the plan", or invokes /implement-plan. Done-criteria are checked against evidence on disk, not asserted from memory; failures escalate through a layered ladder rather than repeated identical attempts; existing code gets behavior-preservation tests before modification; file divergence (touched vs declared) is reconciled before each commit; structured outcome records land in the plan file. Designed for fresh sessions with no prior context. Do NOT use for planning itself — use `plan-small` or `plan-large`. Do NOT use for unplanned coding without a plan file — use `coding-process`. Do NOT use when the user wants audits in the loop — use `implement-plan-audited`.

2026-06-2828

write-agent

hawkyre/hawk-skills

Design or fix an LLM agent's system prompt, tools, and guardrails so it stays strictly inside its domain and only does what it can actually do. Use when building a new agent, writing a system prompt for a "<domain> agent", or when an existing agent misbehaves — drifting off-topic, answering like a general chatbot (e.g. a CRM that starts writing Python), claiming abilities it lacks, answering from memory instead of tools, or caving to off-scope requests. Triggers: "write a system prompt for X", "constrain this agent", "why is my agent answering off-topic", "add guardrails", "keep the agent in scope", "/write-agent". NOT for tuning a one-shot prompt/completion that isn't a tool-using agent, and NOT for general copywriting — that's prompt engineering, not agent scoping.

2026-06-2728

name	review-plan
description	Stress-test a plan file before committing to implementation. Catches architectural mistakes, convention violations, and missing dependencies while changes are still cheap. Invoked directly, not routed from coding-process.

Review a Plan

Process

Load the plan and its context: Read the plan file(s) and any siblings. Plans are HTML — .plans/<slug>/plan.html (single-PR) or the overview.html / data-model.html / plan.html / decisions.html / verification.html / contracts.html set (multi-PR), plus inc-<N>-notes.md. Legacy plans may still be Markdown (*.md) — read whichever exists. Machine fields live on data-* attributes (increments: data-inc, data-size, data-depends, data-files, data-done); read those when checking dependency ordering and done-criteria. Read the relevant .agents/standards/ files that apply to the planned work.
Review for technical soundness:
- Are the architectural decisions correct given the codebase?
- Are the dependencies between increments properly ordered?
- Are there missing increments or gaps in the sequence?
- Will each increment actually pass CI independently?
Review for convention compliance:
- Does the plan follow the project's standards?
- Are files placed in the right directories?
- Does the naming follow conventions?
- Are there patterns in .agents/common-mistakes/ that the plan risks repeating?
Review for conversation fidelity: If reviewing a plan produced during an active conversation, check whether all decisions, constraints, and answered questions from the discussion are captured in the plan. A correct plan that doesn't match what was agreed is worse than a slightly imperfect plan that does. Skip this step if reviewing a plan file without conversation context.
Review for implementability:
- Is each increment scoped tightly enough to implement in one session?
- Are the "done criteria" specific and verifiable?
- Are there ambiguities that will force the implementer to make undocumented decisions?
Summarize findings:
- MUST FIX — Issues that would cause implementation failure or architectural problems
- SHOULD FIX — Issues that would cause friction or technical debt
- CONSIDER — Suggestions for improvement

Rules

Reviewing a plan is 10x cheaper than fixing a bad implementation
The best time to catch a missing dependency is before any code exists
Convention compliance in the plan prevents convention violations in the code
An adversarial reviewer should argue against the plan — not just validate it
Big-output discipline. Heavy command output (project check, full git diff, repo-wide search, long log, large fetch) goes to /tmp/hawk-<skill>-<step>.log, then rg -n '<pattern>' /tmp/hawk-<skill>-<step>.log | head -50 extracts what you need. Read the file only with offset/limit. See README → Big-output discipline.