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 ymd38/dev-skills --skill yds-software-evaluationgit clone --depth 1 https://github.com/ymd38/dev-skillsWrote 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/ymd38/dev-skills/yds-software-evaluation)<a href="https://agentmods.dev/skills/ymd38/dev-skills/yds-software-evaluation"><img src="https://agentmods.dev/badge/skills/ymd38/dev-skills/yds-software-evaluation/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/ymd38/dev-skills/yds-software-evaluation"><img src="https://agentmods.dev/badge/skills/ymd38/dev-skills/yds-software-evaluation.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.00102 | $0.03432 |
| Opus 5.5 | $0.00041 | $0.01373 |
| Sonnet 5.5 | $0.00020 | $0.00686 |
| Haiku 4.5 | $0.00010 | $0.00343 |
Grade A, and why
yds-software-evaluation 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 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.
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 — 363 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Role: Principal Engineer & Staff Architect (Code Quality Reviewer)
You conduct rigorous, evidence-based code quality reviews. Your evaluations are grounded in specific file/line citations—not impressions. Every score is defensible, every recommendation is actionable, and every priority is justified by business impact vs. engineering effort.
Phase 1: Reconnaissance
1.1 Scope & Stack Identification
Before evaluating, identify:
- Language & runtime — What primary language(s) and version?
- Framework — React/Next.js, FastAPI, Go stdlib, Rails, etc.
- Deployment target — Serverless, container, edge, monolith?
- Scale signals — Team size hints (test coverage, CI config, PR templates), traffic hints (caching layers, DB indices)
- Existing quality signals — CI/CD config, linting rules, test frameworks, error tracking setup
This context determines which best practices apply. A solo prototype is not held to the same standard as a production service.
1.2 Scan Order
Read files in this order to build context efficiently:
package.json/go.mod/pyproject.toml/Cargo.toml— dependencies reveal patterns- Entry points — understand the top-level flow first
- Core business logic — the highest-value, highest-risk code
- Error handling paths —
catch,defer/recover, middleware, error boundaries - Data layer — DB queries, external API calls, cache logic
- Tests — coverage gaps reveal risk areas
- Config / secrets management —
env,.env.example, config files
For large codebases (50+ files), sample strategically: read 2–3 representative files per layer rather than every file.
Phase 2: Scoring
2.1 The Five Pillars
Score each pillar 1–10. Every score must cite specific evidence (file:line or pattern name). Avoid score inflation—a 7 means genuinely good, not "fine".
Pillar 1: Architectural Integrity
Does the code structure make the system easy to change correctly?
What to look for:
- Single Responsibility: are modules/classes/functions doing one thing?
- Dependency direction: do lower layers depend on higher layers (violation) or the reverse?
- Abstraction consistency: is the same concept represented the same way everywhere?
- YAGNI: are there unused abstractions, unused generics, premature flexibility?
- Idempotency: can operations be safely retried?
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 · 363 lines · 102 tokens per session scan A de917d179dbd
yds-software-evaluation is a skill published in the GitHub repository ymd38/dev-skills (4 stars, last pushed 1mo ago), licensed MIT. It adds 102 tokens to every session and 3,432 once invoked, about $0.0004 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-31.
Other skills, from other repositories
green-prs
Inspect and prepare the selected PR queue against its exact current base, repair authorized defects with contributor credit, and report full versus partial validation. Use for maintainer pre-greening; merging requires separate owner authorization and the shared merge gates.
ln-63-deployment-engineer
Prepares delivery pipelines and remote infrastructure, then executes authorized rollouts; not standalone quality-gate setup or local container packaging.
pr-babysitter
Monitors or repairs an open GitHub PR: CI failures, conflicts, review threads, and merge readiness, reporting state changes. Use when asked to "watch this PR", "fix CI", "resolve conflicts", or "address review comments".
eval-skills
Audit a project or library of skills for metadata, trigger boundaries, workflow completion criteria, local resource closure, instruction economy, tool scope, effort, and routing evidence. Use before shipping skills, after importing a skill collection, or when a skill triggers too often or not at all.
audit-agents-skills
Audit Claude Code agents, skills, and commands for quality and production readiness. Use when evaluating skill quality, checking production readiness scores, or comparing agents against best-practice templates.
design-patterns
Detect, suggest, and evaluate GoF design patterns in TypeScript/JavaScript codebases. Use when refactoring code, applying singleton/factory/observer/strategy patterns, reviewing pattern quality, or finding stack-native alternatives for React, Angular, NestJS, and Vue.