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

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

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

{boost_skill_cli-1.0.282 → boost_skill_cli-1.0.284}/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.282'
-__version_tuple__ = version_tuple = (1, 0, 282)
+__version__ = version = '1.0.284'
+__version_tuple__ = version_tuple = (1, 0, 284)
 
 __commit_id__ = commit_id = None

{boost_skill_cli-1.0.282 → boost_skill_cli-1.0.284}/boost_cli/commands/configuration.py

@@ -917,11 +917,14 @@ def _tool_discover_github(args: dict):
 
 REGISTRY.register(
     "boost_search",
-    "FIRST STOP before writing a skill, subagent, slash-command, rule, or any "
-    "reusable block of agent instructions from scratch: search thousands of "
-    "curated, installable AI-agent skills across the configured registries. "
-    "Returns ranked matches you can install in one call — don't reinvent one "
-    "that already exists.",
+    "Find an existing, installable skill instead of improvising one. Reach for "
+    "this at two moments: (1) when starting non-trivial work — check whether a "
+    "vetted skill already covers the task before planning it yourself; (2) as "
+    "the FIRST STOP before writing a skill, subagent, slash-command, rule, or "
+    "any reusable block of agent instructions from scratch. Searches thousands "
+    "of curated AI-agent skills across the configured registries and returns "
+    "ranked matches you can install in one call — don't reinvent one that "
+    "already exists.",
     {"type": "object",
      "properties": {"query": {"type": "string",
                               "description": "what the skill should do (a task, "
@@ -930,8 +933,10 @@ REGISTRY.register(
     _tool_search)
 REGISTRY.register(
     "boost_list",
-    "List the skills already installed by boost — check here first to avoid "
-    "reinstalling or duplicating something you already have.",
+    "List the skills already installed and usable right now. Check at the "
+    "START of a task to leverage a capability you already have — an installed "
+    "skill is a vetted procedure you can follow immediately, at no cost — and "
+    "again before installing, to avoid duplicating something you have.",
     {"type": "object", "properties": {}},
     _tool_list)
 REGISTRY.register(

{boost_skill_cli-1.0.282 → boost_skill_cli-1.0.284}/boost_cli/core/mcp.py

@@ -83,19 +83,46 @@ PROTOCOL_VERSION = "2024-11-05"
 # Server-level guidance returned in the `initialize` result. MCP hosts load this
 # into the model's context, so it is boost's one chance to tell an agent WHEN it
 # is relevant — the difference between a search tool that sits unused and one an
-# agent reaches for before reinventing a skill. Framed by the agent's trigger
-# ("about to author reusable instructions"), not boost's nouns.
+# agent reaches for. Framed by the agent's triggers, not boost's nouns.
+#
+# It declares TWO triggers, and the first exists because the second alone was
+# not enough. Framed only as "before you author a skill", agents reached for
+# boost exclusively when they were already about to write one — which is the
+# rarer moment. The common one is starting ordinary work that an installed or
+# installable skill already covers, and nothing was telling them to look. The
+# closing proportion note is load-bearing in the other direction: an unbounded
+# "always check first" turns every trivial turn into a tool call, and an agent
+# that learns to ignore the guidance ignores all of it.
 INSTRUCTIONS = (
     "boost is a package manager for AI-agent skills: reusable, version-tracked "
     "capabilities (skills, rules, slash-commands, subagents) from curated "
-    "registries. BEFORE you author a new skill, subagent, slash-command, rule, "
-    "or any reusable block of agent instructions — or when the user describes a "
-    "repeatable workflow (\"set up code review\", \"add a commit convention\") — "
-    "call boost_search FIRST to check whether a vetted one already exists. "
-    "Installing beats hand-writing: an installed skill is version-pinned, wired "
-    "into every agent on this machine, policy-governed, and shareable with the "
-    "team. Typical flow: boost_search -> boost_info -> boost_install. Only build "
-    "from scratch when a search turns up nothing relevant."
+    "registries.\n"
+    "\n"
+    "Two moments make boost relevant. The first is the one usually missed:\n"
+    "\n"
+    "1. STARTING A TASK. Before doing non-trivial work — building a feature, "
+    "setting up tooling or CI, reviewing code, debugging a class of problem, "
+    "writing docs — stop and check whether a skill already covers it. Call "
+    "boost_list for what is installed and usable right now, and boost_search "
+    "for what could be. A matching skill is a procedure someone already got "
+    "right and vetted; following it beats reconstructing the same steps from "
+    "memory.\n"
+    "\n"
+    "2. AUTHORING. Before you write a new skill, subagent, slash-command, "
+    "rule, or any reusable block of agent instructions — or when the user "
+    "describes a repeatable workflow (\"set up code review\", \"add a commit "
+    "convention\") — call boost_search FIRST to check whether a vetted one "
+    "already exists. Installing beats hand-writing: an installed skill is "
+    "version-pinned, wired into every agent on this machine, policy-governed, "
+    "and shareable with the team.\n"
+    "\n"
+    "Typical flow: boost_search -> boost_info -> boost_install. Only build "
+    "from scratch when a search turns up nothing relevant.\n"
+    "\n"
+    "Proportion: skip the check for trivial or one-off turns — answering a "
+    "question, a small edit, running a command you were just handed. Checking "
+    "once when a task starts is the habit; checking before every tool call is "
+    "noise."
 )
 
 

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

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

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

@@ -232,6 +232,7 @@ docs/roadmap/items/make-the-roadmaps-discoverable.md
 docs/roadmap/items/markdown-consistency-markdownlint-cli2.md
 docs/roadmap/items/markdownlint-lints-the-fuzz-corpus.md
 docs/roadmap/items/mcp-aware-skills.md
+docs/roadmap/items/mcp-check-skills-before-starting-a-task.md
 docs/roadmap/items/mcp-hub-diagram-node-text-overflow.md
 docs/roadmap/items/mcp-launch-objc-fork-safety.md
 docs/roadmap/items/mcp-register-names-server-before-env.md
@@ -287,6 +288,7 @@ docs/roadmap/items/rule-install-native-materialization.md
 docs/roadmap/items/runner-egress-monitoring-stepsecurity-harden-run.md
 docs/roadmap/items/runtime-explain-faithfulness-guardrail.md
 docs/roadmap/items/sbom-aware-scanning-osv-scanner.md
+docs/roadmap/items/sbom-declares-the-wrong-version.md
 docs/roadmap/items/sbom-on-every-release-cyclonedx-syft.md
 docs/roadmap/items/sbom-release-event-never-fires.md
 docs/roadmap/items/scan-and-sync-rules-and-workflows.md

boost_skill_cli-1.0.284/docs/roadmap/items/mcp-check-skills-before-starting-a-task.md

@@ -0,0 +1,30 @@
+---
+id: mcp-check-skills-before-starting-a-task
+board: code
+section: dx
+status: inflight
+category: Interop · Adoption
+complexity: S
+impact: High
+wow: 3
+note: agent reflex
+order: 64
+owner: mcp-task-entrance
+pr: 318
+title: MCP — check for a skill when a task starts, not only when authoring one
+---
+<a href="#mcp-search-before-reinventing">The previous pass</a> gave the MCP server
+<code>initialize</code> <code>instructions</code> and intent-framed tool descriptions, but
+framed both around a single trigger: <em>before you author a new skill</em>. That is the
+rarer moment. Observed behaviour matched the framing exactly — agents called
+<code>boost_search</code> only when they were already about to write a skill, and never to ask
+whether an installed one covered the work in front of them. The common case, starting
+ordinary work that a vetted skill already handles, had nothing pointing at it.
+Broaden to <strong>two</strong> declared triggers: <em>starting a task</em> (call
+<code>boost_list</code> for what is usable right now, <code>boost_search</code> for what could
+be) and the existing <em>authoring</em> one. <code>boost_list</code> is re-framed from "avoid a
+duplicate install" to "leverage a capability you already have" — it is the free half of the
+check. A closing proportion note bounds it, because an unbounded <em>always check first</em>
+turns every trivial turn into a tool call and an agent that learns to ignore the guidance
+ignores all of it. Both triggers and the bound are pinned by tests, so dropping either
+regresses.

{boost_skill_cli-1.0.282 → boost_skill_cli-1.0.284}/docs/roadmap/items/one-commit-can-cut-two-releases.md

@@ -48,5 +48,9 @@ ci will trigger its own release, but it means some merges never get their own ve
 
 <b>Already mitigated:</b> <code>sbom.yml</code> now builds and attaches an SBOM for <em>every</em>
 tag on the commit rather than only the highest, so a duplicate release no longer produces a release
-with no SBOM. Each tag is built separately, because setuptools-scm reads the version from the tag
-and one SBOM cannot honestly describe two versions.
+with no SBOM. Each tag is built separately so its SBOM carries its own version.
+
+<b>Correction:</b> the claim above originally read "because setuptools-scm reads the version from
+the tag", and that is false — it reads the version from the <em>commit</em>, so separate checkouts
+of two tags on one commit produce the same version. That was a second, quieter consequence of the
+duplicate release, fixed separately in <code>sbom-declares-the-wrong-version</code>.

boost_skill_cli-1.0.284/docs/roadmap/items/sbom-declares-the-wrong-version.md

@@ -0,0 +1,54 @@
+---
+id: sbom-declares-the-wrong-version
+board: code
+section: trust
+status: shipped
+category: Supply chain · Bug
+complexity: S
+impact: High
+wow: 5
+note: fixed — release v1.0.278's SBOM declared 1.0.277; the version is now pinned to the tag
+order: 68
+owner: loop/sbom-tag-version
+pr:
+title: The SBOM can declare a different version than the release it is attached to
+---
+<code>sbom.yml</code> builds each released tag separately so that every release gets an SBOM
+describing <em>its own</em> version. It does that by checking the tag out:
+<code>git checkout --detach "refs/tags/$TAG"</code>. The premise is wrong.
+<b>setuptools-scm derives the version from the commit, not from the ref used to reach it</b>, so
+when one commit carries two tags every checkout resolves to the same version — whichever one
+<code>git describe</code> picks, which is not the highest.
+
+Measured against the real repository, detached at each tag in turn:
+
+<code>checked out v1.0.278 -&gt; setuptools-scm says: 1.0.277</code><br>
+<code>checked out v1.0.277 -&gt; setuptools-scm says: 1.0.277</code>
+
+And confirmed in production rather than in a fixture — the published asset on
+<code>v1.0.278</code>, downloaded from the release, contains
+<code>{"name": "boost-skill-cli", "version": "1.0.277"}</code>. <b>The SBOM attached to release
+v1.0.278 describes v1.0.277.</b> A consumer resolving that release's bill of materials gets a
+document for a different version, which is precisely the trust property an SBOM exists to provide.
+
+The blast radius is bounded by how often one commit cuts two releases, which
+<code>one-commit-can-cut-two-releases</code> documents happening three times so far
+(<code>246</code>/<code>247</code>, <code>248</code>/<code>249</code>, <code>277</code>/<code>278</code>).
+Every duplicate pair mislabels one of its two SBOMs. It is <em>not</em> latent in
+<code>publish.yml</code>, which builds the PyPI dist: that job checks out before the sibling run's
+tag exists, so it happens to resolve correctly — all 281 PyPI versions are present and correctly
+numbered. The defect is specific to the job that runs <em>after</em> both tags are in place.
+
+<b>Shipped.</b> The build now pins the version to the tag it is building
+(<code>SETUPTOOLS_SCM_PRETEND_VERSION_FOR_BOOST_SKILL_CLI="${TAG#v}"</code>) and then asserts the
+wheel it produced carries that version, so a package rename — which would silently unhook the
+scoped variable and restore the bug — fails the job instead of shipping a mislabelled document.
+Verified both ways against the live repository: without the pin, <code>v1.0.278</code> resolves to
+<code>1.0.277</code>; with it, <code>1.0.278</code>.
+
+The same exercise settled the other thing this workflow had never proven: the multi-tag loop
+itself. Both <code>run:</code> blocks were extracted verbatim from the YAML and driven against a
+fixture repository with two tags on one commit, with <code>gh</code> and the build toolchain
+stubbed. Resolution returns both tags newest-first, the loop iterates both, and it issues a
+separate <code>upload</code> and a separate post-upload <code>view</code> assertion per tag. That
+path had never executed in production — every commit since it shipped has carried exactly one tag.

{boost_skill_cli-1.0.282 → boost_skill_cli-1.0.284}/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>173</b><span>Loop finds</span></div>
+      <div class="stat"><b>175</b><span>Loop finds</span></div>
       <!-- /ROADMAP:stats -->
     </div>
   </section>
@@ -2707,8 +2707,12 @@ ci will trigger its own release, but it means some merges never get their own ve
 
 <b>Already mitigated:</b> <code>sbom.yml</code> now builds and attaches an SBOM for <em>every</em>
 tag on the commit rather than only the highest, so a duplicate release no longer produces a release
-with no SBOM. Each tag is built separately, because setuptools-scm reads the version from the tag
-and one SBOM cannot honestly describe two versions.</p>
+with no SBOM. Each tag is built separately so its SBOM carries its own version.
+
+<b>Correction:</b> the claim above originally read "because setuptools-scm reads the version from
+the tag", and that is false — it reads the version from the <em>commit</em>, so separate checkouts
+of two tags on one commit produce the same version. That was a second, quieter consequence of the
+duplicate release, fixed separately in <code>sbom-declares-the-wrong-version</code>.</p>
         <div class="meta">
           <span class="m">Complexity <b>M</b></span>
           <span class="m">Impact <b>Med</b></span>
@@ -3151,6 +3155,32 @@ three states: a <b>failing</b> actionlint now fails <code>make</code> (exit 2) i
           <span class="m">fixed — a failing actionlint now fails make, in all three targets</span>
         </div>
       </article>
+
+      <article class="cap rcard" id="mcp-check-skills-before-starting-a-task">
+        <div class="head"><span class="pill inflight">In flight</span><span class="cat">Interop · Adoption</span></div>
+        <h3>MCP — check for a skill when a task starts, not only when authoring one</h3>
+        <p><a href="#mcp-search-before-reinventing">The previous pass</a> gave the MCP server
+<code>initialize</code> <code>instructions</code> and intent-framed tool descriptions, but
+framed both around a single trigger: <em>before you author a new skill</em>. That is the
+rarer moment. Observed behaviour matched the framing exactly — agents called
+<code>boost_search</code> only when they were already about to write a skill, and never to ask
+whether an installed one covered the work in front of them. The common case, starting
+ordinary work that a vetted skill already handles, had nothing pointing at it.
+Broaden to <strong>two</strong> declared triggers: <em>starting a task</em> (call
+<code>boost_list</code> for what is usable right now, <code>boost_search</code> for what could
+be) and the existing <em>authoring</em> one. <code>boost_list</code> is re-framed from "avoid a
+duplicate install" to "leverage a capability you already have" — it is the free half of the
+check. A closing proportion note bounds it, because an unbounded <em>always check first</em>
+turns every trivial turn into a tool call and an agent that learns to ignore the guidance
+ignores all of it. Both triggers and the bound are pinned by tests, so dropping either
+regresses.</p>
+        <div class="meta">
+          <span class="m">Complexity <b>S</b></span>
+          <span class="m hi">Impact <b>High</b></span>
+          <span class="m">Wow <b class="wow">★★★</b></span>
+          <span class="m">agent reflex</span>
+        </div>
+      </article>
       <!-- /ROADMAP:cards -->
 
     </div>
@@ -4253,6 +4283,56 @@ having found error-severity alerts.</p>
           <span class="m">safe scoped to CodeQL (0 open) — adding Scorecard deadlocks every merge</span>
         </div>
       </article>
+
+      <article class="cap rcard" id="sbom-declares-the-wrong-version">
+        <div class="head"><span class="pill shipped">Shipped</span><span class="cat">Supply chain · Bug</span></div>
+        <h3>The SBOM can declare a different version than the release it is attached to</h3>
+        <p><code>sbom.yml</code> builds each released tag separately so that every release gets an SBOM
+describing <em>its own</em> version. It does that by checking the tag out:
+<code>git checkout --detach "refs/tags/$TAG"</code>. The premise is wrong.
+<b>setuptools-scm derives the version from the commit, not from the ref used to reach it</b>, so
+when one commit carries two tags every checkout resolves to the same version — whichever one
+<code>git describe</code> picks, which is not the highest.
+
+Measured against the real repository, detached at each tag in turn:
+
+<code>checked out v1.0.278 -&gt; setuptools-scm says: 1.0.277</code><br>
+<code>checked out v1.0.277 -&gt; setuptools-scm says: 1.0.277</code>
+
+And confirmed in production rather than in a fixture — the published asset on
+<code>v1.0.278</code>, downloaded from the release, contains
+<code>{"name": "boost-skill-cli", "version": "1.0.277"}</code>. <b>The SBOM attached to release
+v1.0.278 describes v1.0.277.</b> A consumer resolving that release's bill of materials gets a
+document for a different version, which is precisely the trust property an SBOM exists to provide.
+
+The blast radius is bounded by how often one commit cuts two releases, which
+<code>one-commit-can-cut-two-releases</code> documents happening three times so far
+(<code>246</code>/<code>247</code>, <code>248</code>/<code>249</code>, <code>277</code>/<code>278</code>).
+Every duplicate pair mislabels one of its two SBOMs. It is <em>not</em> latent in
+<code>publish.yml</code>, which builds the PyPI dist: that job checks out before the sibling run's
+tag exists, so it happens to resolve correctly — all 281 PyPI versions are present and correctly
+numbered. The defect is specific to the job that runs <em>after</em> both tags are in place.
+
+<b>Shipped.</b> The build now pins the version to the tag it is building
+(<code>SETUPTOOLS_SCM_PRETEND_VERSION_FOR_BOOST_SKILL_CLI="${TAG#v}"</code>) and then asserts the
+wheel it produced carries that version, so a package rename — which would silently unhook the
+scoped variable and restore the bug — fails the job instead of shipping a mislabelled document.
+Verified both ways against the live repository: without the pin, <code>v1.0.278</code> resolves to
+<code>1.0.277</code>; with it, <code>1.0.278</code>.
+
+The same exercise settled the other thing this workflow had never proven: the multi-tag loop
+itself. Both <code>run:</code> blocks were extracted verbatim from the YAML and driven against a
+fixture repository with two tags on one commit, with <code>gh</code> and the build toolchain
+stubbed. Resolution returns both tags newest-first, the loop iterates both, and it issues a
+separate <code>upload</code> and a separate post-upload <code>view</code> assertion per tag. That
+path had never executed in production — every commit since it shipped has carried exactly one tag.</p>
+        <div class="meta">
+          <span class="m">Complexity <b>S</b></span>
+          <span class="m hi">Impact <b>High</b></span>
+          <span class="m">Wow <b class="wow">★★★★★</b></span>
+          <span class="m">fixed — release v1.0.278's SBOM declared 1.0.277; the version is now pinned to the tag</span>
+        </div>
+      </article>
       <!-- /ROADMAP:cards -->
 
     </div>

{boost_skill_cli-1.0.282 → boost_skill_cli-1.0.284}/tests/functional/test_cli_configuration.py

@@ -876,8 +876,15 @@ class TestMcp:
         from boost_cli.commands import configuration
         specs = {s["name"]: s["description"].lower()
                  for s in configuration.REGISTRY.specs()}
+        # search carries BOTH triggers: starting a task, and authoring. The
+        # second alone is why the tool sat unused for ordinary work.
+        assert "starting non-trivial work" in specs["boost_search"]
         assert "first stop before writing" in specs["boost_search"]
         assert "reinvent" in specs["boost_search"]
+        # list is the cheap half of the task-start check — leverage what is
+        # already installed, not merely "avoid a duplicate install".
+        assert "start" in specs["boost_list"]
+        assert "leverage" in specs["boost_list"]
         # install points back at the search that should precede it
         assert "boost_search" in specs["boost_install"]
         # info is framed as the vet-before-install step

{boost_skill_cli-1.0.282 → boost_skill_cli-1.0.284}/tests/unit/test_mcp.py

@@ -116,9 +116,17 @@ class TestHandleRequest:
         instr = resp["result"]["instructions"]
         assert instr == mcp.INSTRUCTIONS
         low = instr.lower()
-        assert "before you author" in low          # the trigger moment
+        # TWO triggers must survive here. Authoring alone was the original
+        # framing and it under-fired: agents reached for boost only when about
+        # to write a skill, never to check whether one already covered the work
+        # in front of them. Dropping either trigger regresses that.
+        assert "starting a task" in low            # trigger 1: leverage first
+        assert "boost_list" in instr               # ...what is already installed
+        assert "before you write a new skill" in low   # trigger 2: authoring
         assert "boost_search" in instr             # the concrete first action
         assert "already exists" in low             # the "don't reinvent" frame
+        # ...and it must stay bounded, or an agent learns to ignore all of it.
+        assert "skip the check for trivial" in low
 
     def test_protocol_version_constant(self):
         assert mcp.PROTOCOL_VERSION == "2024-11-05"