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 jubscodes/get-shit-pretty --skill gspdev-eval-changesgit clone --depth 1 https://github.com/jubscodes/get-shit-prettyWrote 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/jubscodes/get-shit-pretty/gspdev-eval-changes)<a href="https://agentmods.dev/skills/jubscodes/get-shit-pretty/gspdev-eval-changes"><img src="https://agentmods.dev/badge/skills/jubscodes/get-shit-pretty/gspdev-eval-changes/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/jubscodes/get-shit-pretty/gspdev-eval-changes"><img src="https://agentmods.dev/badge/skills/jubscodes/get-shit-pretty/gspdev-eval-changes.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.00086 | $0.03180 |
| Opus 5.5 | $0.00034 | $0.01272 |
| Sonnet 5.5 | $0.00017 | $0.00636 |
| Haiku 4.5 | $0.00009 | $0.00318 |
Grade C, and why
gspdev-eval-changes scanned grade C with 1 finding 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.
Recursive force deletehighDestructive command
rm -rf with a variable or a broad path is one typo away from removing the wrong tree.
rm -rf "$TMPDIR" How it starts
The opening of the file, as written. The whole thing — 283 lines — stays where its author put it; the contents beside it link to each section on GitHub.
- Change intent achieved? Did the PR/commit land what it set out to do?
- Skill intent coherent? Does the skill body deliver on its description? (Catches drift between SKILL.md frontmatter
description:and the body — a separate failure mode from the change-intent question.) - Substance preserved or improved? For modifications: did the change avoid sacrificing what the agent needs? For additions: does the new content fit the skill's existing contracts (constraints, output specs, quality bars)?
Examples of changes this covers:
- Adding a new step to a methodology
- Adding a new sibling reference file
- Modifying a rule, constraint, or rubric
- Changing the agent's role or execution mode
- Trimming verbose prose
- Extracting content to siblings
- Renaming inputs/outputs
- Adding a new SKILL.md (skill intent check from scratch)
A change that achieves its goal (Dim 1 = PASS) can still drift the skill away from its stated purpose (Dim 2 = FAIL) if it adds behavior the description doesn't reflect, or removes a step the description promised. A coherent intent + description (Dims 1-2 = PASS) can still break an output spec (Dim 6 = FAIL). All three gates matter.
Spawns one general-purpose evaluator agent per modified file in parallel. Each evaluator compares BEFORE (if any) and AFTER against the parent SKILL.md using a fixed 8-dimension rubric, returns PASS / CONCERNS / FAIL with quoted findings and surgical recommendations.
Different from siblings:
/gspdev-audit— static checks across the whole repo (contracts, installer, version sync). Read-only, no eval./gspdev-housekeeping— drift detection (count mismatches, stale references). Mechanical./gspdev-prompt-audit— semantic analysis of all skill prompts (dead weight, contradictions). Whole-repo, slow.
This skill is targeted: it evaluates the quality of a specific change before it merges.
Input: Optional commit range (default: main..HEAD + uncommitted)
Output: Aggregated verdict table + per-file findings; optional inline restoration of CONCERNS-flagged content
Agent: general-purpose (one per evaluated file, dispatched in parallel)
Step 0: Resolve scope
Determine which files to evaluate:
- If
$ARGUMENTScontains a commit range (e.g.,main..HEAD,HEAD~3..HEAD,feature-branch..main), use it directly - Otherwise default to
main..HEADplus uncommitted working-tree changes
RANGE="${ARGUMENTS:-main..HEAD}"
# Committed changes in range
COMMITTED=$(git diff --name-only "$RANGE" 2>/dev/null | grep -E '^(gsp|dev)/(skills|agents)/.*\.md$' || true)
# Uncommitted working-tree changes
UNCOMMITTED=$(git diff --name-only HEAD 2>/dev/null | grep -E '^(gsp|dev)/(skills|agents)/.*\.md$' || true)
# Combine, dedupe
FILES=$(printf "%s\n%s\n" "$COMMITTED" "$UNCOMMITTED" | sort -u | grep -v '^$')
What ships with it
1 file 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.
- 1mo ago First seen · 283 lines · 86 tokens per session scan C 7046b91d61df
gspdev-eval-changes is a skill published in the GitHub repository jubscodes/get-shit-pretty (55 stars, last pushed 4mo ago), licensed MIT. It adds 86 tokens to every session and 3,180 once invoked, about $0.0003 per session on Opus 5.5. A static security scan graded it C with 1 finding (recursive force delete). No closer match exists in the catalogue, so it is treated as the original; first seen 2026-08-30.
Other skills, from other repositories
crit-cli
Use when an agent needs to author or reply to crit inline comments programmatically (including multi-agent workflows commenting on shared code/plans/docs/proposals), publish or unpublish a crit review with crit share, sync a crit review to or from a GitHub PR or GitLab MR, or read/interpret a crit review JSON file.…
crit-story
Author a crit story and continue the interactive review loop only when the user explicitly invokes crit-story or directly asks you to generate a crit story. Do not infer this skill from generic review, PR, or diff-review requests.
crit
Review code changes, a plan, a live page (running dev server), or a local HTML file with Crit inline comments and structured human feedback. Use only when the user explicitly invokes /crit or directly asks to use Crit; a generic review request does not count.
patch-edit
Apply one rewrite-plan step at a time as small reviewable file edits, never rewriting whole files when a localised change suffices.
code-review
Systematic code review checklist.
microservices-architecture
Guides service boundary analysis, communication pattern selection, data consistency design, API contract strategy, and resilience checklist for microservices systems. Complements the microservices fragment. Invoked when the user asks to design a microservices system, split a monolith, or review service boundaries.