clud-bug 0.5.8 → 0.5.10

package/lib/skills.js

@@ -348,4 +348,124 @@ function sanitizeSlug(name) {
   return name.toLowerCase().replace(/[^a-z0-9-]+/g, '-').replace(/^-+|-+$/g, '');
 }
 
+// Extract the `review_mode` field from a SKILL.md's frontmatter.
+//
+// Contract (from the v0.6 plan, option D-unified):
+//   - `shared`    → the skill loads alongside other shared skills in ONE
+//                   Claude call. Bug-finding baselines + most skills.sh
+//                   contributions live here; they benefit from cross-
+//                   correlation (an evidence-based finding flagged for
+//                   critical-issues-only also gets the convention check).
+//   - `dedicated` → the skill gets its OWN focused Claude call. Reserved
+//                   for domain-specific skills (brand voice, compliance,
+//                   API-contract) where attention dilution at high skill
+//                   counts is the real failure mode.
+//   - Missing field → default to `shared`. Conservative: the skill loads,
+//                   no surprise per-skill API cost. Users opt skills INTO
+//                   `dedicated` by authoring the field.
+//
+// The CLI runtime (v0.5.9) honors this via prompt restructuring inside a
+// single claude-code-action call. The v0.6 GitHub App will use the same
+// field to route to literal parallel API calls. Single source of truth.
+export function readReviewMode(skillContent) {
+  if (typeof skillContent !== 'string') return 'shared';
+  // Scope to the YAML frontmatter block (between the first two `---` lines).
+  // A `review_mode:` line in the body is documentation, not configuration.
+  const fm = skillContent.match(/^---\n([\s\S]*?)\n---/);
+  if (!fm) return 'shared';
+  const m = fm[1].match(/^review_mode:\s*(\S+)\s*$/m);
+  if (!m) return 'shared';
+  // Strip optional YAML string-quotes — `review_mode: "dedicated"` and
+  // `review_mode: 'dedicated'` are both valid YAML, but the (\S+) capture
+  // grabs the quotes too. Without this, quoted forms silently fell back
+  // to `shared` even though the author clearly meant dedicated.
+  const value = m[1].toLowerCase().replace(/^["']|["']$/g, '');
+  return value === 'dedicated' ? 'dedicated' : 'shared';
+}
+
+// Partition a set of loaded skills into {shared, dedicated} buckets per
+// each skill's review_mode frontmatter. Expects skills with a `content`
+// field (SKILL.md text). Skills without content default to `shared`.
+//
+// Shape: input is the same skill objects produced by loadBaseline /
+// writeSkills / listInstalled. Output is two arrays of the same shape;
+// caller decides what to do with each bucket.
+export function partitionByReviewMode(skills) {
+  const shared = [];
+  const dedicated = [];
+  for (const skill of skills) {
+    const mode = readReviewMode(skill?.content);
+    (mode === 'dedicated' ? dedicated : shared).push(skill);
+  }
+  return { shared, dedicated };
+}
+
+// Pull the line for `skillName` from a clud-bug review's `### Per-skill scan`
+// block. The block format (set by the v3+ prompt) is one line per loaded skill:
+//
+//   ### Per-skill scan
+//   - [critical-issues-only]: scanned all paths. 2 critical findings below.
+//   - [brand-voice-review]: scanned 3 microcopy changes. 1 finding (below).
+//   - [pii-and-compliance]: scanned analytics + logging. 0 findings.
+//
+// Returns the OUTCOME portion (everything after the `- [name]: ` prefix), with
+// trailing whitespace stripped. Returns null if the skill isn't mentioned, the
+// comment has no Per-skill scan block, or `comment` is empty.
+//
+// The brackets in the line prefix anchor the match so a partial-name collision
+// (e.g. `brand-voice` finding `brand-voice-review`) is impossible.
+export function extractPerSkillLine(comment, skillName) {
+  if (typeof comment !== 'string' || !comment) return null;
+  if (typeof skillName !== 'string' || !skillName) return null;
+  // Escape regex metacharacters in the skill name. A skill name with a `.` or
+  // `+` would otherwise alter the match. Skills are conventionally kebab-case,
+  // but defense in depth is cheap.
+  const escaped = skillName.replace(/[.*+?^${}()|[\]\\]/g, '\\$&');
+  // Anchor on the bracket-prefix; tolerate optional leading whitespace and
+  // dash. The OUTCOME is everything from after `]:` to end-of-line.
+  const re = new RegExp(`^\\s*-\\s*\\[${escaped}\\]:\\s*(.+?)\\s*$`, 'm');
+  const m = comment.match(re);
+  return m ? m[1] : null;
+}
+
+// Classify a Per-skill scan outcome line into the check-run conclusion the
+// composite action will emit for that skill. Source of truth for the BB.3
+// gate decision — the v0.5.10 composite shells out to node + this helper
+// rather than parsing in bash, so the gate has unit-test coverage and the
+// v0.6 App can reuse the same classification when it routes its own
+// parallel calls.
+//
+// Contract:
+//   - `null` (skill not mentioned in the review) → 'failure'
+//   - line contains "0 findings" / "0 finding" as a STANDALONE TOKEN → 'success'
+//   - line contains "n/a" as a standalone token → 'success'
+//   - empty line (bot emitted "- [name]:" with no outcome) → 'failure'
+//   - otherwise (typically "N finding" / "N findings" with N>0) → 'failure'
+//
+// Why null → failure (not neutral): GitHub's branch-protection contract
+// treats `conclusion: neutral` as PASSING for required status checks —
+// only `failure`, `cancelled`, `timed_out`, `action_required` block merge.
+// A strictSkills entry that doesn't appear in the per-skill scan block
+// (typo, prompt regression, mid-review race) emitting `neutral` would
+// silently pass branch protection, defeating the gate the user opted into.
+// Failing loud is the right posture for a gate that ships with "strict" in
+// its name; the cost is a re-run if a bot mid-review somehow drops a skill.
+//
+// The "0 findings" match is anchored on a leading word boundary so "10
+// findings" / "100 findings" don't substring-match to success — the exact
+// bug that v0.5.10's first revision had, caught by clud-bug-review + claude-
+// review on PR #57.
+export function classifyPerSkillOutcome(outcomeLine) {
+  if (outcomeLine == null) return 'failure';
+  const text = String(outcomeLine);
+  // 0 findings / 0 finding — anchored: NOT preceded by a digit. So "10 findings"
+  // doesn't match (the `0 findings` substring has `1` before it), and "0
+  // findings" / " 0 findings." both match.
+  if (/(^|[^0-9])0\s+findings?\b/i.test(text)) return 'success';
+  // n/a — anchored on word boundaries either side (so "n/a." at sentence end
+  // matches but "diagnostics" would not contain a matching n/a).
+  if (/\bn\/a\b/i.test(text)) return 'success';
+  return 'failure';
+}
+
 export const _internal = { normalizeList, sanitizeSlug, entryKey, MAX_SKILLS, API_BASE, MANIFEST_FILE };

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "clud-bug",
-  "version": "0.5.8",
+  "version": "0.5.10",
   "description": "Claude PR review with project-aware skills. CLI installs a working GitHub Actions workflow and curates skills from skills.sh.",
   "homepage": "https://cludbug.dev",
   "bugs": "https://github.com/thrillmot/clud-bug/issues",

package/templates/skills/baseline/clud-bug-collaboration.md

@@ -1,6 +1,7 @@
 ---
 name: clud-bug-collaboration
 description: How Claude Code agents working in a clud-bug-installed repo should interact with the bot's review threads, strict-mode gate, and skill set. Use this skill whenever you're about to push a commit, address a clud-bug PR review comment, edit anything under .claude/skills/, modify .github/workflows/clud-bug-*.yml, or wonder why a PR check is red. Also use when planning work in a repo that has a `clud-bug-review` workflow installed — even if the user didn't mention clud-bug by name.
+review_mode: shared
 ---
 
 # Working in a clud-bug-installed repo

package/templates/skills/baseline/critical-issues-only.md

@@ -1,6 +1,7 @@
 ---
 name: critical-issues-only
 description: PR review discipline - flag only correctness, security, and performance issues. Skip nits.
+review_mode: shared
 ---
 
 # Critical issues only

package/templates/skills/baseline/evidence-based-review.md

@@ -1,6 +1,7 @@
 ---
 name: evidence-based-review
 description: Every PR review claim must quote the specific code being criticized. No hand-waving.
+review_mode: shared
 ---
 
 # Evidence-based review

package/templates/skills/baseline/respect-existing-conventions.md

@@ -1,6 +1,7 @@
 ---
 name: respect-existing-conventions
 description: Don't suggest changes that fight the codebase's established patterns. Match what's already there.
+review_mode: shared
 ---
 
 # Respect existing conventions

package/templates/workflow-py.yml.tmpl

@@ -1,4 +1,4 @@
-# clud-bug-template-version: v2
+# clud-bug-template-version: v4
 name: Clud Bug 🐛 Crawls Your Code
 
 on:
@@ -12,6 +12,8 @@ jobs:
       contents: read
       pull-requests: write
       id-token: write
+      # checks: write — composite emits per-skill check-runs (BB.3).
+      checks: write
 
     steps:
       - uses: actions/checkout@v6
@@ -56,7 +58,7 @@ jobs:
           anthropic_api_key: ${{ secrets.ANTHROPIC_API_KEY }}
           track_progress: true
           claude_args: |
-            --allowedTools "mcp__github_inline_comment__create_inline_comment,Bash(gh pr comment:*),Bash(gh pr diff:*),Bash(gh pr view:*),Bash(gh api graphql:*),Bash(gh api repos/:*),Bash(git show:*),Bash(cat .claude/skills/.clud-bug.json)"
+            --allowedTools "mcp__github_inline_comment__create_inline_comment,Bash(gh pr comment:*),Bash(gh pr diff:*),Bash(gh pr view:*),Bash(gh api graphql:*),Bash(gh api repos/:*),Bash(git show:*),Bash(cat .claude/skills/.clud-bug.json),Bash(cat .claude/skills/*/SKILL.md)"
           prompt: |
             {{PROJECT_DESCRIPTION}}
 
@@ -80,6 +82,23 @@ jobs:
             based-review]: this claim isn't anchored to a line"). Generic
             advice that contradicts a project skill is wrong by definition.
 
+            Skill routing — shared vs dedicated:
+            Each loaded skill carries a `review_mode:` field in its YAML
+            frontmatter at .claude/skills/<name>/SKILL.md. Two values:
+
+              - `review_mode: shared` — bug-finding / convention / evidence
+                skills. Their findings bundle into the standard "Critical
+                findings" / "Minor findings" sections.
+              - `review_mode: dedicated` — domain-specific skills (brand
+                voice, compliance, API-contract, test-discipline). Each
+                gets its own focused H3 section in the review.
+              - Missing field → treat as `shared`.
+
+            Before writing the review, scan each loaded skill's frontmatter
+            (the first `---`-delimited block of its SKILL.md) to identify
+            its review_mode. You can read them with:
+              cat .claude/skills/*/SKILL.md
+
             At the end of every review, append a single-line footer:
               Skills referenced: [skill-name-1, skill-name-2, ...]
             If you genuinely cited none, list "[none]" and explain why no
@@ -147,6 +166,38 @@ jobs:
             open" are both 0. On follow-up reviews after a fix-push,
             "resolved from prior" should typically be positive.
 
+            Per-skill scan block (required, immediately under the status line):
+            After the **This round:** counters, emit a "### Per-skill scan"
+            section with ONE line per loaded skill — even silent ones. This
+            is the anti-dilution layer: every loaded skill must be
+            acknowledged so authors can see their skill ran, even when it
+            produced no findings.
+
+              ### Per-skill scan
+              - [<skill-name>]: <one-sentence outcome>
+
+            Examples (mix of shared + dedicated, with and without findings):
+              - [critical-issues-only]: scanned all paths. 2 critical findings below.
+              - [evidence-based-review]: applied to all findings. ✓ all anchored.
+              - [respect-existing-conventions]: scanned for pattern fights. 0 findings.
+              - [brand-voice-review]: scanned 3 microcopy changes. 1 finding (below).
+              - [pii-and-compliance]: scanned logging + analytics. 0 findings.
+
+            Per-skill findings sections (dedicated-mode skills only):
+            For each dedicated-mode skill that produced one or more
+            findings, emit a dedicated H3 section before the standard
+            critical/minor buckets:
+
+              ### Brand voice [brand-voice-review]
+              - Finding: button label "Click here!" violates verb-noun rule
+                (lib/ui/Button.tsx:42). Suggested: "Open settings."
+
+            Shared-mode skill findings stay in the existing combined
+            "Critical findings" / "Minor findings" buckets — they
+            cross-correlate (a logging-PII issue belongs in both the
+            critical-issues-only and pii-and-compliance lens at once), so
+            bundling preserves that signal.
+
             Post it via:
               gh pr comment "$PR_NUMBER" --body "<your review>"
 
@@ -171,6 +222,6 @@ jobs:
       # Strict-mode gate — composite action; see workflow.yml.tmpl for design notes.
       - name: Strict mode — fail check on critical findings
         if: success()
-        uses: thrillmot/clud-bug/.github/actions/strict-mode-gate@v0.5.8
+        uses: thrillmot/clud-bug/.github/actions/strict-mode-gate@v0.5.10
         with:
           github-token: ${{ secrets.GITHUB_TOKEN }}

package/templates/workflow-ts.yml.tmpl

@@ -1,4 +1,4 @@
-# clud-bug-template-version: v2
+# clud-bug-template-version: v4
 name: Clud Bug 🐛 Crawls Your Code
 
 on:
@@ -12,6 +12,8 @@ jobs:
       contents: read
       pull-requests: write
       id-token: write
+      # checks: write — composite emits per-skill check-runs (BB.3).
+      checks: write
 
     steps:
       - uses: actions/checkout@v6
@@ -56,7 +58,7 @@ jobs:
           anthropic_api_key: ${{ secrets.ANTHROPIC_API_KEY }}
           track_progress: true
           claude_args: |
-            --allowedTools "mcp__github_inline_comment__create_inline_comment,Bash(gh pr comment:*),Bash(gh pr diff:*),Bash(gh pr view:*),Bash(gh api graphql:*),Bash(gh api repos/:*),Bash(git show:*),Bash(cat .claude/skills/.clud-bug.json)"
+            --allowedTools "mcp__github_inline_comment__create_inline_comment,Bash(gh pr comment:*),Bash(gh pr diff:*),Bash(gh pr view:*),Bash(gh api graphql:*),Bash(gh api repos/:*),Bash(git show:*),Bash(cat .claude/skills/.clud-bug.json),Bash(cat .claude/skills/*/SKILL.md)"
           prompt: |
             {{PROJECT_DESCRIPTION}}
 
