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 agentmods add skills/tradebaas/groundwork/skill-authornpx skills add Tradebaas/Groundwork --skill skill-authorgit clone --depth 1 https://github.com/Tradebaas/GroundworkWhat 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 | $0.00052 | $0.00764 |
| Opus 5 | $0.00026 | $0.00382 |
| Sonnet 5 | $0.00010 | $0.00153 |
| Haiku 4.5 | $0.00005 | $0.00076 |
Grade A, and why
skill-author 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 2d 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.
How it starts
The opening of the file, as written. The whole thing — 53 lines — stays where its author put it; the contents beside it link to each section on GitHub.
skill-author: grow the library deliberately, or not at all
The studied failure mode is real: a library of 557 imported skills with 3 in use. Skills are context spent on every session's listing. Each one must earn that. The general rule this ladder instances - every addition declares where it is paid, and the always-on surface carries the highest bar - is decision 0015.
1. Should this be a skill? (ladder: stop at the first rung)
- One-off knowledge? Put it in the task, not the library.
- A durable fact or rule? It belongs in the owning doc (
docs/standards/, DESIGN.md, AGENTS.md if truly universal), not a skill. - Mechanically checkable? Add a check to
checks/check.mjs+ a fixture test. Never send a model to do a linter's job. - Recurring method requiring judgment (a way of working you'd teach a new senior hire) → that is a skill. The trigger: you've needed it three times, or you know you will.
2. Write it
Create .agents/skills/<name>/SKILL.md (open Agent Skills standard):
- Frontmatter:
name= directory name (lowercase, hyphens, ≤64 chars);description≤1024 chars stating what it does and when to load it. Write the trigger phrases the moment of need actually contains; this line is all the model sees when deciding to load it. - Body ≤500 lines, imperative, information-dense. Structure: purpose (one line) → the method (numbered, decision points explicit; ladders beat essays) → what to record → how it relates to the automated gates (judgment layer above, never duplicate of).
- Heavy reference material goes in files next to SKILL.md, linked one level deep, loaded only when needed. No code snippets that will go stale: point at the living source instead.
- End the body's report instruction with the ⚓ convention if the skill produces user output.
3. Register and validate
- Add one row to the skills table in
AGENTS.md(keep the ≤150-line budget: if it doesn't fit, something else must leave; that trade-off is the point). - Run
node checks/check.mjs. It validates frontmatter, name/dir match, and budgets. - Test the trigger: describe the situation to a fresh session and confirm the skill loads.
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.
- 2d ago First seen · 53 lines · 52 tokens per session scan A f01f00c2a380
skill-author is a skill published in the GitHub repository Tradebaas/Groundwork (2 stars, last pushed 7d ago), licensed MIT. It adds 52 tokens to every session and 764 once invoked, about $0.0003 per session on Opus 5. A static security scan graded it A with 0 findings. No closer match exists in the catalogue, so it is treated as the original; first seen 2026-08-31.
Other skills, from other repositories
mission-driver
Create roadmaps and mission configs, then drive the mission-driver AI dev-loop engine. mission-driver lives at tools/mission-driver/ — it reads missions/ .json and loops CHECK → REVIEWPLANS → EXECPLANS → DRAFTPLANS → DEEPAUDIT until the roadmap is done or the audit budget is exhausted. Use this skill when the user…
keel-plan
Create or revise PLAN.md — propose the phase DAG (phases · gates · dependencies) from the user's goal, get approval, write the table and regenerate the colored Mermaid diagram from it. Statuses flip at rituals (/keel-handover, /keel-phase-review); post-completion fixes land in the Fix log.
keel-stats
Render the ritual telemetry visually — turns .claude/ritual-log into reports/ritual-stats.md with PLAN.md-style colored Mermaid interval boxes (session/compact boundaries) + a counts table. Answers "which skills/commands/hooks ran, how often, in which interval".
sdd-serve
Serve the SDD Builder's AI request queue: claim requests with sddnextrequest, draft the proposal, answer with sddrespondrequest. Never writes spec files — the user accepts each proposal in the builder. Use when the user asks to attend, serve or listen to the SDD board queue. / Atiende la cola de peticiones del SDD…
init
Configure an uninitialized project from an approved charter: stack, scripts, identity, optional Git, and verification.
sdd-workflow
Guide a project with Spec-Driven Development (SDD) discipline - idea, approved spec, consistent plan, tasks, a gate that verifies approval and consent, implementation, validation, and logbook. Bilingual EN/ES. Use when the user wants to start, spec, plan, implement, or validate work with SDD, or mentions specs, plans…