README

Sander Muller's personal Composer-distributed catalog of AI agent skills for PHP projects and Composer packages. Adopt it if your preferences align with Sander's, or use it as a template for your own.

sandermuller/boost-skills is one example of a Composer-distributed AI-skill catalog. It ships a curated mix of generic workflow skills (code review, bug fixing, spec-driven implementation, release checklists, Jira workflows, deployment, and more), tag-gated framework-specific extras, and always-on guidelines — see the full Skills and Guidelines inventories below.

The package carries no runtime code; it's pure Markdown. A sync engine (sandermuller/boost-core or laravel/boost) reads these skills and writes them into each AI agent directory you've configured (Claude Code, Cursor, Copilot, Codex, Gemini, and the rest).

Where do skills come from?

Anywhere you want. Skill sources stack — mix and match freely:

• Your own .ai/skills/ folder, hand-authored next to the rest of the project. Same convention laravel/boost and boost-core both pick up automatically.
• A Composer-installed catalog package. Any package that ships resources/boost/skills/ works. Sander publishes his personal catalog at sandermuller/boost-skills (this repo) — adopt it if your preferences align with Sander's, or use it as a template for your own private/public catalog.
• External, non-Composer sources via boost-core's withRemoteSkills(). Pull GitHub-published .skill bundles or single-skill repos straight from a URL.
• laravel/boost's bundled Laravel skills — Laravel-specific skills shipped by Laravel via laravel/boost (Laravel apps only).

withAllowedVendors() gates Composer-scanned vendors (source 2) only. withTags() filters sources 2, 3, and 4 (Composer vendors, remote skills, laravel/boost bundle). Host .ai/skills/ (source 1) bypasses both gates — your project authored those skills, so the engine treats them as canonical and applies neither filter.

The boost family

If you adopt sandermuller/boost-skills (or any Composer-distributed catalog), pair it with the sync engine that matches your role:

• sandermuller/package-boost-php if you write framework-agnostic Composer packages
• sandermuller/package-boost-laravel if you write Laravel packages
• sandermuller/project-boost if you build a PHP application
• sandermuller/project-boost-laravel if you build a Laravel application (coexists with laravel/boost — adds nine-agent fanout, tag filter, vendor allowlist, remote skills)