@@ -81,6 +83,23 @@ jobs:
             based-review]: this claim isn't anchored to a line"). Generic
             advice that contradicts a project skill is wrong by definition.
 
+            Skill routing — shared vs dedicated:
+            Each loaded skill carries a `review_mode:` field in its YAML
+            frontmatter at .claude/skills/<name>/SKILL.md. Two values:
+
+              - `review_mode: shared` — bug-finding / convention / evidence
+                skills. Their findings bundle into the standard "Critical
+                findings" / "Minor findings" sections.
+              - `review_mode: dedicated` — domain-specific skills (brand
+                voice, compliance, API-contract, test-discipline). Each
+                gets its own focused H3 section in the review.
+              - Missing field → treat as `shared`.
+
+            Before writing the review, scan each loaded skill's frontmatter
+            (the first `---`-delimited block of its SKILL.md) to identify
+            its review_mode. You can read them with:
+              cat .claude/skills/*/SKILL.md
+
             At the end of every review, append a single-line footer:
               Skills referenced: [skill-name-1, skill-name-2, ...]
             If you genuinely cited none, list "[none]" and explain why no
@@ -148,6 +167,38 @@ jobs:
             open" are both 0. On follow-up reviews after a fix-push,
             "resolved from prior" should typically be positive.
 
+            Per-skill scan block (required, immediately under the status line):
+            After the **This round:** counters, emit a "### Per-skill scan"
+            section with ONE line per loaded skill — even silent ones. This
+            is the anti-dilution layer: every loaded skill must be
+            acknowledged so authors can see their skill ran, even when it
+            produced no findings.
+
+              ### Per-skill scan
+              - [<skill-name>]: <one-sentence outcome>
+
+            Examples (mix of shared + dedicated, with and without findings):
+              - [critical-issues-only]: scanned all paths. 2 critical findings below.
+              - [evidence-based-review]: applied to all findings. ✓ all anchored.
+              - [respect-existing-conventions]: scanned for pattern fights. 0 findings.
+              - [brand-voice-review]: scanned 3 microcopy changes. 1 finding (below).
+              - [pii-and-compliance]: scanned logging + analytics. 0 findings.
+
+            Per-skill findings sections (dedicated-mode skills only):
+            For each dedicated-mode skill that produced one or more
+            findings, emit a dedicated H3 section before the standard
+            critical/minor buckets:
+
+              ### Brand voice [brand-voice-review]
+              - Finding: button label "Click here!" violates verb-noun rule
+                (lib/ui/Button.tsx:42). Suggested: "Open settings."
+
+            Shared-mode skill findings stay in the existing combined
+            "Critical findings" / "Minor findings" buckets — they
+            cross-correlate (a logging-PII issue belongs in both the
+            critical-issues-only and pii-and-compliance lens at once), so
+            bundling preserves that signal.
+
             Post it via:
               gh pr comment "$PR_NUMBER" --body "<your review>"
 
@@ -172,6 +223,6 @@ jobs:
       # Strict-mode gate — composite action; see workflow.yml.tmpl for design notes.
       - name: Strict mode — fail check on critical findings
         if: success()
-        uses: thrillmot/clud-bug/.github/actions/strict-mode-gate@v0.5.8
+        uses: thrillmot/clud-bug/.github/actions/strict-mode-gate@v0.5.10
         with:
           github-token: ${{ secrets.GITHUB_TOKEN }}

package/templates/workflow.yml.tmpl

@@ -1,4 +1,4 @@
-# clud-bug-template-version: v2
+# clud-bug-template-version: v4
 name: Clud Bug 🐛 Crawls Your Code
 
 on:
@@ -12,6 +12,10 @@ jobs:
       contents: read
       pull-requests: write
       id-token: write
+      # checks: write — composite action emits per-skill check-runs via
+      # the GitHub Checks API for any skill in .clud-bug.json's strictSkills
+      # list (BB.3, v0.5.10+). No-op when strictSkills is unset.
+      checks: write
 
     steps:
       - uses: actions/checkout@v6
@@ -80,7 +84,7 @@ jobs:
           anthropic_api_key: ${{ secrets.ANTHROPIC_API_KEY }}
           track_progress: true
           claude_args: |
-            --allowedTools "mcp__github_inline_comment__create_inline_comment,Bash(gh pr comment:*),Bash(gh pr diff:*),Bash(gh pr view:*),Bash(gh api graphql:*),Bash(gh api repos/:*),Bash(git show:*),Bash(cat .claude/skills/.clud-bug.json)"
+            --allowedTools "mcp__github_inline_comment__create_inline_comment,Bash(gh pr comment:*),Bash(gh pr diff:*),Bash(gh pr view:*),Bash(gh api graphql:*),Bash(gh api repos/:*),Bash(git show:*),Bash(cat .claude/skills/.clud-bug.json),Bash(cat .claude/skills/*/SKILL.md)"
           prompt: |
             {{PROJECT_DESCRIPTION}}
 
