---
name: snagbadger-initialize-tests
description: Initialize SnagBadger testing through a resource-guided coverage discussion, approved initial scenarios, runtime setup, and authentication or server-side prerequisites.
---

Find the existing SnagBadger runner checkout and adopting project's setup/catalog. Read that runner's `docs/integration/onboarding.md`, `docs/integration/agent-testing.md`, and `docs/integration/testing-runtimes.md`; installed skill folders are not a substitute for the runner. Reuse settled choices from `snagbadger-setup` when invoked during onboarding. Read the host's instructions and preserve existing authored tests and customizations.

## Discuss coverage from resources

Read [coverage preparation](references/coverage.md) before scenario preparation or coverage maintenance. Ask the runtime user to select initial coverage breadth and priorities, such as comprehensive selected-scope coverage or focused core scenarios; reuse an already settled choice. Neither is a default.

Ask for or confirm discovered documentation locations, application URLs agents can inspect, and ticket boards containing implementations and bugs. Identify the available access mechanisms; continue with accessible resources and explicit gaps. Record source pointers with proposed scenarios in a project-local scratchpad. Separate documented expectations, implemented features, open bugs, and uncertain observations. A known bug needs an agreed expected outcome rather than a test that normalizes the bug.

Propose a coverage chart and discuss it with the user in rounds. Refine priorities, prerequisites, steps, expected outcomes, and missing evidence until the user agrees the initial scenarios. This is a live discussion, not automatic test generation. Keep exploration and proposal work read-only until approval; during setup, return the proposed files and prerequisites for its consolidated approval. Standalone invocation obtains its own approval before applying.

## Prepare execution

Discover startup commands, configured application URLs, existing test fixtures, hooks, authentication helpers, and browser tools. Read actual installed runtime schemas before asserting fresh-agent, isolated-context, screenshot, or video support. A new tab in a shared profile is not an isolated context. Keep API/CLI tests usable when browser prerequisites are absent; retain blocked browser scenarios and state their missing support.

Ask how tests should authenticate and perform required server-side actions. Prefer existing supported project mechanisms. Read [test-support integration](references/test-support.md) when login, fixtures, server actions, or missing APIs are involved. Support lifecycle hooks and explicit scenario actions. Guide the user through designing and implementing approved missing project-owned API work; creating these skills does not itself provision a remote service.

## Apply and verify

Use `prepareCoverage` from the runner's `tooling/onboarding/coverage.mts` with the actual catalog, selected scope, resource classifications/pointers, explicit scenario decisions and proposed `CatalogSource` content. Keep unresolved expectations as questions/gaps, and maintain the readable coverage index outside the catalog. Definitions remain authoritative for execution behavior. Use `snagbadger-create-test` for agreed scenarios; when it is unavailable, read the runner's copy.

Show the helper's concrete definition/index before/after changes together with runtime configuration, hook/action registration, dependencies and any API implementation. Obtain approval, then call `validateCoverageApproval` immediately before host-owned writes. On success, apply only the returned immutable `changes`, never the original mutable preparation's changes. Changed files/resources/candidates return to review. Preserve existing IDs, metadata, evidence settings and authored tests. Configure project functions and report review through the existing runner contract. Secrets come from the host environment, not frontmatter or persisted coverage metadata.

Validate the catalog with `node <runner-root>/tooling/testing/plan.mts inspect --catalog <catalog>`. Verify ready startup/runtime/hook capabilities with supported host checks. Record unavailable prerequisites in the scratchpad and test prerequisite prose; do not invent an unsupported `blocked` frontmatter field. Report readiness separately from test outcomes. Offer to execute ready initial scenarios with `snagbadger-test`, using explicit IDs when other tests remain blocked. A runtime attestation is evidence, not a switch that installs a capability.