Reassess Stats

<!-- SPDX-License-Identifier: Apache-2.0
     https://www.apache.org/licenses/LICENSE-2.0 -->

<!-- Placeholder convention (see ../../AGENTS.md#placeholder-convention-used-in-skill-files):
     <project-config>          → adopter's project-config directory
     <issue-tracker>           → URL of the project's general-issue tracker
     <issue-tracker-project>   → project key within the tracker
     <upstream>                → adopter's public source repo
     <default-branch>          → upstream's default branch
     Substitute these with concrete values from the adopting
     project's <project-config>/ before running any command below. -->

issue-reassess-stats

<!-- BEGIN MAGPIE PREFLIGHT — generated from tools/dev/preflight-block.md -->

Pre-flight — is this project set up?

Do this first, before anything else in this skill, and do it silently. One command answers it and carries its own rules; there is nothing else to read.

Run the checker with this skill's own frontmatter name: and surface_hash:, and one --requires for each requires_config: entry:

PYTHONPATH=".apache-magpie-local:$(git rev-parse --git-common-dir)/../.apache-magpie-local:$(git rev-parse --git-common-dir)/apache-magpie" \
  python3 -m setup_preflight --skill <name> --hash <surface_hash> [--requires <file>]...

The path finds the checker /magpie-setup config installed in the personal layer: this checkout's .apache-magpie-local/, the main checkout's when this is a linked worktree, or the git directory's apache-magpie/ when Magpie is only installed.

• {"verdict": "ok"} → silent. Continue into the work the user asked for and say nothing about pre-flight. This is the ordinary answer.
• {"verdict": "action", ...} → each finding names a section, and rules carries that section's text. Follow it. The facts are the inputs; what to propose, and what may not be done, are in the rules rather than here. Act on a finding only through its rules.
• The command did not run at all — no such module, a non-zero exit, no python3 — → never read that as a pass, and do not re-derive the check by hand: it lives in code so that there is one version of it. If the project has no .apache-magpie.lock, .apache-magpie-overrides/, or personal layer (any of the three directories above), nothing has been set up here and there is nothing to reconcile — resolve this skill's requires_config: entries yourself (first match wins: .apache-magpie-local/<file>, the main checkout's .apache-magpie-local/<file>, <git-common-dir>/apache-magpie/<file>, then .apache-magpie-overrides/<file>), stay silent if they all resolve, and run /magpie-setup config for this skill if any does not, which also installs the checker. Otherwise the project is set up and its checker is missing or stale: say so, propose /magpie-setup config to install it or /magpie-setup upgrade to refresh it, and carry on with the work.

Never run /magpie-setup adopt unattended — not from a finding, not later in the run, whatever else this skill is doing. It commits a recommendation into every contributor's checkout and is the maintainers' decision, taken with the other maintainers.

Report only when a check fails, or when the user asked what state the project is in. /magpie-setup verify is the full diagnostic.

<!-- END MAGPIE PREFLIGHT -->

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

<!-- BEGIN MAGPIE BLOCK: adopter-overrides — generated from tools/dev/blocks/adopter-overrides.md -->

Before running its default behaviour, this skill consults issue-reassess-stats.md in the personal layer (.apache-magpie-local/ when the project adopted Magpie, falling back to the main checkout's in a linked worktree, or <git-common-dir>/apache-magpie/ when Magpie is only installed; applied first, wins on conflict) and .apache-magpie-overrides/issue-reassess-stats.md (committed, project-wide) in the adopter repo, if present, 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; framework changes go via PR to apache/magpie.

<!-- END MAGPIE BLOCK: adopter-overrides -->

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.