@@ -101,6 +105,23 @@ jobs:
             based-review]: this claim isn't anchored to a line"). Generic
             advice that contradicts a project skill is wrong by definition.
 
+            Skill routing — shared vs dedicated:
+            Each loaded skill carries a `review_mode:` field in its YAML
+            frontmatter at .claude/skills/<name>/SKILL.md. Two values:
+
+              - `review_mode: shared` — bug-finding / convention / evidence
+                skills. Their findings bundle into the standard "Critical
+                findings" / "Minor findings" sections.
+              - `review_mode: dedicated` — domain-specific skills (brand
+                voice, compliance, API-contract, test-discipline). Each
+                gets its own focused H3 section in the review.
+              - Missing field → treat as `shared`.
+
+            Before writing the review, scan each loaded skill's frontmatter
+            (the first `---`-delimited block of its SKILL.md) to identify
+            its review_mode. You can read them with:
+              cat .claude/skills/*/SKILL.md
+
             At the end of every review, append a single-line footer:
               Skills referenced: [skill-name-1, skill-name-2, ...]
             If you genuinely cited none, list "[none]" and explain why no
@@ -168,6 +189,38 @@ jobs:
             open" are both 0. On follow-up reviews after a fix-push,
             "resolved from prior" should typically be positive.
 
+            Per-skill scan block (required, immediately under the status line):
+            After the **This round:** counters, emit a "### Per-skill scan"
+            section with ONE line per loaded skill — even silent ones. This
+            is the anti-dilution layer: every loaded skill must be
+            acknowledged so authors can see their skill ran, even when it
+            produced no findings.
+
+              ### Per-skill scan
+              - [<skill-name>]: <one-sentence outcome>
+
+            Examples (mix of shared + dedicated, with and without findings):
+              - [critical-issues-only]: scanned all paths. 2 critical findings below.
+              - [evidence-based-review]: applied to all findings. ✓ all anchored.
+              - [respect-existing-conventions]: scanned for pattern fights. 0 findings.
+              - [brand-voice-review]: scanned 3 microcopy changes. 1 finding (below).
+              - [pii-and-compliance]: scanned logging + analytics. 0 findings.
+
+            Per-skill findings sections (dedicated-mode skills only):
+            For each dedicated-mode skill that produced one or more
+            findings, emit a dedicated H3 section before the standard
+            critical/minor buckets:
+
+              ### Brand voice [brand-voice-review]
+              - Finding: button label "Click here!" violates verb-noun rule
+                (lib/ui/Button.tsx:42). Suggested: "Open settings."
+
+            Shared-mode skill findings stay in the existing combined
+            "Critical findings" / "Minor findings" buckets — they
+            cross-correlate (a logging-PII issue belongs in both the
+            critical-issues-only and pii-and-compliance lens at once), so
+            bundling preserves that signal.
+
             Post it via:
               gh pr comment "$PR_NUMBER" --body "<your review>"
 
@@ -204,6 +257,6 @@ jobs:
       # Letting the action's own failure fail the check is louder and right.
       - name: Strict mode — fail check on critical findings
         if: success()
-        uses: thrillmot/clud-bug/.github/actions/strict-mode-gate@v0.5.8
+        uses: thrillmot/clud-bug/.github/actions/strict-mode-gate@v0.5.10
         with:
           github-token: ${{ secrets.GITHUB_TOKEN }}