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
Mit Codex oder Claude installieren Kopieren Sie diesen Prompt, fügen Sie ihn in Codex, Claude oder einen anderen Assistant ein und lassen Sie die Skill-Seite prüfen und installieren.
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
