crap-analyzer
Use to produce a risk-based refactor + test plan for recently-changed code on a diff/branch/PR by computing CRAP (complexity ×…
Use to drive one feature from CP2 to CP8 under a coordinator. It proposes the feature's agent graph (shapes, model classes, loop caps, cost estimate), then dispatches every checkpoint as a fresh agent, stopping only at the front and back human gates. Triggers — "/engineer.run
$ npx -y skills add swingerman/engineer --skill run --agent claude-codeHow it fires
How this skill gets triggered: by you, by Claude, or both.
/runContext preview
The summary Claude sees to decide when to auto-load this skill.
Use to drive one feature from CP2 to CP8 under a coordinator. It proposes the feature's agent graph (shapes, model classes, loop caps, cost estimate), then dispatches every checkpoint as a fresh agent, stopping only at the front and back human gates. Triggers — "/engineer.run
name: run description: Use to drive one feature from CP2 to CP8 under a coordinator. It proposes the feature's agent graph (shapes, model classes, loop caps, cost estimate), then dispatches every checkpoint as a fresh agent, stopping only at the front and back human gates. Triggers — "/engineer.run <feature>", "run this feature end to end", "drive the feature", "coordinate the pipeline", "build it through to verify".
One coordinator per feature, CP2 → CP8. The coordinator is the graph's one model-decided node: it **chooses** the graph (shapes, model class per node, loop caps), records the choice, and then follows fixed edges. Each checkpoint runs as a fresh agent, and the coordinator never reads source code.
Your standing instructions are `${CLAUDE_PLUGIN_ROOT}/references/coordinator.md`. Read it in full before step 1. This file is only the entry point.
the front and back gates as human stops.
**Not for:**
standalone, exactly as before.
Execute `coordinator.md` from "The run". In short: resolve the feature (XS goes to `/engineer.express`), propose a graph that `dae_graph.py` accepts, run its segments, stop only at the gates, and compare the actual run with the proposal at the close.
The coordinator writes **no checkpoint handoffs**: each node writes its own. At the close (or when a stop rule fires), emit one handoff per `${CLAUDE_PLUGIN_ROOT}/references/handoff-summary.md` with `skill: run`, `checkpoint: null`, `artifacts: [features/NNN-<slug>/run-graph.yml]`, a `findings_summary` of estimate vs actual, and `recommended_next` (the gate waiting, or "done").
A methodology kit for engineering-led AI development — spec-driven, test-driven, charter-bound. ATDD + mutation testing + deterministic guardrails. AI agents do the typing. Engineers stay in charge of architecture, behavior contracts, and verification.
Use to produce a risk-based refactor + test plan for recently-changed code on a diff/branch/PR by computing CRAP (complexity ×…
Use to check a feature's code against the charter's architecture rules — dependency layering, cycles, forbidden patterns, file…
Use to drive feature work through the Acceptance Test Driven Development workflow — Given/When/Then specs before code, a…
Use when a single DAE artifact has ambiguities to resolve. Triggers — "/engineer.clarify", "clarify this spec", "resolve…
Use to validate DAE artifacts for schema correctness and cross-artifact consistency. Triggers — "/engineer.consistency-check",…
Use when a Ready feature needs its acceptance criteria discovered before specs are written. Triggers — "/engineer.discover-acs",…