agtmls

Autonomously port a module, script, CLI, or function from one language to another across the polyglot fleet — Rust, Python, Go, C++, Swift, TypeScript, JavaScript, Ruby, and Bash/Shell — preserving business logic exactly while adopting the target language's idioms, error model, concurrency shape, and toolchain, AND proving behavioural equivalence with a differential golden-I/O harness rather than eyeballing. Load when the user says "port this to <lang>", "translate to <lang>", "rewrite in <lang>", "convert this to <lang>", "reimplement <X> in <lang>", "give me the <lang> equivalent", or asks for a Rust↔Python↔Go↔Swift↔TS/JS↔Ruby↔C++ ↔Bash equivalent of existing code. Not for micro-snippets (do those inline) or behaviour-changing redesigns (that's a rewrite, clarify intent first).

Meta-router for the AgtMLS skill catalog — read this first when you are unsure which AgtMLS skill (if any) to load for a task, when several skills look like they might apply, or when onboarding to how this hub's skills and shared references fit together. Points at the cross-language-port skill for porting/translating code between languages, at project bundles (e.g. the noyalib/ family) for project-specific work, and at references/ for the shared Definition of Done. Use when the question is "which skill do I use for X" or "how do AgtMLS skills work".

Use when the user needs this reusable workflow. Replace this with trigger-rich wording that says when to load the skill, what task it handles, and when not to use it.

Use when preparing a pull request, reviewing implementation risk, writing release notes, checking CI, packaging artifacts, or deciding whether a repository is ready to ship.

Use when turning repeated agent work into a loop with trigger conditions, evidence, stopping criteria, uninstall state, validation checks, and reviewable artifacts.

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.

Use when gathering current web evidence, comparing sources, triaging credibility, reading GitHub repositories, checking docs, or deciding whether a claim needs live verification.

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,

Load-bearing design decisions, invariants, and residual weak points for noyalib's parser/loader/CST. Use before modifying scanner/loader/streaming/CST code, adding a config axis or budget, wiring a new deserialise entry point, answering "can I change X here", "why are there three loaders", "which path enforces this limit", "explain the three-loader architecture", "what is a NoSpanLoader", "what invariants must I preserve when editing loader.rs", "what does loader-parity require", or reviewing a PR that touches de.rs / parser/loader.rs / cst/document.rs. Not a runbook for CI/release — see noyalib-ci-and-release. Not incident detail — see noyalib-failure-archaeology.

Recreate a working noyalib development environment from scratch on a fresh machine, resolve toolchain / MSRV / "command not found" errors, and avoid the known Apple-Silicon, no_std, and workspace-boundary traps. Load when a new engineer or AI session is bootstrapping, when `cargo build`, `cargo test`, `make`, cargo-fuzz, Miri, or coverage runs fail before the code is even in scope, or when the answer is "install X" / "run from repo root" / "use `--target aarch64-apple-darwin`".

Load this when working on the noyalib repo and you need to classify a change, decide which gates it must pass, prepare a PR, answer "am I allowed to do X?", decide whether you may bump the MSRV (a breaking event needing an ADR), or judge release readiness. Covers change taxonomy (bug fix / feature / security / restructure / release), the written non-negotiables (forbid(unsafe_code), signed Conventional Commits, ADR triggers, panic policy, MSRV, CI-always-green), the unwritten project laws confirmed with the maintainer, the v0.0.9→v0.0.11 CI cache-poisoning incident behind the isolated CARGO_TARGET_DIR rule, and the PR review flow. Siblings: noyalib-ci-and-release (HOW to run gates locally) and noyalib-validation-and-qa (WHAT evidence a change needs) — this is the rulebook, not the runbook. Date-stamped 2026-07-08; release branch feat/v0.0.14.

