azure-governance-discovery

Azure Governance Discovery Skill

Replaces the legacy governance-discovery-subagent with a deterministic script. The skill exposes scripts/discover.py — a single batched REST traversal that emits the schema-compliant 04-governance-constraints.json envelope. The parent agent (04g-Governance) invokes it via run_in_terminal, reads a compact one-line JSON status from stdout, and proceeds to artifact writing without ever pulling raw Azure REST responses into LLM context.

When to Use

• Step 3.5 governance discovery for a project
• Refreshing the governance snapshot after policy changes
• Regenerating inputs for Step 4 (IaC Plan) and Step 5 (IaC Code)

When NOT to Use

• Writing 04-governance-constraints.md — that stays in the parent agent
• Cross-referencing architecture resources — parent-side LLM work
• Challenger review orchestration — parent-side LLM work
• Any workflow that is not 04g-Governance

Rules

• Stay deterministic — the discovery script is a single batched REST traversal; no LLM calls, no retries that hide errors, no inferred policy effects
• Never pull raw Azure REST responses into LLM context — stdout is exactly one machine-readable JSON status line; the parent agent reads only this line
• Schema compliance is mandatory — envelope MUST conform to tools/schemas/governance-constraints.schema.json (schema_version: governance-constraints-v1)
• Property paths are always strings — use "" for unresolvable paths, never null
• Filter Defender auto-assignments by default — they create policy noise that masks real governance constraints; opt-in via --include-defender-auto
• Exit codes are contract — 0 = COMPLETE, 1 = PARTIAL, 2 = FAILED, 3 = invalid args; the parent agent routes solely on these codes
• No artifact writing — the script emits JSON + a .preview.md; the agent owns the final 04-governance-constraints.md content and traffic-light rendering
• Re-run with --refresh when policy state has changed; otherwise honor the existing JSON