name: snagbadger-create-test description: Create or update agreed SnagBadger Markdown test definitions from application behavior, feature resources, or bug evidence, preserving the existing catalog.#

Find the SnagBadger runner checkout and target catalog. Read its docs/integration/agent-testing.md for the current public catalog format and lifecycle semantics; installed skill folders do not contain a runner. Read project instructions and existing section/test definitions before editing.

Resolve the scenario's source and intended outcome with the user, reusing the accepted onboarding scratchpad when present. Consult supplied documentation, application URLs, implementation tickets, and bug evidence through authorized tools. Distinguish observations from expected behavior and hypotheses. Ask about consequential ambiguity; incomplete bug reports can still inform a proposed test. During initialization, create only agreed scenarios after the setup's change approval.

For definition preparation or coverage maintenance, read the runner's docs/integration/onboarding-coverage.md. Import prepareCoverage and validateCoverageApproval from tooling/onboarding/coverage.mts. Reuse the runtime-selected scope/priorities, classify resource access/evidence and record expectation-decision pointers; unresolved expectations remain proposals. Keep the readable coverage index outside the catalog and preserve unrelated entries. Definitions own execution behavior.

Choose a stable unique ID, executor (browser/api/cli), section, tags, prerequisites, ordered steps, and expected outcomes. Reuse existing hierarchy/settings and keep IDs when updating the same scenario. Add section.md only for genuinely shared metadata, evidence requirements, guidance, hooks, or destination. Preserve unrelated tests. Show replacement or behavior changes before applying them.

Include actual authentication/fixture/action mechanisms at the appropriate lifecycle or scenario steps. Keep missing prerequisites explicit and refer to the onboarding scratchpad's readiness record. Use the current hook registry and host API/CLI action mechanism rather than inline executable YAML or invented bridge requests. Keep secrets in the execution environment. Match evidence requirements to agreed policy and verified runtime capabilities; changing required proof needs user agreement.

Prepare the combined candidate against the actual catalog through prepareCoverage, using explicit add/update/rename/remove intent and existing stable IDs. Show its concrete definition/index before/after changes for approval. Call validateCoverageApproval immediately before writing. On success, apply only the returned immutable changes, never the original mutable preparation's changes; changed sources/files or candidates require re-review. Run node <runner-root>/tooling/testing/plan.mts inspect --catalog <catalog> on the written result. Correct validation errors through the public contract. Finish with changed definitions, maintained source/expectation/test links, deferred gaps, validation and missing prerequisites. Catalog validation proves structure, not successful execution or correct application behavior; offer snagbadger-test when appropriate.