Executable, decision-gated playbook for the noyalib coverage-hardening campaign — driving line/branch/function coverage from the live workspace gate (96 fn / 94 lines / 93 regions per .github/workflows/ci.yml and shared-coverage.yml defaults; doc/TESTING.md still says 95/93/92 and is stale drift) toward the 98 % target declared in PLAN.md. Load this when the ask is "raise coverage", "close the llvm-cov gaps", "what should I work on next", "make coverage-gap says X is under threshold", "ratchet the fail-under numbers", "we're at 96, get us to 98", or any variant of coverage triage on this repo. Coordinates the scripts/coverage-gap-report.sh punchlist, the tests/coverage_*.rs house-pattern, and the shared-coverage.yml gate. Owns the end-to-end workflow: baseline → target selection → gap analysis → test authoring → verification → promotion. Explicitly fences off wrong turns (chasing 100 %, weakening thresholds, assert-free coverage tests, testing invariant_violated defensive paths).

Symptom-driven triage for noyalib (pure-Rust YAML 1.2). Load when a test fails, a parse result surprises you, spans point at the wrong bytes, budget errors fire unexpectedly, `from_str::<Value>` and `from_str::<MyStruct>` disagree, `no_std` breaks despite green CI (symptom triage here; the cache-poisoning CI doctrine that PREVENTS it lives in noyalib-ci-and-release), column desync / spurious indent errors show up, or you need to answer "why does the parse differ?" quickly. Runbook voice with the rationale embedded — for a mid-level engineer or Sonnet-class model with zero project context.

Guides how noyalib is described to the outside world — the ecosystem map, provable differentiators, claiming rules, reproducibility standards, and the serde_yaml refugee migration playbook. Load this when writing or reviewing README claims, release notes / RELEASE-NOTES-*.md, marketing / launch copy, blog posts, conference abstracts, papers, competitor / peer comparisons, migration guides (MIGRATION-FROM-*.md), the COMPARISON.md matrix, benchmark headlines, "why noyalib vs X", "is noyalib faster than X", "what makes noyalib different", "how does noyalib compare to serde_yaml / serde_yaml_ng / serde_yml / serde-norway / serde-yaml-bw / saphyr / serde-saphyr / yaml-spanned / yaml-rust2 / libyaml-safer", or any question about what we can and cannot claim in public. Ecosystem cells drift fast: everything is date-stamped 2026-07-08 and must be re-verified before publication.

