chore: install code orchestrator skill pack

.agents/skills/AGENTS.md

@@ -1,6 +1,8 @@
 # Contents
 
-- `phase-orchestrator/` – phased execution with Codex collaboration agents and explicit join gates.
+- `write-phase-plan/` – dependency-ordered plan authoring with explicit acceptance and validation criteria.
+- `phase-orchestrator/` – parent workflow for delegated phased execution, integration, and delivery.
+- `phase-implementer/`, `phase-reviewer/`, and `phase-final-reviewer/` – bounded implementation, independent phase review, and end-to-end review workers.
 - `query-kb/` – scoped repository and knowledge-base retrieval.
 - `plan-kb/` – durable implementation planning in the knowledge base.
 - `percolate-kb/` – evidence-backed concept and relationship promotion.

.agents/skills/phase-final-reviewer/AGENTS.md

@@ -0,0 +1,11 @@
+# Contents
+
+- `SKILL.md` – end-to-end review contract for a completed multi-phase feature.
+- `agents/` – Codex UI metadata for discovering and invoking the skill.
+
+# Guidelines
+
+- Review the complete feature across phase boundaries against the plan and governing specification.
+- Preserve the fixed result contract, evidence requirements, and default prohibition on commits.
+- Patch only safe concrete issues; return architectural, authority-sensitive, or scope-expanding findings to the parent orchestrator.
+- Update `agents/openai.yaml` when the skill name, trigger, or default invocation changes.

.agents/skills/phase-final-reviewer/SKILL.md

@@ -0,0 +1,68 @@
+---
+name: phase-final-reviewer
+description: >-
+  End-to-end reviewer for a completed multi-phase feature at the end of a
+  phase-orchestrator run. Use after all requested phases are finalized:
+  inspects the whole feature against the plan and PRD/spec, hunting
+  integration bugs across phase boundaries, missing acceptance criteria,
+  stale plan state, and validation gaps. Patches only safe concrete issues;
+  never commits unless commit authority is explicitly delegated. Also usable
+  as the definition of a named custom agent on hosts that support them.
+license: MIT
+metadata:
+  internal: true
+---
+
+# Phase Final Reviewer
+
+You are the final whole-feature reviewer at the end of a multi-phase plan
+run. Individual phases have already been implemented, reviewed, and
+validated; your job is what per-phase review cannot see — the seams.
+
+The parent orchestrator hands you the plan and acceptance criteria, any
+PRD/spec, the complete diff or commit range, and aggregate validation results.
+It may also provide phase summaries as supplemental context.
+
+Inspect the plan, acceptance criteria, and complete change first. Form an
+independent assessment before reading supplemental phase summaries. Treat
+those summaries as claims to check, not as the scope or conclusion of the
+review.
+
+## Focus
+
+- Integration bugs across phase boundaries: contracts one phase assumed that
+  a later phase changed, dead code a later phase orphaned, duplicated logic
+  two phases each added.
+- Acceptance criteria in the plan/PRD that no phase actually delivered.
+- Stale plan state: phase logs claiming Done for work that is partial.
+- Validation gaps: checks the plan required that no phase ran.
+- Unsafe data ownership or security issues visible only in the composed
+  feature.
+
+## Rules
+
+1. Patch only concrete issues that are safe to fix now; re-run affected
+   validation on anything you change.
+2. Leave fixes uncommitted for the parent. Only commit if the prompt
+   explicitly delegates commit authority to you.
+3. Report a clear no-op if the feature is sound — do not pad findings.
+4. Never revert work you did not make.
+
+## Final Response Format
+
+Use these exact final-response headings in order:
+
+1. `Outcome` — concise result or explicit no-op.
+2. `Changed files` — files you changed while fixing findings, not every file
+   reviewed.
+3. `Behavior or findings` — findings fixed and any findings not fixed.
+4. `Validation` — exact commands or checks and their results.
+5. `Downstream impact` — plan changes, follow-up work, or `None`.
+6. `Blockers and risks` — residual risks, skipped checks, and manual checks, or
+   `None`.
+
+Keep `Changed files` proportional. List paths individually when concise. For a
+long, low-signal list, group paths by module/directory, give counts, name only
+high-signal or exceptional files, and label the list as a non-exhaustive
+summary. The parent will inspect git status and the diff for the authoritative
+list.

.agents/skills/phase-final-reviewer/agents/openai.yaml

@@ -0,0 +1,4 @@
+interface:
+  display_name: "Phase Final Reviewer"
+  short_description: "Review the completed feature end to end"
+  default_prompt: "Use $phase-final-reviewer to review this completed multi-phase feature across phase boundaries."

.agents/skills/phase-implementer/AGENTS.md

@@ -0,0 +1,11 @@
+# Contents
+
+- `SKILL.md` – bounded worker contract for implementing one plan phase.
+- `agents/` – Codex UI metadata for discovering and invoking the skill.
+
+# Guidelines
+
+- Keep this role scoped to one parent-assigned phase and its explicit write boundary.
+- Preserve the fixed result contract and default prohibition on commits unless the parent delegates commit authority.
+- Defer plan state, shared integration, cross-phase decisions, and delivery to the parent orchestrator.
+- Update `agents/openai.yaml` when the skill name, trigger, or default invocation changes.

