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/ymd38/dev-skills/yds-software-evaluationnpx 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.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.00102 | $0.03432 |
| Opus 5 | $0.00051 | $0.01716 |
| Sonnet 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 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.
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.
- 4d 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 (3 stars, last pushed 7d ago), licensed MIT. It adds 102 tokens to every session and 3,432 once invoked, about $0.0005 per session on Opus 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
weather-fetcher
Instructions for fetching current weather temperature data for Dubai, UAE from Open-Meteo API.
claude-md-review
Audit a CLAUDE.md file for the patterns that actually degrade Claude Code's output — vagueness, unnamed files, stale facts, and bloat. Use when asked to review, audit, improve, shrink, or fix a CLAUDE.md, and when a project's results feel inconsistent or Claude keeps rediscovering the same context.
best-practices
Searchable knowledge base of 152+ programming best practices across 30+ languages and frameworks. BM25-powered search over curated resources from industry leaders (Google, Airbnb, Uber, Mozilla, Shopify, OWASP).
JavaScript Tooling
Development tools, linting, and testing for JavaScript projects.
common-product-requirements
Standardize PRD discovery and drafting for product scope, user outcomes, requirement IDs, and acceptance criteria. Use when creating PRD, product requirements, feature specification, or acceptance criteria plan.
common-security-standards
Enforce universal security protocols for safe, resilient software. Use when implementing authentication, encryption, authorization, input validation, secret management, or any security-sensitive feature across any language or framework.