sebastienrousseau
UserVerified registry of agent skills for Claude Code, Codex, Aider and Antigravity: content-addressed installs, a signed index with offline verify and revocation, a static security audit with SARIF, and per-skill in-toto attestations. Stdlib-only Python, conformant to agtmls-spec L5.
Categories
Indexed Skills (30)
anti-slop-pr-and-writing
Eliminate AI slop, clichés, sycophancy, and robotic filler from PR descriptions, commit messages, code comments, and technical documentation. Load when reviewing or authoring PRs, drafting release notes, or stripping conversational apologies and binary contrasts while preserving human voice and technical facts.
brainstorming
Turn a vague request into a specification before any plan or code exists. Load when an ask is underspecified, when a feature request arrives with no acceptance criteria, or when you notice you are guessing at what someone wants. Surfaces the decisions, constraints, and deliberate non-goals by asking rather than assuming. Not for diagnosing a defect.
cross-language-port
Port a module, CLI, or function between Rust, Python, Go, C++, Swift, TypeScript, JavaScript, Ruby, and Bash - preserving logic, adopting target idioms, and proving equivalence with a differential golden-I/O harness. Use for 'port/rewrite this in <lang>'. Not micro-snippets or redesigns.
giving-code-review
Review someone else's change so the feedback is actionable and proportionate. Load when reading a pull request, diff, or patch you did not write, and when deciding whether a concern is blocking or merely a preference. Prioritises correctness over style, labels every comment with its severity, and separates what must change from what you would have done differently.
handoff
Write the note that lets someone else — or a later session — resume work in progress without re-deriving it. Load when context is running out, when pausing unfinished work, when switching who or what continues it, and when asked where things stand. Records tree state, evidence, the next concrete action, and the dead ends. Not a summary of what you did.
noyalib-architecture-contract
Load-bearing design decisions, invariants, and weak points in noyalib's parser, loader, and CST. Use before editing scanner, loader, streaming, or CST code, or answering 'why are there three loaders' and 'explain value_target_bypass and stream_eligible'. Not incidents (noyalib-failure-archaeology).
noyalib-build-and-env
Recreate a working noyalib dev environment and fix toolchain, MSRV, and Apple-Silicon traps. Use when cargo build, cargo test, make, fuzz, Miri, or coverage fails before the code is in scope.
noyalib-change-control
The noyalib rulebook: classify a change, pick the gates it must pass, non-negotiables (unsafe, signed commits, ADR triggers, MSRV, panic policy), PR flow. Use for 'am I allowed to do X' or judging release readiness. Not the runbook (noyalib-ci-and-release).
noyalib-ci-and-release
Operate noyalib CI and ship releases: workflow graph, cache-poisoning doctrine, supply-chain gates, tag-driven release flow. Use for red CI, release prep, tagging, cargo-vet or cargo-deny failures. Not which-gates-apply (noyalib-change-control).
noyalib-config-and-flags
Every noyalib configuration axis: Cargo features, ParserConfig DoS budgets and toggles, SerializerConfig, preset constructors. Use for 'what does feature X do', 'how do I limit Y', 'what is the default for max_document_length', 'does strict reject duplicate keys', or adding a new axis safely.
noyalib-coverage-campaign
Raise noyalib line, branch, and function coverage toward the 98% target. Use for 'raise coverage', llvm-cov gaps, coverage-gap triage, ratcheting fail-under thresholds, or picking the next coverage target. Fences off the known wrong turns (chasing 100%, weakening thresholds).
noyalib-debugging-playbook
Symptom-driven triage for noyalib: failing tests, a no_std build that broke despite green CI, surprising parse results, wrong spans, unexpected budget errors, Value-vs-struct disagreement, column desync. Use when answering 'why does the parse differ' fast.
noyalib-diagnostics-and-tooling
Measure instead of eyeball. Use when running or reading coverage, Miri, criterion benchmarks, or cargo-fuzz on noyalib, when interpreting what an llvm-cov regions percentage means, or when a claim needs evidence rather than assertion.
noyalib-docs-and-writing
Maintain noyalib's docs of record and house writing style. Use when authoring or editing README, CHANGELOG, RELEASE-NOTES-vX.Y.Z.md, ADRs under doc/adr/, doc/POLICIES.md, doc/ARCHITECTURE.md, doc/USER-GUIDE.md, GLOSSARY.md, MIGRATION*.md, GETTING_STARTED.md, or crate-level and item-level rustdoc. Covers house rustdoc style (# Examples, # Errors, runnable doctests), commit-message archaeology (Assisted-by trailer, symptom/root-cause bodies), SPDX/REUSE headers per file type, ADR lifecycle (when required, template, post-implementation updates), release-notes template, and the version-refs release audit. Do NOT use for release mechanics (see noyalib-ci-and-release) or competitive positioning (see noyalib-external-positioning).
noyalib-external-positioning
How noyalib is described publicly: ecosystem map, provable differentiators, claiming rules, migration guides, and the COMPARISON matrix against other Rust YAML crates. Use when writing or reviewing README claims, release notes, launch copy, 'why noyalib vs X', or 'can we claim noyalib is faster than yaml-rust2 or saphyr'. Dated claims must be re-verified before publishing.
noyalib-failure-archaeology
The chronicle of noyalib's settled battles: symptom, root cause, evidence, and what NOT to retry. Load BEFORE proposing a fix or refactor - 'has this been tried', 'why is X shaped that way', 'is there regression history here', 'look up the cache poisoning incident behind no_std', 'was the BOM column desync ever fixed'.
noyalib-research-frontier
Open research directions for noyalib and the evidence bar an idea must clear. Use for 'is there a research angle', 'what's worth a paper, RFC, or upstream PR', or setting a falsifiable spec-conformance milestone. Ambitions stay OPEN and CANDIDATE, never roadmap commitments.
noyalib-validation-and-qa
What counts as evidence in noyalib. Use before opening a PR, claiming a fix is done, or adding a test: the evidence bar, test taxonomy, doctest rules, cross-loader parity regression tests, acceptance thresholds. Not running tools (noyalib-diagnostics-and-tooling).
receiving-code-review
Respond to review feedback on your own change without reflexively complying or reflexively defending. Load when handling a change request on your own PR, when a reviewer leaves comments, disagrees with an approach, or asks for something out of scope, and when deciding whether to argue a point or accept it. Every comment gets a decision and a reply; silent edits and silent skips are the failure modes.
refactoring-safely
Change the shape of code without changing what it does. Load when you extract, rename, move, deduplicate, or restructure a module safely across its call sites, and whenever a diff mixes restructuring with new behaviour. Requires a characterisation net before the first edit and keeps structural and behavioural changes in separate commits.
systematic-debugging
Find the root cause of a defect before changing anything. Load when something crashes, hangs, returns the wrong value, fails intermittently, or broke after a change, and the cause is not yet known. Drives reproduce, localize by bisection, explain the mechanism, then fix with a failing-first regression test. Replaces guess-and-check editing.
test-driven-development
Write the failing test first, then the code that makes it pass. Load when adding behaviour, changing behaviour, or pinning a bug, and whenever a test was authored after the code it covers. Enforces red-green-refactor with an observed red phase, so a test that never failed is never mistaken for proof.
using-agtmls
Meta-router for the AgtMLS skill catalog. Read first when unsure which AgtMLS skill applies, when several look relevant, when asking 'is there a skill for porting or noyalib work', or when onboarding to how the hub's skills and shared references fit together.
verification-before-completion
The gate between doing work and claiming it is done. Load before saying finished, fixed, working, or ready, before marking a task complete, and before reporting an outcome to a human. Converts each claim into the observation that would justify it, and names the rationalizations that let unverified work ship. Not the project's own evidence bar or test taxonomy.
writing-plans
Turn a vague or multi-step request into an ordered list of small steps, each with its own done-condition and verification. Load before starting work that touches several files, has unclear scope, or spans more than one session, and when a request needs decomposing before any code is written. Produces a plan a reviewer can check against, not a to-do list.
yaml-domain-reference
YAML 1.2.2 semantics as noyalib implements them: scalar resolution, block vs flow, chomping, anchors, aliases, merge keys with DoS budgets, tags, 1.1-vs-1.2 flags, the Norway problem, and whether nan or octal 0o7 scalars resolve. Use for spec-conformance and plain-scalar questions.
agent-loop-design
Use when turning repeated agent work into a loop with trigger conditions, evidence, stopping criteria, uninstall state, validation checks, and reviewable artifacts.
ai-supply-chain-security
Use when auditing AI-agent supply chain risk, prompt or skill provenance, dependency trust, SBOM/SLSA evidence, MCP tool-poisoning, package provenance, or agent runtime guardrails before release.
pr-review-and-release
Use when preparing a pull request, judging release readiness, reviewing implementation risk with release discipline, writing release notes, checking CI, packaging artifacts, or deciding whether a repository is ready to ship.
web-research-and-source-triage
Use when gathering current web evidence, comparing sources, triaging credibility, reading GitHub repositories, checking docs, or deciding whether a claim needs live verification.
Bio shown is the top-scored skill's repo description as a fallback — real GitHub bios land in a future update.