Modsmith
Patterns, cost review and ready templates for Claude Mods (Claude Code plugins whose...
Install
npx skills add DannyMac180/skills --skill modsmith -g -a claude-code -y- Repository
- DannyMac180/skills745
- Category
- Design
- Updated
- 20d ago
- License
- MIT
- Context cost
- Mediumabout 2,400 tokens
- Runs scripts
- Yes, review before use
What it does
Patterns, cost review and ready templates for Claude Mods (Claude Code plugins whose behaviour is a function-hooks module). Adds what the built-in mod authoring does not: proven designs (fork-check-draw, tool + ledger, mode registry, artifact-backed state), prompt-cache and token-cost review, a vetting pass for someone else's mod, and rules for mods that compose. USE WHEN: build a mod, make a claude mod, mod templates, quiz me after each turn, assumptions tool / register_assumption, supervisor that checks the turn, next-steps check, mode selector / mode registry, effort by domain, model router that keeps the cache, prompt cache cost of a mod, what does this mod cost per turn, review or vet someone's mod before installing, mods that work together, Kanban artifact as shared project state. NOT FOR: classic shell-command hooks in settings.json (PreToolUse etc.), a plain skill or slash command, MCP server authoring, or looking up the hooks API itself (use the engine's plugin-authoring guidance and generated types).
ModSmith
Claude Code ships its own mod authoring: the plugin-authoring skill and the
generated declarations (claude-code.d.ts, written beside every mod as
.claude-plugin/types/claude-code/index.d.ts and by /plugin-types). Those
are the API. This skill does not re-teach it. It adds four things on top:
- Patterns that work, as complete templates you copy and change.
- Cost and prompt-cache review: what a mod costs per turn, what breaks the cache, and how to vet someone else's mod before installing it.
- Composition: how mods share a site, state and the cache.
- Decision notes: every mod ships a
DECISIONS.mdof what was chosen, what was rejected and what is still unverified.
Harnesses go out of date fast. When anything here disagrees with the
generated declarations for the running build, the declarations win. Load the
built-in plugin-authoring skill for any API question.
Step 1: Surface the unknowns
Before writing code, ask the few questions that decide the design. Use the question tool (AskUserQuestion) when it is available, one round, and skip any question the request already answers.
| Question | Why it decides the design |
|---|---|
| What should it show or change, and where? (band above the prompt, footer label, pane, a tool Claude calls, a rewrite of what runs) | Picks the event and the site |
| What triggers it? (every turn, turns that changed files, a slash command, a timer) | Picks the gate |
| May it spend tokens per turn, and roughly how many? (none / one cached fork on qualifying turns / more) | Fork, complete or no model call at all |
| Which mods must it work with? (quiz, supervisor, mode registry, token gauge...) | Shared sites, state contracts, hotkey clashes |
Say what you will assume for anything left unanswered, and record it in the
mod's DECISIONS.md.
