---
name: legion-implement-change
description: Build, fix, or refactor an authorized repository change through implementation, proportionate verification, current manifests, and Git closure. Use legion-intent-design for nuanced outcomes needing durable intent, and legion-spec-design only for real concurrent worker coordination.
metadata:
  source-skill: implement-change
  source-sha256: "505c33b68437a0e5b73111cfc09f000e52d1f1d902c176ebc2f0ac503b79c6a6"
  edition: "2026-09-06"
---

# Implement Change

Own the outcome, not the smallest diff.

Begin from the controlling goal, intent, and current conversation. Treat any proposed implementation as a hypothesis about how to reach the outcome. If the desired reality is still unclear, return to dialogue or `legion-intent-design`; do not manufacture certainty or create an implementation spec merely because the work may be large.

The current request can settle a small change without a separate intent document. Reuse an existing adequate intent. Ask only for missing purpose, preference, authority, or knowledge that materially changes the outcome; resolve ordinary technical choices through inspection and judgment. Complete an already-authorized build after its design or diagnostic phase rather than pausing for another approval.

## Enter through the project map

Establish the owning repository and read its local instructions. Read the maintained project map in full, use its routing to select the relevant domain maps, and read those before inspecting source. This package uses `module-manifest.md` and domain manifests by default; an established equivalent serves the same purpose. The manifests are maintained agent-facing indexes that prevent broad rediscovery of the repository.

Reuse current guidance already read in this conversation. If a manifest is absent, inspect the bounded owning surface directly; missing navigation does not automatically require a whole-repository bootstrap before a small fix.

Use the manifests to bound source investigation, then inspect the routed implementation, call paths, data, and operating surfaces needed to make the change intelligently. Expand beyond that map only when evidence shows the responsibility crosses another boundary or the map is incomplete. A manifest contradiction is unfinished engineering work to reconcile, not ordinary background staleness.

## Make the coherent change

Inspect Git state before editing. Preserve existing work and understand overlapping changes rather than assuming an unseen engineer will resolve them. Make the smallest coherent change that creates the intended capability and leaves the surrounding system truthful. The fewest changed lines is not the goal.

Treat credible defects discovered during implementation as owned project state. Fix a pre-existing defect when it blocks the requested outcome or makes the changed surface untruthful. For unrelated defects, preserve the evidence and a clear follow-up owner rather than silently ignoring them or expanding this task into an unbounded cleanup. Existing damage is not proof the requested change caused it, and chronology is not a reason to conceal it.

Let evidence expand the implementation when the outcome requires it. Return to the person when a discovery changes the intended experience, value tradeoff, or another fact only they can supply—not merely because more files or deeper architecture became involved.

## Verify the claims that matter

Verify after coherent implementation, using evidence matched to the claim. Exercise actual user-facing surfaces for lived behavior; use deterministic checks for machine facts, focused integration proof for contracts, and benchmarks for measurable performance. Tests are evidence under constructed conditions, not authority over contradictory reality. Do not interrupt every tiny edit with ritual checks that provide no new information.

Start with the narrowest checks that can establish the changed behavior. Broaden for shared-contract risk, a relevant regression, or repository requirements. Do not run every project, device, or release suite merely because it exists; likewise, a small diff does not justify skipping a consequential integration check.

When verification exposes an existing failure, establish what it means and own the result. “Pre-existing” identifies chronology, not responsibility and not permission to report success around known damage.

## Finish the engineering operation

Reconcile the project map and every affected domain manifest with the completed system. Update responsibilities, files, routes, contracts, commands, and boundaries whenever they changed. If the existing manifest remains completely accurate, do not create meaningless churn—but make that a deliberate conclusion, never an omission.

Preserve consequential product reasoning in the project's established notes when it would otherwise be lost. Keep the source-navigation map current as its own responsibility.

Leave Git deliberate. Preserve unrelated human work, but commit completed engineering work coherently unless the person or the repository's active workflow requires otherwise. Do not leave accidental generated files, half-applied edits, or unexplained dirty state for the next session. Completion means the intended capability exists, relevant evidence supports it, the manifests describe the resulting project, and the repository records who owns the change.