Skip to content

feat(pr-ready): add doc-check step to the workflow - #56

Merged
5uck1ess merged 3 commits into
mainfrom
feat/pr-ready-doc-check
Apr 10, 2026
Merged

feat(pr-ready): add doc-check step to the workflow#56
5uck1ess merged 3 commits into
mainfrom
feat/pr-ready-doc-check

Conversation

@5uck1ess

Copy link
Copy Markdown
Owner

Summary

Adds a doc-check step to the pr-ready workflow, wired in between changelog and create-pr. Closes the "does this PR need README / ROADMAP / CLAUDE.md updates?" question that currently has to be asked manually on every PR.

What it does

The new step classifies the diff as one of feature / bugfix / breaking / internal / docs-only, then walks a rule table for each candidate doc at the repo root:

  • README.md — update on feature (if user-facing commands/install/feature table changed) or breaking (always).
  • ROADMAP.md — move entries Planned → Implemented on feature; update on breaking removal.
  • CHANGELOG.md — deliberately skipped. Managed by the release pipeline, not individual PRs. Only touched by explicit release-bump PRs.
  • CLAUDE.md / AGENTS.md — update on feature/breaking when project conventions, tool selection rules, or workflow patterns change.
  • docs/*.md — update if an existing subsystem doc describes what you touched.
  • plugin.json / manifest.json / .claude-plugin/ — update when commands, skills, agents, or MCP servers are added/removed/renamed.
  • workflows/*.yml — update when a step is added or its contract changes.

Mechanical edits (moving a ROADMAP bullet, adding a README command row, renaming a manifest entry) are applied directly via Edit/Write and committed with docs: update <files> for <classification> so they land in the PR alongside the code. Ambiguous updates are flagged as [!] TODO entries in the output checklist so the user sees exactly what still needs manual attention before create-pr runs.

Output format:

- [x] README.md — updated: added `devkit pr-ready` command to CLI table
- [ ] ROADMAP.md — not affected (bugfix)
- [ ] CHANGELOG.md — managed by release pipeline
- [!] CLAUDE.md — needs manual update: describe new hook lifecycle

Pipeline order

Before:

validate → necessity → lint → test → security → changelog → create-pr → monitor

After:

validate → necessity → lint → test → security → changelog → doc-check → create-pr → monitor

changelog runs first so the diff's intent is already summarized when doc-check makes its classification decisions.

Files

  • workflows/pr-ready.yml — new step (~70 lines) between changelog and create-pr
  • skills/pr-ready/SKILL.md — updated step list and description

Test plan

  • Workflow YAML parses and step order is validate → necessity → lint → test → security → changelog → doc-check → create-pr → monitor
  • Run pr-ready on a real PR and confirm doc-check emits a usable checklist
  • Verify that a feature PR touching README triggers an [x] apply, and an internal-refactor PR emits [ ] for all docs

Every PR ships without anyone asking "does this need README / ROADMAP /
CLAUDE.md updates?" because the author forgets and there's no step in
the pipeline that forces the question. Add a `doc-check` step to the
pr-ready workflow that runs after `changelog` and before `create-pr`.

The step classifies the diff (feature / bugfix / breaking / internal /
docs-only) and walks a rule table for each candidate doc at the repo
root — README.md, ROADMAP.md, CLAUDE.md / AGENTS.md, docs/, plugin.json
and other manifests, workflows/*.yml — deciding per-file whether this
PR requires an update. CHANGELOG.md is explicitly skipped because it
is owned by the release pipeline, not individual PRs.

Mechanical edits (moving a ROADMAP bullet from Planned to Implemented,
adding a README command row, renaming a manifest entry) are applied
directly via Edit/Write and committed with `docs: update <files> for
<classification>` so they land in the PR alongside the code. Ambiguous
updates are emitted as `[!]` TODO entries in the checklist output so
the user sees exactly what still needs manual attention before
`create-pr` runs.

Also updates skills/pr-ready/SKILL.md to reflect the new 9-step
pipeline.

Verified the YAML parses and step order is
    validate → necessity → lint → test → security
    → changelog → doc-check → create-pr → monitor
The user-facing prompt in pr-gate.sh enumerated the pr-ready pipeline
as "lint, test, security, DRY review, changelog, monitor" — which was
already stale (no "DRY review" step exists) and is now also missing
the new doc-check step added in this PR.

Updated to match the actual workflow order after doc-check:
    lint, test, security, changelog, doc-check, monitor

Found by running this PR's own doc-check rules on itself — this is
exactly the kind of stale mechanical reference doc-check is meant to
catch automatically on future PRs.
Code review on PR #56 flagged that `doc-check` was ordered after
`changelog`, so any `docs: update ...` commit the step creates would
not be reflected in the changelog summary that `create-pr` uses for
the PR body. Swap the order to doc-check → changelog → create-pr so
the changelog always sees doc-check's commits.

Also expand the doc-check rule table with a `skills/*/SKILL.md` entry
the review suggested was missing. SKILL.md files are a first-class
user-facing surface in this repo and were not covered by the previous
rules — which meant a workflow step change could slip through without
syncing the matching skill's step list. New rule: edits to a
`workflows/*.yml` file require the matching `skills/<name>/SKILL.md`
step list to be synced, and SKILL.md mismatches are flagged as
needs-update. (This PR would have caught its own manual SKILL.md
update automatically under the new rule.)

Updated skills/pr-ready/SKILL.md to reflect:
  - new order (doc-check → changelog)
  - skills/*/SKILL.md in the candidate list
  - "Runs before changelog so ..." explanation
@5uck1ess
5uck1ess merged commit f005c0d into main Apr 10, 2026
4 checks passed
@5uck1ess
5uck1ess deleted the feat/pr-ready-doc-check branch April 10, 2026 15:42
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant