agentleFS
scolladonscolladon/craft/skills/planning/SKILL.md

planning

Skill2 starsChanged 34 days agoMITView on GitHub

Craft phase 4 - produce the parted TDD implementation plan via the planner agent; mechanically linted so every part carries its context block.

71 other projects use a version of this.

Adopted by

Most recently taken up by

Used with

Projects with it also use Problem-Solving Techniques, executing and 10 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.
  • truongtv22Skill

    Problem-Solving Techniques

    Apply systematic problem-solving techniques for complexity spirals (simplification cascades), innovation blocks (collision-zone thinking), recurring patterns (meta-pattern recognition), assumption constraints (inversion exercise), scale uncertainty (scale game), and dispatch when stuck. Techniques derived from Microsoft Amplifier project patterns adapted for immediate application.

    Also in 5 projects that use this

  • LucasDuysSkill

    executing

    Autonomous task implementation workflow — implement, test, review, commit for each task in the frontier

    Also in 3 projects that use this

  • mrgoonieSkill

    web-frameworks

    Build modern full-stack web applications with Next.js (App Router, Server Components, RSC, PPR, SSR, SSG, ISR), Turborepo (monorepo management, task pipelines, remote caching, parallel execution), and RemixIcon (3100+ SVG icons in outlined/filled styles). Use when creating React applications, implementing server-side rendering, setting up monorepos with multiple packages, optimizing build performance and caching strategies, adding icon libraries, managing shared dependencies, or working with TypeScript full-stack projects.

    Also in 5 projects that use this

  • mrgoonieSkill

    mcp-management

    Manage Model Context Protocol (MCP) servers - discover, analyze, and execute tools/prompts/resources from configured MCP servers. Use when working with MCP integrations, need to discover available MCP capabilities, filter MCP tools for specific tasks, execute MCP tools programmatically, access MCP prompts/resources, or implement MCP client functionality. Supports intelligent tool selection, multi-server management, and context-efficient capability discovery.

    Also in 5 projects that use this

  • renathoazSkill

    verifying

    Verify work before claiming done.

    Also in 3 projects that use this

  • truongtv22Skill

    mobile-development

    Build modern mobile applications with React Native, Flutter, Swift/SwiftUI, and Kotlin/Jetpack Compose. Covers mobile-first design principles, performance optimization (battery, memory, network), offline-first architecture, platform-specific guidelines (iOS HIG, Material Design), testing strategies, security best practices, accessibility, app store deployment, and mobile development mindset. Use when building mobile apps, implementing mobile UX patterns, optimizing for mobile constraints, or making native vs cross-platform decisions.

    Also in 4 projects that use this

  • +6 more from mrgoonie

The file

We split this skill into the rules it gives an agent

4 rules. 0 are common, 3 are distinctive, and 1 is very specific to this project.

  • 0

    Common

    Most of the 64 edited versions we read keep these.

  • 3

    Distinctive

    This author's own choices. Worth a look.

  • 1

    Very specific

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

  • Common
  • Distinctive
  • Very specific
  1. Very specific:

    When it returns: a final message starting NO-OP: no part remains — takes the

    line 33
  2. Distinctive:

    Coverage: every requirement id in the design doc's Requirements section appears in the planner's mapping.

    line 43
  3. Distinctive:

    Delivers what it claims: read each cited commit's git show --stat and confirm it delivers the requirement mapped to it (the same spot-check …

    line 56
  4. Distinctive:

    Read the plan; verify part sizing (no test-only parts) and that part contexts reference real files/symbols (spot-check).

    line 66

“Common” is measured: kept by at least 6 in 10 of the 64 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

craft:planning

Preamble (always runs — non-overridable)

  1. Manifest read (lint if standalone).
  2. Probe: plan directory (paths.plan, else docs/plan/, create if absent); design doc present? present → hard input; absent → the planner's mandatory input is the resolved brief and it performs its own exploration (slower, never blocked).
  3. Memory read/write surface (advisory). READS: part-sizing entries from prior runs as a weak planner hint (no per-use re-check; confidence-weighted). Prepended to the planner spawn's injected block when non-empty. WRITES: none directly from this phase — part sizing is observed at implementation when each part's pass/blocked outcome is known.
  4. Intention consult surface (advisory). The phase receives the intention consult slice on slot 1 — the IntentionView entries whose subjects intersect this phase's change scope, prepended into the same injected contract block as the memory hint (see skills/run/SKILL.md step 4). An empty slice means the phase runs its own probes.

Procedure (default body — a manifest override: replaces everything below)

  1. Spawn craft:planner with: the design doc path (or brief) + the accepted ADR paths; the absolute working directory; the output path <plan-dir>/<slug>.md; the template "${CRAFT_ROOT:-${CLAUDE_PLUGIN_ROOT}}/templates/plan.md"; the part-gate command (manifest gates.part, or probe: the repo's test runner over touched files, falling back to gates.phase); the commit message docs(plan): <slug>; global + planning-phase context: files verbatim.
  2. When it returns: a final message starting NO-OP: no part remains — takes the no-op branch below; any other return runs "${CRAFT_ROOT:-${CLAUDE_PLUGIN_ROOT}}/scripts/plan-lint.sh" <plan-path> — the phase cannot close red. On failure, respawn fresh with the lint output; ≤2 respawns, then escalate.

    No-op branch (every design requirement is already delivered by a commit this run landed; no plan file exists, so plan-lint is not run). <base> is the default branch the workspace phase probed (origin/HEAD → main → master); resolve it once with git rev-parse --verify --quiet '<base>^{commit}' — a failure escalates. Every check below must pass before anything is recorded:

    • Coverage: every requirement id in the design doc's Requirements section appears in the planner's mapping; an empty or partial mapping fails.
    • Shape: each mapped value is a token matching ^[0-9a-f]{7,40}$ that git rev-parse --verify --quiet '<sha>^{commit}' resolves; a symbolic rev or any other text fails. Each sha is passed to git as one single-quoted argument.
    • Landed this run: git merge-base --is-ancestor <sha> HEAD must exit 0 and git merge-base --is-ancestor <sha> <base> must exit exactly 1; any other exit (128 included) escalates.
    • Not the run's own paperwork: a sha whose git diff-tree --no-commit-id --name-only -r <sha> touches only the design directory, the plan directory and README.md fails — the design commit (with its README corpus-count bump) always lands before planning and delivers no requirement. An ADR commit is not rejected here: a decision can be the deliverable, so the spot-check below judges it.
    • Delivers what it claims: read each cited commit's git show --stat and confirm it delivers the requirement mapped to it (the same spot-check Procedure 3 runs on parts).

    Any failure: respawn fresh with the failures — the same ≤2 respawns — then escalate { planning, reason, ≤3 options }. All pass: append NO-OP(planning): no part remains — <justification> (the planner's requirement → sha list verbatim) and PHASE-DONE(planning): no-op — no part remains in one run-ledger.sh append <run-id> planning call (walk step 7). Commit nothing. Standalone (no open run): report the planner's line and stop — there is no ledger to receive it and no commit.

  3. Read the plan; verify part sizing (no test-only parts) and that part contexts reference real files/symbols (spot-check). Record in the run record. Skipped on the no-op branch: there are no parts.

Download now (ZIP)

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.