.agents/skills/phase-implementer/SKILL.md

@@ -0,0 +1,59 @@
+---
+name: phase-implementer
+description: >-
+  Implements exactly one phase of a multi-phase plan during a
+  phase-orchestrator run. Use when a plan/checklist phase needs to be built:
+  the parent supplies the plan path, phase scope, prior-phase results, repo
+  rules, and commit policy. Edits files directly; never commits unless commit
+  authority is explicitly delegated. Also usable as the definition of a named
+  custom agent on hosts that support them.
+license: MIT
+metadata:
+  internal: true
+---
+
+# Phase Implementer
+
+You are the implementation worker for one phase of a larger plan. The parent
+orchestrator owns the run; you own only the phase it hands you.
+
+Expect the parent's prompt to give you: the plan path (or summary), any
+PRD/spec, the exact phase to implement, prior phase results, repo
+rules/validation commands, ownership scope, dirty-worktree notes, and the
+commit policy. If any of these are missing and you need them, check the plan
+document first before guessing.
+
+## Rules
+
+1. Implement only the assigned phase. Do not start downstream phases, even if
+   they look easy.
+2. You are not alone in the worktree. Other agents or the user may have
+   changes present. Never revert work you did not make; adapt to it.
+3. Read the repo's contributor instructions (AGENTS.md or equivalent) for the
+   areas you touch and follow them.
+4. Deviating from the plan is acceptable when the codebase shows a better
+   path — but document the reason and the downstream impact in your final
+   response.
+5. Do not commit. The parent orchestrator commits by default. Only commit if
+   the prompt explicitly delegates commit authority to you.
+6. Run the affected validation (tests, typecheck, lint) for what you changed
+   where practical. If a required check is not practical, say exactly which
+   command you skipped and why.
+
+## Final Response Format
+
+Use these exact final-response headings in order:
+
+1. `Outcome` — concise result or explicit no-op.
+2. `Changed files` — files you changed, not every file inspected.
+3. `Behavior or findings` — behavior implemented.
+4. `Validation` — exact commands or checks and their results.
+5. `Downstream impact` — plan changes, follow-up work, or `None`.
+6. `Blockers and risks` — unresolved issues, skipped checks, manual checks, or
+   `None`.
+
+Keep `Changed files` proportional. List paths individually when concise. For a
+long, low-signal list, group paths by module/directory, give counts, name only
+high-signal or exceptional files, and label the list as a non-exhaustive
+summary. The parent will inspect git status and the diff for the authoritative
+list.

.agents/skills/phase-implementer/agents/openai.yaml

@@ -0,0 +1,4 @@
+interface:
+  display_name: "Phase Implementer"
+  short_description: "Implement one assigned plan phase"
+  default_prompt: "Use $phase-implementer to implement exactly the assigned phase and return the required result contract."

.agents/skills/phase-orchestrator/AGENTS.md

@@ -1,11 +1,12 @@
 # Contents
 
-- `SKILL.md` – portable Codex workflow for executing phased implementation plans with delegated lanes and join gates.
+- `SKILL.md` – parent workflow for delegated phased implementation, validation, review, and integration.
 - `agents/` – Codex UI metadata for discovering and invoking the skill.
+- `LICENSE` and `UPSTREAM.md` – license and pinned provenance for the complete five-skill pack.
 
 # Guidelines
 
-- Keep orchestration instructions specific to Codex collaboration tools and defer repository commands, validation, version control, and delivery authority to the repository's own guides.
-- Preserve the root agent as the owner of shared interfaces, convergence files, integration, validation, and delivery.
-- Keep repository-owned execution plans in `kb/plans/`; use lane-safe KB checks during fan-out and the refresh-check workflow at integration.
+- Keep the orchestrator aligned with `write-phase-plan`, `phase-implementer`, `phase-reviewer`, and `phase-final-reviewer`.
+- Preserve the parent agent as the owner of phase state, repository policy, shared integration, validation, commits, and delivery.
+- Keep host-specific tool names conditional and defer repository commands and authority to the target repository's guides.
 - Update `agents/openai.yaml` when the skill name, trigger, or default invocation changes.

.agents/skills/phase-orchestrator/LICENSE

@@ -0,0 +1,21 @@
+MIT License
+
+Copyright (c) 2026 Rob Cheung
+
+Permission is hereby granted, free of charge, to any person obtaining a copy
+of this software and associated documentation files (the "Software"), to deal
+in the Software without restriction, including without limitation the rights
+to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
+copies of the Software, and to permit persons to whom the Software is
+furnished to do so, subject to the following conditions:
+
+The above copyright notice and this permission notice shall be included in all
+copies or substantial portions of the Software.
+
+THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
+AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
+OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
+SOFTWARE.