sandermuller/boost-skills
sandermuller/boost-skills is a Composer-distributed catalog of AI agent skills for PHP and Laravel projects. It ships Markdown-only workflow skills, tag-gated framework extras, and always-on guidelines that Laravel Boost or boost-core syncs into your configured AI agent directories.
resolve-conflicts: dangling-symbols.sh no longer reports a clean sweep when:
/** [@deprecated](https://github.com/deprecated) */ public function run(). 2.52.0 dropped the whole line as a comment./* note */ import type Money from './money';. It no longer counts as a declaration.Full changelog: https://github.com/SanderMuller/boost-skills/compare/2.52.0...2.52.1
codex-review defaults to gpt-6.1-sol. Codex CLI 0.156.1 rejects it on a ChatGPT account and 0.159.0 accepts it. Update the CLI, or pass --model gpt-6-sol / set CODEX_REVIEW_MODEL.Full changelog: https://github.com/SanderMuller/boost-skills/compare/2.48.0...2.49.0
evaluate Phase 1 now asks pipeline:verify --server-verified instead of the bare call. The bare call exits 0 only when the server verified every step in the walk, which a pipeline that sequences agent work can never satisfy — an acknowledged step is a self-report and is never counted as verified — so the skip never fired for those projects at all.evaluate skips the mechanical checks those names cover and runs every check they do not. No step mapping and no receipt parsing live in the skill. Exit 0 is never read as a claim that the pipeline holds a check it does not declare, and a step that rewrites the tree is excluded from the names on purpose — a formatter reports that it ran, never that the result is correct.sandermuller/boost-pipeline v0.9.0 or later to skip anything, and v0.10.0 or later when quality.pipeline is set. The flag itself shipped in v0.8.0, but that release names no step ids, so evaluate finds nothing to skip and runs its checks — safe, just no benefit. On v0.7.0 and earlier the option does not exist and the command reports an unknown option, which evaluate treats like any other non-zero exit.quality.pipeline convention. A project that declares several pipelines can name the one evaluate asks about, and evaluate appends --pipeline=<value>. Absent, evaluate asks without it — a multi-pipeline project then gets an error naming its pipelines and runs its checks normally rather than guessing which one to trust.Full Changelog: https://github.com/SanderMuller/boost-skills/compare/2.30.0...2.31.0
evaluate Phase 1 now asks sandermuller/boost-pipeline whether a recorded run already verified the code on disk, instead of reconstructing from memory which check ran when. A project running the pipeline skips the mechanical checks that run covered, but only when the server verified every step: a walk that sequences agent steps does not satisfy that, so the skip does not fire there yet.codex-review now sends the review prompt to Codex on stdin instead of as a command-line argument. Every focused review failed before this: the codex binary is killed by the OS at exec time when any single argument is larger than about 1010 bytes, so it died with no output and nothing to report. The limit is per argument rather than per command line, and a short prompt stays under it — which is why the failure only showed up on real reviews.Full Changelog: https://github.com/SanderMuller/boost-skills/compare/2.29.0...2.30.0
For docs-site packages, the README now links to the published documentation site with absolute URLs instead of to the repo's markdown sources. This flips a convention 2.28.0 introduced. Packages without a docs/ site see no change.
readme: README links point at the published site, not docs/*.md. The docs-site shape's link mechanics now require absolute published-site URLs (for example https://acme.github.io/example-package/installation). This is the ecosystem convention — spatie/laravel-permission, spatie/laravel-medialibrary, livewire/livewire, inertiajs/inertia, and laravel/framework all link their READMEs to the published site, none to repo markdown. Absolute URLs also render everywhere the README lands: GitHub, Packagist, IDE package viewers, forks, and the installed vendor copy, where docs/ is export-ignored and a repo-relative link resolves to nothing. At most one repo-relative pointer to docs/ as the source location stays allowed; repo-relative links to individual pages are now flagged as the non-recommended form. The NN- prefix and rewrites layout is unchanged — it governs filenames, not link form.readme: the link audit validates README links against routes, not the filesystem. README site links cannot resolve on disk, so the audit now checks each one against a route the generator actually produces (the source page after slug and rewrite normalization). On-disk resolution still applies to the single docs/ source pointer and to non-docs repo links such as UPGRADING.md. The URL-stability section adds the consequence: a slug rename now breaks README links too, not only external inbound links.readme: the site-URL-once rule is scoped to prose. A Documentation section made of site links repeats the site root by design. The rule now reads: state the root URL once in running text; page links are navigation and do not count.pre-release: step 5a owns the README link check. The 5a link audit mirrors the new link classes. It also states explicitly that step 5c builds docs/ only and never checks README links, because the README sits outside docs/ — so 5a is the only check for them in both the build and the documented-skip path.Full Changelog: https://github.com/SanderMuller/boost-skills/compare/2.28.0...2.29.0
The readme and pre-release skills now understand packages whose documentation lives in a docs/ static site (for example VitePress on GitHub Pages) instead of the README. Additive — packages without a docs site see no change.
readme: a third README shape — docs-site. For packages with a docs/ site: a thin README (badges, pitch + teaser example, install, one usage example, a Documentation section, standard footer) that links to the docs instead of restating them. The skill defines the detection signals (generator config in docs/, a root config naming docs/ as source, or a deploy workflow building from it), link mechanics that keep README links GitHub-renderable, URL-stability rules under route rewrites (a reorder keeps the published URL, a slug rename needs a redirect), per-surface index-sync rules (docs index and sidebar cover every page; a top nav bar is checked for dead entries only), and a scoped link audit that distinguishes source-file links, generator-routed site links, and asset references. The staleness audit now covers docs/ pages. Sourced from production dogfood.pre-release: the docs site is audited at every release. Step 5a's freshness audit now covers docs pages, index sync, and the link audit on docs-site repos. A new step 5c derives and runs the local docs build — mirror the repo's docs deploy workflow, else pick the package manager from the docs/ lockfile and its build script; a documented skip plus the manual link audit is the fallback when no command is derivable or the toolchain is missing. Where the generator fails the build on dead links (VitePress default), broken cross-links are caught before push instead of at deploy time.pre-release: accurate CI semantics for path-filtered workflows. Step 6 now explains that an unmatched paths filter creates no workflow run at all (not a skipped one), why that absence is correct, and why the per-SHA gate cannot prove a disabled docs workflow ran — the local build attempt is the mandatory docs check, with the CI docs run as additional coverage.pre-release: corrected fallback rationale. The "if the readme / release-notes skill isn't synced" fallbacks no longer claim tag filtering drops them — boost-requires rescues both into every sync that ships pre-release. The fallbacks now name their real audience: sync pipelines that don't honor boost-requires.Full Changelog: https://github.com/SanderMuller/boost-skills/compare/2.27.0...2.28.0
A dedicated skill for the browser pass that frontend-quality can only afford to make one advisory step. Tag-gated on frontend; projects that do not declare it see no change.
eye-verification — a command-only browser verification flow (/eye-verification). frontend-quality ends with an eye-verify step, but it sits behind type-check, lint, and tests, and is deliberately advisory: run it where a harness exists, defer it explicitly where none does. That framing is right for a quality gate and wrong for the moment the browser pass is the task — a UI change whose risk is entirely runtime, or work that has to leave proof behind for a reviewer and QA.
The new skill is that flow, and it is mandatory end to end. It resolves the testables before driving anything, in a fixed priority chain: the PR body's testing section, then the tracker issue's QA testables or reproduction steps, then a spec's edge-case table, and — when none of those exist — gathered from the diff and listed back so the coverage is visible. A section left at its template placeholder yields nothing and falls through rather than passing as a source.
It then drives every testable, including its edge cases, and reports Pass / Fail / NOT VERIFIED with the evidence that proves each one. A testable that could not be driven is named with its reason; an unqualified green over a partial pass is the failure mode the skill exists to prevent.
The last step is the one that is usually skipped: captured is not published. A screenshot proving a testable is stored durably in the repo and attached to the PR or tracker issue that already exists, rather than left at whatever local path the capture wrote it to.
Scope covers committed and uncommitted work both — this runs before the commit more often than after it, so a committed-only diff would report "nothing changed" over a full working tree of frontend edits.
The skill carries the orchestration only. The harness, the coverage contract, the traps that fake a green run, fault injection, and per-element design verification stay in frontend-quality's references and scripts, which it declares via boost-requires and points at rather than duplicating.
frontend-quality routes to it. Its eye-verify step now names the dedicated flow for changes that deserve a full mandatory pass, where the project ships it.
disable-model-invocation: true, and the description carries no activation triggers, so agents that ignore that flag do not auto-activate it either. Invoke it deliberately.frontend, the same tag as frontend-quality — a project that declares one gets both.Full Changelog: https://github.com/SanderMuller/boost-skills/compare/2.26.0...2.27.0
Bot review threads now close on the thread itself. Additive — no configuration change needed.
pr-review-feedback: every bot thread ends in one of three states. Applying the code was only half the loop: reasoning posted as one top-level PR comment left the threads showing as unresolved, so the next reviewer had to read and re-judge every one of them. Each bot thread now ends applied (reply on the thread with what changed, then resolve), declined (reply with the reasoning, then resolve), or deferred (a human took the thread over: reply that it is being worked, leave it open, and the PR goes back to draft until it closes). A top-level comment never counts as closing a thread. Self threads — your own notes-to-self — keep the lighter rule: resolving without a reply is fine. Sourced from production dogfood.
pr-review-feedback: the hard gate got harder. The final verification now pages past 100 review threads, flags threads whose comment list was truncated, verifies a deferred thread actually sits on a draft PR, and catches silent resolves — a resolve without a reply passes the unresolved-threads query, so the gate now demands proof the reply exists (the reply mutation's returned comment URL, or a by-id thread lookup). A thread the agent lacks permission to resolve is reported as blocked work, not waved through as an allowed exception.
pull-requests: one owner for draft/ready. A new Marking a PR Draft / Ready section owns gh pr ready in both directions. Marking ready has one precondition — zero unresolved bot threads, checked with a paginated query before every flip, including the auto-ready for low-risk PRs. Open colleague threads never block: they are the review conversation itself. pr-review-feedback routes its draft/ready flips through this section and now declares the dependency (boost-requires), so the two skills always sync together.
Full Changelog: https://github.com/SanderMuller/boost-skills/compare/2.25.0...2.26.0
A new opt-in guideline that settles which voice an agent writes in, per surface. Additive — a project that does not declare the voice tag sees no change.
voice guideline (opt-in, tag voice). Agent output drifts in register: a PR body reads like marketing, a Jira ticket like a stack trace, a chat reply buries the answer under three paragraphs of throat-clearing. The guideline fixes one rule per writing surface in a routing table — chat replies, PR titles and descriptions, review replies, issue and ticket text, spec files, AskUserQuestion payloads, and commit messages all take ASD-STE100 Simplified Technical English, and the guideline ships those twelve rules with it (one idea per sentence, active voice, simple tenses, everyday words, answer first, no shouting). Text an end user reads routes to the project's own tone-of-voice rules instead, so the two can never compete over the same words. A skill that defines its own voice — humanizer, readme, release-notes — keeps it, and so does prose the user asks for in a named style. The table also states the fallback for a surface it does not list, so an agent never guesses.
The guideline is always-loaded once a project opts in, which is the point: a rule that governs every reply cannot wait for a load trigger. Declare it with ->withTags([..., 'voice']) and run vendor/bin/boost sync. Sourced from production dogfood.
boost-skills now declares the voice tag itself. The catalog eats its own cooking; every reply, PR, and commit message written in this repo follows the guideline.Full Changelog: https://github.com/SanderMuller/boost-skills/compare/2.24.0...2.25.0
A conventions slot for projects that mandate a label on every PR. Optional and additive — leave it out and nothing changes.
pr.labels — a configurable mandatory-PR-label policy for pull-requests. Some organisations require every PR to carry exactly one label from a fixed vocabulary, chosen by a question the diff cannot answer: who wrote the first working version, which change class this is, which compliance category applies. There was no slot for that — pr accepted only title_format, template_path, gates and risk, and rejects unknown keys, so the policy could not even be forward-declared. The remaining option was the guideline layer, which is compiled into CLAUDE.md / AGENTS.md and loaded in every session, so a rule that only matters when a PR is created cost tokens on every unrelated task.
Declared in boost.php, the policy renders inside the pull-requests skill instead, where it is read only when that skill activates:
'pr' => [
'labels' => [
'require_exactly_one' => true, // false ⇒ at most one
'exempt_bot_authors' => true, // skip for Dependabot & friends
'rule' => 'Who wrote the first working version of the main change?',
'rule_doc' => 'docs/pr-label-policy.md', // optional prose
'options' => [
['name' => 'Label A', 'when' => 'criterion for A'],
['name' => 'Label B', 'when' => 'criterion for B', 'on_doubt' => true],
],
],
],
The slot carries the mechanism only. Label names, the deciding question, and the policy prose are yours — no vocabulary and no semantics are fixed by the package, and options has no mandated length beyond needing at least one entry.
The skill applies the name verbatim. These vocabularies are usually aggregated outside the repo, where a translated or re-cased name does not fail loudly; it just stops counting, and the repo drops out of the aggregation unnoticed.
How the label is decided: the agent answers rule from first-hand knowledge when the work happened in the session, treats repository evidence (commit history, trailers, the diff) as an input rather than an answer when the branch predates it, and asks the author otherwise — batched into the existing pre-PR AskUserQuestion call alongside the risk and description-direction questions. on_doubt marks the option an uncertain author falls back to; the agent may not use it to skip asking. A resolved label reaches the PR via gh pr create --label.
The package applies the label, it does not enforce it. Nothing here blocks an unlabelled PR — add a CI check on the PR event if you need a hard gate.
final-verification-review reports the label policy in its closeout check. A configured mandate is now visible before the PR exists rather than at creation time. An unresolved label is a note, since the pre-PR question resolves it; only a config that cannot be satisfied — an empty options list, or several options claiming on_doubt — is reported as blocking.
pr.labels declared, both skills render an explicit no-op and there is no label step. Existing configs are unaffected.schema-version bump. This is additive to v1; schema-version stays 1.pr.risk. A risk tier's own label is routing metadata applied by tier score; pr.labels is an author-declared policy. Declare either, both, or neither — with both, a PR carries both labels.Full Changelog: https://github.com/SanderMuller/boost-skills/compare/2.23.1...2.24.0
Fixes four ways the dangling-symbols.sh companion introduced in 2.23.0 could report a clean sweep on a merge that had a real dangling reference. If you are on 2.23.0, upgrade — a check that silently passes is worse than no check, because resolve-conflicts tells you to trust its result.
No dangling references and exit 0 against a repository that provably had one:
grep.patternType=extended — the word-boundary \b is a GNU regex extension that matches nothing under ERE, so every symbol lookup came back empty. The lookup now uses git grep -w -F: -w is a git option rather than a regex feature, and -F treats the symbol as the literal identifier it is. Verified against the basic, extended, fixed and perl pattern types.color.diff=always / color.ui=always — ANSI escapes prefixed every line, so the ^- and ^+ matching that finds removed declarations stopped working. Closed with --no-color.diff.external, and the GIT_EXTERNAL_DIFF environment variable — an external driver replaced the diff output entirely. Closed with --no-ext-diff.textconv driver bound through .gitattributes — content was rewritten before diffing, so a symbol could be transformed out of the diff. Closed with --no-textconv.die was being called from inside a pipeline subshell, where exit terminates only that subshell; the script printed its error and then fell through to No dangling references with exit 0. Both diffs are now collected in the main shell, so a git failure exits 2.resolve-conflicts no longer falls through to the commit phase on a fast-forward. The fast-forward outcome noted that nothing needed verifying but omitted the explicit stop its sibling outcome carries, leaving a path that reached the commit phase with an empty tree.Full Changelog: https://github.com/SanderMuller/boost-skills/compare/2.23.0...2.23.1
resolve-conflicts now owns the whole merge rather than just the conflicted parts of it, and verifies the cases git reports as clean. Every git behaviour below was checked against real repositories before being written down; two claims the skill previously made turned out to be wrong.
resolve-conflicts, with a shipped companion. A merge can combine both sides cleanly and still leave code that no longer agrees with itself — one side renames a declaration while the other adds a reference to the old name. Git reports no conflict, and a diff against either side looks exactly as it should, because the removal and the stale reference never appear in the same comparison. The new scripts/dangling-symbols.sh companion sweeps both directions (they removed something you call, and you removed something they call) and reports surviving references. Retarget it at any language with --keywords; --help documents the rest.bash -n syntax gate for shipped .sh companions, mirroring the existing node --check path for .mjs assets.resolve-conflicts merges with --no-commit. A conflict-free merge previously committed itself before any of the prescribed verification ran, leaving a failed check fixable only by amending or resetting. Conflicted and clean merges now behave identically: the merge stays staged until the commit phase. Fast-forwards are unaffected and need no verification.DU/UD) carry no <<<<<<< markers — git leaves the surviving side's content in place, so deciding what is left to resolve by grepping for markers skips those files entirely while they look finished. Conflicts are now enumerated by status code, with the opposite side read through git show :N:.pull-requests, pr-review-feedback, and jira-rework route their whole base-sync merge through resolve-conflicts, not just the conflicted case. Each previously restated the post-merge verification itself, precisely because a clean merge never reached the skill. All three now declare boost-requires: resolve-conflicts.merge-tree exit taxonomy in resolve-conflicts. Unrelated histories exit 128 with fatal: refusing to merge unrelated histories, not exit 1 with the not something we can merge message the skill attributed to them. Exit 128 is now documented as its own case, covering both that and the rejected --quiet + --name-only combination.Full Changelog: https://github.com/SanderMuller/boost-skills/compare/2.22.0...2.23.0
Two review-quality disciplines: trace behavior claims to real code before writing them, and check what was built against what was actually required.
CLAUDE.md / AGENTS.md): a claim about how the code currently behaves — a root cause, an existing mechanism, present behavior — must be traced to real code or a runtime observation before it's written into a spec, PR, commit, review, issue, or comment, and no illustrative example may be invented. Intended behavior a spec proposes as a requirement is exempt. Stops one unverified guess from seeding a whole ticket's context and tests on a false premise.code-review — fetch the real requirement (the spec's goals, technical sections, and edge cases; un-superseded linked-issue criteria; or the task itself), then verdict each requirement requirement-down (Met / Partial / Unmet), and scope-check for implied requirements, unrequested extras, silent interpretations, and side effects. The diff shows what was built, never what was forgotten.implement-spec now walks the requirements before final verification — task checkboxes track tasks done, not requirements met, so a required behaviour no task mapped to is otherwise never caught. It verifies each requirement against real code, then runs the full quality gate last so that gate covers anything the walk changed.Full Changelog: https://github.com/SanderMuller/boost-skills/compare/2.21.0...2.22.0
clean-specs skill (command-only, /clean-specs) — a post-merge net that removes spec files whose work is fully shipped: every task box checked and a title/branch-matched, un-reverted merge commit that is an ancestor of the base branch. Conservative by design — it leans toward keeping a spec on any ambiguity, reports and asks for confirmation before deleting, re-checks eligibility against fresh state, and ships the removal as a reviewable PR.pull-requests now removes the implemented spec as a detect-and-verify step, not a from-memory delete. It finds the branch's spec from the diff against the base, removes it, and verifies no unrelated spec was swept in by a broad git add -A — closing the path by which implemented specs reached the base branch. Unrelated specs that were swept in are restored without discarding local content.implement-spec cleanup defers spec removal to that step instead of hand-deleting, and points at /clean-specs as the post-merge backstop.clarify, write-spec, and implement-spec now delegate multi-file research sweeps to a read-only research subagent, keeping the main working context small on research-heavy flows.Full Changelog: https://github.com/SanderMuller/boost-skills/compare/2.20.0...2.21.0
clarify skill — the shared questioning core: code-first exploration,
bisect-to-intent, fuzzy-term sharpening, scenario stress-tests, and an
assumptions audit. Usable standalone (/clarify) or as the base other skills
build on.promptimize skill — turns a rough prompt into one optimized,
model-agnostic prompt and returns only the prompt. Builds on clarify.frontend-quality — a shipped scripts/lib.mjs
helper library (createChecker, capturePageIssues, withFailedRoute) and a
references/eye-verify.md coverage-contract guide, so a project gets
browser-verification plumbing without building its own. console.mjs gained an
--axe accessibility/contrast pass, screen-reader-attribute leak scanning, and
application-request (xhr/fetch) failure gating.write-spec phases now declare an
immutable ID and Depends: edges; implement-spec computes each ready
"wave" and can implement independent phases in parallel under an explicit
opt-in, with write-disjoint and DAG-validation safeguards. Specs without the
new metadata fall back to the existing sequential behaviour.interview now builds on clarify (declares boost-requires: clarify) —
the grilling disciplines live in one place instead of being duplicated across
skills.migration-squash is now invoke-only (disable-model-invocation: true).
It no longer auto-activates on incidental mentions of migrations or
schema:dump; run it explicitly (/migration-squash) or by directly asking
for a squash. This matches its destructive nature — a squash deletes migration
files.validate-skills.php now runs node --check over every shipped
*/scripts/*.mjs companion asset, not only the codex-review wrapper.boost-requires skill-dependency system in the README.Full Changelog: https://github.com/SanderMuller/boost-skills/compare/2.19.0...2.20.0
Activates the skill dependencies declared in 2.18.0. That release shipped the
metadata.boost-requires declarations but they were inert on the engine
available at the time; boost-core 1.4.0 resolves them, so this release raises
the floor to require it.
sandermuller/boost-core ^1.4 (raised from ^1.3).
boost-core 1.4.0 resolves metadata.boost-requires: whenever a skill ships,
every skill it hands off to ships too, and a required skill that a consumer's
tags would otherwise drop is rescued in (transitively, surfaced as an INFO
diagnostic). Pinning the floor here makes the co-shipping guarantee real for
every consumer instead of best-effort. 1.4.0 is additive and backward
compatible, and the catalog already required ^1.3, so the step is small.
Authoring guidance for boost-requires lives in boost-core's README.No skill content changed — the declarations themselves shipped in 2.18.0.
Full Changelog: https://github.com/SanderMuller/boost-skills/compare/2.18.0...2.19.0
Six skills now declare their hard dependencies in frontmatter, dogfooding the
skill-dependency system boost-core is building. Once that engine lands,
selecting a skill will co-ship every skill it hands off to — a dependency the
tag filter would otherwise drop gets rescued, so a skill never delegates to
something that isn't there. This release ships the declarations only: they are
inert under the current engine (boost-core ^1.3 ignores the unknown
metadata.boost-requires key, verified against the shipped engine), so it is
safe ahead of the resolver and changes nothing for consumers until they run a
dependency-aware boost-core. Everything is additive — no skill removed or
renamed.
Skill dependency declarations (metadata.boost-requires). Space-delimited
bare skill names, mirroring boost-tags. Six skills declare their hard
hand-offs:
interview → write-specbug-fixing → test-writingevaluate → code-review codex-reviewfinal-verification-review → evaluate codex-review pull-requestspre-release → readme release-notes upgradingjira-rework → jira-updatesOnly hard hand-offs — where a skill's flow invokes another skill — are
declared. Conditional and routing references stay undeclared on purpose:
jira-create / jira-updates only cross-reference each other for routing,
and capability-gated mentions like backend-quality / frontend-quality are
scoped by tags, so declaring them would rescue tooling into projects that do
not want it.
The declarations were derived from a body-reference audit of the catalog and
validated against boost-core's ship-closure design, then dogfooded through
this repository's own review flow before shipping.
Full Changelog: https://github.com/SanderMuller/boost-skills/compare/2.17.0...2.18.0
frontend-quality/scripts/, emitted as boost-core 1.3
companion assets). Three framework-agnostic tools so a project stops rebuilding the plumbing:
screenshot.mjs — navigate a running app, optionally crop to a --selector with ≥15px
padding (clamped to the page), save a PNG.console.mjs — record console errors/warnings, uncaught page errors, and failed requests;
--text-pattern scans rendered text for a project-supplied leak regex (e.g. untranslated-key
markers); --fail-on-error gates.auth-capture.mjs — the portable auth seam: open a headed browser, log in by hand, save a
Playwright storageState the other two reuse via --storage-state. Knows nothing about any
login form, so it works for any app.
Playwright is a project prerequisite (npm i -D playwright && npx playwright install chromium);
each tool fails fast with that hint if it's absent. What stays per-app is only genuinely
app-specific glue (programmatic SSO login, data seeding, domain drivers)..github/validate-catalog.php). The format validator never
checked that the catalog's own tables agree with what ships; the new gate enforces README
Skills/Guidelines tags vs each skill's metadata.boost-tags, skill/guideline inventory,
the guideline tag sidecar, the documented tag vocabulary, boost:conv tokens vs real
conventions-schema.json slots, and schema-required vs conv usage.frontend-quality/references/design-verification.md).
The full per-element scoring rubric — attributes incl. shadow/elevation, line-height,
letter-spacing, tap-area; the "undocumented difference is a finding, not a deviation" rule;
image-sampling to the nearest project token when there's no token spec; and a ✓/✗ scoring table.codex-review replaced the plugin path with a bounded native-CLI wrapper. The Codex
plugin's companion awaited a turn/completed event with no timeout and hung on stale broker
sessions. The skill now ships scripts/run-codex-review.mjs (a companion asset) that runs the
bare codex CLI under a hard timeout — it cannot hang and cannot read a stale prior run's
output. The wrapper adds an env-configurable timeout (CODEX_REVIEW_TIMEOUT_MS, floor 1000ms;
--timeout-ms wins) and a no-flag target fallback that infers the review target from the repo's
default branch. codex.invocation_mode is deprecated and ignored (retained in the schema so
existing configs keep validating).frontend-quality gained a "seed the off-by-default state before
capturing" step and points at the shipped harness as the primary capture path; pull-requests
documents private-repo image embedding (a committed PNG's ?raw=true blob URL renders inline
for authenticated members; a browser drag-drop user-attachments URL is the no-file fallback;
data: URIs are stripped by GitHub). The javascript guideline was slimmed to the always-on
principle plus a pointer, so the detailed rubric lives on-demand rather than in every project's
CLAUDE.md.pre-release now documents its
release-automation tag (a consumer declaring only php+github would not have received it);
jira-updates drops a github tag it never carried in frontmatter; and the shipped
signed-commits guideline gets its missing row in the Guidelines inventory.Repository-only; none ship to consumers (all under export-ignored paths or dev config):
composer install runs --no-scripts --no-plugins on the fork-exposed pull_request job.composer ecosystem, not just GitHub Actions.stolt/skill-validator pinned exactly (0.0.1; the ^0.0.1 caret resolved to the same version)..mcp.json pointing at a vendor/bin/testbench boost:mcp command this package
does not provide.The codex, eye-verify, and design-verification work was sourced from the upstream catalog and production adoption feedback, then dogfooded through this repository's own evaluate and codex-review flow before shipping.
Full Changelog: https://github.com/SanderMuller/boost-skills/compare/2.16.1...2.17.0
interview and write-spec no longer instruct a redundant manual "Other" option in assumption audits. Both skills told the agent to add an explicit "Other / let me clarify" choice to each AskUserQuestion audit prompt, but AskUserQuestion already appends its own free-text "Other" — so prompts rendered two semantically identical escape hatches. The instruction now drops the manual option and notes the tool supplies one. This also removes the "let me clarify" first-person pronoun, aligning the wording with the ask-user-question guideline shipped in 2.16.0.Full Changelog: https://github.com/SanderMuller/boost-skills/compare/2.16.0...2.16.1
A frontend-quality release: first-class frontend testing and browser eye-verification join the catalog, a new Laravel migration-squash skill and an always-on AskUserQuestion guideline ship, and codex-review is hardened against the plugin hangs that have stalled reviews. Everything here is additive — no skill or guideline was removed or renamed, no conventions slot or schema-version changed, so a consumer upgrading from 2.15.0 keeps every existing behavior and simply gains the new content (tag-gated where noted).
frontend-quality now runs the project's JS/TS test suite (Vitest / Jest / …) as a third check alongside type-checking and linting — scope to the changed area during development, full suite at completion, and cover changed logic with a test. test-writing and bug-fixing gained framework selection for JS/TS runners (auto-detected from package.json), so a frontend bug is reproduced with a failing JS test the same way a backend one is. (frontend tag.)javascript guideline gains an "Eye-verify frontend changes" section, frontend-quality a suggested eye-verify step, pull-requests an advisory pre-PR gate, and bug-fixing / write-spec reference it for visual fixes and UI-feature success measures. Includes per-element / per-attribute design verification (don't eyeball the whole image), ~15px padding around single-element screenshot crops, ephemeral-clone host targeting (a worktree may be served elsewhere — a hard 404 means the wrong host), and PR screenshot mechanics (embed in the PR body, commit a file rather than a base64 data: URI that hosts strip, include the approved design alongside; a harness that can't run this session is a tracked deferral, not a silent skip). Generic — a project supplies its own browser harness (commonly tools/verify/) or a Playwright MCP server.migration-squash skill (laravel tag). Create or review a Laravel migration squash (schema:dump --prune into a single schema baseline) with a verification checklist that catches the defects squash PRs actually ship with: an incomplete dump (DB behind the target), a contaminated dump (a migration applied from an abandoned/local/renamed branch), and a pruned data-migration whose seeded rows vanish on a fresh DB because schema:dump captures structure, not rows. The completeness and contamination checks compare the dump's records against the target's baseline records ∪ migration files — so legitimate history whose files earlier squashes pruned isn't false-flagged. Defaults to the standard mysql-schema.sql (the .dump rename is an optional project variant), keeps the review steps host-neutral, and defers destructive operations to the database-safety guideline.ask-user-question guideline (always-on). In AskUserQuestion the user reads a question from the assistant, so first/second-person pronouns are ambiguous — the guideline says to name the actor explicitly ("the assistant" / "the user") or drop the pronoun, across the question text, every option label, and every option description.codex-review hardened against Codex plugin hangs. The companion awaits a turn/completed notification with no timeout, so a dropped event (broker/version skew, an untrusted ephemeral clone path) could hang a review forever. The skill now clears stale brokers in a preflight before every launch, treats a poll-loop timeout as a hang and recovers via the synchronous bare-CLI path (immune to the hang) rather than reading a stale result, and calls out that ephemeral clone paths (e.g. polyscope) aren't auto-trusted — trust the dir first.pull-requests (a new preflight item plus a sync step in the work-on-existing-PR flow) and jira-rework now merge the resolved base in before pushing, so CI tests the branch against the latest target rather than a stale base — closing a conflict/break class that a green CI run can otherwise hide. The PR analysis compares against the just-fetched origin/<base>. pr-review-feedback already did this.evaluate. Phase 3 keeps a comment only when, without it, a competent reader would draw the wrong conclusion or break the code on edit — a real-but-inferable why belongs in the tracker, not inline. Adds a density signal: more than one surviving comment in a single function is a smell that the code wants splitting or renaming.pull-requests Low/Medium/High block now weighs risk after the checks that run on every change (tests, CI, QA, reviewers): a loud, reversible failure ranks below a silent or irreversible one, and a narrow, well-tested change on a shared path isn't automatically high risk. Projects with pr.risk tiers still delegate scoring to their own matrix.The frontend-testing and eye-verification work and the skill refinements were sourced from upstream and production adoption feedback, then dogfooded through this repository's own evaluate, codex-review, and release flow before shipping.
Full Changelog: https://github.com/SanderMuller/boost-skills/compare/2.15.0...2.16.0
pr-review-feedback now activates on how the team actually asks. The skill's trigger description previously only matched the formal "apply review feedback" wording. It now recognises terse, real-world phrasings — "fix the comments", "fix PR comments", "fix review comments", "fix comments issue 1234" — plus the Dutch "verwerk de comments" / "comments fixen". The description was also trimmed back to a single trigger list (it had grown to two overlapping lists).1234 may be the PR or the issue the PR was created for. Phase 0 probes GitHub to classify the number, and when it's an issue, finds the linked open PR (by branch prefix, then by an explicit issue reference in the PR body) before any feedback is gathered. When more than one PR matches, or none, it lists the candidates and asks rather than guessing.Full Changelog: https://github.com/SanderMuller/boost-skills/compare/2.14.0...2.15.0
pull-requests, bug-fixing, test-writing, backend-quality, the Jira skills, and the rest) wrap each slot as <!--boost:conv …-->default value<!--boost:conv:end-->. boost-core still resolves the whole span to the configured value at sync time; an engine that does not resolve boost:conv — notably laravel/boost — now shows the default value as readable text rather than a gap where the value was previously hidden inside a comment attribute. Requires boost-core ^1.2.1 — the paired form needs the 1.2.1 engine, and the floor skips the empty 1.2.0 tag.pre-release and release-notes hardened against premature and empty releases. Adds an explicit PR-based release flow (merge → re-run CI on the post-merge commit → draft notes → tag; a green feature-branch CI is not the release gate); treats a pre-existing or placeholder-SHA notes file as "no notes yet" (delete and redraft, never edit in place); makes the step-8a pre-tag gate agent-run with a content-presence check that the release's PR is actually merged; and makes the release flow release-branch-aware instead of hardcoding main.Full Changelog: https://github.com/SanderMuller/boost-skills/compare/2.13.0...2.14.0
humanizer now catches the AI tells that survive a vocabulary swap. The skill's Wikipedia-based foundation handled the encyclopedic register; this release grafts the rhetorical and structural patterns from the MIT-licensed stop-slop by Hardik Pandya, which target the punchier "AI blog post" voice. Nine new patterns (#30–#38) cover false agency (abstractions given human verbs to hide who acted), narrator-from-a-distance, throat-clearing openers, dramatic fragmentation, lazy extremes, performative emphasis, business jargon, Wh-openers, and engineered "quotables"; the negative-listing striptease folds into the existing parallelism pattern. Two tools come with them: a Quick Checks pre-delivery pass and an optional five-axis scoring rubric. The new rules are scoped so they don't degrade neutral reference docs — README, API docs, and release notes keep their third-person, impersonal voice and evidentiary phrasing ("the benchmark shows" is not false agency). Untagged, so it applies to any project's prose. Additive under conventions schema-version 1 — no breaking change.Full Changelog: https://github.com/SanderMuller/boost-skills/compare/2.12.0...2.13.0
pr-review-feedback now reliably resolves threads, not just applies the code. A "close the loop" finish-line plus a new Phase 7 hard gate re-query the PR and assert zero unresolved bot/self threads remain (colleague threads stay gated). Resolving each bot/self thread is now mandatory, thread IDs are re-fetched if they scroll off, and the skill's triggers gained Copilot / CodeRabbit / "resolve threads" so natural-language asks discover it. Fixes feedback being applied while the review threads were left open. Additive under conventions schema-version 1 — no breaking change.Full Changelog: https://github.com/SanderMuller/boost-skills/compare/2.11.0...2.12.0
Five workflow skills gained a named anchor concept (a "Leitwort") that recurs through the skill, with one key step reframed as a gate the agent can't rationalise past. The writing skills picked up a shared prose trio. All additive under conventions schema-version 1 — no new convention slot, no breaking change.
bug-fixing now anchors on the red test / red-green-refactor: no production edit until a red test reproduces the bug (with a carve-out for defects that genuinely can't be expressed as an automated test).code-review anchors on proportionality and code health over time — match each finding to its real impact, review for net improvement, and cut findings that don't earn their line.test-writing frames every test as an executable specification (the name reads as scenario + outcome) and names the assertion roulette smell — one behaviour per test, not the "one assertion per test" misreading.resolve-conflicts names the semantic conflict — a clean textual merge that still drops one side's behaviour — and gates the verify phase on preserving both intents.ux-review adds the principle of least astonishment as a justify-don't-reject gate: novel UI is allowed, but must be justified against user expectation.pull-requests names its existing why, not what rule and adds omit needless words; release-notes and readme adopt omit needless words; readme and humanizer adopt curse of knowledge (write for a reader who lacks your context).Full Changelog: https://github.com/SanderMuller/boost-skills/compare/2.10.0...2.11.0
The pr-review-feedback skill now treats a test as part of fixing a bug, not an afterthought. When review feedback flags a runtime fault or an edge case, the skill writes a failing test that reproduces it before applying the fix, then verifies at quality-check time that every fix is covered. Additive under conventions schema-version 1 — no new convention slot, and pure style/refactor feedback still needs no test.
pr-review-feedback — a bug or edge-case fix now requires a test. Phase 3 (Apply Changes) gained a step: when a comment flags a runtime fault (a wrong type, a bad boundary condition, a feature/permission edge, a regression), add a failing test that reproduces it before touching the fix, then make the change so the test passes. Phase 4 (Verify Quality) was reframed from "add a test" to "confirm every fix is covered" — it now verifies the regression/edge-case test exists and passes rather than merely suggesting one. The style/refactor carve-out is preserved: cosmetic feedback needs no new test, only that existing tests still pass.project-boost slug to project-boost-php. A guideline reference pointed at the old package slug; downstream readers following it would have hit the wrong name.Full Changelog: https://github.com/SanderMuller/boost-skills/compare/2.9.0...2.10.0
An issue-resolution preflight for the pull-requests skill, so a PR is never opened without a tracker issue behind it unless the change is a deliberate chore. Surfaced while tightening a downstream application's issue workflow, where PRs were landing with no linked issue because nothing in the flow asked for one. Additive under conventions schema-version 1 — a project whose branch patterns carry no {issue_key} placeholder sees no new step, and no new convention slot is introduced.
pull-requests — issue-resolution preflight. A new first preflight item runs only when the project's branch patterns include an {issue_key} placeholder (i.e. the project links PRs to a tracker). It resolves the issue before the branch is named, since the key feeds the branch name, the PR title, and the template's issue reference. The branch's existing key is reused when present; an issue known from the conversation is confirmed against the tracker; otherwise the user is asked — via a single AskUserQuestion — to name an existing issue, create one on the spot, or proceed as a chore against a no-{issue_key} branch pattern (e.g. chore/{slug}). A project whose patterns carry no {issue_key} placeholder skips the step entirely.pull-requests — tracker-aware issue verification and creation. A dedicated step splits the resolution path by key style so the right tool is used: a bare GitHub issue number goes through gh issue view / gh issue create, while a Jira-style key (HPB-1234) goes through the read-only jira_get_issue MCP tool to confirm and the jira-create skill to open one. gh issue is never run against a non-GitHub key, and jira-updates is explicitly excluded — it is a post-PR mutation flow, not a pre-PR lookup.pull-requests — branch-rename and title guidance now issue-aware. The branch-pattern preflight step folds the resolved issue key into the suggested rename when an {issue_key} pattern applies (e.g. feature/1234-add-export). The PR-title placeholder docs no longer assume a Jira-style key: {issue_key} resolves a Jira-style key (HPB-1234) or a bare GitHub issue number (1234) depending on the project's patterns. The empty-placeholder rule trims an adjacent dash or # and drops any brackets left wrapping nothing, so a chore PR title reads cleanly ([#{issue_key}] {short_title} → Add export when there is no issue).The change was dogfooded through a downstream application's PR flow, then reviewed (including an external Codex pass) before shipping.
Full Changelog: https://github.com/SanderMuller/boost-skills/compare/2.8.0...2.9.0
Two refinements to the php/github-tagged skills, both surfaced while migrating a downstream application onto the project-boost family. The backend-quality test-runner substitution is now complete end-to-end, and a new opt-in quality.rector convention slot gives Rector a home in the completion and PR-preflight flows. Additive under conventions schema-version 1 — a project that declares nothing sees no behavior change.
backend-quality — runner substitution now covers every command. The configured test runner (testing.backend_framework) was previously substituted only in the intro prose; the Tier 1 / Tier 2 command blocks and the Quick Reference table hardcoded vendor/bin/pest. On a phpunit-configured project that pointed the agent at a binary that does not exist, and the intro's "if your runner is phpunit, run phpunit instead" disclaimer was a weak patch against the commands actually followed. Every command block and table cell now resolves the runner at sync time, and the full suite prefers the project's composer test script when one is defined.quality.rector convention slot. A new optional boolean. When quality.rector: true, backend-quality's completion tier and the pull-requests preflight run vendor/bin/rector process to completion before Pint, then re-run Pint (Rector's output is not style-clean, so it always needs a Pint pass after). The slot is strictly opt-in — the step is never triggered by Rector merely being present in the dependency tree or by a stray rector.php, so adopting the catalog changes no existing project's flow. The ordering rule (Rector before Pint; always Pint after Rector) is encoded in both skills, and the PR preflight uses the same scoped pint --dirty --format agent invocation as backend-quality.The changes were dogfooded through this repository's own evaluate → codex-review → release flow before shipping.
Full Changelog: https://github.com/SanderMuller/boost-skills/compare/2.7.0...2.8.0
A code-brevity lens folded into the evaluate self-review loop and the code-review skill, inspired by the "lazy senior developer" pattern — stop at the first viable solution, and prefer the standard library, a native or framework feature, or an already-installed dependency over hand-rolled code. The family already pushed hard on correctness, style, and convention; this adds the missing pull toward writing less. It rides the existing review-and-fix loop rather than a standalone always-on guideline, so a project whose code is already lean sees no change.
evaluate — over-engineering review row + brevity floor. Phase 2's review table gains an Over-engineering category: unrequested abstractions, speculative generality, premature flexibility, and hand-rolled code a stdlib/native/framework feature or installed dependency replaces — anything deletable without losing required behavior. A "brevity has a floor" guardrail sits directly under the table: shortening code is a win only when nothing required is lost, and validation at trust boundaries, error / data-loss handling, security, accessibility, explicitly-requested functionality, and tests for non-trivial logic are never traded away to shrink code. Findings flow through the existing Phase 4 fix loop like any other.code-review — sharpened Code Quality bullet. The soft "Unnecessary complexity" line becomes an Over-engineering lens carrying the same floor, so the structured fresh-eyes pass (run as evaluate's Phase 6 and standalone) checks brevity independently of the self-review.The lens was dogfooded through this repository's own evaluate → review → release flow before shipping.
Full Changelog: https://github.com/SanderMuller/boost-skills/compare/2.6.0...2.7.0
Three handoff-hardening guards for the write-spec → implement-spec pair, adapted from the /improve skill's plan/execute model. They tighten what happens when a spec is implemented later than it was written, when a load-bearing assumption turns out to be false mid-implementation, and when a test passes without actually exercising the change. All additive under conventions schema-version 1 — no new slots, and a spec written before this release implements exactly as before.
write-spec / implement-spec — drift detection. write-spec now stamps the commit a spec was planned against (<!-- spec:planned-at <sha> <date> -->) directly under the title, with a +uncommitted marker when the working tree was dirty and a refresh rule for Conversion Mode. implement-spec runs a drift preflight at the start of every invocation and resume — not just the first phase — using single-ref git diff <sha> so it catches both committed changes and the implementer's own uncommitted edits to cited files. On a material mismatch it stops and surfaces the stale file:line rather than building against moved line numbers; a missing stamp (older specs, non-git) simply skips the check.write-spec / implement-spec — STOP conditions. write-spec derives a ## STOP Conditions section from the load-bearing subset of the assumptions ledger — an actionable view, not a competing record, so the ledger stays the single source of truth. implement-spec reads it when present (absent on pre-2.6 specs, which is not an error) and gains a documented-vs-undocumented deviation contract: a minimal deviation logged in ## Findings with rationale is acceptable; an undocumented one is a failure, and a triggered STOP condition halts implementation.implement-spec — test-assertion guard. Because a single agent both writes a spec's tests and checks its own boxes, the skill now requires each test to assert the spec'd observable behaviour — a green test that exercises nothing is not coverage. Confirm the assertion would fail without the change before checking the Tests box.The changes were dogfooded through this repository's own write-spec → implement-spec → review → release flow before shipping.
Full Changelog: https://github.com/SanderMuller/boost-skills/compare/2.5.0...2.6.0
A trio of skill refinements around the review-and-merge flow: self-review feedback now auto-applies, the feedback flow syncs the branch with its base before touching code, and conflict detection moved earlier so it can run without side effects. All additive under conventions schema-version 1 — no new slots, and a project that never reviews its own PRs sees the same behavior as before.
pr-review-feedback — self-review comments auto-apply. Thread authors now fall into three roles instead of two: self (the authenticated gh api user login), bot, and colleague (any other human). A thread is auto-handled when every comment in it is from a bot or from you, so the common loop — open your own PR, leave notes-to-self, then run the skill — now picks those notes up, evaluates them, and applies/replies/resolves automatically, exactly like bot feedback. Another human commenting anywhere in the thread still flips the whole thread to colleague and back behind the colleague_gate. Previously a self comment was treated as a colleague thread and gated.pr-review-feedback — Phase 1b base-branch sync. Before applying feedback, the skill now brings the PR's base branch in, so changes land on top of an up-to-date branch rather than one that has drifted. It checks for a clean working tree, probes for conflicts without side effects, and hands off to resolve-conflicts when the merge would conflict — with an old-Git fallback and a note that thread line numbers go stale after the merge (match by diffHunk, not line).resolve-conflicts — Phase 0 side-effect-free conflict detection. A new first phase finds out whether a merge will conflict and which files without touching the working tree: git merge-tree --write-tree locally (with the exit-code semantics spelled out — 0 clean, 1 split into conflict-vs-error by stdout, 128 for the --quiet+--name-only combo), or GitHub's GraphQL mergeable / mergeStateStatus when only a PR number is in hand (including the UNKNOWN-is-async caveat). This is what pr-review-feedback's Phase 1b probe hands off to.The refinements were sourced from real-world adoption feedback and dogfooded through this repository's own review and release flow before shipping.
Full Changelog: https://github.com/SanderMuller/boost-skills/compare/2.4.0...2.5.0
Two new optional conventions slots and a batch of skill refinements drawn from real-world adoption. Everything here is additive under conventions schema-version 1 — a consumer that declares neither new slot, and existing slot-aware skills, behave exactly as before.
fixtures.anonymization conventions slot — an optional anonymization gate, consumed by the evaluate skill (and inherited by final-verification-review), that guards a publicly-shipped package against leaking proprietary product domain — real entity/class names, table/column names, route keys, domain jargon, copied comments — through code samples and fixtures. Declare a guideline pointer (the policy prose lives in your own always-on guideline, not the slot), a scope (default ['tests/', 'src/'] — src/ ships in the dist archive, so its code samples are the worst leak surface), and an optional forbidden_terms denylist for a deterministic fast-path. Absent ⇒ no check, no behavior change. Mirrors the translations gate's knobs-in-slot / prose-in-guideline split.review conventions slot — optional PR review-feedback configuration for the pr-review-feedback skill: extra bot_reviewers logins (extends the built-in automated-reviewer set rather than replacing it) and a colleague_gate on/off toggle. With the gate on (default), a human colleague's review threads are never auto-acted on; turning it off opts a project into full automation. Absent ⇒ built-in defaults.final-verification-review — the closeout skill is now flow-aware. Alongside the existing PR flow it supports projects that ship by committing directly to a target branch (optionally cutting a release): the branch and work-state checks adapt, the gates stay flow-agnostic, and the verdict points at the matching next step (a PR, or a commit and pre-release).pull-requests — expanded the description guide with a per-change-type "how much to say" table and a plain-language / no-AI-mumbo-jumbo section (compound-noun stacks, metaphors, and diff-jargon are out), cross-referencing the humanizer skill. Before drafting a description the skill now asks the author for a direction — what the PR's headline is — batched with the risk question in a single prompt.pr-review-feedback — sharpened the bot-vs-colleague classification: a thread counts as a bot thread only when every comment in it is from a bot, so one human reply flips the whole thread to colleague (and a thread whose comments were truncated fails safe to colleague). Configurable via the new review slot.interview — rewritten from a structured-questionnaire flow into an adversarial grilling flow: read the codebase before asking, one question at a time with a recommended answer, sharpen fuzzy terms, stress-test rules with concrete edge cases, cross-reference stated behavior against the code, and a final assumptions-and-fuzziness audit so a spec can be signed off without an end-to-end read.write-spec — added a requirements-settled gate (bounce back to interview when the ask is still fuzzy, judged after loading issue context), a research-before-writing checklist, an Assumptions Audit with an ## Assumptions ledger, and a light "spec already exists" conversion mode.jira-create / jira-updates — functional edge cases now become dedicated QA-testable blocks, sourced from the spec's ## Edge Cases table or the PR's edge-case list; technical-only edges stay out of the issue tracker.evaluate — runs the new fixtures.anonymization check as part of its review phase when the slot is configured.The skill refinements were sourced from upstream and production adoption feedback, then dogfooded through this repository's own closeout and release flow before shipping.
Full Changelog: https://github.com/SanderMuller/boost-skills/compare/2.3.0...2.4.0
final-verification-review skill — a thin pre-PR closeout orchestrator for the moment work is done and a PR is next. It runs the full evaluate loop (including the Codex review per its dedup rules), then dry-runs the pull-requests preflight check-only — branch/base resolution with the rename/stop semantics mirrored from pull-requests, work state, the project's pr.gates, and title-format/template preconditions — and ends in a single READY / NOT READY verdict with the exact missing items. It never creates the PR; that stays pull-requests' job. Orchestrates without duplicating: code verification belongs to evaluate, gate definitions to pull-requests. Tagged github; reads the existing branches.patterns, github.default_base_branch, and pr.gates slots.codex-review hardened with a re-review loop. A review is stale the moment a fix changes a file, so the skill now re-runs the review after applying fixes until a round comes back clean — with explicit stop rules (a clean round is final, a dismissals-only round is final, capped at 3 rounds) and scope-aware re-review semantics so committed-work reviews see the fix commits while working-tree reviews never sweep the user's uncommitted work into a commit. Also new: a sibling sweep (an accepted finding that reveals a bug class triggers a scan of the reviewed scope for other instances) and an engine-fidelity rule (retry the same engine on capacity/transient failures; never substitute another reviewer or fall back to self-review).evaluate Phase 7 (Codex review) generalized. The manual-invocation-only carve-out is gone: the external review now applies regardless of how evaluate was invoked, with a dedup-based skip that mirrors the pull-requests gate's since_last_code_change freshness window — any task file counts (code, docs, skills, config), not only code, so docs-only changes can no longer slip past a stale review. An unrunnable Codex review is surfaced in the report instead of silently skipped.evaluate and final-verification-review. Subagent support is now near-universal across the synced agents but with divergent semantics (barrier-style, explicit-request-only, serial delegation), and the Agent Skills spec defines no orchestration vocabulary — so both skills describe parallelism as portable prose intent: read-only fan-out only, fixes always serial in the main context, no nesting, the sequential order stays canonical, and a scripted workflow feature is an optional escalation rather than a dependency.The closeout-loop patterns (re-review-until-clean, bug-class sweep, engine fidelity) were informed by studying the public openclaw/agent-skills autoreview skill and validated through dogfooding on this repository's own release flow before shipping.
Full Changelog: https://github.com/SanderMuller/boost-skills/compare/2.2.0...2.3.0
Two optional conventions slots and a generalized evaluate skill. Everything here is additive under conventions schema-version 1 — a consumer that declares neither slot, and existing slot-aware skills, behave exactly as before.
pr.risk conventions slot — optional PR risk-tier routing for the pull-requests skill. Declare variable-length tiers (a routing discriminator — reviewer_count is implemented, with codeowners_path / blast_radius / gate_skill reserved for a future minor — plus human_reviewers, require_codeowners, label, free-form extra actions, and per-tier or slot-level ai_reviewers), with optional matrix_doc / assessment_skill. pull-requests renders and routes by your tiers when declared, and falls back to its generic Low/Medium/High question when absent. Orthogonal to pr.gates — a gate-only project is never pushed into a tier.translations conventions slot — optional DB-driven translation-key validation, consumed by a new conditional check in the evaluate skill. Declare a per-consumer key_pattern plus file_based_prefixes (framework_groups + vendor_namespace_exempt) and an optional rules_doc. Scoped to database-stored keys that bypass the framework's own file-based validation; absent ⇒ no check.evaluate skill hardened with two general-purpose phases, so projects no longer need to shadow it to get them: evaluation-scope resolution (resolve the change set once; never fall back to the whole-branch diff) and an Audit Code Comments phase (a Remove / Replace / Trim / Keep ladder with tooling-annotation exemptions). The Security review row now also covers auth checks, XSS, and SQL injection alongside the existing checks.boost-core requirement to the current ^0.20 || ^0.21 || ^0.22 || ^0.23 || ^1.0.Validated against real-world adoption (a production app with DB-driven translations and ISO-27001 PR routing) before release: declaring the slots replaces ~200 lines of duplicated host prose with single-source declarative data, with no change for consumers that don't adopt them.
Full Changelog: https://github.com/SanderMuller/boost-skills/compare/2.1.0...2.2.0
Adds support for boost-core 0.23 and the 1.x line, raises the minimum engine to ^0.20, and ships a new signed-commits guideline. See UPGRADING.md for the one migration step.
boost-core ^0.20. The accepted range is now ^0.20 || ^0.21 || ^0.22 || ^0.23 || ^1.0, dropping 0.16–0.19. This is a support-policy cutoff, not a hard requirement of the shipped skills (they still resolve correctly on 0.16) — it aligns boost-skills with the config API boost-core froze for 1.0: ->withTags(...) takes a single array as of boost-core 0.20.0 (it was variadic through 0.19). If you were already on boost-core 0.20+, the only effective change is the added 0.23 / 1.x support. Consumers on 0.16–0.19 should move to 0.20+ and update their boost.php ->withTags(...) call to the array form — see UPGRADING.md.boost-core 0.23 and 1.x support. ^0.23 and ^1.0 join the require range, so consumers can adopt the upcoming 0.23 engine and the 1.0 line without boost-skills capping them.signed-commits guideline. When a repository has commit signing enabled, never fall back to an unsigned commit if the signing agent (1Password, gpg-agent, etc.) is unavailable — stop and surface the failure instead of bypassing it with --no-gpg-sign. Self-gating: inert for repositories without signing configured, so it never blocks workflows that don't sign.->withTags([...]) form to match the boost-core 0.20+ builder signature.Full Changelog: https://github.com/SanderMuller/boost-skills/compare/2.0.6...2.1.0
Compatibility patch. boost-skills now accepts boost-core 0.22 alongside 0.16–0.21, so consumers can adopt the upcoming engine release without boost-skills capping them. No skill behavior changed.
boost-core require to ^0.16 || ^0.17 || ^0.18 || ^0.19 || ^0.20 || ^0.21 || ^0.22. Forward-compat for the upcoming boost-core 0.22 release, which freezes the conventions-token and tag/sidecar contracts boost-skills depends on as semver-protected public format/behavior. Under Composer's 0.x caret rules each minor is opt-in, so the previous ceiling would have excluded the 0.22 root — this keeps consumers running both packages able to adopt the new engine minor without boost-skills capping them. ^0.16 remains the token-resolution floor.Full Changelog: https://github.com/SanderMuller/boost-skills/compare/2.0.5...2.0.6
Compatibility patch. boost-skills now accepts boost-core 0.21 alongside 0.16–0.20, so consumers can adopt the upcoming engine release without boost-skills capping them. No skill behavior changed.
boost-core require to ^0.16 || ^0.17 || ^0.18 || ^0.19 || ^0.20 || ^0.21. Forward-compat for the upcoming boost-core 0.21 release. Under Composer's 0.x caret rules each minor is opt-in, so the previous ceiling would have excluded the 0.21 root — this keeps consumers running both packages able to adopt the new engine minor without boost-skills capping them. boost-core 0.21 carries a pre-1.0 breaking change (FileEmitter::emit() returns iterable<EmittedFile>); boost-skills ships skills and guidelines with no FileEmitter implementation, so that change is a no-op here. ^0.16 remains the token-resolution floor.Full Changelog: https://github.com/SanderMuller/boost-skills/compare/2.0.4...2.0.5
Maintenance patch. boost-skills adopts boost-core's .config/boost.php config location for its own dev tooling and widens the engine constraint to accept boost-core 0.20. No skill behavior changed.
boost.php to .config/boost.php. boost-core 0.17+ resolves the engine config from either the project root or .config/; this repo adopts the tidier .config/ location for its own dev setup. The file is dev-only (export-ignored), so consumers — who supply their own boost config — are unaffected. The dev-tooling floor is boost-core 0.18 here (via package-boost-php), which always carries the .config/ resolver.package-boost-php dev dependency to ^0.17. Pulls boost-core ^0.18 || ^0.19 into the dev tree.boost-core require to ^0.16 || ^0.17 || ^0.18 || ^0.19 || ^0.20. Forward-compat for the upcoming boost-core 0.20 release. Under Composer's 0.x caret rules each minor is opt-in, so the previous ceiling would have excluded the 0.20 root — this keeps consumers running both packages able to adopt the new engine minor without boost-skills capping them. ^0.16 remains the token-resolution floor.Full Changelog: https://github.com/SanderMuller/boost-skills/compare/2.0.3...2.0.4
Compatibility patch. boost-skills now accepts boost-core 0.19 alongside 0.16, 0.17, and 0.18, so consumers can adopt the new engine release without boost-skills capping them. No skill behavior changed.
boost-core require to ^0.16 || ^0.17 || ^0.18 || ^0.19. boost-core 0.19.0 is additive and changes nothing boost-skills uses (the conventions-inlining engine is unchanged since 0.16). But under Composer's 0.x caret rules each minor is opt-in, so the previous ^0.16 || ^0.17 || ^0.18 ceiling excluded the 0.19 root — capping any consumer running both packages at boost-core <0.19. ^0.16 remains the token-resolution floor (the mcp.jira sub-key token still needs the 0.16.0 resolver); 0.19 is simply now accepted.Full Changelog: https://github.com/SanderMuller/boost-skills/compare/2.0.2...2.0.3
Compatibility patch. boost-skills now accepts boost-core 0.18 alongside 0.16 and 0.17, so consumers can adopt the new engine release without boost-skills capping them. No skill behavior changed.
boost-core require to ^0.16 || ^0.17 || ^0.18. boost-core 0.18.0 is additive and changes nothing boost-skills uses (the conventions-inlining engine is unchanged since 0.16). But under Composer's 0.x caret rules each minor is opt-in, so the previous ^0.16 || ^0.17 ceiling excluded the 0.18 root — capping any consumer running both packages at boost-core <0.18. ^0.16 remains the token-resolution floor (the mcp.jira sub-key token still needs the 0.16.0 resolver); 0.18 is simply now accepted.Full Changelog: https://github.com/SanderMuller/boost-skills/compare/2.0.1...2.0.2
Compatibility patch. boost-skills now accepts boost-core 0.17 alongside 0.16, so consumers can adopt the new engine release without a boost-skills upgrade getting in the way. No skill behavior changed.
boost-core require to ^0.16 || ^0.17. boost-core 0.17.0 is additive — it adds .config/boost.php support and is fully back-compatible — and changes nothing boost-skills uses (the conventions-inlining engine is unchanged since 0.16). But under Composer's 0.x caret rules a bare ^0.16 resolves to >=0.16 <0.17, which excluded 0.17. That capped any consumer running both packages at boost-core <0.17. ^0.16 remains the token-resolution floor (the mcp.jira sub-key token still needs the 0.16.0 resolver); 0.17 is simply now accepted.2.0 upgrade gotchas in UPGRADING.md: a host .blade.php guideline silently dropped during sync, and a host shadow keeping its convention block. Both surfaced from real-world adoption of the 2.0 token-inlining migration.Full Changelog: https://github.com/SanderMuller/boost-skills/compare/2.0.0...2.0.1
Slot-aware skills now resolve their project-convention values into the skill body at sync time via boost-core's conventions-inlining tokens (shipped in 0.15.0), instead of reading the always-loaded ## Project Conventions block at agent runtime. Once a consumer's synced catalog is fully token-sourced, that block drops entirely — the values are baked into each skill. Adopting needs boost-core ^0.16.
boost-core ^0.16 (hard floor). The 10 slot-aware skills (jira-create / jira-rework / jira-updates, pull-requests, codex-review, write-spec, interview, bug-fixing, backend-quality, test-writing) now contain <!--boost:conv--> tokens. The inliner ships in 0.15.0, but the three Jira skills use an mcp.jira open-vocab sub-key token that only the 0.16.0 resolver handles — on 0.15 it emits raw, losing the value. On any engine below 0.16 at least one token emits raw into the skill body, so ^0.16 is enforced as a composer require constraint, not just documentation. This also makes the slot-aware skills sandermuller/boost-core-specific — they don't resolve under laravel/boost (no inliner). Adopt a family-package release that floats boost-core to include ^0.16 (e.g. package-boost-php ^0.16.1). See UPGRADING.md.$.slot references to render-time tokens. Each skill's ## Project Conventions slots documentation table is removed (obsolete once values inline); the slot dependency is now in the tokens + the schema. Agent behavior is unchanged — skills dispatch identically; the value is inlined instead of read from the block.mcp.jira as a clean scalar token (<!--boost:conv path="mcp.jira" mode="inline" fallback="mcp-atlassian"-->), resolving the MCP server-namespace segment directly — declared mcp.jira → schema-default mcp-atlassian → fallback. (pull-requests still renders the whole mcp map as YAML for its gate tools.)conventions-schema.json gains render mode pins on the structured / list slots (branches.patterns, pr.gates, mcp → yaml; testing.forbid, spec.research_docs → inline/bullets) as drift guards so a slot always renders in a consistent mode.github.default_base_branch, codex.invocation_mode, jira.project_key, …) inline their value directly into the prose.branches.patterns, pr.gates) render as YAML data the skill's algorithm prose then operates on at agent runtime — the value is inlined, the logic stays in the skill.boost where --conventions shows each slot's effective resolved value (declared / schema-default / fallback).composer require --dev "sandermuller/boost-skills:^2.0"
# via a family package that floats boost-core to include ^0.16 (e.g. package-boost-php ^0.16.1)
vendor/bin/boost sync # or `php artisan project-boost:sync` in Laravel
No boost.php or slot-vocabulary changes — same ->withConventions([...]), same schema v1. The ## Project Conventions block in CLAUDE.md disappears once your full synced skill set is token-sourced (the engine keeps it until everything converges, so partial states are safe). See UPGRADING.md for the full 1.9.x → 2.0 path.
Full Changelog: https://github.com/SanderMuller/boost-skills/compare/1.9.9...2.0.0
Consumer-facing boost-core floor ^0.13 → ^0.13 || ^0.14 (README + UPGRADING). package-boost-php 0.15.1 widened its boost-core constraint to ^0.13 || ^0.14 (absorbing 0.14.0's project-scope reconcile-on-sync), so a fresh family install now resolves boost-core 0.14.0 — outside the ^0.13 floor 1.9.8 stated (^0.13 = >=0.13 <0.14). The floor now matches the family range, with 0.14.0 added to the notable-versions list (dropped-emitter orphan reaping, sha-gated so operator edits are preserved).
boost-skills has no direct boost-core require — the family package pins the engine — so this is prose-floor accuracy, not a composer-constraint change. (boost-core is pre-v1; expect the floor to track each engine minor until the public API settles.)
composer require --dev "sandermuller/boost-skills:^1.9.9"
vendor/bin/boost sync # or `php artisan project-boost:sync` in Laravel
No schema, slot, or skill-body changes — floor-tracking only.
Full Changelog: https://github.com/SanderMuller/boost-skills/compare/1.9.8...1.9.9
Consumer-facing boost-core floor ^0.11 → ^0.13 (README + UPGRADING). The ^0.11 floor (set in 1.9.5) had gone stale + disjoint from the family: the current family packages narrow boost-core to ^0.13, so a consumer reading "Requires ^0.11" while installing a current family package (which pulls ^0.13) got contradictory guidance — ^0.11 and ^0.13 are non-overlapping ranges. The floor now matches the family line and lists the notable engine versions folded into it:
0.9.0 — conventions-source-flip (values move to boost.php)0.9.3 — render-fail-then-write data-loss patch0.10.0 — cross-agent capability-loss fix + boost doctor entry-point banner0.11.0 — BoostWrapperContract (bare-CLI sync stops false-positive-deleting wrapper-injected files)0.12.0 — markerless guidance files: CLAUDE.md / AGENTS.md become wholesale boost-owned; operator content moves to .ai/guidelines/boost-skills has no direct boost-core require (it's a markdown catalog — the family package pins the engine), so this is prose-floor accuracy, not a composer-constraint change.
require-dev package-boost-php ^0.13 → ^0.15 (dev-env dogfood; pulls boost-core 0.13.0). The catalog now dev-syncs under the markerless guidance model — verified safe: boost-skills' own CLAUDE.md is fully vendor-generated (zero hand-authored content), so wholesale-ownership regenerates it losslessly..gitignore managed block adds .boost/ (the 0.13 sync-manifest dir).composer require --dev "sandermuller/boost-skills:^1.9.8"
vendor/bin/boost sync # or `php artisan project-boost:sync` in Laravel
No schema, slot, or skill-body changes — floor-tracking + dev-env only. If you hand-edited content into a generated CLAUDE.md / AGENTS.md, move it to .ai/guidelines/ before adopting boost-core 0.12+ (markerless makes those files wholesale boost-owned); see boost-core's 0.12.0 notes.
Full Changelog: https://github.com/SanderMuller/boost-skills/compare/1.9.7...1.9.8
test-writing + bug-fixing — testing.forbid category-alias expansions rendered inline. Both skills previously deferred to "see the schema description for alias expansions", but the schema description isn't loaded into the agent's context — so an agent had to know from general knowledge that js-test-frameworks includes cypress. Now the full expansion is inline in both skills:
| Alias | Expands to |
|---|---|
js-test-frameworks |
vitest, jest, mocha, cypress, playwright |
browser-test-frameworks |
cypress, playwright |
php-browser-tests |
dusk, panther |
A forbid: ['js-test-frameworks'] now visibly refuses a Cypress test without the agent needing outside knowledge. Surfaced by runtime-dispatch verification against a proving consumer — an agent resolved the alias membership via general knowledge, which a stricter agent could have missed.
composer require --dev "sandermuller/boost-skills:^1.9.7"
vendor/bin/boost sync # or `php artisan project-boost:sync` in Laravel
No schema or convention changes — the alias map is unchanged (this renders the existing schema map into agent context).
Full Changelog: https://github.com/SanderMuller/boost-skills/compare/1.9.6...1.9.7
require-dev sandermuller/package-boost-php ^0.12 → ^0.13. package-boost-php 0.13.0 widens its boost-core constraint to ^0.10 || ^0.11. boost-skills' dev environment was pinned ^0.12, capping the transitive boost-core at ^0.10 — inconsistent with the ^0.11 consumer floor that 1.9.5 documents. The bump lets the dev environment resolve boost-core 0.11.0, so the catalog now dev-tests against the same floor it tells consumers to use. Dev-only constraint; consumers unaffected.Full Changelog: https://github.com/SanderMuller/boost-skills/compare/1.9.5...1.9.6
A dispatch-prose audit across all six under-dogfooded conventions-schema slot groups (pr.gates, codex.invocation_mode, testing.forbid, spec.filename_pattern, mcp.*, branches.patterns) — the slots no real consumer exercises yet, where a vendor-skill prose bug would surface only when someone first adopts them. Caught six real prose/schema gaps that schema validation can't (validation checks input shape, not vendor dispatch prose). Plus a boost-core ^0.11 floor-bump.
pull-requests (pr.gates) — gate-ordering flow-control clarified (only stop_and_request halts; warn / skip continue to the next gate); shell_command failure modes enumerated (exit-127 / crash / timeout / Bash-tool error); mcp_tool success + failure shapes defined; default-value annotations added to the YAML examples.codex-review (codex.invocation_mode) — auth-failure / $.codex.setup_doc / pr.gates interaction concerns moved from plugin-nested subsections into a shared "Cross-cutting concerns" section so both invocation modes get parity. Base-branch resolution prose restated inline (first-match-wins) so the skill is self-sufficient without pull-requests loaded.test-writing (testing.forbid) — now slot-aware: reads $.testing.backend_framework (write tests for that runner) + $.testing.forbid (never write in forbidden frameworks). Adds metadata.schema-required: ^1 + a Project Conventions slots table.jira-updates (mcp.*) — "Available Tools" header no longer hardcodes the mcp-atlassian server name; resolves via $.mcp.jira so custom MCP server-name segments work.conventions-schema.json — spec.filename_pattern gains its missing "default": "specs/{slug}.md" (sibling slots all carry schema defaults; write-spec asserted this default the schema didn't back). branches.patterns description broadened to name all consumers (base resolution by pull-requests + codex-review; the pattern field's reuse by write-spec for {issue_key} detection).sandermuller/boost-core ^0.11 (was ^0.10). 0.11.0 adds the BoostWrapperContract so bare-CLI boost sync no longer false-positive-flags wrapper-injected files for deletion — the correctness half of the wrong-entry-point bug class (0.10.0 closed the discoverability half with the boost doctor entry-point banner). 0.10.x + 0.9.x improvements ride in transitively.composer require --dev "sandermuller/boost-skills:^1.9.5" "sandermuller/boost-core:^0.11"
vendor/bin/boost sync # or `php artisan project-boost:sync` in Laravel
No boost.php or convention changes. The slot-vocabulary is unchanged — these are prose/schema-default refinements, not new slots.
Full Changelog: https://github.com/SanderMuller/boost-skills/compare/1.9.4...1.9.5
Closes a tag-bucketing inconsistency where the pre-release skill was the odd-one-out in the release-tooling cluster (pre-release tagged php github while siblings readme / release-notes / upgrading are all tagged release-automation). Surfaced by a downstream consumer who reasonably declared withTags(Php, Github) for an application repo and ended up needing to explicitly exclude pre-release since the app doesn't do release work.
pre-release skill re-tagged: php github → php github release-automation. Subset-AND match — all three tags required for the skill to sync. Preserves PHP+GitHub scoping (the skill references Rector/Pint/Pest/PHPStan + gh release create) while adding the opt-in gate to align with sibling release-tooling skills.release-automation declared (standard family pattern, gets you readme/release-notes/upgrading siblings): no change — pre-release still syncs.release-automation declared: lose pre-release. Likely correct — if not doing release work, the skill doesn't apply.Php + Github (the surfaced case): correctly stop receiving pre-release. If you previously had an explicit withExcludedSkills(['pre-release']) to silence it, you can drop that line.If you want pre-release back, add release-automation to your withTags(...).
composer require --dev "sandermuller/boost-skills:^1.9.4"
vendor/bin/boost sync # or `php artisan project-boost:sync` in Laravel
Full Changelog: https://github.com/SanderMuller/boost-skills/compare/1.9.3...1.9.4
require-dev sandermuller/package-boost-php ^0.10 → ^0.12. Tracks the family-package's 0.11 → 0.12 floor-bump (which itself floored boost-core to ^0.10, aligned with what boost-skills 1.9.2 already requires). Dev-only constraint — keeps the catalog's own dev environment current with the family. Consumers unaffected (the require-dev constraint doesn't propagate downstream)..gitignore managed-region catches up to current engine output: drops .github/copilot-instructions.md, .github/skills/, AGENTS.md, CLAUDE.md. Per the boost-core 0.9.0+ / 0.9.6+ path-ownership contract, those paths are either retired emitters or tracked audit copies.Full Changelog: https://github.com/SanderMuller/boost-skills/compare/1.9.2...1.9.3
Floor-bumps the engine to boost-core ^0.10 for the cross-agent capability-symmetry fix that landed in 0.10.0. Laravel projects wiring the bare-CLI hook (BoostAutoSync::run in composer.json scripts) previously lost bundled pest-testing / livewire-development / filament-development / Inertia / Flux / Volt / Tailwind / Wayfinder / laravel-best-practices skills to Cursor / Copilot / Codex — the gap was masked locally by laravel/boost's MCP server for Claude Code only.
boost-core floor ^0.9.3 → ^0.10 (README + UPGRADING). Load-bearing per 0.10.0's entry-point-mismatch banner + the three-case boost tags diagnostic split. Earlier 0.9.3 data-loss patch + 0.9.4 diagnostic visibility ride along transitively.1.8.0 mis-tag is called out inline — pin ^1.8.1 or ^1.9.0+, never bare ^1.8.release-notes skill body (consumer-facing for agents drafting release bodies):
## Added / ## Changed / ## Fixed / ## Internal; no ## What's changed umbrella).## Validation / quality-gate counts, ## Acknowledgments / pattern-tracking, dogfooding narrative, process choreography, peer-handle credits, "unchanged from prior" segments.composer require --dev "sandermuller/boost-skills:^1.9.2" "sandermuller/boost-core:^0.10"
vendor/bin/boost sync # or `php artisan project-boost:sync` in Laravel projects
Per 0.10.0's entry-point-mismatch banner: Laravel projects currently wired to the bare-CLI hook in composer.json scripts should swap to [@php](https://github.com/php) artisan project-boost:sync to close the cross-agent symmetry gap. boost doctor flags the mismatch automatically once boost-core 0.10 is installed alongside project-boost-laravel.
Full Changelog: https://github.com/SanderMuller/boost-skills/compare/1.9.1...1.9.2
autoresearch skill — Laravel deep-dive subsection absorbed. Vendor body grew from 286 → 488 lines with a new "Laravel projects — deep-dive variations" section layered on top of the generic flow. Activated for Laravel route/job/Eloquent code paths; skipped for pure-PHP, raw PDO, or CPU-bound targets per an activation-rubric table at the top of the section. The deep-dive covers:
query_count + execution_median_ms) instead of one — query count is often the dominant signal for database-heavy work.DB::beginTransaction() / rollBack() + cache()->flush() / Once::flush() between iterations.sandermuller/stopwatch profiling helper with explicit fallback to manual hrtime(true) checkpoints.improved = queries < prev_queries OR execution_ms < prev_ms * 0.98.migrate:fresh ban, factories not raw SQL, transaction rollback, Once::flush() between iterations, no test modification, preserve API contracts, never weaken security).Two strong-directive inline pointers in the generic body (Step 2 baseline + Phase 6 decide) route Laravel readers into the deep-dive with explicit consequence framing — "Skipping the deep-dive and drafting a generic benchmark for a Laravel target will leave you optimizing the wrong metric." Generic flow stays intact for non-Laravel consumers; pure-PHP / raw-PDO / different-ORM consumers can skip the deep-dive entirely per the activation rubric.
Consumers maintaining a local autoresearch shadow with Laravel-specific content can drop the shadow on 1.9.1 adoption.
ai-guidelines skill — Laravel-substitute note. Single inline note after the first vendor/bin/boost sync reference: Laravel projects with sandermuller/project-boost-laravel installed should substitute php artisan project-boost:sync for vendor/bin/boost sync throughout the skill. The bare vendor/bin/boost sync currently errors on Container::path() in Laravel projects until a wrapper-side or engine-side fix lands; the note closes the consumer-side friction without polluting the canonical skill with wrapper-specific commands at every reference.
README.md — Requires-line polish + floor-pin discipline cross-link. Reference to "boost-skills 1.8.0" updated to "boost-skills 1.8.1+" (the 1.8.0 tag was mis-tagged and ships 1.7.2 content). Added a brief sentence on the load-bearing-only floor-pin discipline: polish-tier improvements in subsequent 0.9.x releases (e.g. 0.9.4 diagnostic-visibility UX) ride along via the range constraint without forcing the floor higher.
composer require --dev --with-all-dependencies \
"sandermuller/boost-skills:^1.9.1"
vendor/bin/boost sync
vendor/bin/boost validate
Or in Laravel projects with project-boost-laravel:
composer require --dev --with-all-dependencies \
"sandermuller/boost-skills:^1.9.1"
php artisan project-boost:sync
vendor/bin/boost validate
No migration step from 1.9.0. Drop-in replacement.
1.9.1 ships absorption-pattern data point #2 (codex-review absorption in 1.8.0-rc1 was #1; autoresearch absorption is #2). The shape — universal-content-moves-into-catalog, with the absorbed content scoped via an activation-rubric — continues to earn its place. Real-world adoption signal: a proving consumer maintained a local shadow with substantive content that generalized cleanly to other consumers in the same framework class; absorbing it into the catalog drops the shadow and broadens the value.
Full Changelog: https://github.com/SanderMuller/boost-skills/compare/1.9.0...1.9.1
How can I help you explore Laravel packages today?