agentleFS
Sign inStart free
xiaolaixiaolai/vmark/.claude/skills/planning/SKILL.md

planning

Skill851 starsChanged 29 days agoISCView on GitHub

Create comprehensive implementation plans and write them to plan files. Use when the user asks for a plan, comprehensive plan, systematic workflow design, or wants decisions documented in a plan file.

We split this skill into the rules it gives an agent

22 rules. 0 are common, 17 are distinctive, and 5 are very specific to this project.

  • 0

    Common

    Most of the 59 edited versions we read keep these.

  • 17

    Distinctive

    This author's own choices. Worth a look.

  • 5

    Very specific

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

  • Common
  • Distinctive
  • Very specific
  1. Distinctive:

    Use this skill when the user asks for planning, a roadmap, a spec-to-implementation breakdown, or wants decisions documented.

    line 10
  2. Distinctive:

    no migrations and no multi-phase rollout

    line 20
  3. Distinctive:

    Create a Decision Log:

    line 55
  4. Distinctive:

    Create an Open Questions list:

    line 57
  5. Very specific:

    Add priority + estimates (S/M/L) and explicit ordering/dependencies between WIs.

    line 69
  6. Distinctive:

    Every WI includes tests + acceptance.

    line 74
  7. Very specific:

    Use the template at templates/TEMPLATE.md (bundled with this skill) if available, otherwise follow the structure above.

    line 77
  8. Very specific:

    Write plans to dev-docs/plans/YYYYMMDD-HHMM-<topic>.md.

    line 78
  9. Distinctive:

    Always report the saved plan path.

    line 79
  10. Distinctive:

    Every WI must include explicit tests to write before implementation (file names and test intent).

    line 83
  11. Distinctive:

    If tests cannot be written, call it out explicitly and propose the smallest test seam to enable them.

    line 84
  12. Distinctive:

    If the plan changes anything persisted (DB, on-disk cache, config files, APIs that clients store):

    line 102
  13. Very specific:

    Add a Data Model section (tables/columns/keys, versions).

    line 104
  14. Distinctive:

    Add a Migration Plan:

    line 105
  15. Distinctive:

    Add Invariants + validation queries (what to check post-migration).

    line 109
  16. Distinctive:

    Add a Backfill / reindex strategy if needed.

    line 110
  17. Very specific:

    If the plan touches indexing/search/performance-sensitive paths:

    line 114
  18. Distinctive:

    Add acceptance thresholds (e.g.

    line 118
  19. Distinctive:

    If behavior changes are user-visible or risky:

    line 122
  20. Distinctive:

    Add a Rollout Plan (feature flags, staged enablement, default-off vs default-on).

    line 124
  21. Distinctive:

    Always produce a plan file and include its path in the response.

    line 129
  22. Distinctive:

    Ask at most 1–2 clarifying questions only when they change the rules.

    line 130

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

Planning Skill

When to use

Use this skill when the user asks for planning, a roadmap, a spec-to-implementation breakdown, or wants decisions documented.

Modes

Choose the lightest mode that meets the request.

quick-plan

Use when:

  • task is small/medium and non-breaking
  • no migrations and no multi-phase rollout

Output:

  • 3–8 Work Items (WI-###), each with tests + acceptance

full-plan (default)

Use when:

  • migrations/persistence changes
  • API/contract changes (public tools, schemas, SDKs)
  • multi-phase roadmaps
  • performance-sensitive work

Output:

  • structured plan sections (see “Plan file template”)

Process

  1. Clarify outcomes
    • Restate desired behaviors and constraints.
    • Identify ambiguities and propose defaults if the user doesn’t decide.
    • Capture constraints & dependencies (runtime versions, OS, external services, feature flags, required tools).
    • Capture gaps: list requirement/behavior gaps or missing decisions revealed here.
  2. Inventory current behavior
    • Trace entry points → state/store → side effects → persistence.
    • List key files/modules and the invariants they rely on.
    • Note ownership/priority rules (windows, workspaces, files).
    • Capture gaps: list where current behavior diverges from the stated outcomes.
  3. Define target rules
    • Convert outcomes into explicit rules and precedence.
    • For each rule, include: trigger/context, expected behavior, scope, constraints, and exclusions.
    • Edge-case pass: cover empty/none, invalid/malformed, boundary sizes, conflicting state, multi-surface coordination, persistence/restore, and I/O failures.
    • Capture gaps: list rules that lack implementation support or current behavior conflicts.
    • Create a Decision Log:
      • decision, options considered, rationale, and why alternatives were rejected.
    • Create an Open Questions list:
      • questions that block correctness, who decides, and what the default is if not decided.
  4. Structure the plan
    • Break into Work Items (WI-###), each with:
      • Goal
      • Acceptance (measurable) (correctness + performance + UX where relevant)
      • Tests (first) (file names + test intent; unit/integration/e2e as applicable)
      • Touched areas (file paths + key functions/classes/symbols)
      • Dependencies (other WIs, external tools/services)
      • Risks + mitigations
      • Rollback / revert strategy
    • Add priority + estimates (S/M/L) and explicit ordering/dependencies between WIs.
    • Capture gaps: map each gap to at least one WI (or record as “out of scope”).
    • Plan lint (required):
      • Sections present (Outcomes, Constraints, Current Behavior, Target Rules, Work Items, Testing).
      • WI numbering is sequential and referenced consistently.
      • Every WI includes tests + acceptance.
  5. Write the plan file
    • Use the template at templates/TEMPLATE.md (bundled with this skill) if available, otherwise follow the structure above.
    • Write plans to dev-docs/plans/YYYYMMDD-HHMM-<topic>.md.
    • Always report the saved plan path.

Testing Requirements

  • Every WI must include explicit tests to write before implementation (file names and test intent).
  • If tests cannot be written, call it out explicitly and propose the smallest test seam to enable them.
  • Include a Testing Procedures section in the plan with required commands and when to run them.
  • End the plan with a short Manual Test Checklist.

Acceptance Criteria Guidance

Acceptance must be measurable and verifiable:

  • Good: “Search returns v1 schema with locator_v1 for every result (unit test).”
  • Bad: “Search feels better.”

Plan → Verify Handoff (required)

At the end of the plan, include:

  • Evidence to collect per WI (tests, logs, manual steps).
  • Any required fixtures or sample data.

Migration / persistence requirements (when applicable)

If the plan changes anything persisted (DB, on-disk cache, config files, APIs that clients store):

  • Add a Data Model section (tables/columns/keys, versions).
  • Add a Migration Plan:
    • forward migration steps
    • rollback steps
    • compatibility guarantees (old clients vs new server)
  • Add Invariants + validation queries (what to check post-migration).
  • Add a Backfill / reindex strategy if needed.

Observability requirements (when applicable)

If the plan touches indexing/search/performance-sensitive paths:

  • Define metrics (latency, throughput, memory, DB size growth).
  • Define where logs go and how to enable verbose tracing.
  • Add acceptance thresholds (e.g. “index 1000 docs < X minutes on machine Y”).

Rollout requirements (when applicable)

If behavior changes are user-visible or risky:

  • Add a Rollout Plan (feature flags, staged enablement, default-off vs default-on).
  • Define “kill switch” conditions and how to revert quickly.

Output Requirements

  • Always produce a plan file and include its path in the response.
  • Ask at most 1–2 clarifying questions only when they change the rules.

Download now (ZIP)

  • Other versions65 projects use a version of this.

    Word for word · 0

    None found.

    Edited · 0

    None found.

    Wrote their own version · 65

    1. langchain-ai/deepagents★ 31ksame name
    2. open-metadata/OpenMetadata★ 16ksame name
    3. atopile/atopile★ 4ksame name
    4. awslabs/agent-plugins★ 918same name
    5. ryanthedev/code-foundations★ 381same name
    6. markmdev/meridian★ 184same name
    7. mblode/agent-skills★ 177same name
    8. tmcfarlane/team-avatar★ 111same name
    9. Towow-ai/Flowness★ 107same name
    10. duongthinh03/portfolio★ 85same name

    55 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 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
  • 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