agentsclimarketplace

Plan before executing

Skill kalshamsi/fable-discipline-skills/skills/plan-before-executing

11 evidence-backed process-discipline skills for Claude Code — Fable 5 working disciplines transplanted onto Opus, blind A/B validated

Install
npx -y skills add kalshamsi/fable-discipline-skills --skill plan-before-executing

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

2 things to look at

  • 29 days oldThe repository was created 29 days ago. New is not bad, but a brand new repository carrying a familiar-sounding name is the shape a typosquat arrives in, and there has been no time for anyone else to find a problem with it.
  • 0 stars0 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.

What its author says it does

Copied from the file, not written here

For any multi-step work, commit to an explicit ordered plan — steps, dependencies, and what done looks like — before producing the deliverable, then follow it and note deviations. Use this whenever a task has multiple parts, ordering constraints, dependencies, or deadlines, even if the user never says "plan" — rewrites with several required changes, research with sequenced questions, event or rollout schedules, runbooks, migrations, restructurings, multi-document deliverables, anything where step B needs step A's result. If you catch yourself about to start on the first piece of a many-piece task, that is the trigger.

SKILL.md

3.4 KB, as published. Nobody here has run it

Plan Before Executing

Diving straight into a multi-step task is where steps get skipped, dependencies get violated, and requirements silently fall out. Decomposing a problem into an ordered plan before solving it measurably reduces missed steps and wrong sequencing (Plan-and-Solve, Least-to-Most prompting), and disciplined operations put the plan half strictly before do/check/act for the same reason (Toyota A3 / PDCA): a plan is cheap to fix; a half-built deliverable is not.

Process

  1. Extract everything the task requires. List every part, constraint, deadline, and dependency stated or implied in the input. This inventory is what protects you from dropping items later.
  2. Order the steps by dependency, not by ease. For each step, note what it needs from earlier steps and any date or resource constraint. If two orderings both work, pick one and say so; if a stated constraint makes the task impossible, surface that now rather than mid-execution.
  3. Define done before starting. Write what the finished deliverable contains and what would count as a violated constraint — this is the checklist you verify against at the end.
  4. Execute in plan order. Work step by step; check off each item from the step-1 inventory as it lands in the deliverable.
  5. Note deviations, don't hide them. If execution reveals the plan was wrong, adjust — and record what changed and why, so the final result and the stated plan agree.

What this looks like

  • Event planning: venue is booked before invitations go out; catering headcount waits on the RSVP deadline; every task from the brief appears on the timeline.
  • Research report: background questions are answered before the comparison section that depends on them; each source requested in the brief is used or its absence explained.
  • Code migration: schema change ships before the code that reads the new column; the rollback step exists before the rollout begins.

Output rules

  • Never narrate your own diligence. No "I carefully planned...", "having mapped all dependencies...", "as instructed, I first...". The discipline shows in a deliverable whose ordering is correct and complete — not in self-description.
  • Keep output proportionate to the task. A five-step task needs a five-line plan, not a project charter.
  • The planning happens before or while producing the answer; only its results appear in the output. Show the plan itself when the plan is the deliverable (runbook, schedule, rollout) or when the user needs to approve sequencing — otherwise just deliver work that follows it.

Grounding: Wang et al. 2023, Plan-and-Solve Prompting (arXiv:2305.04091); Zhou et al. 2022, Least-to-Most Prompting (arXiv:2205.10625); Toyota A3 / PDCA — plan precedes do/check/act (ASQ).

Keep looking

Skills are one crate of 328,083. Ordering is by how many stacks a row turns up in, so the top of any crate is what has actually been picked rather than what has the most stars.