Happier Implement

Happier Implement

Implement the requested outcome through the real owner and consumed runtime path. This skill owns the common change workflow; it does not create plans, authorize plan deviations, conduct a review-only program, or turn a diagnosis request into source edits.

1. Normalize the change and authority

Classify the requested work as a feature/change, bug fix, refactor/migration, mechanical transformation, or accepted review fix. Confirm that the user requested implementation rather than assessment, diagnosis, planning, or review only.

• For an approved plan, also use .agents/skills/happier-implement-plan; that skill supplies the authoritative contract, execution units, state, and amendment rules.
• For an accepted review finding, preserve the review's adjudicated impact and authority, then choose the coherent implementation rather than copying the reviewer's proposed mechanism blindly.
• For a runtime/session/provider/auth investigation without source changes, use .agents/skills/happier-diagnose.
• For read-only GitHub issue grouping or diagnosis, use .agents/skills/happier-issue-triage and .agents/skills/happier-issue-diagnose. Enter this implementation workflow only after the user authorizes source changes, carrying forward the established issue evidence and version basis.
• For a reported defect or regression, read bug-fix-loop.md before editing production behavior.
• When the repository constitution defines a successor-line obligation, include a destination disposition in the complete outcome. Work on and validate one coherent source batch first, then invoke the owning port workflow once at that boundary. Reuse current-basis diagnosis and port evidence, and revisit only changed intents unless scope, ownership, or architecture materially changed; do not port or reanalyze the destination during every source edit.

Do not create a repository plan on agent initiative. Use an internal checklist when useful, but keep it ephemeral unless an approved program already designates durable tracking.

2. Establish the complete outcome backward

State the real intent, exclusions, and outermost observable result. Derive the implementation backward:

1. name the user-visible, operational, compatibility, and architectural truths that must hold;
2. identify the canonical owners or artifacts that establish each truth;
3. identify the real entry points, consumers, wiring, migrations, removals, and compatibility paths required to make those owners authoritative;
4. identify the two or three links whose failure would be most damaging or least visible;
5. choose deciding evidence that observes the truths at the outermost practical contract surface.

Imports, registrations, types, file existence, mocked wiring, and helper tests are supporting evidence. They do not complete a user flow, CLI/API contract, persisted-state transition, process lifecycle, provider integration, or published artifact when that real surface is runnable.

Preserve every authorized outcome: integration, migration, removals, compatibility, UX, accessibility, security, privacy, performance, platform behavior, testing, and validation. Solution economy simplifies the implementation inside that boundary; it never reduces the boundary.

3. Discover the current owner and affected corridor

Before production changes, inspect enough current evidence to name:

• the canonical owner and why the behavior belongs there;
• inputs, normalization, callers, producers, consumers, readers, writers, and user-visible outputs;
• state, persistence, lifecycle, schema, feature, provider, compatibility, and platform seams that are materially coupled;
• existing tests, testkits, live recipes, and generated outputs;
• same-concept split-brains, bypasses, legacy paths, parallel decisions, and planned removals;
• current relevant diff and compatible uncommitted work that must be preserved.

Search by symbols and domain identifiers, not filenames alone. Stop once the material owner, corridor, risks, and deciding checks are established; do not keep searching for reassurance.

Dirty or concurrently edited files are normal and do not establish ownership. Inspect current bytes, preserve compatible changes, and layer in-scope work on top. Coordinate only actual same-hunk edits, incompatible decisions at one conceptual seam, destructive moves, single-producer generated outputs, or exclusive runtime resources.

4. Select the smallest coherent systemic change

Apply root Scope-preserving solution economy at implementation time: preserve the complete feature outcome, challenge unsupported machinery rather than the feature itself, and fold behavior into the canonical owner through reuse, refinement, consolidation, or refactoring before adding another path.

Prefer, in order, to add nothing when the complete outcome already holds; correct/reuse/refine/consolidate the canonical owner; use the language or platform; use an existing package-owned dependency; or add the smallest clear consumed implementation.

Smallest coherent does not mean smallest diff. Update every materially affected caller, reader, writer, consumer, platform path, and compatibility direction. Remove or migrate active competing owners and bypasses when the authorized outcome makes them obsolete. Do not centralize coincidental similarity across distinct bounded contexts or absorb unrelated debt.

Before adding a protocol, registry, table, state machine, gate, lease, generation, fallback, cache, or parallel path, name the approved requirement, reproduced failure, external contract, or reachable risk it serves. Apply the deletion test. If the mechanism only adds concepts while required behavior survives without it, do not build it.

Treat every timeout, retry count, quota, request/body or collection-size cap, truncation threshold, and similar guard as an owner-level product decision. Search for the containing operation's canonical deadline or resource boundary first and reuse it; do not add a shorter phase-local cutoff or guessed "safe" number. If no real contract or measured resource failure requires a bound, add none. When one is required, keep its derivation beside the owner, preserve valid data when paging or explicit incompleteness can do so safely, make activation observable, and prove both the rejecting/timeout case and valid behavior beyond the previously tempting arbitrary cutoff.

5. Shape execution for throughput

Use direct implementation for tightly coupled work and .agents/skills/decompose-gates for meaningful independent responsibilities. For repeated units with an unproven shared assumption, apply that skill's concurrency ramp: gate only dependent replication, keep independent work moving, and skip the ramp when prior evidence or a deterministic tool already proves the unit shape.

Delegate complete responsibilities rather than tiny edits. A lane owns its discovery, implementation, focused RED/GREEN proof, relevant validation, compact self-review, and concise result. Briefs name the goal, intent, corridor, evidence, dependencies, collision surfaces, completion and negative criteria, validation, permissions, and stop conditions. Do not reserve files or duplicate generic doctrine in every brief.

Use the fastest reliable mechanism for the work:

• repository scripts and generators;
• compiler/language-server renames;
• AST-aware codemods for structural repetition;
• bounded structured replacement for uniform text/configuration;
• formatters and deterministic validators;
• batched retrieval with compact output.

Preview broad transformations, establish their match set, inspect representative and aggregate diffs, and validate omissions plus unintended matches. Do not build tooling when a few direct edits are safer and faster.

6. Resolve uncertainty with evidence

Uncertainty is an investigation task, not a reason to skip in-scope work. Classify the missing answer first: if source, history, a focused prototype, test, schema, log, measurement, runtime state, artifact, or current primary documentation can decide it safely, retrieve that evidence. Ask only for a genuine product, preference, authority, or tradeoff decision evidence cannot settle, unavailable external state, or material expansion/redesign. Continue independent work that cannot prejudge that decision.

7. Implement through a valid test and real path

• Use .agents/skills/happier-testing. Production behavior changes require meaningful RED for the intended observable contract, minimal coherent GREEN, then refactoring with tests green.
• Mock only genuine system boundaries; keep internal domain behavior real.
• Implement through the canonical/public owner boundary and a consumed path, not a dormant horizontal spine.
• Use .agents/skills/happier-compatibility for released wire, semantic, persistence, migration, upgrade, coexistence, or rollback seams.
• Use relevant UI/design/React/React Native skills for user-facing work under DESIGN.md and package instructions.
• Preserve performance, continuity, accessibility, security, privacy, and Windows/Linux/macOS behavior wherever the changed corridor can materially differ.

Classify unexpected failures before changing code: production defect, test drift, harness drift, environment/resource failure, external-contract change, or unrelated failure. A green test is invalid evidence when the harness suppresses errors, mocks away the deciding path, or asserts the defective contract.