boost-skill-cli 1.0.284__tar.gz → 1.0.286__tar.gz

{boost_skill_cli-1.0.284 → boost_skill_cli-1.0.286}/.gitignore

@@ -235,6 +235,12 @@ mutants/
 # dir (see evals/run_evals.py), so only the per-run scores land here; the
 # committed evals/baseline.json is what regressions are measured against.
 evals/results.json
-tests/visual/node_modules/
 tests/visual/out/
-tests/visual/package-lock.json
+
+# Installed npm trees, never the lockfiles that describe them. Both
+# package-lock.json files ARE committed on purpose: package.json pins only the
+# direct dependencies, so without the lock every transitive package resolves
+# fresh at install time. The lock carries an integrity hash for all 181 (root)
+# and 81 (tests/visual) packages, which is what makes `npm ci` reproducible and
+# what OpenSSF Scorecard's Pinned-Dependencies check asks for.
+node_modules/

{boost_skill_cli-1.0.284 → boost_skill_cli-1.0.286}/CLAUDE.md

@@ -11,7 +11,7 @@ make venv                                      # .venv from the hash-pinned requ
 .venv/bin/pytest tests/unit/test_catalog.py -q                    # one test file
 .venv/bin/pytest tests/unit/test_catalog.py::test_scan_dir -q     # one test
 .venv/bin/pytest tests/functional -q -k install                   # functional tests matching "install"
-make lint                                      # the whole static tier — see the recipe, it is 18 commands
+make lint                                      # the whole static tier — read the recipe, it is long
 make test                                      # unit + functional with 80% coverage gate
 make check                                     # the full required gate — see table below
 

{boost_skill_cli-1.0.284 → boost_skill_cli-1.0.286}/MANIFEST.in

@@ -9,4 +9,7 @@ prune .idea
 prune .claude
 prune .github
 exclude .coverage
+# The npm lint/test toolchain (stylelint, eslint, puppeteer-core, axe-core). CI
+# only; nothing in the shipped runtime touches node.
+exclude package.json package-lock.json
 global-exclude __pycache__ *.pyc *.pyo .DS_Store

{boost_skill_cli-1.0.284 → boost_skill_cli-1.0.286}/Makefile

@@ -61,7 +61,17 @@ lint:
 	$(VENV)/bin/interrogate boost_cli/core
 	$(VENV)/bin/refurb boost_cli
 	$(VENV)/bin/codespell boost_cli docs README.md
-	@if command -v actionlint >/dev/null 2>&1; then actionlint; \
+	@# actionlint does not lint `run:` blocks itself — it shells out to
+	@# shellcheck, and if shellcheck is not on PATH it skips them silently and
+	@# still exits 0. So `make lint` could report a clean workflow lint having
+	@# never looked inside a single script. shellcheck is pinned in
+	@# requirements/lint-tools.in for exactly this; put $(VENV)/bin on PATH so
+	@# actionlint finds it, and fail loudly rather than run a hollow check.
+	@if command -v actionlint >/dev/null 2>&1; then \
+	  if [ ! -x $(VENV)/bin/shellcheck ]; then \
+	    echo "shellcheck missing from $(VENV) — actionlint would skip every run: block. Re-run 'make venv'."; exit 1; \
+	  fi; \
+	  PATH="$(CURDIR)/$(VENV)/bin:$$PATH" actionlint; \
 	else echo "actionlint not on PATH — skipping (CI enforces it)"; fi
 	$(PY) scripts/build_registries.py --check
 	$(PY) scripts/build_roadmap.py --check

{boost_skill_cli-1.0.284 → boost_skill_cli-1.0.286}/PKG-INFO

@@ -1,6 +1,6 @@
 Metadata-Version: 2.4
 Name: boost-skill-cli
-Version: 1.0.284
+Version: 1.0.286
 Summary: boost — Homebrew for AI coding skills
 Author: Jonathan Reyes
 License: GNU GENERAL PUBLIC LICENSE

{boost_skill_cli-1.0.284 → boost_skill_cli-1.0.286}/boost_cli/_version.py

