Prepare execute
Use when a valid EZPowers feature spec must be mapped into a dependency-valid implementation plan with exact project-local checks and complete criterion coverage. Not for implementing the plan.From its SKILL.md
npx -y skills add dlwlgus9125/EZPowers --skill prepare-executeAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
One thing to look at
- 12 stars12 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.
SKILL.md
3.0 KB, as published. Nobody here has run it
Prepare Execute
Map a valid acceptance contract to a small implementation plan. The plan owns dependencies, criterion coverage, and exact checks; the active host owns how it edits, delegates, isolates, reviews, and retries the work.
Load and inspect
Read .ezpowers/contracts/plan-contract.md and
.ezpowers/contracts/verification-contract.md; they are the source of truth
for the managed schema and check rules. Read the selected spec and its
design_context, architecture and frontend-design artifacts, every applicable
nearest DESIGN.md, repository instructions, the documentation graph when
present, source, tests, CI commands, and .ezpowers/config.json.
When the plan changes product-code module boundaries, read
.ezpowers/contracts/engineering-practices-contract.md and preserve the
focused codebase-design seams and regression checks in the task mapping.
Validate the spec first with the exact command in the plan contract. Return to
spec when a criterion is ambiguous or cannot be automated without weakening
its observable claim. Return to design-architecture when planned work would
contradict the spec's architecture impact or introduce an unrecorded boundary.
Plan and validate
Create one plan under docs/plans/. Explain ordered vertical slices,
dependencies, expected files, constraints, prerequisites, non-goals, and risks
in Markdown. Carry settled architecture paths and constraints as inputs; do
not add a tail-end task that merely makes documentation resemble the code.
Add exactly one managed JSON block using the canonical plan
contract. New plans use schema v2, give every task an explicit depends_on
array, and declare check concurrency only when independence has reproducible
evidence; unproven checks remain unsafe barriers. Map every criterion exactly once and bind it to real named or inline
project checks. Preserve frontend, accessibility, integration, and visual
oracles; missing tooling becomes an explicit prerequisite. For UI work,
include code-to-DESIGN.md alignment and check-project. Reuse the exact
required ezpowers.design check when registered; otherwise add it as a
plan-local static check. Add the pinned official CLI command only when that
package is already installed locally, always with npx --no-install.
Run:
python .ezpowers/ezpowers.py validate --plan <plan-path> --json
python .ezpowers/ezpowers.py trace --plan <plan-path> --json
Missing, duplicate, unknown, cyclic, or weakened coverage is blocking. Report the plan
path, topological task waves, assurance-graph hash, exact criterion coverage, configured and plan-local checks,
including required ezpowers.docs and applicable ezpowers.design checks when
documentation is ready, and unresolved prerequisites. Continue to execute
only with a valid plan.