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/scopenpx skills add Tradebaas/Groundwork --skill scopegit 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.00070 | $0.00816 |
| Opus 5 | $0.00035 | $0.00408 |
| Sonnet 5 | $0.00014 | $0.00163 |
| Haiku 4.5 | $0.00007 | $0.00082 |
Grade A, and why
scope 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 — 64 lines — stays where its author put it; the contents beside it link to each section on GitHub.
scope: the boundary is a decision, not a feeling
docs/product/BRIEF.md is the single measuring stick. This skill is the only path that changes it.
Sharpening scope
For each candidate capability, make it earn its place:
- Which user, in which situation, is blocked without it?
- Does an existing capability (SC-item), a platform feature, or an off-the-shelf product already cover it? (Decision ladder: don't rebuild what exists.)
- Can version one ship without it? If yes, it goes to Out of scope or INTAKE with a trigger.
Write results as numbered, testable SC-items. Vague scope ("a dashboard") is not scope; scope
says what the user can do ("SC-3: owner sees per-project hours, filterable by month").
Phrase each one so the owner recognizes it without a translation: their words, no jargon, no
component names. The progress overview quotes these lines back to them verbatim
(node checks/progress.mjs), so a line only they can read is a line they cannot check.
A fuzzy word in any answer ("you said account: the Customer or the User?") gets pinned in the
glossary docs/product/CONTEXT.md the moment it surfaces.
Sharpen at the project's class depth: begin §2 defines personal, team, and organization
and names which BRIEF discovery rows each class answers. A change that shifts the class
upward - a personal tool gains team users, a team tool reaches a client - reopens every
BRIEF discovery row that says n/a: re-ask those at the new depth before widening anything
else.
Triage: INTAKE.md
Nothing is built from INTAKE. Per item, propose one of:
- In scope → owner signs off → add/extend an SC-item → gets a spec (
specskill). - Out of scope → record the reason in BRIEF's out-of-scope list. Say it plainly; a parked good idea is not a rejection of the person.
- Later → stays in INTAKE with an explicit revisit trigger ("after launch", "if >100 users").
- Bug → not a scope question; goes straight to a fix with a regression test.
For an in-scope item, name the cheapest tier that delivers it (decision 0015: an artifact or on-demand skill before a gate, a gate before an always-on rule); the tier is part of the recommendation.
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 · 64 lines · 70 tokens per session scan A fc5297e43552
scope is a skill published in the GitHub repository Tradebaas/Groundwork (2 stars, last pushed 7d ago), licensed MIT. It adds 70 tokens to every session and 816 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
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…
keel-handover
Add this session's block to HANDOVER.md before ending or compacting — done / tried-failed / latest / next. Rotates via /keel-distill when the 3-block cap is hit.
keel-team
OWNER-only setup wizard for a REAL human team (different people, different machines) — declare the owner (arm owner-guard), register members (@tags), seed lanes + author folders + the comprehension protocol, size the caps, pick the §6 contribution model + host wall. Packages the existing Multi-user playbook into one…
init
把这个 agent 项目模板初始化成一个真实项目——通过分阶段访谈问清项目定位、技术栈、领域概念、红线和范围，然后填充 AGENTS.md 与 docs/ 里的所有 TODO(init) 占位。当用户说"初始化项目"、"应用这个模板"、"帮我把项目建起来"、"续问 init"、"接着上次的问题继续"，或者 AGENTS.md 顶部还有「这个仓库还没初始化」引用块时使用。.
ship-change
完整交付一个功能或一次改动的标准流程，从确认范围、实现、自测到收尾同步文档。当用户说"做一下 X 功能"、"实现"、"加个"、"改一下"这类需要动代码的任务时使用，尤其是改动会跨多个文件的时候。.
keel-adopt
Adopt Keel's discipline into an EXISTING project (brownfield) — inventory, non-destructive merge, back-fill docs from real code, migrate security. Never overwrites.