What counts as evidence in the noyalib repo. Load this BEFORE opening a PR, BEFORE claiming a fix is done, and BEFORE adding a test. Covers the evidence bar (regression test must fail on the pre-fix tree; wrong-but-green is the enemy), the test taxonomy (coverage_*, cst_*, spec/, official_suite, proptest, competitor_bugs, de*/ser*, issue_* regressions, ~480 doctests), the certified inventory (official YAML Test Suite + benches/fixtures/*.yaml), SPDX-headed file naming, doctest rules (# Examples + errors-parse-a-repro from Error::KeyCollision), and the acceptance thresholds (coverage 98/98/98 target vs live 96/94/93; official-suite floor is the merge gate; clippy -D warnings; rustfmt clean). Use for "how do I add a test", "does this need a regression test", "how do I write a cross-loader parity test", "what evidence must a PR carry". Not this skill: running tools → noyalib-diagnostics-and-tooling; the coverage campaign → noyalib-coverage-campaign. v0.0.14, dated 2026-07-08.

Load this when operating noyalib's CI or shipping a release. Covers the workflow graph (ci.yml orchestrator, shared-* reusables, security.yml, scorecard.yml, release.yml), THE cache-poisoning doctrine (isolated CARGO_TARGET_DIR per compile surface — the v0.0.9-v0.0.11 lesson), reading CI failures fast with gh, the supply-chain gate constellation (cargo-vet, cargo-deny, cargo-machete, cargo-semver-checks, REUSE, osv-scanner mirror rule), the tag-driven release flow (version bump → CHANGELOG → RELEASE-NOTES → version-refs audit → squash-merge → tag push → release.yml → satellite lockstep), and the shared-workflow caller-permissions trap (union callee scopes or the run startup-fails with 0 jobs, no annotation). Triggers: "CI is red", "release prep", "how do I tag", "cargo-vet failure", "cargo-deny advisory", "workflow permissions", "cache poisoning", "MSRV job broke", "satellite didn't publish". Sibling: noyalib-change-control (which gates apply). Date-stamped 2026-07-08; branch feat/v0.0.14.

YAML 1.2.2 spec knowledge as noyalib implements it — scalar resolution (resolve_plain_ext table), documents/streams/directives (§6.8, §9.1.2), block vs flow, block-scalar chomping (|/>/-/+), line breaks (§5.4 LF/CR/CRLF), anchors/aliases/merge keys with DoS budgets (max_alias_expansions, alias_anchor_ratio, max_merge_keys), tags (!!str/!!int/!!bool/!!null/!!binary → RFC 4648), YAML 1.1 vs 1.2 flags (legacy_booleans/octal/sexagesimal), the Norway problem, MergeKeyPolicy Auto/AsOrdinary/Error, and official-suite conformance arithmetic. Load when reasoning about YAML semantics, plain-scalar coercion, or spec-conformance work. Use for "explain merge keys / anchors / chomping / tags", "how do I resolve a plain scalar", "why does `no` parse as false", "does noyalib accept `nan` / `.inf` / octal `0o7`", "how many cases does the official YAML suite cover".

Catalog of every configuration axis in noyalib — Cargo features (defaults, deps, production vs experimental, MSRV interactions), `ParserConfig` DoS budgets and behavioural toggles, `SerializerConfig` emission style, and the two preset constructors (`ParserConfig::new`, `ParserConfig::strict`). Use when asked "what does feature `X` do", "how do I limit `Y`", "what's the default for `max_depth` / `max_document_length` / alias expansions", "how do I add a Cargo feature", "how do I add a `ParserConfig` axis", "which toggle disables the streaming fast path", "does the minimal profile drop `serde_ignored`", "does `strict()` reject duplicate keys". Also the checklist for adding a new axis without repeating the FlowStyle-ignored (#84) or the Loader/NoSpanLoader budget-drift class of bug.

Measure instead of eyeball. Use when running or interpreting coverage, Miri, criterion benchmarks, or cargo-fuzz on noyalib; when proving a fix works (differential testing, budget-breach assertions, bench-gated optimisations, clean-fingerprint verification); when reading tool output (regions/lines/functions percentages, Miri UB reports, criterion time/thrpt/change tables, libfuzzer runs/corpus/artifacts); when a claim needs evidence rather than an assertion.

The chronicle of noyalib's settled battles. Load BEFORE proposing a fix, refactor, or "I noticed X is shaped oddly" change. Answers "has this been tried?", "why is X shaped that way?", "is there a known regression history for this area?", "was this ever reverted?", "check history before I propose X", "look up the incident behind Y", or "explain the story of Z". Covers the cache-poisoning no_std mask, the distinct-typed key- collision campaign (loader parity + nan-key follow-on), BOM column desync, lone-CR line breaks, alias span misdirection, FlowStyle ignored, #46 depth-counter imbalances, RUSTSEC/cargo-vet trust-chain gaps, and workspace-split shared-workflow caller permissions. Each entry: symptom → root cause → evidence (commit SHA + file) → status → what NOT to retry. Dated 2026-07-08.

What's next for noyalib — the open, candidate research directions where this library could advance the state of the art, PLUS the discipline that turns a hunch into an accepted result here. Frontier thesis chosen 2026-07-07: YAML-spec leadership — conformance beyond the official test suite, edge-case authority, upstream spec/suite contributions, becoming the reference implementation for YAML 1.2.2 ambiguities. Load when asking "is there a research angle here?", "what would be worth a paper / RFC / upstream PR?", "how do we know an idea earned its way in?", "what's a falsifiable milestone for a spec-conformance push?". Ambitions are OPEN and CANDIDATE; nothing on this page is a v0.1.0 commitment. Covers the frontier thesis, four open problem statements with first-three-steps grounded in this repo, and the research methodology (evidence bar, hypothesis-predicts-numbers, idea lifecycle) that has produced the results noyalib already ships. Dated 2026-07-07.