name: snagbadger-setup description: Guide installation or reconfiguration of SnagBadger bug reporting, agentic testing, or both in selected applications, with project discovery and approved changes.#
Implement the adopter's agreed setup, not just instructions. Use the portable skill name snagbadger-setup; snagbadger:setup is the product workflow name. Find an existing SnagBadger runner checkout with tooling/onboarding/discover.mts and docs/integration/onboarding.md. An installed skill alone is not the runner or published SDK packages. Ask for the runner location only when it cannot be found. Read its onboarding contract before preparing changes.
Discover and scope#
Start a read-only discovery subagent alongside the intent interview. Give it the target workspace and the actual runner command node <runner-root>/tooling/onboarding/discover.mts --root <workspace>. Have it return application paths, evidence-backed suggestions, unsupported stacks, and gaps. When delegation is unavailable, perform discovery yourself and state that it was sequential. Read host instructions before exploring its code. Use existing commands/configuration as clues; discovery never runs package scripts.
Ask whether the user wants the bug report button, agentic testing, or both. Show detected application targets, grouping manifests for the same directory. Let the user select one or several and choose shared setup or tailored setup one application at a time. Shared choices still need per-application integration points, library recommendations, and verification. For existing setup, offer update or replacement; preserve authored tests/custom code in updates and explicitly list replacement boundaries.
Plan in parallel#
After scope is settled, use separate read-only workers for independent areas when delegation is available: reporting/provider and harvesters; testing resources and coverage; execution prerequisites. Workers return findings and proposals, not competing writes. Read reporting decisions when reporting or provider configuration is needed. Testing-only setup also configures the provider and harvesters.
Prefill a consolidated review with discovered values. Ask for missing facts and user decisions in manageable rounds; maintain answers in a project-local onboarding scratchpad. Ask about documentation, inspectable application URLs, and ticket boards even when discovery supplied likely resources: confirm the proposed sources and invite additions. Read resources through available authorized tools and continue with explicit gaps when inaccessible. Treat tickets as evidence, distinguishing implementation from desired behavior and unresolved bugs.
When testing is selected, offer the skills.sh command from the runner's onboarding contract, using its actual accessible source and available skill names. Invoke snagbadger-initialize-tests as part of setup once available; read its installed instructions or the runner's copy. It owns the coverage discussion, execution prerequisites, agreed initial scenarios, authentication/server actions, and blocked-test handling. Supply settled choices rather than asking them again. Bring its proposed changes into the same final review before writing.
Approve, apply, verify#
Show concrete proposed code/configuration, dependencies and installation source, custom harvesters, testing files, missing API work, and replacement/deletion paths. Resolve scenario-dependent server actions after coverage is understood. Obtain approval before applying the proposed plan; review consequential new changes discovered during recovery.
Use public SDK and runner contracts from the actual installation. Verify compatibility with the host package manager and framework. Preserve unrelated files. Make approved project-local changes, initialize agreed tests, and verify each target. Keep application writes sequential when sharing files; isolated verification may overlap. Use supported host checks and browser tools, honoring their real capabilities.
Finish with an application-by-application summary: changed files, checks actually observed, ready features, blocked tests and their missing prerequisites, and next steps. Offer initial execution through snagbadger-test. Provider project configuration does not prove an end user's browser account is connected. A discovered application bug is a test finding, not automatically an installation failure.