📦 deps(thirdparty): update snapshots
This commit is contained in:
ci[bot]
@@ -0,0 +1,32 @@
|
||||
---
|
||||
name: trigger-boundary-auditor
|
||||
description: >
|
||||
Audits the trigger boundaries of the six brooks-lint skills for false-triggering
|
||||
risk and routing collisions. Use before a release, or after editing any
|
||||
SKILL.md `description:` field. Read-only — reports findings, makes no edits.
|
||||
tools: Read, Grep, Glob
|
||||
---
|
||||
|
||||
You audit the trigger surfaces of the brooks-lint skills. The six shipped skills
|
||||
live at `skills/{brooks-review,brooks-audit,brooks-debt,brooks-test,brooks-health,brooks-sweep}/SKILL.md`.
|
||||
Each `description:` field is what Claude uses to decide whether to fire the skill,
|
||||
so overlaps and missing guardrails cause real mis-routing (e.g. `brooks-debt`
|
||||
firing on an HTTP `/health` question).
|
||||
|
||||
Do this:
|
||||
|
||||
1. Read every `skills/*/SKILL.md` frontmatter `description` field.
|
||||
2. For each skill, check it contains a `Do NOT trigger for:` clause. Flag any that
|
||||
are missing one — this is a hard repo requirement.
|
||||
3. Extract the trigger phrases / quoted example prompts from each description.
|
||||
Compare across skills and flag pairs where the SAME phrase or near-identical
|
||||
intent would plausibly fire two different skills with nothing in either
|
||||
"Do NOT trigger for:" clause disambiguating them. Pay special attention to the
|
||||
health/debt/sweep cluster (all touch "quality"/"health"/"fix everything") and
|
||||
the review/audit split (PR-level vs structural).
|
||||
4. Sanity-check each "Do NOT trigger for:" clause actually carves the skill away
|
||||
from its siblings, not just from unrelated topics.
|
||||
|
||||
Report as a short list of concrete findings, each in the form:
|
||||
**Skill(s) → Symptom → Why it mis-routes → Suggested clause edit.**
|
||||
If a skill is clean, say so. Do not edit any files; recommendations only.
|
||||
@@ -0,0 +1,50 @@
|
||||
---
|
||||
name: new-skill
|
||||
description: >
|
||||
Scaffold a new brooks-lint analysis skill so it passes `npm run validate` and
|
||||
`npm run evals` on the first try — generates skills/{name}/SKILL.md (with the
|
||||
mandatory "Do NOT trigger for:" clause and a Process section citing guide step
|
||||
ranges) plus skills/{name}/{name}-guide.md (sequentially numbered steps), then
|
||||
appends paired eval scenarios.
|
||||
Triggers when the maintainer asks to "add a new skill", "scaffold a skill", or
|
||||
"create a brooks-lint mode".
|
||||
Do NOT trigger for: editing an existing skill's content, adding a single eval to
|
||||
an existing skill, or authoring skills for some other plugin.
|
||||
disable-model-invocation: true
|
||||
---
|
||||
|
||||
# brooks-lint — New Skill Scaffold
|
||||
|
||||
Skill name comes from `$ARGUMENTS` (kebab-case, e.g. `brooks-security`). If empty,
|
||||
ask for the name and a one-line purpose first.
|
||||
|
||||
Follow the repo's "Adding a New Skill" checklist exactly:
|
||||
|
||||
1. **Create `skills/{name}/SKILL.md`** with frontmatter — `name`, a `description`
|
||||
that ends with a `Do NOT trigger for:` clause (validate-enforced for shipped
|
||||
skills; omitting it causes false triggering), and a `Process` section of 3–6
|
||||
bullets that cite the guide's step ranges inline (e.g. `Scan risks (Steps 1–6 of
|
||||
the guide)`). Mirror the structure of an existing skill such as
|
||||
`skills/brooks-review/SKILL.md` (Setup → Process → Mode line).
|
||||
2. **Create `skills/{name}/{name}-guide.md`** with sequentially numbered steps —
|
||||
no gaps, no duplicates. Sub-steps like `Step 2a` are allowed. The guide owns the
|
||||
detailed steps; the SKILL.md Process is just an orientation skeleton.
|
||||
3. **Wire the framework.** The new SKILL.md Setup section must Read the relevant
|
||||
`_shared/` files (`common.md` for Iron Law + Report Template, plus
|
||||
`decay-risks.md` / `test-decay-risks.md` as applicable) — `_shared/` is NOT
|
||||
auto-loaded.
|
||||
4. **Add eval coverage** to `evals/evals.json`: append with the next sequential
|
||||
`id` at least one happy-path scenario (with the relevant risk code in
|
||||
`expected_output`) and at least one false-positive scenario flagged
|
||||
`no_risk_codes: true`. Each scenario needs `id`, `name`, `prompt`,
|
||||
`expected_output`, `mode`, `files`.
|
||||
5. **Validate.** `npm run validate` (structure + step continuity + Process-section
|
||||
presence) and `npm run evals` (eval schema). Fix until both pass.
|
||||
6. **Local-test.** `cp -r skills/* ~/.claude/skills/brooks-lint/` (if you've
|
||||
symlinked `~/.claude/skills/brooks-lint` to the repo, skip this — edits are
|
||||
already live), trigger the new skill in a Claude session, verify the Iron Law
|
||||
output, then restore the marketplace copy: `/plugin marketplace update` →
|
||||
`/plugin install brooks-lint@brooks-lint-marketplace`.
|
||||
|
||||
Do NOT register a slash command by hand — short forms are auto-installed by the
|
||||
session-start hook. Report the files created and the validate/evals results.
|
||||
@@ -0,0 +1,41 @@
|
||||
---
|
||||
name: release
|
||||
description: >
|
||||
Cut a brooks-lint release: set the version in package.json, propagate it across
|
||||
all four plugin manifests + README badge, write the CHANGELOG entry, validate,
|
||||
then commit, push, tag, and publish the GitHub release.
|
||||
Triggers when the maintainer asks to "release", "cut a release", "ship a new
|
||||
version", or "bump and publish" brooks-lint.
|
||||
Do NOT trigger for: propagating an already-decided version without releasing
|
||||
(use `npm run bump` directly), CHANGELOG edits alone, or questions about the
|
||||
release process that don't ask to perform it.
|
||||
disable-model-invocation: true
|
||||
---
|
||||
|
||||
# brooks-lint — Release
|
||||
|
||||
Target version comes from `$ARGUMENTS` (e.g. `1.4.0`). If empty, ask the maintainer
|
||||
for the semver bump before doing anything.
|
||||
|
||||
Execute these steps in order. `bump-version.mjs` reads the version FROM
|
||||
`package.json` and does NOT touch the changelog — so the version edit and the
|
||||
CHANGELOG entry are manual; the script only fans the version out to manifests + badge.
|
||||
|
||||
1. **Set the source of truth.** `npm version <version> --no-git-tag-version`
|
||||
(the `--no-git-tag-version` flag is required — plain `npm version` would create
|
||||
its own commit + tag and collide with the manual commit in step 5).
|
||||
2. **Propagate.** `npm run bump` — writes the version into
|
||||
`.claude-plugin/plugin.json`, `.claude-plugin/marketplace.json`,
|
||||
`.codex-plugin/plugin.json`, `gemini-extension.json`, and the README badge.
|
||||
3. **Write the changelog.** Add a new `## <version>` section at the top of
|
||||
`CHANGELOG.md` with categorized notes (Added / Fixed / Changed) summarizing the
|
||||
commits since the last release tag (`git log <last-tag>..HEAD --oneline`).
|
||||
4. **Validate.** `npm run validate` — fails if any manifest, the README badge, or
|
||||
the CHANGELOG entry is out of sync. Fix and re-run until clean. Then `npm test`.
|
||||
5. **Commit & push.** Stage the changed manifests, README, and CHANGELOG; commit
|
||||
with a conventional message (`chore(release): bump version to <version>`); push
|
||||
to `main` (direct-to-main repo — no PR).
|
||||
6. **Tag & publish.** Create the GitHub release:
|
||||
`gh release create v<version> --title "v<version>" --notes "<changelog section>"`.
|
||||
|
||||
Report the released version and the GitHub release URL when done.
|
||||
Reference in New Issue
Block a user