agentleFS
Sign inStart free
mattmirelesmattmireles/gemma-tuner-multimodal/.claude/skills/execute-plan/SKILL.md

execute-plan

Skill1.5k starsChanged 4 days agoMITView on GitHub

Execute a checked-in implementation plan for this repo phase by phase. Commits land once per completed phase locally; push and CI monitoring run once after every phase is done (not after each phase). Use when the user provides a concrete plan path and wants end-to-end implementation, phase audits, plan updates, commits, push, and CI monitoring. Do not use for creating a plan, one-off fixes without a checked-in plan, or read-only review work.

  • Commits and pushes

We split this skill into the rules it gives an agent

14 rules. 0 are common, 11 are distinctive, and 3 are very specific to this project.

  • 0

    Common

    Most of the 21 edited versions we read keep these.

  • 11

    Distinctive

    This author's own choices. Worth a look.

  • 3

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Distinctive:

    Use this skill to execute an existing repo plan without collapsing the work into one giant unreviewed change.

    line 10
  2. Distinctive:

    No checked-in plan exists yet.

    line 22
  3. Very specific:

    If execute-plan was routed implicitly or inferred rather than invoked directly, it may prepare local implementation work but must stop …

    line 37
  4. Distinctive:

    Read references/index.md first.

    line 46
  5. Very specific:

    Read the target plan and linked docs (README.md, README/guides/, README/skills/, and README/notes/ if present) before changing code.

    line 47
  6. Distinctive:

    After all phases are complete:

    line 64
  7. Very specific:

    follow git-push for syncing with origin, pushing the branch, watching GitHub Actions, and fixing failures until green (phase commits stay …

    line 65
  8. Distinctive:

    Never revert unrelated user work.

    line 74
  9. Distinctive:

    Stop only when an existing change creates a real safety or correctness conflict with the current phase.

    line 75
  10. Distinctive:

    Before each phase commit, explicitly verify:

    line 80
  11. Distinctive:

    Do not create a new plan inside this workflow.

    line 90
  12. Distinctive:

    Do not silently skip the audit step.

    line 91
  13. Distinctive:

    Do not push with known failing CI unless the user explicitly overrides that rule.

    line 95
  14. Distinctive:

    Read references/index.md first.

    line 100

“Common” is measured: kept by at least 6 in 10 of the 21 edited versions of this file we could read. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

Execute Plan

Purpose

Use this skill to execute an existing repo plan without collapsing the work into one giant unreviewed change. The unit of progress is one completed phase at a time.

Use When

  • A concrete checked-in plan path exists (commonly docs/plans/... or a team-agreed path; README/plans/ is gitignored here for local-only drafts).
  • The plan is implementation-ready.
  • The user wants the full implementation loop, not just discussion.

Do Not Use When

  • No checked-in plan exists yet.
  • The request is a one-off fix without a real plan.
  • The request is planning, brainstorming, or read-only review.

Authority Model

  • Explicit invocation of $execute-plan counts as authorization for this workflow's git side effects. Direct naming also counts, for example "use execute-plan":
    • During phases (step 4): narrow phase commits on the current branch only. You may git fetch and merge/rebase locally to integrate origin/main when needed—do not git push to origin and do not run the full git-push skill until all phases are complete.
    • After all phases (step 5): one git-push pass: integrate upstream, push the branch, monitor GitHub Actions, and fix failures until green.
  • If execute-plan was routed implicitly or inferred rather than invoked directly, it may prepare local implementation work but must stop before the first commit or push and explain why.
  • At the start of the workflow, state that execute-plan is running: phase commits first, then a single push/CI tail—unless the user opts out of remote writes.

Procedure

  1. Read references/index.md first.
  2. Read the target plan and linked docs (README.md, README/guides/, README/skills/, and README/notes/ if present) before changing code.
  3. Refuse to start if the plan is missing, too vague to execute honestly, or still requires planning work.
  4. Execute one phase at a time:
    • 4a. Execute the current phase. Implement only the active phase scope. Make it perfect. No god modules. No bugs. Just elegant, modular code.
    • 4b. Audit the execution with phase-audit. Prefer delegated review when the runtime supports it cleanly; otherwise run the same checklist locally against the canonical rubric. Double-check the work and fix findings before moving on. Make it perfect.
    • 4c. Update the plan. Make the phase checkboxes match reality before calling the phase complete.
    • 4d. Commit only your changes. Stage only the files for the completed phase (narrower than the default git-commit whole-tree staging) and follow the git-commit skill for the commit message (what and why). Stop after the commit—do not push. Per-phase push is an anti-pattern here.
  5. After all phases are complete:
    • follow git-push for syncing with origin, pushing the branch, watching GitHub Actions, and fixing failures until green (phase commits stay narrower than default git-commit; git-push still applies merge/push/CI loop).

Worktree Rules

  • Ignore unrelated dirty files unless they directly conflict with the active phase.
  • Never revert unrelated user work.
  • Stop only when an existing change creates a real safety or correctness conflict with the current phase.

Audit Contract

Before each phase commit, explicitly verify:

  • the phase goal is actually complete
  • the plan checkboxes match the implementation
  • obvious edge cases are handled
  • tests or checks are appropriate for the change
  • the current phase is commit-ready

Boundaries

  • Do not create a new plan inside this workflow.
  • Do not silently skip the audit step.
  • Do not push to origin between phase commits. Reserve git push and the git-push skill for step 5 (after every phase is implemented and committed), unless the user explicitly asks for a different cadence.
  • Do not push with known failing CI unless the user explicitly overrides that rule.

Canonical Docs

Read references/index.md first. It maps the shared workflow guide, the phase audit rubric, and the artifacts needed to execute a plan cleanly.

Handoff Rules

  • Hand off to phase-audit when clean delegated review is available.
  • Hand off to create-plan only if the user actually needs a new plan instead of execution.

Download now (ZIP)

  • Other versions23 projects use a version of this.

    Word for word · 0

    None found.

    Edited · 0

    None found.

    Wrote their own version · 23

    1. danielvm-git/bigpowers★ 286same name
    2. alamops/skills★ 53same name
    3. Integralist/agent-skills★ 20same name
    4. Ovich/charrette★ 13same name
    5. Ovich/swarmstorm★ 13same name
    6. T-miracle/codex-skills-zh★ 5same name
    7. preetamnath/agent-skills★ 4same name
    8. gfrancodev/overdrive★ 3same name
    9. giuice/giuice-agent-skills★ 3same name
    10. melconcoast/code-idea★ 3same name

    13 more not listed

    How matches are found. Word for word: the exact same text. Edited: shares passages with this file (“99% same” means 99% of its five-word phrases also appear here; 10% or more counts). Their own version: similar meaning, or, weakest, the same name. We can’t tell which project had it first. Projects are counted among the 200 most-starred candidates, and mentions are links to the repository we found, up to 50 per site, so both counts are a floor.

  • Used alongsideProjects with it also use to-spec, grill-with-docs and 5 more.

    Other files people use alongside this one.

    Files found in the same public projects as a version of this one, more often than they turn up anywhere else. Each project counts once, large collections count for less, and this file's own repository is left out.
    • GoogleSkill

      to-spec

      Turn the current conversation into a spec and publish it to the project issue tracker — no interview, just synthesis of what you've already discussed.

      Also in 3 projects that use this

    • MicrosoftSkill

      grill-with-docs

      Grilling session that challenges your plan against the existing domain model, sharpens terminology, and updates documentation (CONTEXT.md, ADRs) inline as decisions crystallise. Use when user wants to stress-test a plan against their project's language and documented decisions.

      Also in 4 projects that use this

    • GoogleSkill

      domain-modeling

      Build and sharpen a project's domain model. Use when the user wants to pin down domain terminology or a ubiquitous language, record an architectural decision, or when another skill needs to maintain the domain model.

      Also in 3 projects that use this

    • Hugging FaceSkill

      implement

      Make tests pass. Invoke after /write-tests produces failing tests.

      Also in 3 projects that use this

    • NVIDIASkill

      research

      Before designing a feature, research how comparable libraries solve the problem, check best practices, known pitfalls, and upstream changes. Use when starting a new feature, investigating an unfamiliar area, or the user asks to research something.

      Also in 3 projects that use this

    • +2 more from google
  • In this repository20 other files it gives its agents.

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

Check your setup, free