agentsclimarketplace

Plan

Skill KonH/ClaudeTools/plugins/k/skills/plan

Claude Code plugin with skills shared across project

Install
npx -y skills add KonH/ClaudeTools --skill plan

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

  • 24 days oldThe repository was created 24 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.
  • 1 stars1 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

Create an implementation plan and save it to docs/specs/<YY_MM_DD_HH>_<name>/plan.md, gated by a required constitution check.

SKILL.md

3.7 KB, 839 tokens by cl100k_base, as published. Nobody here has run it

Create a plan for the requested task and save it to docs/specs/<YY_MM_DD_HH>_<name>/plan.md.

Doc paths

Default convention: docs/specs/ for spec/plan folders, docs/constitution.md for project principles. Check the project's CLAUDE.md for overriding locations before falling back to these defaults.

Constitution Gate (required)

A plan may not be finalized without a constitution. Before anything else:

  1. Check whether docs/constitution.md exists.
  2. If it does not: stop, tell the user no constitution was found, and ask whether they want one created now — and what principles it should capture. Do not invent principles on their behalf. Only continue once a constitution exists (pre-existing or just created with their input).

Once a constitution exists, the architect sub-agent reads it before finalizing the plan and appends a Constitution Check section to the plan:

  • Either: No conflicts found — plan aligns with all principles.
  • Or: a numbered list of principles the plan would violate, each with a one-sentence proposed resolution

The orchestrator surfaces any violations to the user before presenting the final plan. If there are violations, the user must confirm each resolution before the plan is written. Do not write the plan file if unresolved violations exist.

Orchestration

Spawn an architect sub-agent (general-purpose) to design and write the plan. Brief it with:

  • The user's task description
  • Relevant project rules (from CLAUDE.md and any project rules directory)
  • The contents of docs/constitution.md
  • Existing spec/plan folders in docs/specs/ (list them to resolve an existing dated spec identifier)
  • The output path and format rules below

The architect writes the plan file directly. You (orchestrator) then:

  1. Present the plan contents to the user
  2. Collect feedback and re-brief the architect if changes are needed (iterate until approved)
  3. Run the plan-review skill as a final check — present any concerns one by one and ask the user to approve each fix
  4. Stop and wait for the user to run the implement skill

Spec Detection

If $ARGUMENTS contains a spec folder name or index, or if a docs/specs/<index>_* folder exists with no plan.md yet:

  • Read docs/specs/<YY_MM_DD_HH>_<name>/spec.md
  • Brief the architect with the spec contents
  • Include a Spec section at the top of the plan (verbatim summary of intent and acceptance criteria from the spec)

If no spec folder is found (a purely technical task — migration, refactor, infra), create docs/specs/<YY_MM_DD_HH>_<name>/plan.md using the current local timestamp, just without a spec.md in that folder.

Plan File Rules

  • The containing spec folder uses YY_MM_DD_HH_name, where the timestamp is the local creation time and name is a short kebab-case description (e.g. 26_07_18_14_map-prototype)
  • Structure: goal, approach, steps — keep it concise
  • If the plan touches source code, include a Tests section covering what unit/integration tests should be added or updated
  • Do NOT make any code, asset, or file changes — only write the plan document
  • End every plan with the line: Use the implement skill to start working on the plan or request changes.

Step Block Structure

Split steps into two sections:

Section 1 — Agent Steps (Claude performs autonomously via file edits and tools):

  • Use markdown checkboxes: - [ ] **Step title** — concise description

Section 2 — User Steps (requires manual interaction Claude cannot perform — an external editor/tool, visual inspection, hardware, etc.):

  • Use numbered headings (### N. Title) with body text — no checkboxes

Gives 0 of the 12 instructions most plan spec skills give in 839 tokens

Counted across 1,099 of the 1,860 authors here whose files we hold, read 2026-08-07

  • ask one question at a timein 51 of 1099
  • Break plans into vertical slicesin 29 of 1099, across 11 files
  • Publish issues in dependency orderin 27 of 1099, across 9 files
  • Iterate until user approves the breakdownin 25 of 1099, across 7 files
  • Explore the repository to understand the codebase statein 24 of 1099, across 7 files
  • Use domain glossary vocabularyin 23 of 1099, across 5 files
  • Apply correct triage labels to published issuesin 23 of 1099, across 5 files
  • prefer AFK slices over HITLin 22 of 1099, across 7 files
  • write a specification before writing any codein 22 of 1099, across 14 files
  • Write failing tests before implementation codein 22 of 1099, across 20 files
  • ask clarifying questions until requirements are concretein 21 of 1099, across 13 files
  • Respect existing architecture decision recordsin 20 of 1099, across 5 files

Said here and by no other author read

  • check project configuration for overriding paths
  • verify a constitution file exists
  • ask the user to provide constitution principles
  • spawn an architect sub-agent to write the plan
  • append a constitution check section to the plan
  • surface constitution violations to the user

Grouped from the skills themselves: near-identical wordings counted once, and counted by distinct author, so one author publishing three of these counts once. Length counted with cl100k_base; the agent that loads this file may tokenize it differently.

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.