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 ymm-oss/fsl --skill fsl-design-reviewgit clone --depth 1 https://github.com/ymm-oss/fslWrote 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/ymm-oss/fsl/fsl-design-review)<a href="https://agentmods.dev/skills/ymm-oss/fsl/fsl-design-review"><img src="https://agentmods.dev/badge/skills/ymm-oss/fsl/fsl-design-review/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/ymm-oss/fsl/fsl-design-review"><img src="https://agentmods.dev/badge/skills/ymm-oss/fsl/fsl-design-review.svg" alt="Reviewed on agentmods" width="80" height="20"></a>- NVIDIA SkillSpector pass
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.00155 | $0.03489 |
| Opus 5.5 | $0.00062 | $0.01396 |
| Sonnet 5.5 | $0.00031 | $0.00698 |
| Haiku 4.5 | $0.00015 | $0.00349 |
Grade A, and why
fsl-design-review 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 13d 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 — 200 lines — stays where its author put it; the contents beside it link to each section on GitHub.
FSL Design Exploration — A Procedure for Translating Design Decisions into Contract-Conformance Checks
The core is the following 5-step procedure. Design principles (SOLID etc.) are not the starting point of the procedure; they appear as judgment lenses at each step. This skill's job is to translate "is this design good?" into "does this design conform to the frozen contract?" and have fslc answer with counterexamples.
Prerequisite: FSL syntax, verification commands, and repair protocol follow
the fsl skill and its topic-specific references. This skill supplies only the
procedure and the interpretation of results.
If the user needs a new design-layer .fsl written before review, use
fsl-design for authoring and return here for review/proposal judgment.
Procedure
Step 1 — Translate the design question into the language of contracts
Design questions almost always fall into one of four shapes: comparing new design proposals / adding a variant or extension / reviewing a change to an existing design / judging substitutability. In every shape, what you identify is the same:
- The open part: what may change (variants, extension points, the changed site)
- The closed part = the contract: what must not break (invariants, guards, externally observable state)
Lens — OCP: decide the "range you close" here. DIP: what abstraction should the design proposals all depend on in common. Align with the user on the candidate contracts as a bullet list before proceeding (do not create a deliverable file; chat is fine).
Do not infer the open/closed boundary, extension points, substitutability contract, variant roster, or action correspondence from general design taste. If the source material does not say what must remain stable or how a detail action maps to an abstract action, ask. A refinement proof is only meaningful for the contract the human agreed to freeze.
Step 2 — Freeze the contract as an abstract spec
After the contract boundary is confirmed, write the contract as an abstract spec
and push it through the fsl skill's standard workflow up to check → verify →
--engine induction (proved recommended). If the contract itself is contradictory,
the design exploration cannot even begin — a violated here is a defect in the
contract, not in a design proposal.
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.
- 13d ago Changed · -3 lines 6d75c30d3250
- 18d ago Changed · +2 lines 02d88b56806d
- 27d ago Changed · +25 lines 97f64e85525d
- 2mo ago First seen · 176 lines · 155 tokens per session scan A 0fb7624bfa61
fsl-design-review is a skill published in the GitHub repository ymm-oss/fsl (35 stars, last pushed today), licensed Apache-2.0. It adds 155 tokens to every session and 3,489 once invoked, about $0.0006 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-30.
Other skills, from other repositories
python-style
Validate Python code against style and architectural conventions.
python-engineering-guidelines
General Python engineering standards for writing, reviewing, and refactoring maintainable code. Use when Codex works on Python code, especially in medium/large projects, runtime adapters, APIs, SDK integrations, async services, stateful systems, or refactors where readability, explicit typing, module boundaries, side…
project-onboarding
Standard procedure for onboarding new software projects: Feature analysis, code quality review, onboarding checklist, and task creation.
docs-analysis
Document requirements analysis: Analyzes concept and requirements documents in the docs/ folder, checks requirements against current code, and creates a consolidated difference report.
impact
Use when asked what a change could break or affect, "is this safe to commit/push/merge?", "what does this break?", or before committing a multi-file change — the callers outside the diff, the tests guarding them, and the contracts the change crosses.
diffctx
Use when reviewing or explaining a commit, PR, branch or uncommitted diff — "review my last commit", "review before merge", "review my changes", "what else does this change affect" — the callers and tests the change reaches outside its diff, then the surrounding code.