boost-skill-cli 1.0.313__tar.gz → 1.0.314__tar.gz

{boost_skill_cli-1.0.313/boost_skill_cli.egg-info → boost_skill_cli-1.0.314}/PKG-INFO

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

{boost_skill_cli-1.0.313 → boost_skill_cli-1.0.314}/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.313'
-__version_tuple__ = version_tuple = (1, 0, 313)
+__version__ = version = '1.0.314'
+__version_tuple__ = version_tuple = (1, 0, 314)
 
 __commit_id__ = commit_id = None

{boost_skill_cli-1.0.313 → boost_skill_cli-1.0.314}/boost_cli/core/rag.py

@@ -421,10 +421,48 @@ def rerank(query: str, hits: List[Hit], limit: int = 10) -> Tuple[List[Hit], str
     return (picked + rest)[:limit], "Claude relevance"
 
 
+# The damping constant from the original reciprocal-rank-fusion paper. It is
+# why plain RRF needs no tuning: large enough that the top few ranks are close
+# together, so one engine's confident #1 cannot bury the other engine's #2.
+RRF_K = 60
+
+
+def rrf_fuse(rankings: List[List[Hit]], limit: int = 60) -> List[Hit]:
+    """Fuse ranked hit lists by reciprocal rank: ``sum 1/(RRF_K + rank)``.
+
+    Fuses on **ranks, not scores**, which is the whole point. A BM25 score and
+    a cosine similarity are on incomparable scales, so blending them needs a
+    calibration step that has to be fitted and re-fitted per corpus; rank
+    fusion sidesteps it entirely and is the respected zero-tuning default.
+
+    Entries are identified by ``(name, tap)`` — the same key both engines
+    already dedupe on — and the first ranking's hit object wins, so the caller
+    passes BM25 first and keeps its query-term-highlighted snippet for display.
+
+    The returned ``score`` is the fused rank score, not a BM25 score: it exists
+    to order these hits against each other, and comparing it to a raw BM25
+    score from elsewhere would be meaningless.
+    """
+    scores: Dict[Tuple[str, str], float] = {}
+    chosen: Dict[Tuple[str, str], Hit] = {}
+    for hits in rankings:
+        for rank, hit in enumerate(hits, start=1):
+            entry = hit["entry"]
+            key = (entry["name"], entry["tap"])
+            scores[key] = scores.get(key, 0.0) + 1.0 / (RRF_K + rank)
+            chosen.setdefault(key, hit)
+    ordered = sorted(scores, key=lambda key: (-scores[key], key[0], key[1]))
+    fused: List[Hit] = [
+        {"entry": chosen[key]["entry"], "score": scores[key],
+         "snippet": chosen[key]["snippet"]}  # type: ignore[typeddict-item]
+        for key in ordered[:limit]]
+    return fused
+
+
 def retrieve_any(query: str, k: int = 60, kind: Optional[str] = None,
                  entries: Optional[List[dict]] = None
                  ) -> Tuple[Optional[List[Hit]], str]:
-    """Prefer the opt-in dense backend, floor to BM25.
+    """Fuse BM25 and dense when both are available; floor to whichever is.
 
     Returns ``(hits, engine_label)``; ``hits`` is ``None`` only when no index of
     any kind exists so the caller can fall back to ``catalog.search``.
@@ -432,21 +470,37 @@ def retrieve_any(query: str, k: int = 60, kind: Optional[str] = None,
     Public because every retrieval entry point must make the same engine
     choice: `cmd_search` calling ``retrieve`` directly meant the CLI could
     never use a built dense index, while the MCP path could.
+
+    This used to *prefer* dense whenever it was ready. The golden-set eval
+    retired that: over 91 queries BM25 and local dense tie on hit@1, with the
+    recall and MRR gaps inside the noise floor, while human-phrased queries
+    separate them sharply in opposite directions. Preferring either one hands
+    half the queries to the engine that is worse at them, so they are fused.
+
+    Both engines are over-fetched to ``RRF_K`` before fusing. Fusing only the
+    top-k of each would discard exactly the candidates the other engine was
+    going to promote, which is most of the value.
     """
     from . import dense
-    if dense.ready():
-        hits = dense.retrieve(query, k=k, kind=kind, entries=entries)
-        # An empty list is not the same answer as None. ``dense.retrieve``
-        # returns ``[]`` whenever every KNN neighbour was dropped for a kind
-        # mismatch or for no longer being live, which is a *thin index*, not a
-        # verdict on the query — and taking it as final short-circuits the
-        # documented "everything degrades to BM25" contract, so `boost search`
-        # answered "no results" while a perfectly good BM25 index sat unused.
-        # Only a non-empty dense result is final.
-        if hits:
-            return hits, "dense vectors"
-    if ready():
-        return retrieve(query, k=k, kind=kind, entries=entries), "BM25 full-content"
+    pool = max(k, RRF_K)
+    dense_hits = dense.retrieve(query, k=pool, kind=kind,
+                                entries=entries) if dense.ready() else None
+    # An empty list is not the same answer as None. ``dense.retrieve`` returns
+    # ``[]`` whenever every KNN neighbour was dropped for a kind mismatch or
+    # for no longer being live, which is a *thin index*, not a verdict on the
+    # query — and taking it as final short-circuits the documented "everything
+    # degrades to BM25" contract, so `boost search` answered "no results" while
+    # a perfectly good BM25 index sat unused. Only a non-empty dense result
+    # counts as a ranking to fuse.
+    bm25_hits = retrieve(query, k=pool, kind=kind,
+                         entries=entries) if ready() else None
+    if dense_hits and bm25_hits:
+        return (rrf_fuse([bm25_hits, dense_hits], limit=k),
+                "hybrid RRF (BM25 + dense)")
+    if dense_hits:
+        return dense_hits[:k], "dense vectors"
+    if bm25_hits is not None:
+        return bm25_hits[:k], "BM25 full-content"
     return None, ""
 
 

{boost_skill_cli-1.0.313 → boost_skill_cli-1.0.314/boost_skill_cli.egg-info}/PKG-INFO

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

{boost_skill_cli-1.0.313 → boost_skill_cli-1.0.314}/boost_skill_cli.egg-info/SOURCES.txt

@@ -421,6 +421,7 @@ tests/bdd/features/steps/mcp_steps.py
 tests/bdd/features/steps/quality_steps.py
 tests/eval/baseline.json
 tests/eval/explain.jsonl
+tests/eval/golden-natural.jsonl
 tests/eval/golden.jsonl
 tests/eval/recommend.jsonl
 tests/eval/taps.txt
@@ -534,6 +535,7 @@ tests/unit/test_project_mcp_sidecar.py
 tests/unit/test_projectlock.py
 tests/unit/test_provenance.py
 tests/unit/test_rag.py
+tests/unit/test_rag_fusion.py
 tests/unit/test_registries_fresh.py
 tests/unit/test_registry.py
 tests/unit/test_registry_categories.py

{boost_skill_cli-1.0.313 → boost_skill_cli-1.0.314}/docs/roadmap/items/keyless-semantic-search-for-everyone.md

@@ -194,3 +194,69 @@ A rerun stored all 3740, and two 30-batch replays never reproduced a failure, so
 resource pressure rather than a defect — the retry path (no commit recorded for a failed tap)
 did its job. The figures above come from a complete index.
 
+<b>Step 4 shipped, measured against the same 91 queries.</b> <code>retrieve_any</code> no longer
+picks an engine; it over-fetches <code>RRF_K</code>=60 from each and fuses by reciprocal rank,
+<code>1/(60+rank)</code> summed, keyed on <code>(name, tap)</code> &mdash; the key both engines
+already dedupe on. Adding a <code>hybrid</code> column to the eval:
+<code>catalog.search</code> hit@1 0.714; BM25 hit@1 0.780, recall 1.000, MRR 0.860, nDCG 0.895;
+dense hit@1 0.780, recall 0.956, MRR 0.853, nDCG 0.876; <b>hybrid hit@1 0.813, recall 0.978, MRR
+0.883, nDCG 0.905</b>.
+
+Hybrid leads on <code>hit@1</code>, MRR and nDCG, and gives up 2 queries of recall to BM25.
+<b>Neither difference is significant</b> by the bar set above: +3 net queries on hit@1 and &minus;2
+on recall, both inside the ~6-query floor for <em>p</em>&lt;0.05 at this <em>n</em>. So the case for
+fusing is not "it scores higher" &mdash; it is that fusing is the only option that is <em>at or near
+best on both query shapes</em>, where preferring either engine is measurably wrong for half of them.
+
+<b>This reverses a deliberate earlier decision</b>, and that is worth flagging rather than burying:
+<code>test_a_non_empty_dense_result_is_still_final</code> existed precisely to stop
+<code>retrieve_any</code> "always running BM25 too". Its premise was that a dense hit is the better
+answer, which the tie above retires. The other half of that fix &mdash; an <em>empty</em> dense
+result is a thin index, not a verdict, and must fall through to BM25 &mdash; still stands and is
+still tested.
+
+<b>One honest counter-observation.</b> On two hand-picked human-phrased queries, fusion at k=3
+<em>lost</em> the best dense hit: <code>"my app is slow"</code> dropped
+<code>performance-optimization</code> and <code>"I need to make my website accessible"</code>
+dropped <code>accessibility-guidelines</code>, in both cases because a junk BM25 rank-1 outweighed a
+good dense rank-2. That is exactly the tradeoff this card predicted &mdash; "rank fusion discards
+confidence" &mdash; and it is an anecdote at n=2 against a measured win at n=91, so it did not block
+shipping. It is the strongest argument for the query set step 6 still needs, and the first thing to
+re-measure once that exists.
+
+<b>Step 6's real deliverable, and it settles the question.</b> The missing piece was never a number
+&mdash; it was a query set of the shape this feature exists for.
+<code>tests/eval/golden-natural.jsonl</code> is 50 queries written from each target's own
+<code>description</code> and nothing else, phrased as a user problem, with the target's distinctive
+name tokens deliberately excluded (a query containing "docker" finds <code>docker-expert</code> by
+string match and measures nothing). The whole set was written <em>before</em> any engine was run
+against it and scored once, so it could not be selected to flatter a result already seen. A
+mechanical check caught five queries that had leaked a name token and they were rewritten.
+
+Over the same corpus at k=10, 50 queries: <code>catalog.search</code> recall 0.330 hit@1 0.080;
+<b>BM25 recall 0.690 hit@1 0.240</b>; <b>dense recall 0.760 hit@1 0.420</b>;
+<b>hybrid RRF recall 0.820 hit@1 0.420</b> MRR 0.559 nDCG 0.614.
+
+<b>BM25 collapses on this shape</b> &mdash; hit@1 falls from 0.780 on the keyword set to
+<b>0.240</b> here, recall from 1.000 to 0.690. And dense beats it by <b>+9 net queries</b> on hit@1
+(21 of 50 against 12), which clears the ~6-query significance floor this card set. <b>That is the
+first significant retrieval difference anyone has measured in this repo</b>, and it is in the
+opposite direction from the keyword set.
+
+So the two sets together say something neither says alone. On keyword queries BM25 and dense tie and
+hybrid edges ahead; on natural queries BM25 is far behind and hybrid is at-or-above dense on every
+metric. <b>Hybrid is the only engine that is at or near best on both shapes</b> &mdash; which is
+precisely the argument step 4 was shipped on, now with a significant margin behind it rather than
++3 queries inside the noise.
+
+One caveat the slice exposes: <code>skill</code> queries score hit@1 0.459 against
+<code>workflow</code> 0.308. The workflows in this corpus are overwhelmingly
+<code>&lt;technology&gt;-expert</code> agents, so a problem-phrased query has to bridge from a
+symptom to a product name with no shared vocabulary at all &mdash; the hardest case, and the one
+where a larger embedding model would most likely show its value. Worth re-running against Voyage
+before concluding the local model is enough.
+
+The set is deliberately <b>not</b> wired into <code>make eval</code> or the required gate: it needs
+the <code>[rag]</code> extra and a built store, and its purpose is comparing engines rather than
+flooring one. Run it with <code>--golden tests/eval/golden-natural.jsonl</code>.
+

{boost_skill_cli-1.0.313 → boost_skill_cli-1.0.314}/docs/roadmap.html

@@ -780,7 +780,73 @@ is, at best, tied for them.
 <b>Method note.</b> The first indexing pass reported 3 taps failed to embed (2716 of 3740 passages).
 A rerun stored all 3740, and two 30-batch replays never reproduced a failure, so it was transient
 resource pressure rather than a defect &mdash; the retry path (no commit recorded for a failed tap)
-did its job. The figures above come from a complete index.</p>
+did its job. The figures above come from a complete index.
+
+<b>Step 4 shipped, measured against the same 91 queries.</b> <code>retrieve_any</code> no longer
+picks an engine; it over-fetches <code>RRF_K</code>=60 from each and fuses by reciprocal rank,
+<code>1/(60+rank)</code> summed, keyed on <code>(name, tap)</code> &mdash; the key both engines
+already dedupe on. Adding a <code>hybrid</code> column to the eval:
+<code>catalog.search</code> hit@1 0.714; BM25 hit@1 0.780, recall 1.000, MRR 0.860, nDCG 0.895;
+dense hit@1 0.780, recall 0.956, MRR 0.853, nDCG 0.876; <b>hybrid hit@1 0.813, recall 0.978, MRR
+0.883, nDCG 0.905</b>.
+
+Hybrid leads on <code>hit@1</code>, MRR and nDCG, and gives up 2 queries of recall to BM25.
+<b>Neither difference is significant</b> by the bar set above: +3 net queries on hit@1 and &minus;2
+on recall, both inside the ~6-query floor for <em>p</em>&lt;0.05 at this <em>n</em>. So the case for
+fusing is not "it scores higher" &mdash; it is that fusing is the only option that is <em>at or near
+best on both query shapes</em>, where preferring either engine is measurably wrong for half of them.
+
+<b>This reverses a deliberate earlier decision</b>, and that is worth flagging rather than burying:
+<code>test_a_non_empty_dense_result_is_still_final</code> existed precisely to stop
+<code>retrieve_any</code> "always running BM25 too". Its premise was that a dense hit is the better
+answer, which the tie above retires. The other half of that fix &mdash; an <em>empty</em> dense
+result is a thin index, not a verdict, and must fall through to BM25 &mdash; still stands and is
+still tested.
+
+<b>One honest counter-observation.</b> On two hand-picked human-phrased queries, fusion at k=3
+<em>lost</em> the best dense hit: <code>"my app is slow"</code> dropped
+<code>performance-optimization</code> and <code>"I need to make my website accessible"</code>
+dropped <code>accessibility-guidelines</code>, in both cases because a junk BM25 rank-1 outweighed a
+good dense rank-2. That is exactly the tradeoff this card predicted &mdash; "rank fusion discards
+confidence" &mdash; and it is an anecdote at n=2 against a measured win at n=91, so it did not block
+shipping. It is the strongest argument for the query set step 6 still needs, and the first thing to
+re-measure once that exists.
+
+<b>Step 6's real deliverable, and it settles the question.</b> The missing piece was never a number
+&mdash; it was a query set of the shape this feature exists for.
+<code>tests/eval/golden-natural.jsonl</code> is 50 queries written from each target's own
+<code>description</code> and nothing else, phrased as a user problem, with the target's distinctive
+name tokens deliberately excluded (a query containing "docker" finds <code>docker-expert</code> by
+string match and measures nothing). The whole set was written <em>before</em> any engine was run
+against it and scored once, so it could not be selected to flatter a result already seen. A
+mechanical check caught five queries that had leaked a name token and they were rewritten.
+
+Over the same corpus at k=10, 50 queries: <code>catalog.search</code> recall 0.330 hit@1 0.080;
+<b>BM25 recall 0.690 hit@1 0.240</b>; <b>dense recall 0.760 hit@1 0.420</b>;
+<b>hybrid RRF recall 0.820 hit@1 0.420</b> MRR 0.559 nDCG 0.614.
+
+<b>BM25 collapses on this shape</b> &mdash; hit@1 falls from 0.780 on the keyword set to
+<b>0.240</b> here, recall from 1.000 to 0.690. And dense beats it by <b>+9 net queries</b> on hit@1
+(21 of 50 against 12), which clears the ~6-query significance floor this card set. <b>That is the
+first significant retrieval difference anyone has measured in this repo</b>, and it is in the
+opposite direction from the keyword set.
+
+So the two sets together say something neither says alone. On keyword queries BM25 and dense tie and
+hybrid edges ahead; on natural queries BM25 is far behind and hybrid is at-or-above dense on every
+metric. <b>Hybrid is the only engine that is at or near best on both shapes</b> &mdash; which is
+precisely the argument step 4 was shipped on, now with a significant margin behind it rather than
++3 queries inside the noise.
+
+One caveat the slice exposes: <code>skill</code> queries score hit@1 0.459 against
+<code>workflow</code> 0.308. The workflows in this corpus are overwhelmingly
+<code>&lt;technology&gt;-expert</code> agents, so a problem-phrased query has to bridge from a
+symptom to a product name with no shared vocabulary at all &mdash; the hardest case, and the one
+where a larger embedding model would most likely show its value. Worth re-running against Voyage
+before concluding the local model is enough.
+
+The set is deliberately <b>not</b> wired into <code>make eval</code> or the required gate: it needs
+the <code>[rag]</code> extra and a built store, and its purpose is comparing engines rather than
+flooring one. Run it with <code>--golden tests/eval/golden-natural.jsonl</code>.</p>
         <div class="meta">
           <span class="m">Complexity <b>L</b></span>
           <span class="m hi">Impact <b>High</b></span>

{boost_skill_cli-1.0.313 → boost_skill_cli-1.0.314}/scripts/eval_retrieval.py

@@ -145,6 +145,22 @@ def dense_ranker(k: int) -> Ranker:
         [h["entry"]["name"] for h in (dense.retrieve(q, k=max(k * 4, 60)) or [])])
 
 
+def hybrid_ranker(k: int) -> Ranker:
+    """BM25 and dense fused by reciprocal rank (rag.rrf_fuse).
+
+    Measured as its own engine rather than inferred from the other two: a
+    hybrid win must not be creditable to whichever component did not earn it,
+    which is why each engine is also reported alone.
+    """
+    def rank(q: str) -> List[str]:
+        pool = max(k * 4, 60)
+        b = rag.retrieve(q, k=pool)
+        d = dense.retrieve(q, k=pool) or []
+        return _dedupe([h["entry"]["name"]
+                        for h in rag.rrf_fuse([b, d], limit=pool)])
+    return rank
+
+
 def rerank_ranker(k: int) -> Ranker:
     """BM25 shortlist reordered by the LLM rerank stage (Tier 2a)."""
     def rank(q: str) -> List[str]:
@@ -369,7 +385,7 @@ def main(argv: Optional[List[str]] = None) -> int:
     ap.add_argument("--golden", type=Path, default=DEFAULT_GOLDEN)
     ap.add_argument("-k", type=int, default=10, help="cutoff for @k metrics")
     ap.add_argument("--engines", default="auto",
-                    help="comma list of catalog,bm25,dense (default: auto)")
+                    help="comma list of catalog,bm25,dense,hybrid (default: auto)")
     ap.add_argument("--build", action="store_true",
                     help="(re)build the BM25 index before evaluating")
     ap.add_argument("--rerank", action="store_true",
@@ -406,10 +422,13 @@ def main(argv: Optional[List[str]] = None) -> int:
     if (args.engines == "auto" or "dense" in wanted) and dense.ready():
         if "dense" not in wanted:
             wanted.append("dense")
+    if (args.engines == "auto" or "hybrid" in wanted) and dense.ready():
+        if "hybrid" not in wanted:
+            wanted.append("hybrid")
     factory = {"catalog": catalog_ranker, "bm25": bm25_ranker,
-               "dense": dense_ranker}
+               "dense": dense_ranker, "hybrid": hybrid_ranker}
     labels = {"catalog": "catalog.search", "bm25": "BM25 full-content",
-              "dense": "dense vectors"}
+              "dense": "dense vectors", "hybrid": "hybrid RRF"}
 
     results: List[dict] = []
     per_cases: Dict[str, List[dict]] = {}

boost_skill_cli-1.0.314/tests/eval/golden-natural.jsonl

@@ -0,0 +1,84 @@
+# Natural-language retrieval judgments — the queries golden.jsonl does not contain.
+#
+# WHY THIS FILE EXISTS. golden.jsonl grades catalog items by NAME, and its queries
+# carry the vocabulary of the docs they target ("generate algorithmic art with
+# p5.js flow fields"). That is BM25's home ground: measured over the pinned
+# corpus it scores recall 1.000 there, which CLAUDE.md records as expected. So
+# the set cannot distinguish retrieval engines on the thing the keyless dense
+# work was built for — a user describing a PROBLEM in their own words.
+#
+# METHOD, stated so it can be checked rather than trusted:
+#   1. Every query was written from the target's own `description` field and
+#      nothing else. No retrieval was run against any engine while composing —
+#      the whole set was written first and scored once, so the queries could not
+#      be selected to flatter a result already seen. That ordering is the point;
+#      see keyless-semantic-search-for-everyone for why fitting and reporting on
+#      one set is the failure mode here.
+#   2. Queries deliberately AVOID the target's distinctive name tokens. A query
+#      containing "docker" finds docker-expert by string match and measures
+#      nothing. "my containers keep restarting" is the question a user actually
+#      has.
+#   3. Where two items genuinely serve one intent (mcp-builder and build-mcp are
+#      near-duplicates in this corpus), both are listed relevant. Grading one as
+#      wrong would penalise an engine for a corpus duplication, not a retrieval
+#      failure.
+#
+# HOW TO RUN. Needs the pinned corpus (scripts/ensure_eval_corpus.sh) and, for
+# the dense/hybrid columns, the [rag] extra plus a built store:
+#   python3 scripts/eval_retrieval.py --golden tests/eval/golden-natural.jsonl -k 10
+# NOT wired into `make eval` or the required gate: that gate must stay
+# deterministic and offline-ish, and this set is for comparing engines rather
+# than flooring one. Adding it to the gate would also floor a number nobody has
+# argued for yet.
+#
+# One JSON object per line: {query, relevant[], kind, note}
+{"query": "my writing is too wordy and people skim past the important parts", "relevant": ["write-concisely"], "kind": "skill", "note": "clarity, no shared vocabulary with the name"}
+{"query": "an error surfaces deep in the call stack and I cannot tell what originally triggered it", "relevant": ["root-cause-tracing"], "kind": "skill", "note": "tracing back from a symptom"}
+{"query": "I keep patching symptoms instead of whatever is actually wrong underneath", "relevant": ["why", "root-cause-tracing"], "kind": "skill", "note": "five-whys intent"}
+{"query": "what convention should I follow for the messages I write when recording changes in git", "relevant": ["commit"], "kind": "skill", "note": "conventional commits"}
+{"query": "I keep stashing half-finished work every time I have to switch branches", "relevant": ["git-worktrees"], "kind": "skill", "note": "worktrees without naming them"}
+{"query": "I want to attach review status to a commit without rewriting any history", "relevant": ["git-notes"], "kind": "skill", "note": "metadata on commits"}
+{"query": "check what I changed for injection flaws and leaked credentials before it goes in", "relevant": ["security-auditor"], "kind": "workflow", "note": "vulnerability review"}
+{"query": "am I actually exercising the risky paths or only the easy ones", "relevant": ["test-coverage-reviewer"], "kind": "workflow", "note": "coverage quality"}
+{"query": "read through my diff and tell me what is broken in it", "relevant": ["bug-hunter"], "kind": "workflow", "note": "defect finding"}
+{"query": "does this change follow the conventions the rest of the project uses", "relevant": ["code-reviewer"], "kind": "workflow", "note": "guideline adherence"}
+{"query": "I need a single page covering what went wrong, why it happened and what we will do", "relevant": ["analyse-problem"], "kind": "skill", "note": "A3 report"}
+{"query": "help me lay out everything that might be contributing, grouped into categories", "relevant": ["cause-and-effect"], "kind": "skill", "note": "fishbone"}
+{"query": "I want to run small controlled experiments and keep iterating on the result", "relevant": ["plan-do-check-act"], "kind": "skill", "note": "PDCA"}
+{"query": "drive my locally running site in a real browser and confirm it behaves", "relevant": ["webapp-testing"], "kind": "skill", "note": "playwright without the word"}
+{"query": "get the text out of a scanned document so I can search it", "relevant": ["pdf"], "kind": "skill", "note": "extraction"}
+{"query": "I need to edit a Word file programmatically", "relevant": ["docx"], "kind": "skill", "note": "office format"}
+{"query": "read numbers out of a spreadsheet and write some back", "relevant": ["xlsx"], "kind": "skill", "note": "office format"}
+{"query": "put together a slide deck for a presentation", "relevant": ["pptx"], "kind": "skill", "note": "office format"}
+{"query": "make a short looping animation small enough to post in chat", "relevant": ["slack-gif-creator"], "kind": "skill", "note": "gif constraints"}
+{"query": "make this match our company colours and typefaces", "relevant": ["brand-guidelines"], "kind": "skill", "note": "brand application"}
+{"query": "the interface looks generic and I want it to feel deliberate", "relevant": ["frontend-design"], "kind": "skill", "note": "visual design intent"}
+{"query": "expose an external API as tools an assistant can call", "relevant": ["mcp-builder", "build-mcp"], "kind": "skill", "note": "two near-duplicate items in this corpus"}
+{"query": "the model keeps ignoring part of my instructions", "relevant": ["prompt-engineering"], "kind": "skill", "note": "prompt authoring"}
+{"query": "I am running out of room in the window and important details get dropped", "relevant": ["context-engineering"], "kind": "skill", "note": "context limits"}
+{"query": "I want to package a repeatable procedure so it can be reused later", "relevant": ["skill-creator", "create-skill"], "kind": "skill", "note": "duplicate intent in corpus"}
+{"query": "how do I tell whether my changes to the instructions actually helped", "relevant": ["agent-evaluation"], "kind": "skill", "note": "measuring prompt changes"}
+{"query": "run something automatically every time before code is committed", "relevant": ["create-hook"], "kind": "skill", "note": "git hooks"}
+{"query": "turn this ticket into a proper technical specification", "relevant": ["analyze-issue"], "kind": "skill", "note": "issue to spec"}
+{"query": "open a change request with the right template filled in", "relevant": ["create-pr"], "kind": "skill", "note": "PR creation"}
+{"query": "gather all the unresolved feedback on my change into a task list", "relevant": ["load-pr-comments"], "kind": "skill", "note": "review comments"}
+{"query": "the written guides no longer match what the code does", "relevant": ["update-docs"], "kind": "skill", "note": "stale documentation"}
+{"query": "walk me through writing a guide together step by step", "relevant": ["doc-coauthoring"], "kind": "skill", "note": "structured authoring"}
+{"query": "this needs careful multi-step logic rather than a quick guess", "relevant": ["thought-based-reasoning"], "kind": "skill", "note": "reasoning depth"}
+{"query": "I want several different perspectives to argue about my design before I commit to it", "relevant": ["critique"], "kind": "skill", "note": "multi-judge debate"}
+{"query": "look back over what you just produced and improve on it", "relevant": ["reflect"], "kind": "skill", "note": "self-refinement"}
+{"query": "keep this lesson around so the same mistake is not repeated", "relevant": ["memorize"], "kind": "skill", "note": "persisting insights"}
+{"query": "some of the decisions we recorded are probably out of date now", "relevant": ["decay"], "kind": "skill", "note": "evidence freshness"}
+{"query": "generate visuals from code with a bit of controlled randomness", "relevant": ["algorithmic-art"], "kind": "skill", "note": "creative coding"}
+{"query": "produce a good looking printable document rather than a web page", "relevant": ["canvas-design"], "kind": "skill", "note": "print output"}
+{"query": "apply one consistent look across slides, documents and pages", "relevant": ["theme-factory"], "kind": "skill", "note": "theming"}
+{"query": "what does calling the model actually cost per token", "relevant": ["claude-api"], "kind": "skill", "note": "pricing reference"}
+{"query": "my containers keep restarting and I cannot work out why", "relevant": ["docker-expert"], "kind": "workflow", "note": "avoids the word docker"}
+{"query": "the layout falls apart on a narrow screen", "relevant": ["css-expert"], "kind": "workflow", "note": "responsive layout"}
+{"query": "I want automated tests that click through the app like a person would", "relevant": ["cypress-expert"], "kind": "workflow", "note": "e2e testing"}
+{"query": "our full-text queries have got slow as the index grew", "relevant": ["elasticsearch-expert"], "kind": "workflow", "note": "search performance"}
+{"query": "how should I choose partition and sort keys for this access pattern", "relevant": ["dynamodb-expert"], "kind": "workflow", "note": "key design"}
+{"query": "my shell script fails silently in the pipeline and I never notice", "relevant": ["bash-expert"], "kind": "workflow", "note": "defensive scripting"}
+{"query": "I need to configure a fleet of servers repeatably without doing it by hand", "relevant": ["ansible-expert"], "kind": "workflow", "note": "config management"}
+{"query": "keep database schema versions in step across environments", "relevant": ["flyway-expert"], "kind": "workflow", "note": "migrations"}
+{"query": "background jobs are piling up and not getting processed", "relevant": ["celery-expert", "bullmq-expert"], "kind": "workflow", "note": "two queue libraries, both defensible"}

{boost_skill_cli-1.0.313 → boost_skill_cli-1.0.314}/tests/functional/test_cli_discovery.py

@@ -1128,8 +1128,13 @@ class TestReindex:
         boost("reindex", "--dense")
         assert dense.ready() is True
         r = boost("search", "brainstorming")
-        assert "ranked by dense vectors" in r.out
-        assert "full-content BM25" not in r.out
+        # Both indexes are built here, so retrieve_any fuses rather than
+        # picking: the label names both engines. It used to read "ranked by
+        # dense vectors", from when a ready dense store ended the search —
+        # see rag.retrieve_any for why the golden-set tie retired that.
+        assert "ranked by hybrid RRF (BM25 + dense)" in r.out
+        assert "ranked by BM25 full-content" not in r.out, \
+            "a built dense store must still contribute, not be bypassed"
 
     def test_empty_store_warns_instead_of_reporting_success(
             self, boost, tapped, monkeypatch):

{boost_skill_cli-1.0.313 → boost_skill_cli-1.0.314}/tests/unit/test_rag.py

@@ -964,7 +964,10 @@ class TestEngineRouting:
         rag._save([{"n": "a", "t": "x/y", "k": "skill", "c": 0, "l": 1,
                     "snip": "s", "tf": {"react": 1}}], {})
 
-    def test_prefers_dense_when_ready(self, sandbox, monkeypatch):
+    def test_dense_alone_when_bm25_has_no_index(self, sandbox, monkeypatch):
+        # Renamed: this never set up a BM25 index, so it was measuring "dense
+        # is the only engine available", not a preference between the two.
+        # There is no preference any more — with both present they fuse.
         monkeypatch.setattr(dense_mod, "ready", lambda: True)
         picked = [{"entry": {"name": "d", "tap": "x/y"}, "score": 9.0,
                    "snippet": "D"}]
@@ -1018,18 +1021,26 @@ class TestEngineRouting:
         monkeypatch.setattr(dense_mod, "retrieve", lambda *a, **k: [])
         assert rag.search("react", smart=False) is None
 
-    def test_a_non_empty_dense_result_is_still_final(self, sandbox, monkeypatch):
-        # The fix must not turn into "always run BM25 too": a real dense hit
-        # ends the search, even with a BM25 index present that would rank
-        # something else first.
+    def test_a_non_empty_dense_result_is_now_fused_not_final(self, sandbox,
+                                                             monkeypatch):
+        # SUPERSEDED CONTRACT, deliberately. This used to assert that a real
+        # dense hit ended the search — "the fix must not turn into 'always run
+        # BM25 too'". The golden-set eval retired the premise: dense does not
+        # beat BM25 there (hit@1 0.780 each over 91 queries), so ending the
+        # search on a dense hit hands keyword queries to an engine that is at
+        # best tied for them. Both rankings are now fused by RRF.
+        #
+        # The half of the old fix that still stands is tested above: an EMPTY
+        # dense result is not a verdict, and must still fall through to BM25.
         self._bm25_ready()
         monkeypatch.setattr(dense_mod, "ready", lambda: True)
         monkeypatch.setattr(dense_mod, "retrieve", lambda *a, **k: [
             {"entry": {"name": "d", "tap": "x/y"}, "score": 9.0, "snippet": "D"}])
         hits, label = rag.search("react", smart=False,
                                  entries=[_entry("a", tap="x/y")])
-        assert label == "dense vectors"
-        assert [h["entry"]["name"] for h in hits] == ["d"]
+        assert "hybrid" in label.lower(), label
+        assert "d" in [h["entry"]["name"] for h in hits], \
+            "the dense hit must survive fusion, not be dropped"
 
 
 class TestAtomicIndexSave: