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/comisai/comis/gsd-buildernpx skills add comisai/comis --skill gsd-buildergit clone --depth 1 https://github.com/comisai/comisWhat 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.00104 | $0.02804 |
| Opus 5 | $0.00052 | $0.01402 |
| Sonnet 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 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 — 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.
- 2d 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 2d ago), licensed Apache-2.0. It adds 104 tokens to every session and 2,804 once invoked, about $0.0005 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
org-sync
Use when the CEO wants an organization-wide sync across PuPu's agent teams — running each org's internal sync, then a cross-org sync where departments challenge each other, converging into one decision list. Triggers: "跑一次 org sync", "全局同步", "组织盘点", "/org-sync", "各部门现在什么情况", "有什么要我拍板的".
release-feature-audit
Use when a new PuPu feature finishes implementation and needs its consistency audit before its ticket is marked done — "audit #123", "审计这个功能", "这个 feature 过一遍检查" — or when release-close-sprint roll-call finds a new feature that was never audited. Also covers standalone i18n checks ("漏翻了吗", "检查 i18n"), which used to be…
gitnexus-impact-analysis
Use when the user wants to know what will break if they change something, or needs safety analysis before editing code. Examples: "Is it safe to change X?", "What depends on this?", "What will break?".
growth-analyst
Use when analyzing PuPu's open-source growth or health for the founder — GitHub traffic, downloads/installs, releases, community, or contributor activity — or when producing a growth report or weekly COO report. Repo is haoxiang-xu/PuPu. Triggers: "how is PuPu growing?", "are people installing PuPu?", "which release…
test-api
Use when running QA / regression tests against PuPu, when verifying a code change actually works in the running app, or when reading PuPu UI/state without screenshotting manually. Triggers on tasks like "test that PuPu still creates chats correctly", "verify the new model selector works end-to-end", "send a message…
org-court
Use when any org-change proposal needs adjudication - adding/removing/redesigning agents or teams, changing org rules, or evaluating org granularity. Runs PuPu's HR court: a proposal is heard by four dimension assessors (comm efficiency / context cleanliness / signal ratio / routing cost), the judge verifies evidence…