@@ -18,7 +18,7 @@ version_tuple: tuple[int | str, ...]
 commit_id: str | None
 __commit_id__: str | None
 
-__version__ = version = '1.0.284'
-__version_tuple__ = version_tuple = (1, 0, 284)
+__version__ = version = '1.0.286'
+__version_tuple__ = version_tuple = (1, 0, 286)
 
 __commit_id__ = commit_id = None

{boost_skill_cli-1.0.284 → boost_skill_cli-1.0.286}/boost_skill_cli.egg-info/PKG-INFO

@@ -1,6 +1,6 @@
 Metadata-Version: 2.4
 Name: boost-skill-cli
-Version: 1.0.284
+Version: 1.0.286
 Summary: boost — Homebrew for AI coding skills
 Author: Jonathan Reyes
 License: GNU GENERAL PUBLIC LICENSE

{boost_skill_cli-1.0.284 → boost_skill_cli-1.0.286}/boost_skill_cli.egg-info/SOURCES.txt

@@ -155,6 +155,7 @@ docs/roadmap/items/BOOST-D24.md
 docs/roadmap/items/BOOST-D25.md
 docs/roadmap/items/BOOST-D26.md
 docs/roadmap/items/accessibility-audit-pa11y-ci-axe-core.md
+docs/roadmap/items/actionlint-skips-shellcheck-silently.md
 docs/roadmap/items/adapter-conformance-langgraph-leg-never-ran.md
 docs/roadmap/items/ai-bridge-silent-failure-logging.md
 docs/roadmap/items/ambiguous-tap-short-name-resolution.md
@@ -528,5 +529,6 @@ tests/unit/test_workflow_timeouts.py
 tests/unit/test_workflows.py
 tests/visual/a11y_check.mjs
 tests/visual/console_check.mjs
+tests/visual/package-lock.json
 tests/visual/package.json
 tests/visual/visual_check.mjs

boost_skill_cli-1.0.286/docs/roadmap/items/actionlint-skips-shellcheck-silently.md

@@ -0,0 +1,58 @@
+---
+id: actionlint-skips-shellcheck-silently
+board: code
+section: dx
+status: shipped
+category: Testing · Bug
+complexity: S
+impact: Med
+wow: 4
+note: fixed — shellcheck is pinned in lint-tools and both gates now assert it is there
+order: 69
+owner: loop/lint-shellcheck
+pr:
+title: The second silent skip &mdash; <code>actionlint</code> runs, and checks no <code>run:</code> block at all
+---
+<code>make-lint-masks-actionlint-failures</code> fixed the layer everyone can see: <code>make
+lint</code> discarded actionlint's exit status. There is a second layer underneath it, and the
+first fix does not reach it. <b><code>actionlint</code> does not lint <code>run:</code> blocks
+itself.</b> It shells out to <code>shellcheck</code>, and when shellcheck is not on
+<code>PATH</code> it skips every one of them &mdash; no warning, no note, exit 0.
+
+Same workflow file, same actionlint binary, only <code>PATH</code> differs:
+
+<code>without shellcheck -&gt; (no output) exit=0</code><br>
+<code>with shellcheck    -&gt; bad.yml:8:9: shellcheck reported issue in this script: SC2001 &hellip; exit=1</code>
+
+So the honest description of the gate before this change was: <code>make lint</code> ran a workflow
+linter that silently declined to look inside any script, and reported success. That is not
+hypothetical either &mdash; it is exactly how an <code>SC2001</code> reached CI from a green local
+gate, in the very change that fixed layer one.
+
+<b>CI was not safe, only lucky.</b> Its actionlint step carried the comment "shellcheck is
+preinstalled on the runner, so run: blocks are checked too" &mdash; true today, and an unpinned,
+unversioned, silently revocable dependency on somebody else's base image. If GitHub ever drops it
+from <code>ubuntu-latest</code>, CI degrades to the same hollow check with no signal that anything
+changed. For a repository that hash-pins its entire lint toolchain precisely so an upstream release
+cannot move a gate underneath it, an implicit dependency on a runner image is the same bug in a
+different coat.
+
+<b>Shipped.</b> <code>shellcheck-py==0.11.0.1</code> is declared in
+<code>requirements/lint-tools.in</code> and hash-pinned into the generated
+<code>lint-tools.txt</code> like every other tool, which puts it on both sides: CI installs it from
+that lock, and <code>make venv</code> puts it in <code>.venv/bin</code>. <code>make lint</code> now
+prepends <code>.venv/bin</code> to <code>PATH</code> so actionlint can find it, and <b>fails</b> if
+it is missing rather than running a check it knows is hollow; CI asserts <code>command -v
+shellcheck</code> before invoking actionlint. Verified in four states against the real recipe: the
+tool absent (skip message, exit 0), shellcheck missing from the venv (exit 1 with a message naming
+the fix), both present and workflows clean (exit 0), and both present with an <code>SC2001</code> in
+a <code>run:</code> block (exit 1 &mdash; the case that used to pass). The old recipe on that same
+file exits 0.
+
+<b>What is deliberately still skipped.</b> If <code>actionlint</code> itself is absent,
+<code>make lint</code> prints a message and continues. Closing that would mean pinning
+<code>actionlint-py</code>, which is sdist-only and fetches the binary from the network at install
+time, and which tracks a different actionlint version than the URL-pinned one CI uses. Trading a
+pinned binary for a build-time download is a worse trade than the skip, so the skip stays and is
+documented rather than quietly tolerated. The wider gap named by the earlier card is also still
+open: <code>zizmor</code> and <code>gitleaks</code> run only in CI and have no Makefile equivalent.