The four sandermuller/* packages bundle the sandermuller/boost-core sync engine, so you rarely install boost-core yourself. laravel/boost (Laravel's own engine, MCP server, and docs API) coexists with project-boost-laravel in Laravel apps — the family-package layers the nine-agent fanout and filters on top. If you'd rather skip the family controls and use laravel/boost standalone, it reads any Composer-distributed catalog (including this one) just as well; follow its setup for that one. If none of these fit (a non-PHP package, say), install boost-core directly.

Install

If you adopt sandermuller/boost-skills as your catalog, install it together with the family package for your engine role. For a framework-agnostic package author, that is package-boost-php:

composer require --dev sandermuller/boost-skills sandermuller/package-boost-php

Swap package-boost-php for package-boost-laravel or project-boost to match your role. The steps below use the boost-core engine's commands; on laravel/boost, follow its own setup instead and ensure sandermuller/boost-skills is among the packages it syncs.

boost-core, pulled in by the family package, ships an interactive setup command:

vendor/bin/boost install

boost install generates a boost.php in your project root and lets you pick target agents and allowlisted vendors. Skills sync only from allowlisted vendors, so make sure sandermuller/boost-skills is selected. The result looks like:

return BoostConfig::configure()
    ->withAgents([
        Agent::CLAUDE_CODE,
        Agent::COPILOT,
        Agent::CODEX,
    ])
    ->withAllowedVendors([
        'sandermuller/boost-skills',
        'sandermuller/package-boost-php',
    ])
    ->withTags(['php', 'github']);

Declare your project's capabilities in ->withTags(...) — tagged skills and guidelines sync only to projects that opt in. Common starters are 'php' and 'github'; see the Tags registry for the full vocabulary. After a sync, vendor/bin/boost tags shows which tagged content is currently filtered out vs synced — handy for spotting capabilities you may want to declare.

Then fan the skills out:

vendor/bin/boost sync

Re-sync after edits by running vendor/bin/boost sync, or wire the BoostAutoSync callback into your composer.json's post-install-cmd / post-update-cmd to re-sync automatically on every composer install / composer update. The generated agent directories (.claude/skills/, .github/skills/, and the rest) stay out of version control; boost-core manages that .gitignore block.

Skills

Tags

Most skills and guidelines are universal — they sync to every project. Some carry capability tags naming what the project needs (or has opted in to) for the content to be useful. A project declares its capabilities in boost.php via ->withTags(...), and only matching content syncs.

The tag mechanism (subset-AND match, withTags() declaration in boost.php, metadata.boost-tags in skill frontmatter, the .boost-tags.yaml sidecar manifest for guidelines) is family-canonical — defined by boost-core and applies to any Composer-distributed catalog. The tag vocabulary below is one catalog's choice — Sander's mix of capabilities surfaced by skills and guidelines boost-skills ships. Other catalogs may organize differently. Owner names which boost-family package ships the content using each tag.

boost-core ships a broader Tag enum (SanderMuller\BoostCore\Enums\Tag) with cases not bound to any skill in this catalog — Tag::Filament, Tag::Livewire, Tag::Volt, Tag::Inertia, Tag::Flux, Tag::Pest, Tag::Tailwind, and others. These are forward-compatible slots in the family vocabulary. Declaring them in your withTags(...) is harmless today (no shipped skill targets them yet) and survives boost install picker re-runs per boost-core's declared-but-undiscovered preservation rule. The table below covers only the tags boost-skills itself currently ships content under; see Tag::* in boost-core for the full enum vocabulary.

github and github-issues are independent. github covers any GitHub-hosted repo (used by PR and release skills); github-issues is the narrower tag for projects that track issues in GitHub Issues specifically. A repo hosted on GitHub but tracking issues in Jira declares github but not github-issues. Both are independently declarable in ->withTags(...).

A skill or guideline can carry more than one tag, and then applies only where the project declares all of them — jira-rework is jira + github. Skill tags live inline in the skill's SKILL.md frontmatter (metadata.boost-tags); guideline tags live in a sidecar .boost-tags.yaml manifest (guidelines stay frontmatter-free for laravel/boost compatibility). Filtering needs boost-core 0.5+ for skills and 0.6+ for the guideline manifest; on older versions or under laravel/boost, the tags are inert and everything in this package syncs.

Project Conventions schema

Some vendor skills in this catalog reference project-specific values — Jira project key, GitHub owner / repo, branch-naming patterns, PR title format, test framework, codex invocation mode, MCP server-name mappings. Rather than baking those values into vendor skill bodies (which would force every consumer to shadow the skill to override the embedded value), boost-skills 1.7.0+ ships a JSONSchema vocabulary at resources/boost/conventions-schema.json that names the slots. Consumers declare values in boost.php via ->withConventions([...]); boost sync inlines each slot value directly into the skill bodies at sync time (2.0+; the 1.7–1.9 line instead rendered a ## Project Conventions block that skills read at agent runtime).

Requires sandermuller/boost-core ^0.20 (accepted range ^0.20 || ^0.21 || ^0.22 || ^0.23 || ^1.0). Slot-aware skills resolve their convention values at sync time via boost-core's conventions-inlining tokens (<!--boost:conv-->, shipped in 0.15.0); the three Jira skills additionally use an mcp.jira sub-key token that only the 0.16.0 resolver handles. The conventions-token machinery itself requires 0.16.0+ (below it the mcp.* sub-key token emits raw and the value is lost), but the declared floor is higher by policy: boost-skills 2.1.0 declares boost-core ^0.20 || ^0.21 || ^0.22 || ^0.23 || ^1.0, raising the floor from ^0.16 to ^0.20 as a support-policy cutoff that aligns the catalog with the config API boost-core froze for 1.0 (->withTags(...) became array-form in 0.20.0) — not merely the token resolver. Each newer 0.x minor is accepted additively and ^1.0 forward-covers the 1.x line; the family package you adopt (package-boost-php / package-boost-laravel / project-boost / project-boost-laravel) also floats the engine. Earlier engine milestones folded in: 0.9.0 (conventions-source-flip — values move to boost.php), 0.9.3 (data-loss patch), 0.10.0 (cross-agent capability-loss fix), 0.11.0 (BoostWrapperContract), 0.12.0 (markerless guidance files — operator content moves to .ai/guidelines/), 0.14.0 (reconcile-on-sync), 0.15.0 (conventions inlining — convention values render into skills at sync; the always-loaded ## Project Conventions block drops once a project is fully token-sourced), 0.16.0 (open-vocab mcp.* sub-key resolution + conventions-token leak detection).

Skill bodies inline slots via <!--boost:conv path="jira.project_key" ...--> tokens, resolved at sync time; the boost slots command lists the same slots in dotted form (jira.project_key). The path= and dotted forms name the same slot.

Declare conventions in boost.php:

return BoostConfig::configure()
    ->withAgents([Agent::CLAUDE_CODE, Agent::COPILOT, Agent::CODEX])
    ->withAllowedVendors(['sandermuller/boost-skills', /* ... */])
    ->withTags([Tag::Php, Tag::Github, Tag::Laravel])
    ->withConventions([
        'schema-version' => 1,
        'jira' => [
            'project_key' => 'HPB',
        ],
        'github' => [
            'owner' => 'my-org',
            'repo' => 'my-app',
        ],
        // … other slot groups consumer needs …
    ]);

