Happier Implement Plan

Happier Implement Plan

Execute an approved plan as its orchestrator and integrator. Read and apply .agents/skills/happier-implement for the common implementation workflow; this skill adds plan authority, execution-state, amendment, boundary-review, and completeness rules. It does not create, materially refine, approve on the user's behalf, or redesign a plan.

1. Resolve authorization and the execution contract

• Identify the exact plan path, approved contract revision, intent, exclusions, material requirement/invariant IDs, execution units, acceptance criteria, and designated tracking area.
• The current user's explicit direction to implement a named plan is execution authorization and may serve as approval when that same plan was awaiting approval. Record approval only in the plan's designated identity area; do not alter requirements while doing so.
• If several plans could match, the named plan is unavailable, or approval would select among materially different contracts, resolve that ambiguity before production edits.
• Do not create a replacement plan, add unapproved requirements, or turn ordinary implementation decisions into amendments.

Route plan authoring and user-approved amendments to .agents/skills/happier-plan; route deep review, QA, finding triage, and authorized review-fix loops to .agents/skills/happier-review.

2. Recover current state without reopening design

Read the complete approved plan when it is not already active in context. Recover:

• approved intent, target state, decisions, exclusions, negative requirements, and acceptance criteria;
• current execution statuses and evidence pointers;
• completed, active, blocked, and ready execution units;
• current code/test anchors and external contracts the next unit relies on;
• active delegated runs and durable reports that actually exist;
• relevant current diff, dirty-worktree state, plan relationships, and shared conceptual seams.

Uncommitted work is normal. Inspect and preserve it; it does not reserve a file or justify skipping the requested change.

Do not add a generic preflight plan-review phase. Recheck only load-bearing anchors that may have moved, then begin. If primary evidence materially invalidates the approved contract, follow the amendment procedure instead of silently changing course.

3. Build the plan critical path and ready queue

Use .agents/skills/decompose-gates when the plan needs lane decomposition. Map:

• independently verifiable consumed verticals and their material requirement/invariant IDs;
• dependencies and the earliest check that can invalidate downstream work;
• ready implementation, QA-preparation, deterministic migration, validation, and scheduled review work;
• shared conceptual seams and the lane responsible for integrating each decision;
• actual collision surfaces: same edit hunk, incompatible live-contract decisions, destructive moves/rewrites, single-producer generated output, or exclusive mutable runtime resources;
• the fewest substantial integrated boundaries that receive formal independent review.

Name a precondition only when plan ordering cannot guarantee it: external authority/credentials, runtime/device availability, released artifacts, immutable external contracts, or other environment state. Verify it read-only before dependent work when practical. Do not create precondition ceremony for ordinary code dependencies.

Use maximum useful parallelism. Keep ready independent work moving when it shortens the critical path and dispatch newly unblocked work without waiting for unrelated lanes. Do not target a fleet size or create filler lanes. File overlap alone is not a collision.

4. Dispatch meaningful plan-aware lanes

Delegate complete responsibilities, not tiny searches or isolated edits. Every meaningful implementation, review, or QA lane reads the complete approved plan once unless it is already active in that lane's context. Reference the on-disk plan rather than pasting it.

For Codex, set fork_turns explicitly and default to fork_turns="none"; inherit only the minimal recent context that is indispensable. Each brief includes:

• plan path/revision and requirement/gate IDs;
• real intent, exact corridor, current evidence, and paths/symbols;
• dependencies, preconditions, and seam/resource coordination;
• dirty-state warning and instruction to preserve compatible work;
• concrete completion and negative criteria;
• required RED/GREEN, broader validation, and live QA;
• authorized scope, expected write corridor without exclusive reservations, output/evidence, and stop/fallback conditions.

A lane owns its analysis, implementation, focused tests, relevant validation, compact self-review, and concise result. Tell it that it is not alone in the checkout. Do not paste bulky logs, diffs, or generic doctrine into briefs.

5. Execute every unit through happier-implement

Apply .agents/skills/happier-implement to each execution unit, using the approved requirements as its outcome and evidence contract. Validate at the earliest tier that consumes the changed behavior, batching shared package/runtime setup under root Validation without dropping a material obligation.

The plan remains authoritative. Use best judgment only for details it intentionally leaves open. Do not reduce required integration, migration, removals, compatibility, UX, platform support, testing, or validation.

Lane outcomes are VERIFIED_COMPLETE, IMPLEMENTED_NOT_VERIFIED, PARTIAL, BLOCKED, or AMENDMENT_REQUIRED. A worker's DONE report is a claim, not final status.