codex-harness-javascript: Skill for Codex

Frontend Delivery Workflow

This is a user-facing workflow entry point. It coordinates agents; it does not contain implementation knowledge.

Intent

Run continuously from the smallest valid workflow entry until acceptance, pause, or a real blocker. Do not stop merely because Jira Tasks/Subtasks were created.

Entry resolution

Resolve the current entry before spawning agents:

• NEW: no valid Jira workflow exists for the requested work.
• RESUME: valid Jira analysis/task tree exists and relevant requirements are unchanged.
• REPLAN: relevant requirements or approved architecture changed materially.
• PAUSE: the user explicitly asks to stop/pause an active workflow.
• ACCEPTANCE: executable work is complete and final acceptance is due.

Natural-language pause intent such as dừng lại, tạm dừng, để mai làm tiếp, or equivalent must route to PAUSE.

Controller execution rule

The Primary Controller owns runtime transport for the whole workflow:

• native child-agent spawn/retry/interrupt/close/verification;
• Jira connector calls requested by Orchestrator;
• cross-agent runtime-resource cleanup supervision.

Orchestrator owns workflow decisions. It must not call native agent lifecycle APIs or Jira directly. It returns controller-actions; the Primary Controller executes them exactly and returns confirmed results to the same Orchestrator child.

Keep one Orchestrator child alive across the active delivery workflow. Do not restart it after every Coding/Testing result.

Continuous delivery

For NEW:

1. Primary Controller spawns Brain for bounded requirement analysis and project-stack discovery.
2. Capture Brain result, then explicitly close and verify the Brain child.
3. Primary Controller spawns one Orchestrator child in planning mode with execution intent deliver and supplies the approved analysis/Jira context.
4. Orchestrator returns status: awaiting-controller with exact jira-call and/or dispatch-specialist actions as needed.
5. Primary Controller executes those actions without changing their intent/payload and sends confirmed action results back to the same Orchestrator child.
6. For dispatch-specialist, Primary Controller applies the native retry policy, collects the specialist result/runtime-resource evidence, ensures owned resources are cleaned, explicitly closes/verifies the specialist child, then returns the result to Orchestrator.
7. Repeat the controller-action loop until Orchestrator returns a terminal reconciliation result with acceptance inputs ready.
8. Close and verify the Orchestrator child.
9. Spawn Brain for final acceptance, then close/verify the Brain acceptance child before reporting the workflow complete.