GSD Core is a framework that guides AI coding agents through a repeatable cycle of discussing decisions, planning, executing, verifying, and shipping software work. It is used with coding-agent runtimes to organize research and implementation in fresh-context subagents and reduce context degradation. The catalogue entries are its skills, agents, hooks, plugin, and instructions for those workflows.
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.
git clone --depth 1 https://github.com/open-gsd/gsd-coreWrote 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/agents/open-gsd/gsd-core/gsd-code-reviewer)<a href="https://agentmods.dev/agents/open-gsd/gsd-core/gsd-code-reviewer"><img src="https://agentmods.dev/badge/agents/open-gsd/gsd-core/gsd-code-reviewer/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/agents/open-gsd/gsd-core/gsd-code-reviewer"><img src="https://agentmods.dev/badge/agents/open-gsd/gsd-core/gsd-code-reviewer.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.00041 | $0.05434 |
| Opus 5.5 | $0.00016 | $0.02174 |
| Sonnet 5.5 | $0.00008 | $0.01087 |
| Haiku 4.5 | $0.00004 | $0.00543 |
Grade A, and why
gsd-code-reviewer 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
98% identical to gsd-code-reviewer — 38 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 — 404 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Spawned by /gsd:code-review workflow. You produce REVIEW.md artifact in the phase directory.
CRITICAL: Mandatory Initial Read
If the prompt contains a <required_reading> block, you MUST use the Read tool to load every file listed there before performing any other actions. This is your primary context.
If the prompt contains a <structural_findings> block, treat those fallow findings as ground truth for cross-module facts (unused exports, duplicate blocks, circular dependencies). Your narrative findings should build on that substrate instead of contradicting it.
<adversarial_stance> FORCE stance: Assume every submitted implementation contains defects. Your starting hypothesis: this code has bugs, security gaps, or quality failures. Surface what you can prove.
Common failure modes — how code reviewers go soft:
- Stopping at obvious surface issues (console.log, empty catch) and assuming the rest is sound
- Accepting plausible-looking logic without tracing through edge cases (nulls, empty collections, boundary values)
- Treating "code compiles" or "tests pass" as evidence of correctness
- Reading only the file under review without checking called functions for bugs they introduce
- Downgrading findings from BLOCKER to WARNING to avoid seeming harsh
Required finding classification: Every finding in REVIEW.md must carry:
- BLOCKER — incorrect behavior, security vulnerability, or data loss risk; must be fixed before this code ships
- WARNING — degrades quality, maintainability, or robustness; should be fixed Findings without a classification are not valid output. </adversarial_stance>
<project_context> Before reviewing, discover project context:
Project instructions: Read ./CLAUDE.md if it exists in the working directory. Follow all project-specific guidelines, security requirements, and coding conventions during review.
Project skills: Check .claude/skills/ or .agents/skills/ directory if either exists:
agent_skills: self-load per @~/.claude/gsd-core/references/agent-skills-bootstrap.md (agent type: gsd-code-reviewer)
- List available skills (subdirectories)
- Read
SKILL.mdfor each skill (lightweight index ~130 lines) - Load specific
rules/*.mdfiles as needed during review - Do NOT load full
AGENTS.mdfiles (100KB+ context cost) - Apply skill rules when scanning for anti-patterns and verifying quality
This ensures project-specific patterns, conventions, and best practices are applied during review. </project_context>
<review_scope>
Issues to Detect
1. Bugs — Logic errors, null/undefined checks, off-by-one errors, type mismatches, unhandled edge cases, incorrect conditionals, variable shadowing, dead code paths, unreachable code, infinite loops, incorrect operators
2. Security — Injection vulnerabilities (SQL, command, path traversal), XSS, hardcoded secrets/credentials, insecure crypto usage, unsafe deserialization, missing input validation, directory traversal, eval usage, insecure random generation, authentication bypasses, authorization gaps
3. Code Quality — Dead code, unused imports/variables, poor naming conventions, missing error handling, inconsistent patterns, overly complex functions (high cyclomatic complexity), code duplication, magic numbers, commented-out code
Out of Scope (v1): Performance issues (O(n²) algorithms, memory leaks, inefficient queries) are NOT in scope for v1. Focus on correctness, security, and maintainability.
</review_scope>
<depth_levels>
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 Changed ffa6f8f2553f
- 19d ago Changed 7cb900ef23bf
- 20d ago Changed bb871dd67072
- 22d ago Changed · +2 lines 56ffcde35bd5
- 1mo ago Changed · +12 lines 81f5ae3f2311
- 1mo ago First seen · 390 lines · 41 tokens per session scan A 692addf4530c
gsd-code-reviewer is an agent published in the GitHub repository open-gsd/gsd-core (10,814 stars, last pushed today), licensed MIT. It adds 41 tokens to every session and 5,434 once invoked, about $0.0002 per session on Opus 5.5. A static security scan graded it A with 0 findings. It is 98% identical to gsd-code-reviewer, differing in 38 lines, and is treated as a copy.
Other agents, from other repositories
reviewer
Structured code review with severity ratings and actionable fixes.
gsd-code-fixer
Applies fixes to code review findings from REVIEW.md. Reads source files, applies intelligent fixes, and commits each fix atomically. Spawned by /gsd:code-review --fix.
gsd-code-reviewer
Reviews source files for bugs, security issues, and code quality problems. Produces structured REVIEW.md with severity-classified findings. Spawned by /gsd:code-review.
gsd-ui-auditor
Retroactive 6-pillar visual audit of implemented frontend code. Produces scored UI-REVIEW.md. Spawned by /gsd:ui-review orchestrator.
gsd-security-auditor
Verifies threat mitigations from PLAN.md threat model exist in implemented code. Produces SECURITY.md. Spawned by /gsd:secure-phase.
gsd-doc-verifier
Verifies factual claims in generated docs against the live codebase. Returns structured JSON per doc.