Bug report diagnosis

Readonly for this skill. Input = a product report (chat, ticket, described screenshot, user steps). Output = a chat diagnosis in two audiences: plain language for whoever will retest, and a short pointer for the next coding agent. Then dispatch that agent unless diagnose-only.

This skill does not change product code. ns-execution-gitlab-issue or ns-coder owns the patch. Entry priority 4a. Full routing: ../../ns-harness/references/code-skill-routing.md. Continue rules: references/continue-handoff.md.

Session boot

See ../../ns-harness/references/session-boot.md. Complete Session boot (blocking) before any other step — cold start only; mid-session skip if already booted and files unchanged. Never tool-Read AGENTS.md.

Load architecture-rules.md and project-rules.md. If docs/context/ exists, open only what the investigation map asks (overlay or the matching brownfield row) — not the whole corpus. This skill does not write product code or docs/context/ files (session-boot implementation writes do not apply).

Routing (read first)

Trigger phrases: references/entry-triggers.md.

Use when the user wants a product-story diagnosis — screen, expected vs actual, ticket as a report. Screen story still enters here even when they will want a fix afterwards: diagnose first, then dispatch.

Do not enter when the user asks to implement or fix code without a screen story → ns-coder (priority 5). Do not enter for GitLab ISSUE_URL as the host's first skill (bare execution URL) → ns-execution-gitlab-issue (priority 1). Do not enter for stack/CI/log with no screen story → ns-investigator (priority 4b). Do not enter for multi-day / version scope → ns-spec-driven (priority 2).