Magpie Issue Reassess Stats

issue-reassess-stats

Table of Contents generated with DocToc

• Pre-flight — is this project set up?

Pre-flight — is this project set up?

Do this first, before anything else in this skill, and do it silently: on the happy path it costs three file checks and prints nothing.

A marketplace install delivers skills only. Nothing in it configures this repository, and on most harnesses no code runs at all when a plugin is installed or upgraded — there is no post-install step to rely on. Claude Code's SessionStart hook covers only the all-in-one plugin, so for every other install this check is the one thing standing between a stale or unadopted repo and a skill that acts on wrong assumptions.

1. Is a lock present? If .apache-magpie.lock exists, this project uses the pinned-snapshot install. Compare it with .apache-magpie.local.lock:
   • local lock missing → the snapshot was never fetched on this machine;
   • ref / commit differ → this machine is on a different framework version than the project pins.
2. No lock? Then this is the marketplace install (or nothing at all). Look for a <project-config>/ directory. If there is none, the project has not been adopted and every <placeholder> in this skill is unresolved.
3. Anything unresolved above → stop and propose /magpie-setup (or /magpie-setup upgrade for a version mismatch). Say which of the three checks failed and what you found. Do not run setup unattended and do not continue this skill on a guess: a skill that proceeds against an unadopted repo writes to the wrong tracker.

Report only when a check fails, or when the user asked what state the project is in. /magpie-setup verify is the full diagnostic — this is deliberately the cheap subset that is worth paying for on every invocation.

Read-only dashboard skill over the verdict.json artefacts produced by issue-reassess campaigns. Surfaces a health rating, classification distribution, the still-fails-* action tail, partial-fix surfaces, new-issue candidates from cross-family probes, and per-component breakdowns.

The skill is the read-only counterpart to issue-reassess — both consume the same on-disk artefacts. Where reassess writes verdicts (one per candidate) and a report.md, this skill renders an at-a- glance dashboard for the maintainer to scan.

Modelled on pr-management-stats.

Golden rules

Golden rule 1 — read-only on tracker AND on campaign artefacts. This skill reads verdict.json files and emits HTML. It does not modify any campaign artefact, does not post to <issue-tracker>, does not re-invoke issue-reproducer.

Golden rule 2 — HTML by default. The dashboard is designed for the "what should I do today" glance. Markdown and tables-only fallbacks are available for terminal pipelines (--markdown, --tables-only).

Golden rule 3 — surface action candidates first. The dashboard opens with the still-failing-bug count and the new-issue candidates from probes — these are where work happens. The bulk fixed-on-master / cannot-run-* counts come second.

Golden rule 4 — fresh read on every invocation. The dashboard re-reads verdict.json files on every run; no in-memory caching. This makes the dashboard a coherent snapshot of the campaign state at the moment of invocation.

Golden rule 5 — multi-campaign reads are explicit. When the user points the skill at a directory that contains multiple campaign subdirectories, it asks which one — never silently aggregates across campaigns.

Adopter overrides

Before running the default behaviour documented below, this skill consults .apache-magpie-local/issue-reassess-stats.md (personal, gitignored) and .apache-magpie-overrides/issue-reassess-stats.md (committed, project-wide) in the adopter repo if it exists, and applies any agent-readable overrides it finds. See docs/setup/agentic-overrides.md for the contract.

Hard rule: agents NEVER modify the snapshot under <adopter-repo>/.apache-magpie/. Local modifications go in the override file.

Snapshot drift

Also at the top of every run, this skill compares the gitignored .apache-magpie.local.lock (per-machine fetch) against the committed .apache-magpie.lock (the project pin). On mismatch the skill surfaces the gap and proposes /magpie-setup upgrade.

Prerequisites

• A campaign directory exists at the path the user supplies (or the project's default per <project-config>/reproducer-conventions.md).
• That directory contains <KEY>/verdict.json files for the campaign's candidates (at least one).

No tracker access required — the skill operates entirely on on-disk artefacts.

Inputs

The default output is HTML to stdout; the user pipes it to a file or opens it directly.

Step 0 — Pre-flight

1. Campaign directory exists at the supplied path.
2. At least one verdict.json present under the directory.
3. Override consultation — see Adopter overrides above.
4. Drift check — see Snapshot drift above.

If the directory has multiple campaign subdirs (e.g., the user pointed at <scratch>/), prompt which to use.

Step 1 — Fetch the verdicts

Read every verdict.json under the campaign directory. Parse and schema-validate each per issue-reproducer/verdict-composition.md. Skip and report any file that fails to parse; do not aggregate partial data.

Full details: fetch.md.

Step 2 — Classify

Bucket each verdict by classification (10 labels) and orthogonally by nature (5 labels). Detect multi-case partial fixes from the cases array. Cross-tabulate classification × nature.

Full details: classify.md.

Step 3 — Aggregate

Compute the dashboard's payload:

• Total candidates, breakdown by classification and nature.
• Health rating (Healthy / Needs attention / Action needed) per the project's thresholds.
• Action candidates (still-failing tail).
• Closure candidates (fixed-on-master with strong evidence).
• New-issue candidates (probe findings).
• Per-component breakdown.

Full details: aggregate.md.

Step 4 — Render

Emit the dashboard. Default is HTML with inline CSS (single self- contained file); markdown and tables-only fallbacks honour the --markdown and --tables-only flags.

Full details: render.md.

Step 5 — Output

Write to stdout (default), to a file if --output was passed, or present in the agent's response if the user invoked the skill interactively.

The HTML output is self-contained — no external CSS, no JS, no images. A maintainer opens it in any browser without setup.

Step 6 — Hand-back

Surface to the user:

• The path to the rendered output (if file mode).
• Headline numbers (count of still-failing, count of new-issue candidates).
• Recommended next actions:
  • For each still-failing candidate: /magpie-issue-fix-workflow <KEY>.
  • For each closure candidate: a manual close via the tracker.
  • For each new-issue candidate: a manual file via the tracker.

The skill never executes any of these next actions — it only recommends.

Hard rules

• Never modify campaign artefacts. Read-only on the campaign directory; no re-running issue-reproducer, no rewriting verdict.json.
• Never post to <issue-tracker> — the dashboard is a local view; tracker writes go through other skills.
• Never aggregate across campaigns without an explicit user prompt. Each campaign's verdicts are scoped to one <campaign-id>.
• Never invent counts. If a verdict.json failed to parse, it's surfaced as a parse error, not counted in the totals.

Failure modes

References

• fetch.md — reading verdict files.
• classify.md — classification + nature bucketing.
• aggregate.md — health rating, action candidates, recommendation rules.
• render.md — HTML layout, markdown fallback, recommendation panel.
• issue-reassess — producer of the verdicts this skill consumes.
• issue-reproducer/verdict-composition.md — the schema being read.
• pr-management-stats — the structural template this skill mirrors.
• tools/dashboard-generator/ — reference implementation that produces the same output deterministically (for adopters who want CI-rendered dashboards without invoking the agent).
• docs/issue-management/README.md — family overview.