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/specnpx skills add Tradebaas/Groundwork --skill specgit 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.00058 | $0.01270 |
| Opus 5 | $0.00029 | $0.00635 |
| Sonnet 5 | $0.00012 | $0.00254 |
| Haiku 4.5 | $0.00006 | $0.00127 |
Grade A, and why
spec 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 yesterday.
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 — 88 lines — stays where its author put it; the contents beside it link to each section on GitHub.
spec: as much process as the change deserves, and no more
1. Pick the tier: argue it, don't default upward
- S: no spec. Small, clear, reversible: bugfix, copy change, config tweak, single-file change with obvious behavior. The commit message and a test are the record. If you're explaining the tier choice in more than a sentence, it isn't S.
- M: spec.md only. A feature or change in one area, buildable in a session or two.
- L: spec.md + plan.md. Multi-session, multi-area, risky, or contested. Copy
docs/specs/TEMPLATE-PLAN.mdto plan.md: build order (owned by the ticket graph), seams/interfaces touched, migration/rollback, verification approach.
Two honest tests: Would a senior write this down first? and Will anyone need to know why in three months? Yes to either → at least M.
2. Tier M and L: interview before writing
Build shared understanding first; a finished draft the owner can only react to is not that. Tier S is exempt: a bugfix gets no interview. The rules:
- One question at a time. Each question comes with your recommended answer and a one-line reason, so the owner can accept the default or push back cheaply.
- Recommendations are argued, not agreeable. A question with a real design choice behind it
gets the
critical-thinkingmoves first: the recommendation names the alternative it beat. - Facts are looked up, never asked. Whatever the repo, the docs, or the code can answer, you answer yourself before asking anything.
- Decisions are put to the owner, never assumed. Scope, trade-offs, and preferences are the owner's; surface each one as a question, however obvious the answer seems.
- Pin fuzzy terms as they surface. A word with two possible meanings goes into the glossary
docs/product/CONTEXT.mdright then, so the spec uses one word for one thing. - Write only after confirmation. Close the interview by playing back your understanding in a few lines and asking the owner to confirm it. Only then start writing. Record the confirmation (date plus the owner's words) in the spec's sign-off line; it replaces a bare "approved".
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.
- yesterday First seen · 88 lines · 58 tokens per session scan A b1dfe9bf7cb3
spec is a skill published in the GitHub repository Tradebaas/Groundwork (2 stars, last pushed 6d ago), licensed MIT. It adds 58 tokens to every session and 1,270 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".
init
Configure an uninitialized project from an approved charter: stack, scripts, identity, optional Git, and verification.
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…
review-creative
Audit customer-facing work for UX, accessibility, brand fit, credibility, and generic AI output. Use for design, marketing, document, presentation, or visual review.