Sonar Workflow Skill

Sonar provider for the findings-pipeline sonar-issue producer. The provider surface is exactly TWO pure, zero-LLM verbs — no triage judgment lives here:

• fetch_findings — fetch gate-blocking new-code issues from SonarQube/SonarCloud, apply the pre-filter (sonar-rules.json), and file one sonar-issue finding per surviving issue via manage-findings add. The untrusted Sonar message is quarantined under raw_input.{message} (never embedded raw in the top-level detail); the batched manage-findings ingest pass promotes it after validate_struct.
• post_responses — apply already-decided triage dispositions back to Sonar (a do_transition dismissal: wontfix for suppressed, falsepositive for rejected), keyed by each finding's own hash_id.

Both verbs FAIL LOUD when Sonar is not configured (a typed unconfigured status). Consumer dispatch lives in phase-6-finalize/workflow/sonar-roundtrip.md.

Architectural context: This SKILL.md owns the producer-side CLI surface. For the producer→store→consumer→gate flow that connects this producer to the unified store, the per-domain ext-triage consumer dispatch, and the invariant gate, see ref-workflow-architecture/standards/findings-pipeline.md.

Enforcement

Execution mode: Two pure provider verbs — fetch_findings files new-code Sonar issues to the ledger (untrusted message quarantined under raw_input); post_responses transmits already-decided triage dismissals back to Sonar. Triage judgment lives in the consolidated triage pass, NOT in this provider.