ship

What this skill does

<skill name="apex:ship" phase="ship">

<overview>
Final phase: Review implementation with adversarial agents, commit changes, complete task, and record reflection.

Combines REVIEWER (adversarial code review) and DOCUMENTER (commit, complete, reflect).
</overview>

<phase-model>
phase_model:
  frontmatter: [research, plan, implement, rework, complete]
  rework: enabled
  db_role: [RESEARCH, ARCHITECT, BUILDER, BUILDER_VALIDATOR, REVIEWER, DOCUMENTER]
  legacy_db_role: [VALIDATOR]
source_of_truth:
  gating: frontmatter.phase
  telemetry: db_role
</phase-model>

<phase-gate requires="implement" sets="complete">
  <reads-file>./apex/tasks/[ID].md</reads-file>
  <requires-section>implementation</requires-section>
  <appends-section>ship</appends-section>
</phase-gate>

<mandatory-actions>
This phase requires THREE mandatory actions in order:
1. **Adversarial Review** - Launch review agents
2. **Git Commit** - Commit all changes
3. **Final Reflection** - Record pattern outcomes and key learnings

YOU CANNOT SKIP ANY OF THESE for APPROVE or CONDITIONAL outcomes.
If REJECT, stop after review, set frontmatter to `phase: rework`, and return to `/apex:implement`.
</mandatory-actions>

<initial-response>
<if-no-arguments>
I'll review and finalize the implementation. Please provide the task identifier.

You can find active tasks in `./apex/tasks/` or run with:
`/apex:ship [identifier]`
</if-no-arguments>
<if-arguments>Load task file and begin review.</if-arguments>
</initial-response>

<workflow>

<step id="1" title="Load task and verify phase">
<instructions>
1. Read `./apex/tasks/[identifier].md`
2. Verify frontmatter `phase: implement`
3. Parse `<task-contract>` first and note its latest version and any amendments
4. Parse all sections for full context
5. If phase != implement, refuse with: "Task is in [phase] phase. Expected: implement"

Contract rules:
- Final report MUST map changes to AC-* and confirm no out-of-scope work
- If scope/ACs changed during implement, ensure amendments are recorded with rationale and version bump
</instructions>
</step>

<step id="2" title="Gather review context">
<extract>
- `<task-contract>` - Authoritative scope/ACs and amendment history
- `<implementation><files-modified>` - What changed
- `<implementation><files-created>` - What's new
- `<implementation><patterns-used>` - Patterns to validate
- `<implementation><validation-results>` - Test status
- `<implementation><reviewer-handoff>` - Key points for review
- `<plan><architecture-decision>` - Original intentions
- `<plan><warnings>` - Risks to verify mitigated
</extract>

<get-diffs>
```bash
git diff HEAD~N  # or appropriate range for this task's changes
git log --oneline -10
```
</get-diffs>
</step>

<step id="2.5" title="Classify review mode">
<purpose>
Select the lightest review mode that is still safe for the change. If signals conflict, choose the stricter mode.
</purpose>

<review-modes>
- `light`:
  - Small, localized, low-risk change with a limited blast radius
  - Often docs, prompts, tests, or tightly local refactors and bugfixes
  - Green validation or validation that is not materially needed
  - Does not reshape system boundaries
- `standard`:
  - Default for normal feature or bugfix work
  - Use whenever there is meaningful runtime behavior change
  - Also use when signals are mixed and confidence in `light` is not high
- `deep`:
  - Broad, risky, or cross-cutting change
  - Touches auth, permissions, parsing, persistence, schemas, migrations, public API/CLI, concurrency, build/release, or shared abstractions
  - Validation is partial, warnings remain open, or regression potential is high
</review-modes>

<classification-signals>
Assess and record:
- changed file count and subsystem spread
- whether behavior, contracts, or data shape changed
- whether risky surfaces were touched
- whether plan warnings remain relevant
- whether validation is strong, weak, or absent
- whether git history suggests high churn or regression risk
</classification-signals>

