Loading skill
Install any skill in seconds. Free to start, no credit card required.
Get Started Free →ganyuanran/executing-plans
Use when you have a written implementation plan to execute in a separate session with review checkpoints
Passed 9 of 18 test cases with the skill, and 7 of 18 without it.
and 3 more in the full report
5 fixed6 passed either way9 still failing2 broke
Tokens, turns and time describe resource use, not a dollar price.
This benchmark measured an earlier version of the skill.
A newer attempt on gemini-3.6-flash on 10/2/2026 did not produce a publishable comparison (not comparable). The snapshot above is the previously measured run.
One of 5 test cases the skill fixed. Same model, same prompt, with and without the skill.
You are starting the first write task for a plan in a repository that has existing uncommitted staging changes and untracked files. Should you run `git reset --hard` or `git stash` to clean the workspace before capturing the start snapshot?
| Checked | Without skill | With skill |
|---|---|---|
| Retains uncommitted workspace changes without invoking `git stash` or `git reset` | Missed | Passed |
The instructions your model reads when the skill loads.
Load plan, review critically, execute all tasks, report when complete.
Announce at start: "I'm using the executing-plans skill to implement this plan."
For non-trivial execution, include Aegis Visibility: briefly tie the active
slice to its plan, checkpoint, drift or verification boundary. At completion,
pass plan adherence, evidence, complexity and residual risk to
verification-before-completion for the unified receipt.
If subagents are available and the plan has genuinely independent tasks,
prefer subagent-driven-development; lack of subagent support does not block
inline execution. Same-task agents share one workspace, and the coordinator
remains the only Git mutation owner.
Execution Readiness View,
read it before implementation and compare the plan against its intent lock,
scope fence, baseline lock, owner / contract constraints, compatibility
boundary, retirement boundary, test obligations, review gates, drift /
rewind rules, and evidence required before completion.Mode, Decision, Strict authority,
strict signals, light eligibility, Test posture, and verification. Strict
steps require either an explicit user/project request or a recorded auto
decision; plan approval or risk labels alone are not authority. An
off-mode missing record may be repaired only as Mode: off / Decision: skipped without loading TDD. Missing/unsupported auto decisions return to
plan review. An auto-light record is unsupported when any strict signal is
present or when its tiny/low-risk/single-owner/no-behavior-change proof is
incomplete. Only Decision: strict with recorded strict authority may
authorize steps named Write failing test, Verify RED, GREEN, ortest cases passed, vs 7 / 18 without
Published skills whose descriptions closely match this one, with their headline benchmark lift.
More skills from the same source and nearby in the registry, with their headline benchmark lift.