Getting it into your agent
One page per mod, every tool's command on it. A separate URL per tool would split the same page into five that compete with each other.
npx skills add mishahanin/heading-os-marketplace --skill create-plangit clone --depth 1 https://github.com/mishahanin/heading-os-marketplaceWrote this? Show the measurements
A badge with what this costs and how it scanned, read live from this page, so it follows the numbers instead of freezing them. Markdown for a README, HTML for a documentation site or a project page.
[](https://agentmods.dev/skills/mishahanin/heading-os-marketplace/create-plan)<a href="https://agentmods.dev/skills/mishahanin/heading-os-marketplace/create-plan"><img src="https://agentmods.dev/badge/skills/mishahanin/heading-os-marketplace/create-plan/github.svg" alt="Measured on agentmods" height="20"></a>Or the 80×15 button, for a site that already has a row of RSS and ATOM ones. Only the verdict fits; the numbers stay here.
<a href="https://agentmods.dev/skills/mishahanin/heading-os-marketplace/create-plan"><img src="https://agentmods.dev/badge/skills/mishahanin/heading-os-marketplace/create-plan.svg" alt="Reviewed on agentmods" width="80" height="20"></a>What it costs to keep this loaded
Counted locally with the o200k_base tokenizer, which is exact for GPT models; Claude uses its own tokenizer and its counts differ. Treat this as one consistent yardstick across the catalogue rather than a bill. Prices are per million input tokens.
| Model | Per session | Once invoked |
|---|---|---|
| Fable 5.1 | $0.00079 | $0.01389 |
| Opus 5 | $0.00039 | $0.00694 |
| Sonnet 5 | $0.00016 | $0.00278 |
| Haiku 4.5 | $0.00008 | $0.00139 |
Grade A, and why
create-plan scanned grade A with 0 findings against 26 rules in 11 categories — prompt injection, anti-refusal, data exfiltration, privilege escalation, supply chain, agent snooping, system-prompt leakage, SSRF and excessive agency — measured 11d ago.
A static scan of the body, not an audit. Every finding is printed with the line that produced it so you can judge whether it matters here. A mod is markdown that instructs an agent; that is exactly why what it instructs is worth reading.
Nothing flagged
None of the 26 patterns this scan looks for appear in this file: no shell pipes, no recursive deletes, no credential paths, no hidden text, no instruction-override or anti-refusal phrasing, no agent-config snooping. That is not a guarantee, it is the absence of the things that are checkable.
This is a copy
100% identical to create-plan — 0 lines differ, which has more behind it and is treated as the original. This page carries a canonical link to it rather than competing with it.
How it starts
The opening of the file, as written. The whole thing — 128 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Plan
Create a detailed implementation plan for changes to this workspace. Plans are thorough documents that capture the full context, rationale, and step-by-step tasks needed to execute a change with complete alignment across the project.
Variables
request: $ARGUMENTS (describe what you want to plan — new command, new workflow, structural change, template update, etc.)
Instructions
- IMPORTANT: You are creating a PLAN, not implementing changes. Research thoroughly, think deeply, then output a comprehensive plan document.
- Use your reasoning capabilities to think hard about the request, workspace structure, and best approach.
- Research the workspace to understand existing patterns, conventions, and how this change fits.
- Create the plan in the
plans/directory with filename:YYYY-MM-DD-{descriptive-name}.md- Use today's date
- Replace
{descriptive-name}with a short, kebab-case name (e.g., "add-guest-research-command", "restructure-outputs", "create-outreach-workflow")
- Fill out every section of the Plan Format below. Replace all
<placeholders>with specific, actionable content. - Be thorough — this plan will be executed by
/implementand needs enough detail to execute without ambiguity. - Follow existing patterns. Study similar files in the workspace before proposing new structures.
Research Phase
Before writing the plan, investigate:
-
Read core reference files:
CLAUDE.md— workspace overviewcontext/— background context on the user and project
-
Explore relevant areas:
- If creating a skill: read existing skills in
.claude/skills/ - If modifying outputs: explore
outputs/structure and examples - If updating templates: check
reference/for existing patterns - If adding scripts: review
scripts/for conventions
- If creating a skill: read existing skills in
-
Understand connections:
- How does this change relate to existing workflows?
- What files reference or depend on areas being changed?
- Are there naming conventions to follow?
What ships with it
2 files beside SKILL.md in the same directory: the scripts, references and assets a skill reads on demand. Not counted in the per-session cost; read them before you install if any of them is executable.
What this file has done since we first saw it
Hashed on every crawl. A supply-chain change to an agent config is a question of when, not whether, so the history is kept rather than the latest state alone.
- 11d ago First seen · 128 lines · 79 tokens per session scan A 101a6ed114cf
create-plan is a skill published in the GitHub repository mishahanin/heading-os-marketplace (2 stars, last pushed 4d ago), licensed Apache-2.0. It adds 79 tokens to every session and 1,389 once invoked, about $0.0004 per session on Opus 5. A static security scan graded it A with 0 findings. It is 100% identical to create-plan, differing in 0 lines, and is treated as a copy.
Other skills, from other repositories
adr
Use when the user knows what they want built and says "/adr", "write an ADR for X", "decide and build X", or "ADR-driven". Turns an intent into a grounded, cited, build-ready ADR at docs/adr/YYYY-MM-DD- .md — load-bearing decisions surfaced to the human — then hands off to nightshift:plan's landing step (the plan is…
domain-modeling
Use when pinning down domain terminology, building a ubiquitous language or project glossary, disambiguating overloaded or vague terms, or maintaining a CONTEXT.md — or when another skill needs to sharpen the domain model. Do NOT use for recording architectural decisions (use adr) or for writing implementation specs.
plan
Use when the user has an idea, feature, or fix that is more than a one-sitting edit and says "plan this", "write a plan for X", "/nightshift:plan", or "what would it take to build X". Sizes the work (trivial → no artifact; medium → a lean plan; large → a short spec first), asks one question at a time until the design…
watch
Use when a Nightwatch spec queue is about to run, or is already running, and someone needs to fire it, watch it, and steer it — "launch nightwatch", "watch the run", "/nightwatch:watch", "pause it", "skip that spec". Runs preflight, launches run.sh, arms the journal and workflow-journal monitors, knows what is safe to…
morning
Use when the user says "/nightshift:morning", "what happened overnight", "how did the night go", "why did the loop stop", or opens a session in a repo with a loop/ directory after a scheduled run. Reads the journal since the last start line and every open land / land:blocked pull request, says per stop what happened…
writing-artifacts
Use when writing or revising a durable written artifact — README, ADR, design doc, PR description, release notes, runbook, error message, user-facing docs. Gives a positive writing system (reader model, sentence positions, document jobs), not a ban-list. Do NOT use for conversational replies to the user (global…