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/maintainnpx skills add Tradebaas/Groundwork --skill maintaingit 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.00074 | $0.01427 |
| Opus 5 | $0.00037 | $0.00714 |
| Sonnet 5 | $0.00015 | $0.00285 |
| Haiku 4.5 | $0.00007 | $0.00143 |
Grade A, and why
maintain 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 — 94 lines — stays where its author put it; the contents beside it link to each section on GitHub.
maintain: the product is now a running system
Maintenance sessions still follow the session protocol: STATE.md first, one task, state updated. Maintenance is scope-bound too; "while maintaining" is not a license to rebuild.
Observability: you cannot maintain what you cannot see
First maintenance session: confirm the minimum exists, or create it and record it in
docs/operations/monitoring.md:
- Errors are captured somewhere a human looks (error tracking, log alerts, per stack).
- The critical flow has a heartbeat: you find out it broke before the user tells you.
- Failure of background jobs/integrations is visible, not silently swallowed. The studied production system's worst bugs were invisible failures marked "done".
The maintenance loop (each session, in this order)
- Signals: errors, alerts, intake since last session. Triage bugs (fix + regression test)
from wishes (INTAKE.md →
scope). - Dependencies: audit for known vulnerabilities (blocking; fix now), then routine updates
in small, verified batches: never a big-bang upgrade with feature work mixed in. On a
platform stack (the stack file's header declares a hosted platform) the audit has the same
job and different subjects: connectors and the permissions they carry, installed managed
solutions and store apps, plugins and custom code registered in the instance, and the
vendor's own release and deprecation notices. Those last ones move on the vendor's schedule
rather than yours, which is what makes a platform go stale while every project file sits
untouched. The installed design method is a dependency too, and the only one that is not in a
manifest: re-run
node checks/design-method.mjs --installto take its current release (it reports the installed version and changes nothing when that is already the newest), read the version back from the enforcement line at the top ofnode checks/check.mjs, and note it in STATE.md when it moved. Read the release notes for a rule that was dropped: decision 0020 credits rules to that method, and one that disappears upstream comes back into a Groundwork file rather than being forked there. - Debt harvest:
grep -rn "defer:" --exclude-dir=.git .→ reconcile with DEBT.md. Flag markers whose upgrade trigger has fired, andno-triggermarkers (those rot silently). Paying debt is a proposed, owner-approved task like any other. - Drift check:
node checks/check.mjs+ spot-check that STATE.md, BRIEF and reality still agree. Docs describing a system that no longer exists → fix + denylist. - Success metrics: a read date in BRIEF's measurement plan that has passed gets read now,
and the number written next to its criterion in BRIEF, dated. Nothing due, nothing to do.
Measured below target is a finding for
scope, not a defect fordebug: the capability works, the value did not arrive.
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 · 94 lines · 0 tokens per session scan A 53c839660a94
maintain is a skill published in the GitHub repository Tradebaas/Groundwork (2 stars, last pushed 7d ago), licensed MIT. It adds 74 tokens to every session and 1,427 once invoked, about $0.0004 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…