boost sync renders the array into a marker-bounded YAML block under ## Project Conventions in CLAUDE.md (agent-read surface). boost.php is the single source of truth; edit there, run boost sync, the rendered block updates automatically.

Slot taxonomy

Two patterns:

• Value slots — scalar / array / path values. Vendor skill reads and uses directly. Example: jira.project_key is a string; vendor jira-create substitutes it into mutation calls.
• Policy slots — typed-object arrays with a type: discriminator. Vendor dispatches on the discriminator. Example: pr.gates is a list of typed gates (skill_invoked / shell_command / mcp_tool); vendor pull-requests enforces each in declared order.

Missing-slot behavior is per-slot: value slots prompt the user once per session; policy slots are skipped silently (no enforcement) when absent.

Slot groups (v1)

All 11 groups are root-optional — only schema-version: 1 is root-required. A consumer without (say) a Jira tracker simply doesn't declare the jira group; no scaffold noise, no forced placeholder. Inside each declared group, leaves with required semantics must be present (e.g. jira.project_key is required if jira is declared at all). The full machine-readable contract lives in resources/boost/conventions-schema.json.

Tooling

Schema-versioning

Vendor skills declare metadata.schema-required in their frontmatter — a Composer-style semver range naming which schema-version they consume. boost-skills' v1 vocabulary is schema-version: 1; current slot-aware skills (jira-create, pull-requests) declare schema-required: ^1. A future v2 schema is published via a vendor minor bump; consumers update their host schema-version declaration when their full vendor lineup supports it. Skills with mismatched schema-required skip-write with a warning; no broken syncs.

Vendor schema vs catalog vocabulary

The mechanism (JSONSchema validation, ->withConventions([...]) builder method, boost-core engine surface) is family-canonical — defined by boost-core and applies to any vendor catalog. The slot vocabulary above is THIS catalog's choice; other Composer-distributed catalogs can ship their own schemas at resources/boost/conventions-schema.json and contribute to the host's combined slot vocabulary (subject to the engine's collision-handling rules: first-allowlisted wins on same-type, throws on type-mismatch).

Migrating from 1.7.x

If you adopted boost-skills 1.7.0 / 1.7.1 / 1.7.2, your ## Project Conventions block lived as a hand-edited YAML region inside CLAUDE.md (the boost-core 0.8.x shape). Under boost-core 0.9.0+, boost.php becomes the single source of truth; the YAML block in CLAUDE.md is regenerated from boost.php at every sync.

One-command migration:

vendor/bin/boost convert-conventions

This reads the existing YAML block from CLAUDE.md, decodes it, and writes the values into boost.php's ->withConventions([...]) array (or appends the method to the existing builder chain if absent). After conversion, boost sync rerenders the block from the new source. CLAUDE.md remains tracked in git; no git rm --cached step is needed (the 0.8.3 tracking decision carries through 0.9.0).

If boost.php already declares ->withConventions([...]) and the CLAUDE.md block also has non-empty content that differs, convert-conventions fails closed and asks the operator to reconcile manually — never silently destroys either source. After reconciliation, re-run.

Guidelines

Alongside skills, the package ships guidelines under resources/boost/guidelines/ — short Markdown files of project-wide conventions that the sync engine folds into CLAUDE.md / AGENTS.md. Unlike skills, guidelines are always active — no on-demand activation.

Guidelines can be tagged, like skills, so one ships only to projects with the matching capability. But a guideline file stays frontmatter-free (for laravel/boost compatibility — it has no guideline frontmatter parser), so the tags live in a sidecar resources/boost/guidelines/.boost-tags.yaml manifest instead. boost-core 0.6.0+ reads it; on older boost-core and under laravel/boost the manifest is inert and every guideline ships.

Editing skills and guidelines

Each skill is a Markdown file at resources/boost/skills/<name>/SKILL.md with YAML frontmatter — name and description, plus optional metadata (a skill's boost-tags live here) and argument-hint. Guidelines are plain Markdown at resources/boost/guidelines/<name>.md with no frontmatter — they must start directly at a heading, so they render correctly under both boost-core and laravel/boost. Edit both here in this repository, not in a consuming project's synced copy, which boost-core overwrites on the next sync. The ai-guidelines skill documents the frontmatter contract and authoring conventions.

Changelog

See CHANGELOG.md for release history.

Security

Found a vulnerability? Email github@scode.nl rather than opening a public issue. See SECURITY.md for the disclosure policy.

Credits

• Sander Muller

License

MIT. See LICENSE.