Minimum-requirements checklist for any change — code or docs-only. Run this before every PR creation or push to avoid CI failures on the first attempt.
Installation
Installer avec Codex ou Claude Copiez ce prompt, collez-le dans Codex, Claude ou un autre assistant, puis laissez-le vérifier la page du skill et l'installer pour vous.
Minimum-requirements checklist for any change — code or docs-only. Run this before every PR creation or push to avoid CI failures on the first attempt.
Pre-PR Checklist
Purpose
Ensure every change — including simple, single-agent tasks — satisfies the repository's minimum requirements before a PR is created. This avoids predictable CI failures (release-notes guardrail, snapshot guardrail, formatting, coverage thresholds).
When to Use
Mandatory before any report_progress call (coding agents) or scripts/pr-github.sh create call (local agents) that introduces changes to the repository.
Category A — Docs/agent-tooling only (all changed files are under docs/exceptdocs/agents.md and docs/spec.md, .github/ (any subdirectory or file), website/, website.old/, assets/, tests/, scripts/, or src/tests/shell/):
→ Skip to Step 6 (Commit hygiene). Build/test/work-item checks are not required.
Category B — Code/tooling (any file in src/ (except src/tests/shell/), examples/, docs/agents.md, docs/spec.md, README.md, or CONTRIBUTING.md):
→ Complete all steps below.
Step 1 — Work Item Folder
Every code/tooling PR must be anchored to a work item folder. If you are doing a simple task without a full workflow, create a minimal one now.
Determine the folder
Branch prefix
Folder prefix
feature/<NNN>-...
docs/features/<NNN>-.../
fix/<NNN>-...
docs/issues/<NNN>-.../
workflow/<NNN>-...
docs/workflow/<NNN>-.../
If the branch does not match any prefix, use docs/workflow/ (most internal/tooling changes fall here). Use the next-issue-number skill to reserve an issue number if you don't already have one.
Create minimal required files (if missing)
docs/<type>/<NNN>-<slug>/release-notes.md — describe the change in one or two sentences. No screenshots required for simple changes:
docs/<type>/<NNN>-<slug>/work-protocol.md — log your agent entry (required by the validate-work-protocol hook):
# Work Protocol: <Shorttitle>**Work Item:**`docs/<type>/<NNN>-<slug>/`**Branch:**`<branch-name>`**Workflow Type:**<Feature | BugFix | Workflow>**Created:**<YYYY-MM-DD>## Agent Work Log### <YourAgentName>-**Date:**<YYYY-MM-DD>-**Summary:**<Whatyoudid>-**Artifacts Produced:**<Filescreatedormodified>-**Problems Encountered:** None
Note: For simple single-agent changes the validate-work-protocol hook only blocks report_progressafter the trigger agent (Code Reviewer for features/bugs; Workflow Engineer for workflow items) has logged an entry. So for single-agent tasks the hook will not block you — but the release-notes guardrail (validate-release-notes.sh) will. Both release-notes.md and work-protocol.md must be present.
Step 2 — Code Formatting
dotnet format src/tfplan2md.slnx --verify-no-changes --verbosity diagnostic
If formatting errors are found, auto-fix and re-check:
dotnet format src/tfplan2md.slnx
dotnet format src/tfplan2md.slnx --verify-no-changes
Use the run-dotnet-tests skill. The project has mandatory coverage thresholds (84.48 % line, 72.80 % branch). New code must be tested.
scripts/test-with-timeout.sh -- dotnet test --solution src/tfplan2md.slnx --configuration Release
Snapshot changes
If any file under src/tests/Oocx.TfPlan2Md.Tests/TestData/Snapshots/ changed, use the update-test-snapshots skill and include SNAPSHOT_UPDATE_OK in at least one commit message:
Skip this step only if the change has no effect on markdown output (e.g., internal refactoring with no observable output change, or pure tooling/docs changes).
For internal-only PRs (docs/scripts/agents only), use docs:, chore:, ci:, style:, or refactor: — notfeat:, fix:, or perf: (those trigger version bumps)
CHANGELOG.md has not been edited (it is auto-generated by Versionize in CI)
Working tree is clean: scripts/git-status.sh --short