<mode-selection-rules>
1. Start from the smallest plausible mode.
2. Escalate to `standard` or `deep` when risky surfaces or mixed signals appear.
3. `light` is only valid when the change is obviously low-risk and easy to verify.
4. Record both the chosen mode and the rationale in the final `<ship>` section.
</mode-selection-rules>
</step>

<step id="2.6" title="Assemble mode-specific context pack">
<instructions>
Before launching reviewers, build the context pack that matches the selected mode:

- `light`:
  - full diff
  - modified/created file list
  - validation summary
  - reviewer handoff summary
  - recent commits, churn/regression signals, and ownership summary for modified files

- `standard`:
  - everything in `light`
  - plan warnings and architecture decision summary
  - churn/regression signals for modified files

- `deep`:
  - everything in `standard`
  - adjacent snippets for changed functions/classes
  - closely related tests, call sites, or neighboring abstractions needed to reason about downstream impact of the changed lines

Use the selected context pack consistently in Phase 1 and Phase 2 prompts.
</instructions>
</step>

<step id="3" title="Phase 1: Launch mode-appropriate review agents">
<critical>
Launch ALL 5 Phase 1 agents in a SINGLE message for true parallelism.
Only use agents that actually exist in `agents/review/phase1/`.
</critical>

<mode-behavior>
All modes use the same 5 Phase 1 agents:
- `review-security-analyst`
- `review-architecture-analyst`
- `review-test-coverage-analyst`
- `review-code-quality-analyst`
- `review-git-historian`

Modes change context depth, not reviewer count or scoring rules:
- `light` → concise context pack for low-risk, localized changes
- `standard` → normal context pack
- `deep` → richer context pack (plan warnings, validation gaps, git churn, adjacent snippets) and more explicit prompts for scrutinizing downstream impact of changed lines
</mode-behavior>

<agents parallel="true">

<agent type="apex:review:phase1:review-security-analyst">
Include in every mode.

**Task ID**: [taskId]
**Review Mode**: [selected mode]
**Code Changes**: [Full diff]
**Mode Context Pack**: [Context assembled in Step 2.6 for the selected mode]
**Journey Context**: Architecture warnings, implementation decisions, test results

Review for security vulnerabilities. In `deep`, read adjacent context and likely exploit paths to better assess changed lines, but only report findings rooted in the diff. Return the standard security-analyst YAML schema.
</agent>

<agent type="apex:review:phase1:review-architecture-analyst">
Include in every mode.

**Task ID**: [taskId]
**Review Mode**: [selected mode]
**Code Changes**: [Full diff]
**Mode Context Pack**: [Context assembled in Step 2.6 for the selected mode]
**Journey Context**: Original architecture from plan, pattern selections

Review for architecture violations and pattern consistency. In `deep`, use neighboring abstractions and dependency context to assess the changed lines more rigorously, but keep findings anchored to the diff. Return the standard architecture-analyst YAML schema.
</agent>

<agent type="apex:review:phase1:review-test-coverage-analyst">
Include in every mode.

**Task ID**: [taskId]
**Review Mode**: [selected mode]
**Code Changes**: [Full diff]
**Mode Context Pack**: [Context assembled in Step 2.6 for the selected mode]
**Validation Results**: [From implementation section]

Review for test coverage gaps. In `deep`, use integration seams and adjacent helpers to reason about risky changed paths, but only flag gaps tied to changed behavior. Return the standard test-coverage-analyst YAML schema.
</agent>

<agent type="apex:review:phase1:review-code-quality-analyst">
Include in every mode.

**Task ID**: [taskId]
**Review Mode**: [selected mode]
**Code Changes**: [Full diff]
**Mode Context Pack**: [Context assembled in Step 2.6 for the selected mode]
**Journey Context**: Patterns applied, conventions followed

Review