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 skills add comisai/comis --skill gsd-buildergit clone --depth 1 https://github.com/comisai/comisWrote this? Show the measurements
A badge with what this costs and how it scanned, read live from this page, so it follows the numbers instead of freezing them. Markdown for a README, HTML for a documentation site or a project page.
[](https://agentmods.dev/skills/comisai/comis/gsd-builder)<a href="https://agentmods.dev/skills/comisai/comis/gsd-builder"><img src="https://agentmods.dev/badge/skills/comisai/comis/gsd-builder/github.svg" alt="Measured on agentmods" height="20"></a>Or the 80×15 button, for a site that already has a row of RSS and ATOM ones. Only the verdict fits; the numbers stay here.
<a href="https://agentmods.dev/skills/comisai/comis/gsd-builder"><img src="https://agentmods.dev/badge/skills/comisai/comis/gsd-builder.svg" alt="Reviewed on agentmods" width="80" height="20"></a>What 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.1 | $0.00104 | $0.02804 |
| Opus 5.5 | $0.00042 | $0.01122 |
| Sonnet 5.5 | $0.00021 | $0.00561 |
| Haiku 4.5 | $0.00010 | $0.00280 |
Grade A, and why
gsd-builder 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 1mo 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 — 142 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Driving a GSD autonomous build from a design doc
You implement a whole milestone from a design document by driving Claude Code (your claude-code
skill + the terminal_session_* tools) through the GSD workflow in the target repo:
stage the repo + doc →
/gsd-new-milestone(define the milestone from the doc) → confirm the scope →/gsd-autonomous(build every phase, TDD) → verify → report.
You are the orchestrator: GSD itself (/gsd-*) runs inside the driven Claude Code, not in you.
Your job is to set it up, drive it through the gates, keep the long run healthy, and verify the
result honestly. This is a multi-hour, durable drive — treat it as one from the start (durable
session, per-phase engagement, honest verification).
0. Prerequisites (check first; STOP and tell the operator if missing)
- A
claudeallow-entry is configured (see the terminal-driver docs) and Claude Code is authenticated on the host. - GSD is reached purely through the driven Claude's
/gsd-*slash-commands (/gsd-new-project,/gsd-autonomous, …). Issue them directly in your build session — there is nothing to verify or check beforehand, and no shell command to run to "confirm GSD" (its tooling is internal and not onPATH). Run the entire build in that one session, in your target project only — never open a second session and never switch to a different project. If GSD genuinely isn't installed, the slash-command itself says so; only then stop and tell the operator to install it (GSD ships fromgithub.com/open-gsd/gsd-core). - You have the target repo (a git URL or an existing path) and the design document (the operator usually sends it in the chat).
- A well-structured design doc is the linchpin: it should contain a clear scope / requirements / phases section (GSD turns this into the roadmap). A vague doc → a wrong milestone built unattended. If the doc is thin, say so before starting.
1. Stage the work
Do all staging through the driven Claude session (launched in §2), not your own exec/bash tool: that tool runs in a narrow sandbox and often cannot see host paths outside the agent workspace, so cat-ing the operator's doc path with it returns a false "no such file". The driven Claude has filesystem:home and reads/writes anywhere under the home dir — use it for every file step below. Only conclude the doc is genuinely missing if the driven Claude (not your own tool) also can't find it.
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.
- 1mo ago First seen · 142 lines · 104 tokens per session scan A 97d96c68989c
gsd-builder is a skill published in the GitHub repository comisai/comis (5 stars, last pushed 1mo ago), licensed Apache-2.0. It adds 104 tokens to every session and 2,804 once invoked, about $0.0004 per session on Opus 5.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
b3os-verification
Skill "b3os-verification" from b3rys/b3rys-team-os, covering b3rys verification — prove it, and keep it proven, 1. three principles, 2. five ratchets — verification that only gets stronger, 3. layers and rubric and 4. proving the checks — mutants.
sparc-methodology
SPARC (Specification, Pseudocode, Architecture, Refinement, Completion) comprehensive development methodology with multi-agent orchestration.
test-driven-development
Use when implementing any feature or bugfix, before writing implementation code.
behavior-contract
Bug condition/postcondition formalization as testable Behavior Contracts. Defines invariants that must be preserved across fixes.
ap-implementer
Report the compatibility redirect to ap-worker; this retired role cannot perform new work.
strict-tdd
Strict RED->GREEN->REFACTOR test-driven development with enforcement. Never write production code before a failing test. Atomic commits per TDD cycle.