Load for pre-PR self-review or pull-request review that must verify the matched intent, allowed scope, required tests/docs, forbidden actions, architecture gates, and merge readiness; not for a general code-quality diff review alone.
The English summary is being prepared. Showing the original description.
Review the instructions the agent will receive before you install.
<!-- ABOUTME: Pre-PR and PR review checklist driven by the matched intent. -->
<!-- ABOUTME: Verifies paths in scope, tests, docs, rules, and forbidden actions before opening or approving a PR. -->
Review mode — when asked to review someone else's PR.
Step 0 — Upstream Freshness Gate
Fetch latest upstream to ensure diffs and merge-bases reflect current develop:
git fetch origin develop
Ensure the PR branch is cleanly mergeable with origin/develop with zero stale base drift.
Step 1 — Re-Identify the Intent
Which matching entry in intents.yaml does this PR implement? If the PR spans multiple intents, review each in turn and merge the checklists without loading the full registry into task context.
Step 2 — Execute the Intent's PR Checklist
For each item in the intent's pr_checklist, collect evidence:
Is every changed file inside the intent's paths_in_scope?
Is no changed file inside the intent's paths_forbidden?
Are the changes minimal (not bundling unrelated refactors)?
If any answer is "no", split the PR or escalate to the user.
3.1 Two-Axis Quality Gate
Axis 1: Standards & Clean Architecture: Verify layer boundaries, absence of raw DTO returns in repositories, manually instantiated validators, and check against the Fowler 12-Smell Baseline (no Primitive Obsession, Feature Envy, or Shotgun Surgery).
Axis 2: Intent & Spec Fidelity: Verify every acceptance criterion from the matched intent without unasked-for scope creep or speculative abstractions.
dotnet test --project tests/Event.Architecture.Tests/Event.Architecture.Tests.csproj --configuration Release --verbosity quiet
Step 5 — Critical Rules Checklist (applies to every PR)
No as any, @ts-ignore, @ts-expect-error, or equivalent C# type-suppression hack.
No new rm, mv, or > shell redirection in scripts.
No .env, credentials, or secrets staged.
Self-documenting code: no synthetic ABOUTME: headers on code (.cs, .razor, .css, project files); standard C# XML doc comments (/// <summary>) where non-inferable.
No duplicated content across docs, skills, or agents (point — don't copy).
Step 6 — Documentation Sanity
docs/internal/QUICK_REFERENCE.md updated if a new invariant was introduced.
docs/internal/API_CHANGELOG.md updated if a public contract changed.
dev/_journal/journal.md appended if a non-obvious finding emerged.
Cross-check the diff against the intent's forbidden_without_approval list. If any item triggers, the PR MUST carry explicit approval in its description or be rejected.
Step 8 — Output Contract
Produce a summary the reviewer can paste into the PR:
Intent: <intent-id>
Files changed: <count> (all in scope ✔)
Build: ✔
Tests: <project list> — all green
Docs: <files> updated
Forbidden actions: none triggered
Outstanding questions: <list or None>
When Review MUST Fail
Any checklist item lacks evidence.
Any file is outside paths_in_scope or inside paths_forbidden.
Any forbidden_without_approval item triggered without approval.
Any architecture test (Event.Architecture.Tests.*) fails.
Load for Blazor/MudBlazor UI changes involving forms, dialogs, focus, keyboard navigation, landmarks, ARIA, color contrast, RTL-safe styling, or WCAG 2.2 AA tests; not for backend-only changes.
The English summary is being prepared. Showing the original description.
Load when a task asks to research, verify, compare, or look up framework/package behavior, release notes, standards, RFCs, CVEs, or unfamiliar APIs; use repository evidence first, then official docs, and not for codebase navigation alone.
The English summary is being prepared. Showing the original description.
Load for Aspire AppHost work: start/stop/wait resources, inspect dashboard/logs/traces, add integrations/resources, rebuild a service, run isolated worktrees, or diagnose Aspire orchestration; not for plain dotnet apps, container-only deployments, or cloud deployment.
The English summary is being prepared. Showing the original description.
Load for authentication or authorization changes involving BFF cookies/tokens, JWT validation, claims/user ID extraction, policies, handler access checks, impersonation, or 401/403 bugs; not for UI affordance gating alone.
The English summary is being prepared. Showing the original description.
Load for Blazor BFF server work involving YARP proxy routes, cookie sessions, access-token forwarding/refresh, downstream API calls, BFF handlers, or browser-to-API auth failures; not for client component rendering or API JWT validation alone.
The English summary is being prepared. Showing the original description.
Load when editing Blazor `.razor.css`, scoped selectors, `::deep`, BEM class names, RTL/logical CSS properties, or styling nested MudBlazor components; not for global design tokens or non-Blazor CSS.
The English summary is being prepared. Showing the original description.