GSD Pi is a command-line coding agent and project workflow system that plans, implements, verifies, and tracks software work through milestones, tasks, Git worktrees, and stored project notes. It is for developers who want structured, longer-running agent sessions using different model providers. The catalogue entries extend GSD Pi with skills and agents.
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 open-gsd/gsd-pi --skill observabilitygit clone --depth 1 https://github.com/open-gsd/gsd-piWrote 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/open-gsd/gsd-pi/observability)<a href="https://agentmods.dev/skills/open-gsd/gsd-pi/observability"><img src="https://agentmods.dev/badge/skills/open-gsd/gsd-pi/observability/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/open-gsd/gsd-pi/observability"><img src="https://agentmods.dev/badge/skills/open-gsd/gsd-pi/observability.svg" alt="Reviewed on agentmods" width="80" height="20"></a>- NVIDIA SkillSpector pass
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.00076 | $0.01859 |
| Opus 5.5 | $0.00030 | $0.00744 |
| Sonnet 5.5 | $0.00015 | $0.00372 |
| Haiku 4.5 | $0.00008 | $0.00186 |
Grade A, and why
observability 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 18d 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 — 179 lines — stays where its author put it; the contents beside it link to each section on GitHub.
This skill is the thinking process for adding it. Not "add logs everywhere" — add the right signals at the right decision points.
Invocation points:
- Building auto-mode-style code (loops, dispatch, guards, retries)
- Adding a background job, watcher, or scheduled task
- Writing a server or long-running process
- Refactoring a subsystem that has been hard to debug
- Addressing a production bug where "we had no visibility" surfaced
<core_principle>
LOG DECISIONS, NOT ACTIVITY. "Entering function X" is noise. "Dispatched unit slice/S02 after guard check passed because status=pending" is signal. Every log line should answer a question a future debugger will ask.
FAIL LOUDLY AND PERSIST THE REASON. Silent try/catch that returns undefined is an anti-pattern. If something fails, the failure state needs to be somewhere a fresh agent can find it — a JSONL, a status file, a health endpoint.
OBSERVABILITY IS NOT FREE. Every log allocation, every metric, every health check costs CPU and disk. Add only what you would actually read. </core_principle>
Step 1: Map the failure modes
Before instrumenting, list what can go wrong:
- What inputs could be invalid? External API responses, user-submitted data, filesystem state, env vars.
- What external dependencies could fail? Network, DB, child processes, filesystem permissions.
- What internal invariants could break? State transitions, lock acquisition, concurrency assumptions.
- What silent corruption is possible? Truncated writes, partial transactions, stale caches.
This map tells you where to instrument. Don't instrument uniformly — instrument at the decision points where these failures would manifest.
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.
- 18d ago Changed · +4 lines 60693f7fa96b
- 1mo ago First seen · 175 lines · 76 tokens per session scan A a2be68994d43
observability is a skill published in the GitHub repository open-gsd/gsd-pi (1,326 stars, last pushed yesterday), licensed MIT. It adds 76 tokens to every session and 1,859 once invoked, about $0.0003 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-30.
Other skills, from other repositories
gsd-debug
Systematic debugging with persistent state across context resets.
gsd-forensics
Post-mortem investigation for failed GSD workflows — diagnoses what went wrong.
gsd-ns-review
quality gates | code review debug audit security eval ui.
gsd-audit-fix
Autonomous audit-to-fix pipeline — find issues, classify, fix, test, commit.
gsd-debug
Systematic debugging with persistent state across context resets.
gsd-graphify
Build, query, and inspect the project knowledge graph in .planning/graphs/.