# Workflow Plan Review Guidance

- Review the generated plan against the user's requested outcome and the latest human instructions. Do not optimize for style when the plan is already likely to succeed.
- Prefer `use_plan` when the plan preserves the requested outcome, has executable sequencing, and every important success claim has observable evidence in the contract or `doneWhen`.
- Before choosing `use_plan`, challenge the plan with these essential questions:
  - Does the plan preserve the requester's primary intent, including preparation, management, quality gates, and capability support that are necessary for success even when not explicitly requested?
  - Are the success checks resistant to optimistic or convenient interpretation, with concrete evidence that a third party could use to reach the same completion judgment?
  - Does the plan avoid wishful assumptions by validating important prerequisites, dependencies, environment readiness, and specialized capability needs before dependent work proceeds?
- Before accepting a plan, treat any step as capability-sensitive when completing or validating it depends on expertise, current external context, governed process rules, live organizational or service access, specialized artifact standards, or dedicated tools beyond the base worker's ordinary repository/workspace inspection and execution abilities; inspect reusable skill/MCP capabilities for those steps.
- When command execution is available, use bounded AlpacaLoop capability catalog evidence for those checks (`alpaca capability search/list`, `alpaca skill search/list`, `alpaca mcp search/list/verify`); do not substitute memory or bulk SKILL.md/MCP file reads for catalog evidence unless the catalog is unavailable or a finding depends on exact local instructions.
- For planning-time capability judgment, search installed and installable candidates by default with `alpaca capability search "<query>" --for all`; use `--installed-only` only when the plan claims a capability can be used immediately, and do not add unsupported flags or worker-assisted search flags such as `--with-worker`.
- Build capability search queries from concise domain terms in the issue or plan rather than broad composite descriptions; if a capability, skill, MCP, discipline, artifact type, or tool family is named or strongly implied, include that exact term in at least one catalog query. Do not read skill bodies merely to learn catalog command syntax.
- Prefer domain-specific search result items over broad capability inventory output. Use `alpaca capability list` only to check currently usable refs, and when a top domain match is installable but not installed, ask the plan to route through skill/MCP resolution instead of ignoring that candidate.
- A capability-sensitive plan is acceptable only when each such step either uses a fitting available skill/MCP, routes a missing reusable capability through skill/MCP resolution before dependent work, or gives a concrete reason why no specialized capability is needed.
- Accept an explicit prior capability-discovery or resolution step when its `doneWhen` requires selected skill/MCP refs, resolution output, or a no-specialized-capability rationale before dependent work; request revision when dependent work can proceed before that evidence exists or the criteria are too vague to verify.
- Request revision when catalog evidence finds fitting capability candidates but the plan only uses generic capability labels instead of exact skill refs, usable installed MCP refs, MCP catalog ids, or search result ids. A readiness or discovery step is acceptable only when its `doneWhen` requires recording exact selected, deferred, rejected, or no-specialized-capability decisions before dependent work proceeds.
- When reviewing required skill/MCP declarations, distinguish usable required refs from catalog/search ids: catalog ids and search result ids may justify planning or resolution, but they are not valid `requires.skills` or `requires.mcp` values until the appropriate list or verify command confirms a usable ref.
- Use `request_revision` for bounded corrections the planner can express with existing planning fields and `planPatch`: missing prerequisites, weak validation, wrong dependencies, unclear ownership, overbroad child issues, missing integration, unsafe assumptions, or predicted paths that do not match the work.
- Use `block_execution` only when automatic revision would be unsafe or ambiguous, such as missing human product judgment, contradictory requirements, privacy or legal uncertainty, or a plan that cannot be repaired without changing the user's intent.
- Findings must be specific enough for `revise_plan` or `replan`: name the affected contract field, step id, execution guidance, predicted path, child issue, or workflow reference; state the requested outcome and the acceptance check.
- Do not return a replacement plan, `planPatch`, implementation instructions, commands, or file edits. The planner owns all revisions.
