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/jubscodes/get-shit-pretty/gspdev-eval-changesnpx 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.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 | $0.00086 | $0.03180 |
| Opus 5 | $0.00043 | $0.01590 |
| Sonnet 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 4d 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.
- 4d 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 (54 stars, last pushed 2mo ago), licensed MIT. It adds 86 tokens to every session and 3,180 once invoked, about $0.0004 per session on Opus 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
figma-generate-component-doc
Generate complete Markdown documentation for a Figma component — anatomy/layer tree, design tokens (colors, spacing, typography), states/variants matrix, accessibility notes, content guidelines, and optional code-parity + YAML frontmatter. Use when the user wants a docs page or handoff spec for a component or…
figma-version-history
List a Figma file's version history, snapshot the file at any past version, and diff two versions (added/removed/renamed pages plus deep per-component changes). Use when the user wants to inspect Figma history — triggers: 'list Figma versions', 'what versions does this file have', 'show version history', 'snapshot…
figma-comments
Read, post, reply to, and delete comments on a Figma file via the REST API — including pinning a comment to a specific node and threading replies. Use when the user wants to work with Figma comments programmatically — triggers: 'get Figma comments', 'read comments on this file', 'post a comment in Figma', 'leave a…
figma-scan-code-accessibility
Scan generated/authored HTML for accessibility violations with axe-core (Deque) running over JSDOM — structural and semantic rules: ARIA attributes and roles, accessible names, alt text, form labels, heading order, landmarks, semantic HTML, tabindex, duplicate IDs, lang attribute, and 50 more. Use on the CODE side of…
figma-import-tokens
Push design tokens from code INTO Figma as variables — DTCG / tokens.json / a token object → Figma variable collections, modes, and values. Use when the user wants to sync tokens code→Figma: triggers 'import tokens into Figma', 'create Figma variables from my tokens.json / DTCG / Tailwind config', 'sync design tokens…
figma-analyze-component-set
Analyze a Figma COMPONENTSET as a state machine for code generation — extract variant axes (state/size/etc.), map state variants to CSS pseudo-classes (hover→:hover, focus→:focus-visible, disabled→:disabled, error→[aria-invalid]), and compute per-variant visual diffs (only what changes per state). Use when generating…