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/ymm-oss/fsl/fsl-from-codenpx skills add ymm-oss/fsl --skill fsl-from-codegit clone --depth 1 https://github.com/ymm-oss/fslWhat 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.00112 | $0.02300 |
| Opus 5 | $0.00056 | $0.01150 |
| Sonnet 5 | $0.00022 | $0.00460 |
| Haiku 4.5 | $0.00011 | $0.00230 |
Grade A, and why
fsl-from-code 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 2d 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 — 163 lines — stays where its author put it; the contents beside it link to each section on GitHub.
FSL From Code — extracting a design spec from an implementation
Use this skill when the input is existing code and the deliverable is an FSL
design-layer spec. The direction is the reverse of fsl-design: there is no
upper requirements contract to refine to, so the spec is anchored downward —
its faithfulness is proved by replaying the generated conformance harness against
the very code it was read from. That conformance harness is this skill's seam:
the downward analogue of a refinement seam, a contract checked against real code
rather than against an upper spec. If the user later wants an upper requirements
contract, building that upward refinement seam is fsl-design's job, not this
skill's.
Before writing syntax, read ../fsl/SKILL.md, then use its reference index to
load only the needed language rules, verifier workflow, and repair detail. Inside this
repository, study the canonical triple in reverse: examples/e2e/impl/expense.py
(plain code) → examples/e2e/3_design.fsl (the spec) → examples/e2e/impl/test_conformance.py
(the generated Adapter + random-walk Monitor). That triple is exactly the artifact
this skill produces, read backwards.
Boundary
Produce only:
- A design-layer kernel
specwhose state/actions/guards/effects are read from the code, each tagged with a// SRC: file:linewitness - Invariants and forbidden flows that the human confirmed, tagged with
// ASSUME-n:ledger comments - The
fslc testgenconformance harness, with the Adapter wired to the real code
Do not:
- Invent invariants, guards, states, or transition targets to make the spec look complete or to make it verify. A missing rule is a question, not a default.
- Produce a requirements or business layer, or refine upward.
- Claim implementation conformance unless the harness actually ran green against the
code (a spec that only
verifys is internally consistent, not faithful to code).
Why this is not a transpiler — three zones
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.
- 2d ago First seen · 163 lines · 112 tokens per session scan A 86372d597fd2
fsl-from-code is a skill published in the GitHub repository ymm-oss/fsl (21 stars, last pushed 5d ago), licensed Apache-2.0. It adds 112 tokens to every session and 2,300 once invoked, about $0.0006 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-30.
Other skills, from other repositories
propagate
Generate tests from Allium specifications. Use when the user wants to propagate tests, generate test files from a spec, write tests for a specification, create property-based tests, produce state machine tests, check test coverage against spec obligations, or understand what tests a specification requires.
allium
Give your AI agents something more useful than a prompt. Velocity through clarity.
elicit
Run a structured discovery session to build an Allium specification through conversation. Use when the user wants to create a new spec from scratch, elicit or gather requirements, capture domain behaviour, specify a feature or system, define what a system should do, or is describing functionality and needs help…
tend
Tend the Allium garden. Use when the user wants to write, edit, update, add to, improve, clarify, refine, restructure, fix or migrate Allium specs. Covers adding entities, rules, triggers, surfaces and contracts, fixing syntax or validation errors, renaming or refactoring within specs, migrating specs to a new…
weed
Weed the Allium garden. Find where Allium specifications and implementation code have diverged, and help resolve the divergences. Use when the user wants to check spec-code alignment, compare specs against implementation, audit for spec drift or violations, sync specs with code or code with specs, or verify whether…
witness
Independently witness that an Allium loop's convergence claim is true and was reached honestly. Use when the user wants to verify a loop's self-report, confirm tests really pass and no generated test was weakened, produce a convergence certificate or witness record, gate CI on a trustworthy signal, or check that an…