petrova-status

Read-only inspection of one or more petrova-line repos. Three commands back this skill, all hitting local clones (no GitHub auth required):

Command	Use for
petrova status	Cross-repo summary table: per-repo phase, open milestones, recent decisions.
petrova diagnose <slug>	Single-repo deep dive: current phase, open milestones, recent decisions and findings, CI status. Returns a diagnosis_id other verbs (notably propose_fix) can bind to.
petrova validate <slug>	MR / convention compliance: closed decision docs have sign-off (MR-7), filenames match ISO date (MR-4), AGENTS.xml well-formed (MR-6), CLAUDE.md size heuristic (MR-12), milestone IDs unique.

Workflow

1. Pick the right command

Map the user’s question to the command:

• “What’s the state of the fleet?” / “what’s open across all my repos?” → petrova status
• “What’s going on with <repo>?” / “diagnose <repo>” → petrova diagnose <slug>
• “Does <repo> comply with petrova rules?” / “audit <repo>’s docs” → petrova validate <slug>

2. Optionally derive the slug

If the user names a repo by directory path or git remote rather than slug, run:

bash "${PETROVA_HOME:-$HOME/code/workspace/petrova-hq}/skills/petrova-act/scripts/repo-slug.sh"

(Same script as petrova-act — it returns the slug for the current cwd or errors if not in registry.)

3. Run

petrova status
petrova status --repo kahn-hq smo1-io
petrova diagnose kahn-hq
petrova diagnose kahn-hq --since 2026-04-01 --scope decisions
petrova validate kahn-hq

Add --json if the human wants structured output.

4. Report

Show the CLI’s output verbatim, then add a one-line synthesis if there are >5 rows or interesting outliers (e.g. “petrova-hq is the only repo with an open phase right now”). Don’t paraphrase per-row data — the table format is the point.

What this skill does NOT do

• Does not open PRs or modify files. Use petrova-act for that.
• Does not reach GitHub directly — local clones only. CI status fields return unknown until TASKSET 5+ extends with App-installation reads.
• Does not bypass the registry. Repos absent from registry.yaml are invisible to all three commands; this is intentional.

When to chain into petrova-act

Common pattern: diagnose → notice a milestone gap or open finding → petrova-act propose_fix (binds to the diagnosis_id) or petrova-act open_decision (records the call before acting). The diagnosis_id from a diagnose run is valid for 24h in ~/.petrova/diagnoses.jsonl; propose_fix will refuse stale ones.