boost_skill_cli-1.0.286/docs/roadmap/items/scorecard-findings-triage.md

@@ -0,0 +1,74 @@
+---
+id: scorecard-findings-triage
+board: code
+section: pipeline
+status: shipped
+category: Supply chain
+complexity: M
+impact: Med
+wow: 2
+note: 7 open · 3 now hash-pinned, 3 decided, 1 clears itself
+order: 13
+owner: loop/scorecard-pinned-deps
+pr:
+title: OpenSSF Scorecard's findings, triaged into three piles
+---
+Scorecard files into the same code-scanning inbox as CodeQL, so its findings read like
+code defects and get ignored alongside the false positives. They are not defects — they
+are <b>posture metrics</b>, and they must not be dismissed as "false positive" the way the
+<code>serve.py</code> traversal alerts legitimately were, because that misrepresents the
+repo's security posture. Triaged 2026-07-25, re-triaged 2026-07-29 against the 7 still open.
+<b>Fixed</b> — <code>TokenPermissions</code> #26/#27/#28: <code>ci</code>,
+<code>codeql</code> and <code>adapter-conformance</code> had no top-level
+<code>permissions:</code> block at all, scoring 0. Added <code>contents: read</code> as the
+least-privilege default.
+<b>Intentional, leave</b> — <code>TokenPermissions</code> #39/#37/#25/#24:
+<code>publish.yml</code> needs <code>contents: write</code> to create the release and tag,
+<code>osv-scanner</code> needs <code>security-events: write</code> to upload SARIF, and
+<code>ci.yml</code>'s <code>tests</code> job needs <code>contents: write</code> for the
+coverage-badge push. "Fixing" these breaks the release pipeline. They should be
+<b>dismissed as used-in-tests/acceptable-risk with a reason</b>, not left open to rot the list.
+<b>Correction — <code>PinnedDependencies</code> was NOT "not code-fixable".</b> The first
+pass filed #40/#41/#48 under <i>"npx and pip invocations inside steps, not actions, so
+SHA-pinning does not apply"</i>. That reads the check as being about action SHAs, and it
+is not: for npm the remediation is a <b>committed lockfile</b>, and all three hits were
+<code>npm install</code> steps. <code>tests/visual/package.json</code> pinned its two direct
+deps exactly — and <code>.gitignore</code> then <i>excluded the lockfile</i>, so 79
+transitive packages resolved fresh on every run. <code>theme-lint</code> was worse:
+<code>npm install stylelint@16 eslint@9</code> re-resolved the whole linter every run, so
+the linter CI executed was never the linter anyone reviewed. Both trees are now hash-pinned
+(181 + 81 packages, integrity on every one) and installed with <code>npm ci</code>;
+<code>dependabot.yml</code> gains both npm directories, because a pin with no update path is
+only half the job.
+<b>What the pin immediately exposed.</b> Committing the lock made
+<code>osv-scanner</code> able to see the transitive tree for the first time, and it failed
+the branch at once on <b>CVE-2026-14257</b> (<code>brace-expansion</code>, CVSS 7.5,
+unbounded expansion → OOM). Pre-existing, not introduced: the old floating
+<code>npm install eslint@9</code> resolved the same package, invisibly. The advisory's range
+is <i>all versions below 5.0.8</i>, so the 1.x maintenance line has no fix — and the obvious
+patch, an <code>overrides</code> entry forcing <code>brace-expansion@^5</code>, <b>breaks
+eslint</b>: v5 exports <code>{ expand }</code> where <code>minimatch@3</code> requires a
+callable default, so <code>eslint "style/**/*.{js,mjs}"</code> dies with
+<i>"expand is not a function"</i> while plain <code>eslint style/</code> still passes — a
+green-looking linter with a broken glob path. The real fix is upstream:
+<code>eslint@10</code> depends on <code>minimatch@^10.2.5</code>, which requires the patched
+<code>brace-expansion@^5.0.8</code>. Bumped 9.39.5 → 10.8.0; all 262 packages across both
+locks now return zero OSV advisories.
+<b>Open by decision, correctly</b> — <code>BranchProtectionID</code> #33 (4/10) and
+<code>CodeReviewID</code> #34 (0/26 approved changesets) are two readings of one deliberate
+choice recorded in <a href="#main-has-no-branch-protection">its own card</a>: require status
+checks, do <i>not</i> require reviews, because the working model is parallel
+<code>loop/*</code> branches that self-merge and there is no second reviewer. Every warning
+Scorecard prints under #33 — stale-review dismissal, required approvers, CODEOWNERS review,
+last-push approval — follows from that one choice. They stay open because the score is
+<b>accurate</b>: this repo really does merge without human review. Dismissing them would be
+the lie.
+<b>Clears itself</b> — <code>MaintainedID</code> #35 is <i>"repository was created within the
+last 90 days"</i>. Created 2026-07-17, so it resolves on its own around 2026-10-15. Nothing
+to do but not dismiss it.
+<b>Needs a human, not a commit</b> — <code>CIIBestPracticesID</code> #36 is the one
+remaining actionable finding, and it cannot be fixed from a branch: it asks whether the
+project is registered for an OpenSSF Best Practices badge, which means creating a project
+entry at <code>bestpractices.dev</code> under a real account and answering its criteria. The
+prerequisites are already in place (LICENSE, SECURITY.md, CONTRIBUTING.md,
+CODE_OF_CONDUCT.md, a published CI gate); only the registration is missing.

{boost_skill_cli-1.0.284 → boost_skill_cli-1.0.286}/docs/roadmap.html

@@ -110,7 +110,7 @@
       <div class="stat"><b>16</b><span>Shipped</span></div>
       <div class="stat"><b>1</b><span>Next up</span></div>
       <div class="stat"><b>4</b><span>Planned</span></div>
-      <div class="stat"><b>175</b><span>Loop finds</span></div>
+      <div class="stat"><b>176</b><span>Loop finds</span></div>
       <!-- /ROADMAP:stats -->
     </div>
   </section>
@@ -2015,13 +2015,13 @@ path is never used — that fixes the behaviour without satisfying Dependabot's
       </article>
 
       <article class="cap rcard" id="scorecard-findings-triage">
-        <div class="head"><span class="pill planned">Planned</span><span class="cat">Supply chain</span></div>
-        <h3>OpenSSF Scorecard's 15 findings, triaged into three piles</h3>
+        <div class="head"><span class="pill shipped">Shipped</span><span class="cat">Supply chain</span></div>
+        <h3>OpenSSF Scorecard's findings, triaged into three piles</h3>
         <p>Scorecard files into the same code-scanning inbox as CodeQL, so its findings read like
 code defects and get ignored alongside the false positives. They are not defects — they
 are <b>posture metrics</b>, and they must not be dismissed as "false positive" the way the
 <code>serve.py</code> traversal alerts legitimately were, because that misrepresents the
-repo's security posture. Triaged 2026-07-25:
+repo's security posture. Triaged 2026-07-25, re-triaged 2026-07-29 against the 7 still open.
 <b>Fixed</b> — <code>TokenPermissions</code> #26/#27/#28: <code>ci</code>,
 <code>codeql</code> and <code>adapter-conformance</code> had no top-level
 <code>permissions:</code> block at all, scoring 0. Added <code>contents: read</code> as the
@@ -2032,19 +2032,55 @@ least-privilege default.
 <code>ci.yml</code>'s <code>tests</code> job needs <code>contents: write</code> for the
 coverage-badge push. "Fixing" these breaks the release pipeline. They should be
 <b>dismissed as used-in-tests/acceptable-risk with a reason</b>, not left open to rot the list.
-<b>Not code-fixable</b> — <code>MaintainedID</code> is repository age; <code>CodeReviewID</code>
-counts approved changesets and is structurally 0 while loops self-merge;
-<code>CIIBestPracticesID</code> is an opt-in badge programme; the four
-<code>PinnedDependencies</code> hits are <code>npx</code> and <code>pip</code> invocations
-inside steps, not actions, so SHA-pinning does not apply to them as written.
-<code>BranchProtectionID</code> is tracked separately in
-<a href="#main-has-no-branch-protection">its own card</a> — it is a workflow decision, not a
-config oversight.</p>
+<b>Correction — <code>PinnedDependencies</code> was NOT "not code-fixable".</b> The first
+pass filed #40/#41/#48 under <i>"npx and pip invocations inside steps, not actions, so
+SHA-pinning does not apply"</i>. That reads the check as being about action SHAs, and it
+is not: for npm the remediation is a <b>committed lockfile</b>, and all three hits were
+<code>npm install</code> steps. <code>tests/visual/package.json</code> pinned its two direct
+deps exactly — and <code>.gitignore</code> then <i>excluded the lockfile</i>, so 79
+transitive packages resolved fresh on every run. <code>theme-lint</code> was worse:
+<code>npm install stylelint@16 eslint@9</code> re-resolved the whole linter every run, so
+the linter CI executed was never the linter anyone reviewed. Both trees are now hash-pinned
+(181 + 81 packages, integrity on every one) and installed with <code>npm ci</code>;
+<code>dependabot.yml</code> gains both npm directories, because a pin with no update path is
+only half the job.
+<b>What the pin immediately exposed.</b> Committing the lock made
+<code>osv-scanner</code> able to see the transitive tree for the first time, and it failed
+the branch at once on <b>CVE-2026-14257</b> (<code>brace-expansion</code>, CVSS 7.5,
+unbounded expansion → OOM). Pre-existing, not introduced: the old floating
+<code>npm install eslint@9</code> resolved the same package, invisibly. The advisory's range
+is <i>all versions below 5.0.8</i>, so the 1.x maintenance line has no fix — and the obvious
+patch, an <code>overrides</code> entry forcing <code>brace-expansion@^5</code>, <b>breaks
+eslint</b>: v5 exports <code>{ expand }</code> where <code>minimatch@3</code> requires a
+callable default, so <code>eslint "style/**/*.{js,mjs}"</code> dies with
+<i>"expand is not a function"</i> while plain <code>eslint style/</code> still passes — a
+green-looking linter with a broken glob path. The real fix is upstream:
+<code>eslint@10</code> depends on <code>minimatch@^10.2.5</code>, which requires the patched
+<code>brace-expansion@^5.0.8</code>. Bumped 9.39.5 → 10.8.0; all 262 packages across both
+locks now return zero OSV advisories.
+<b>Open by decision, correctly</b> — <code>BranchProtectionID</code> #33 (4/10) and
+<code>CodeReviewID</code> #34 (0/26 approved changesets) are two readings of one deliberate
+choice recorded in <a href="#main-has-no-branch-protection">its own card</a>: require status
+checks, do <i>not</i> require reviews, because the working model is parallel
+<code>loop/*</code> branches that self-merge and there is no second reviewer. Every warning
+Scorecard prints under #33 — stale-review dismissal, required approvers, CODEOWNERS review,
+last-push approval — follows from that one choice. They stay open because the score is
+<b>accurate</b>: this repo really does merge without human review. Dismissing them would be
+the lie.
+<b>Clears itself</b> — <code>MaintainedID</code> #35 is <i>"repository was created within the
+last 90 days"</i>. Created 2026-07-17, so it resolves on its own around 2026-10-15. Nothing
+to do but not dismiss it.
+<b>Needs a human, not a commit</b> — <code>CIIBestPracticesID</code> #36 is the one
+remaining actionable finding, and it cannot be fixed from a branch: it asks whether the
+project is registered for an OpenSSF Best Practices badge, which means creating a project
+entry at <code>bestpractices.dev</code> under a real account and answering its criteria. The
+prerequisites are already in place (LICENSE, SECURITY.md, CONTRIBUTING.md,
+CODE_OF_CONDUCT.md, a published CI gate); only the registration is missing.</p>
         <div class="meta">
           <span class="m">Complexity <b>M</b></span>
           <span class="m">Impact <b>Med</b></span>
           <span class="m">Wow <b class="wow">★★</b></span>
-          <span class="m">15 open · 3 fixed, 4 intentional, 5 not code-fixable</span>
+          <span class="m">7 open · 3 now hash-pinned, 3 decided, 1 clears itself</span>
         </div>
       </article>
 
@@ -3181,6 +3217,60 @@ regresses.</p>
           <span class="m">agent reflex</span>
         </div>
       </article>
+
+      <article class="cap rcard" id="actionlint-skips-shellcheck-silently">
+        <div class="head"><span class="pill shipped">Shipped</span><span class="cat">Testing · Bug</span></div>
+        <h3>The second silent skip &mdash; <code>actionlint</code> runs, and checks no <code>run:</code> block at all</h3>
+        <p><code>make-lint-masks-actionlint-failures</code> fixed the layer everyone can see: <code>make
+lint</code> discarded actionlint's exit status. There is a second layer underneath it, and the
+first fix does not reach it. <b><code>actionlint</code> does not lint <code>run:</code> blocks
+itself.</b> It shells out to <code>shellcheck</code>, and when shellcheck is not on
+<code>PATH</code> it skips every one of them &mdash; no warning, no note, exit 0.
+
+Same workflow file, same actionlint binary, only <code>PATH</code> differs:
+
+<code>without shellcheck -&gt; (no output) exit=0</code><br>
+<code>with shellcheck    -&gt; bad.yml:8:9: shellcheck reported issue in this script: SC2001 &hellip; exit=1</code>
+
+So the honest description of the gate before this change was: <code>make lint</code> ran a workflow
+linter that silently declined to look inside any script, and reported success. That is not
+hypothetical either &mdash; it is exactly how an <code>SC2001</code> reached CI from a green local
+gate, in the very change that fixed layer one.
+
+<b>CI was not safe, only lucky.</b> Its actionlint step carried the comment "shellcheck is
+preinstalled on the runner, so run: blocks are checked too" &mdash; true today, and an unpinned,
+unversioned, silently revocable dependency on somebody else's base image. If GitHub ever drops it
+from <code>ubuntu-latest</code>, CI degrades to the same hollow check with no signal that anything
+changed. For a repository that hash-pins its entire lint toolchain precisely so an upstream release
+cannot move a gate underneath it, an implicit dependency on a runner image is the same bug in a
+different coat.
+
+<b>Shipped.</b> <code>shellcheck-py==0.11.0.1</code> is declared in
+<code>requirements/lint-tools.in</code> and hash-pinned into the generated
+<code>lint-tools.txt</code> like every other tool, which puts it on both sides: CI installs it from
+that lock, and <code>make venv</code> puts it in <code>.venv/bin</code>. <code>make lint</code> now
+prepends <code>.venv/bin</code> to <code>PATH</code> so actionlint can find it, and <b>fails</b> if
+it is missing rather than running a check it knows is hollow; CI asserts <code>command -v
+shellcheck</code> before invoking actionlint. Verified in four states against the real recipe: the
+tool absent (skip message, exit 0), shellcheck missing from the venv (exit 1 with a message naming
+the fix), both present and workflows clean (exit 0), and both present with an <code>SC2001</code> in
+a <code>run:</code> block (exit 1 &mdash; the case that used to pass). The old recipe on that same
+file exits 0.
+
+<b>What is deliberately still skipped.</b> If <code>actionlint</code> itself is absent,
+<code>make lint</code> prints a message and continues. Closing that would mean pinning
+<code>actionlint-py</code>, which is sdist-only and fetches the binary from the network at install
+time, and which tracks a different actionlint version than the URL-pinned one CI uses. Trading a
+pinned binary for a build-time download is a worse trade than the skip, so the skip stays and is
+documented rather than quietly tolerated. The wider gap named by the earlier card is also still
+open: <code>zizmor</code> and <code>gitleaks</code> run only in CI and have no Makefile equivalent.</p>
+        <div class="meta">
+          <span class="m">Complexity <b>S</b></span>
+          <span class="m">Impact <b>Med</b></span>
+          <span class="m">Wow <b class="wow">★★★★</b></span>
+          <span class="m">fixed — shellcheck is pinned in lint-tools and both gates now assert it is there</span>
+        </div>
+      </article>
       <!-- /ROADMAP:cards -->
 
     </div>

{boost_skill_cli-1.0.284 → boost_skill_cli-1.0.286}/requirements/lint-tools.in

@@ -30,3 +30,13 @@ interrogate==1.7.0
 # itself, which is why this set is lint-only and never a runtime dependency.
 # Reuses the mypy pinned above.
 refurb==2.3.1
+# shellcheck, as a pinned dependency rather than an assumption. actionlint does
+# not lint `run:` blocks itself — it shells out to shellcheck, and when
+# shellcheck is not on PATH it skips that entirely and still exits 0. Same
+# workflow file, same actionlint: without shellcheck, no output and exit 0; with
+# it, `SC2001` and exit 1. CI got away with it because the GitHub runner image
+# happens to preinstall shellcheck, which is an unpinned, unversioned, silently
+# revocable dependency on somebody else's base image — and locally, where it is
+# usually absent, `make lint` was passing a check it never ran. Pinning it here
+# puts it on both sides and makes the version reviewable like every other tool.
+shellcheck-py==0.11.0.1

{boost_skill_cli-1.0.284 → boost_skill_cli-1.0.286}/requirements/lint-tools.txt

@@ -564,6 +564,13 @@ ruff==0.16.0 \
     --hash=sha256:e5115729eb08c585e5121978ba5d5b60caeae394ce21b9fb5e6cd33a1c6c9b1e \
     --hash=sha256:e95c448fca1fb2a18372a9440926c5a6ee789639bb975c72e7ae6d0b04218ab4
     # via -r requirements/lint-tools.in
+shellcheck-py==0.11.0.1 \
+    --hash=sha256:1b274df81de5b000ff78db433e7328b87e52e3c38481c60f8e488c3095beef05 \
+    --hash=sha256:5c620c88901e8f1d3be5934b31ea99e3310065e1245253741eafd0a275c8c9cc \
+    --hash=sha256:6b88d0a244c82ed07e06a53e444da841f69330ca59ae15d4a66c391655dae7a0 \
+    --hash=sha256:784156289ecb17e91c692cd783ab5152333309588cabb10032a047331c63e759 \
+    --hash=sha256:b6a3fee28efda2e16e38d6e6d59faf7224300256456639727370d404730849e8
+    # via -r requirements/lint-tools.in
 six==1.17.0 \
     --hash=sha256:4721f391ed90541fddacab5acf947aa0d3dc7d27b2e1e8eda2be8970586c3274 \
     --hash=sha256:ff70335d468e7eb6ec65b95b99d3a2836546063f63acc5171de367e834932a81