<< All versions

Skill v1.0.0

currentAutomated scan100/100
swingerman/engineer/feature-edit
──Details
PublishedOctober 22, 2026 at 04:08 PM
Content Hashsha256:a3b6be6c5e2f1b48...
Git SHA8884a4ac9101
──Files
Files (1 file, 3.1 KB)
SKILL.md3.1 KBactive
SKILL.md · 38 lines · 3.1 KB

version: "1.0.0" name: feature-edit description: Use when an in-flight feature must change — scope shifts, an AC is refined, the plan evolves, a behavior is added or removed. Triggers — "/engineer.feature-edit", "change feature X to", "the ACs need updating", "revise the plan", "scope changed".

feature-edit

Intent-driven editing of an in-flight feature. The human describes what should now be true; this skill figures out which files and tools to touch and orchestrates the change, including the downstream cascade.

The cascade-owning skill — clarify and refine deliberately stay single-artifact and route multi-artifact propagation here. Mixed mode: the agent proposes an edit plan, the human confirms before any write.

When to use

Any time an existing feature's artifacts must change. checkpoint: null.

Not for: a brand-new capability (discuss); within-one-artifact ambiguity, no behavior change (clarify); validating consistency (consistency-check); cleaning up code (refine).

Workflow

  1. Resolve + identify the feature — resolve the methodology root + manifest via ${CLAUDE_PLUGIN_ROOT}/scripts/dae_resolve.py (see references/resolving.md); locate the feature (slug, branch, or search feature.md titles/outcomes).
  2. Is this actually an edit? — if the intent is a new capability or too big for one feature, surface it and redirect to discuss. Stop.
  3. Classify the entry artifact — the highest-level artifact the intent directly changes: outcome/scope → feature.md; a behavior → acs.md; a GWT detail → spec.md; architecture/phasing → plan.md.
  4. Build the edit plan — the cascade runs strictly downstream (feature.md → acs.md → spec.md → plan.md); upstream problems are surfaced, never auto-propagated. Per downstream artifact, classify by blast radius: small/mechanical → feature-edit edits directly; substantial → invoke the owning skill (discover-acs / atdd:atdd / plan) in edit-pass mode.
  5. Present the plan; human confirms — show entry artifact, cascade, and how each step is handled. Nothing is written before confirmation.
  6. Execute — in cascade order: direct edits and owning-skill invocations; regenerate .build/spec.json after any spec.md change; re-run affected test streams if code exists. If regeneration reveals an upstream problem, stop and surface it.
  7. Sync — update progress.md (affected checkpoint rows) and the tracker via the driver. If the edit adds or changes a user-facing surface (route, command, screen), update that feature's row in the verify-<app> feature map (${CLAUDE_PLUGIN_ROOT}/references/verify-app-skill.md).
  8. Handoff — emit a summary.

Handoff

Emit per ${CLAUDE_PLUGIN_ROOT}/references/handoff-summary.md. checkpoint: null; artifacts lists every artifact edited. recommended_next: typically "re-run /engineer.consistency-check".

References

All versions