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 debug-like-expertgit 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/debug-like-expert)<a href="https://agentmods.dev/skills/open-gsd/gsd-pi/debug-like-expert"><img src="https://agentmods.dev/badge/skills/open-gsd/gsd-pi/debug-like-expert.svg" alt="Measured on agentmods" 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.00044 | $0.01764 |
| Opus 5 | $0.00022 | $0.00882 |
| Sonnet 5 | $0.00009 | $0.00353 |
| Haiku 4.5 | $0.00004 | $0.00176 |
Grade A, and why
debug-like-expert 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 7d 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.
This is a copy
88% identical to debug-like-expert — 198 lines differ, which has more behind it and is treated as the original. This page carries a canonical link to it rather than competing with it.
How it starts
The opening of the file, as written. The whole thing — 232 lines — stays where its author put it; the contents beside it link to each section on GitHub.
The skill emphasizes treating code you wrote with MORE skepticism than unfamiliar code, as cognitive biases about "how it should work" can blind you to actual implementation errors. Use scientific method to systematically identify root causes rather than applying quick fixes.
Important: If you wrote or modified any of the code being debugged, you have cognitive biases about how it works. Your mental model of "how it should work" may be wrong. Treat code you wrote with MORE skepticism than unfamiliar code - you're blind to your own assumptions.
<core_principle> VERIFY, DON'T ASSUME. Every hypothesis must be tested. Every "fix" must be validated. No solutions without evidence.
ESPECIALLY: Code you designed or implemented is guilty until proven innocent. Your intent doesn't matter - only the code's actual behavior matters. Question your own design decisions as rigorously as you'd question anyone else's. </core_principle>
<analysis_only_rule> THIS SKILL IS READ-ONLY. DO NOT MODIFY CODE.
The entire purpose is deep analysis and diagnosis. Making changes during investigation:
- Pollutes the evidence
- Introduces new variables
- Makes root cause harder to isolate
You are a diagnostician, not a surgeon. Present findings, then let the user decide. </analysis_only_rule>
<quick_start>
<evidence_gathering>
Before proposing any solution:
A. Document Current State
- What is the EXACT error message or unexpected behavior?
- What are the EXACT steps to reproduce?
- What is the ACTUAL output vs EXPECTED output?
- When did this start working incorrectly (if known)?
B. Map the System
- Trace the execution path from entry point to failure point
- Identify all components involved
- Read relevant source files completely, not just scanning
- Note dependencies, imports, configurations affecting this area
C. Gather External Knowledge (when needed)
- Use MCP servers for API documentation, library details, or domain knowledge
- Use web search for error messages, framework-specific behaviors, or recent changes
- Check official docs for intended behavior vs what you observe
- Look for known issues, breaking changes, or version-specific quirks
See references/when-to-research.md for detailed guidance on research strategy.
</evidence_gathering>
<root_cause_analysis>
A. Form Hypotheses
Based on evidence, list possible causes:
- [Hypothesis 1] - because [specific evidence]
- [Hypothesis 2] - because [specific evidence]
- [Hypothesis 3] - because [specific evidence]
B. Test Each Hypothesis
For each hypothesis:
- What would prove this true?
- What would prove this false?
- Design a minimal test
- Execute and document results
See references/hypothesis-testing.md for scientific method application.
C. Eliminate or Confirm
Don't move forward until you can answer:
- Which hypothesis is supported by evidence?
- What evidence contradicts other hypotheses?
- What additional information is needed?
</root_cause_analysis>
<solution_proposal>
Only after confirming root cause:
A. Design Recommended Fix
- What is the MINIMAL change that would address the root cause?
- What are potential side effects?
- What could this break?
- What tests should run after implementation?
B. Document, Don't Implement
- Describe the fix with enough detail for implementation
- Include specific file paths, line numbers, and code snippets
- Explain WHY this addresses the root cause
- Note any prerequisites or dependencies
What ships with it
5 files beside SKILL.md in the same directory: the scripts, references and assets a skill reads on demand. Not counted in the per-session cost; read them before you install if any of them is executable.
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.
- 7d ago First seen · 232 lines · 44 tokens per session scan A d6fbe0b26e15
debug-like-expert is a skill published in the GitHub repository open-gsd/gsd-pi (1,201 stars, last pushed today), licensed MIT. It adds 44 tokens to every session and 1,764 once invoked, about $0.0002 per session on Opus 5. A static security scan graded it A with 0 findings. It is 88% identical to debug-like-expert, differing in 198 lines, and is treated as a copy.
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-audit-fix
Autonomous audit-to-fix pipeline — find issues, classify, fix, test, commit.
gsd-ns-review
Route to the appropriate quality / review skill based on the user's intent. gsd-code-review-fix was absorbed by gsd-code-review --fix in #2790.
gsd-debug
Systematic debugging with persistent state across context resets.
gsd-graphify
Build, query, and inspect the project knowledge graph in .planning/graphs/.