Run a final readiness pass on a stable branch or pull request diff using structured checks plus a final whole-diff review.
From workflow-orchestrationnpx claudepluginhub mikecubed/agent-orchestration --plugin workflow-orchestrationThis skill uses the workspace's default tool permissions.
Provides JPA/Hibernate patterns for Spring Boot entity design, relationships, N+1 prevention, query optimization, transactions, auditing, pagination, indexing, and pooling.
Manages knowledge base ingestion, sync, organization, deduplication, and retrieval across local files, MCP memory, vector stores, Git repos, and Supabase. Useful for saving, searching, or updating knowledge systems.
Retrieves, analyzes, and updates Jira tickets via MCP server or direct REST API. For understanding requirements, adding comments, transitioning status, and linking git branches.
Use this skill when a branch or pull request diff is finally stable and you want one last high-signal readiness pass before asking for human review.
This is a final integrated gate, not an inline coding step.
Persistent team, squad, or fleet-style long-lived orchestration is out of scope for this skill. Use a separate orchestration layer if persistent coordination is needed.
Activate when the developer asks for things like:
Before you start, identify:
Use:
If no structured checker exists, continue with the final reviewer only. If the diff is small or focused, skip the scout and proceed directly.
If the active runtime offers a higher-cost orchestration mode such as a Fleet command or Claude Code agent teams, keep it optional and reserve it for unusually large or high-risk final review surfaces.
In most cases, one structured checker and one final reviewer are enough. Before escalating, explain the expected benefit and ask the developer whether they want the extra token cost.
Escalate only when:
If team mode is approved, keep one final reviewer responsible for the single readiness verdict so the outcome does not fragment across agents.
Resolve the active model for each role using this priority chain:
Project config — look for the runtime-specific config file in the current project root:
.copilot/models.yaml.claude/models.yamlThese are plain YAML files (no markdown, no fenced blocks). Read the structured-check, final-reviewer, and scout keys directly. If a key is absent, fall back to the baked-in default for that role — do not re-prompt for a key that is missing.
Session cache — if models were already confirmed earlier in this session, reuse them without asking again.
Baked-in defaults — if neither config file nor session cache exists, show the defaults below, ask the user to confirm or override them once, then cache the answer for the rest of the session.
The config files are plain YAML (not markdown). Create the file for the active runtime and set only the keys you want to override — absent keys fall back to the baked-in defaults. The keys for this skill are:
structured-check: <model-name>
final-reviewer: <model-name>
scout: <model-name>
See docs/models-config-template.md in this plugin for ready-to-copy templates for both runtimes.
| Runtime | Role | Default model |
|---|---|---|
| Copilot CLI | Structured check | gpt-5.4 |
| Copilot CLI | Final reviewer | gpt-5.4 |
| Copilot CLI | Scout | claude-haiku-4.5 |
| Claude Code | Structured check | claude-opus-4.6 |
| Claude Code | Final reviewer | claude-opus-4.6 |
| Claude Code | Scout | claude-haiku-4.5 |
Before invoking this skill:
If the diff is still moving significantly, stabilize it first.
Before running the final gate:
Evaluate the integrated result, not a partial local slice.
Before proceeding to structured checks, run a fast scout pass to prepare the review surface for efficient downstream processing:
docs/workflow-artifact-templates.md with at least: task shape, relevant files, comparison baseline, and validation commands.Skip the scout pass when the diff is small or focused enough that a single reviewer can process it without pre-slicing — for example, fewer than roughly ten files in a single coherent module.
If the stable diff is:
Do not force code-only tooling onto a non-code diff.
When multiple checker options exist, prefer the most semantic one available:
When a structured checker applies:
If the diff is large enough that a single pass becomes noisy, split the review into coherent slices first and preserve one final whole-diff judgment at the end.
Focus on:
When the structured checker stalls, times out, or the diff is large enough to cause processing delays, apply the following rescue-before-abandon sequence instead of immediately stopping the gate:
Do not abandon the gate because a single checker stalled or the diff was large. Always attempt at least one rescue pass and record any scope reductions, skipped checks, or processing-delay mitigations in the readiness report.
Classify findings into:
Do not treat every automated finding as truth. Ground them in the actual code and diff.
After any structured findings are triaged:
End with one of these outcomes:
Produce a readiness report following the template in docs/workflow-artifact-templates.md. The report MUST record:
none;The report MUST also include the workflow outcome measures defined in docs/workflow-artifact-templates.md:
discovery-reuse — yes, no, or skipped (whether the discovery brief was reused by downstream checks);rescue-attempts — integer count of rescue attempts during the gate, or 0;final-gate-result — one of ready, ready-with-follow-ups, not-ready, or stopped, using the normalized token form of the verdict above:
ready for review -> readyready with follow-ups -> ready-with-follow-upsnot ready -> not-readystopped by user -> stoppedPopulate these fields once, at gate completion. If the gate stops early, record whatever measures are available and note which fields are incomplete.
The result should make the next action obvious.
Use a durable report shape so the next actor can make a decision quickly. For example:
Review surface: PR #128 against main
Structured checker: codex review + repo test suite
Current state: done
Blockers:
- Missing null-path coverage in src/api/createWidget.js
Fix-now:
- Rename duplicate option key in plugin.json example
Follow-ups:
- Consider extracting shared validation helper after merge
Skipped checks:
- None
Unresolved questions:
- None
Next action: Send back for the one fix-now item, then rerun readiness
Verdict:
- ready with follow-ups
discovery-reuse: yes
rescue-attempts: 0
final-gate-result: ready-with-follow-ups
A final readiness pass is not complete until:
docs/workflow-artifact-templates.md has been published.Before issuing a readiness verdict, confirm ALL of the following.
CI state gate
Review state gate
Diff integrity gate
If any item is FAIL or requires human confirmation: surface the item, ask what is needed, and do not issue a "ready to merge" verdict until all items are PASS.
Before stopping because a structured checker stalled or the diff exceeded the review budget, always follow the rescue-before-abandon sequence defined in § Rescue policy for structured-check delays: narrow scope, drop non-critical checks, serialize, and re-evaluate. Stop only after the rescue pass fails or the developer confirms abandonment.
When a hard stop is necessary, report why the gate is not yet trustworthy, record the rescue attempt and its outcome, and resume only on a stable diff.