@fro.bot/systematic 2.24.0 → 2.25.0

package/dist/cli.js

@@ -6,7 +6,7 @@ import {
   findCommandsInDir,
   findSkillsInDir,
   getConfigPaths
-} from "./index-175fc4yn.js";
+} from "./index-3q3ns1xh.js";
 
 // src/cli.ts
 import fs from "fs";

package/dist/index.js

@@ -13,7 +13,7 @@ import {
   loadConfig,
   loadConfigWithSources,
   parseFrontmatter
-} from "./index-175fc4yn.js";
+} from "./index-3q3ns1xh.js";
 
 // src/index.ts
 import fs5 from "fs";

package/dist/lib/frontmatter.d.ts

@@ -4,6 +4,18 @@ export interface FrontmatterResult<T = Record<string, unknown>> {
     hadFrontmatter: boolean;
     parseError: boolean;
 }
+/**
+ * Returns the raw YAML text between the opening and closing `---` delimiters,
+ * or `null` when the content has no frontmatter block.
+ *
+ * Scope: flat top-level frontmatter only. Nested/indented mapping values are
+ * returned verbatim as part of the block — callers that scan individual lines
+ * (e.g. parse-safety checks) must skip indented lines themselves.
+ *
+ * Handles LF and CRLF line endings. The closing `---` does not need a trailing
+ * newline (handles files that end immediately after the delimiter).
+ */
+export declare function extractFrontmatterBlock(content: string): string | null;
 /**
  * Parses YAML frontmatter from Markdown content.
  *

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@fro.bot/systematic",
-  "version": "2.24.0",
+  "version": "2.25.0",
   "description": "Structured engineering workflows for OpenCode",
   "type": "module",
   "homepage": "https://fro.bot/systematic",
@@ -37,7 +37,7 @@
     "docs:build": "bun run docs:generate && bun run --cwd docs build",
     "docs:preview": "bun run --cwd docs preview",
     "docs:verify": "bun install --frozen-lockfile && bun run --cwd docs playwright install --with-deps chromium && bun run docs:build",
-    "docs:generate": "bun docs/scripts/transform-content.ts && bun scripts/generate-config-schema.ts && bun docs/scripts/generate-config-reference.ts",
+    "docs:generate": "bun docs/scripts/generate-stats.ts && bun docs/scripts/transform-content.ts && bun scripts/generate-config-schema.ts && bun docs/scripts/generate-config-reference.ts",
     "schema:generate": "bun scripts/generate-config-schema.ts",
     "schema:drift": "bun scripts/generate-config-schema.ts --check",
     "registry:build": "bun scripts/build-registry.ts",
@@ -65,9 +65,9 @@
     "@opencode-ai/plugin": "^1.1.30"
   },
   "devDependencies": {
-    "@biomejs/biome": "2.4.15",
-    "@opencode-ai/plugin": "1.15.10",
-    "@opencode-ai/sdk": "1.15.10",
+    "@biomejs/biome": "2.4.16",
+    "@opencode-ai/plugin": "1.15.13",
+    "@opencode-ai/sdk": "1.15.13",
     "@semantic-release/exec": "7.1.0",
     "@types/bun": "latest",
     "@types/js-yaml": "4.0.9",

package/skills/ce-compound/references/schema.yaml

@@ -23,12 +23,16 @@ tracks:
       - integration_issue
       - logic_error
   knowledge:
-    description: "Best practices, workflow improvements, patterns, and documentation"
+    description: "Best practices, workflow improvements, patterns, conventions, and documentation"
     problem_types:
       - best_practice
       - documentation_gap
       - workflow_issue
       - developer_experience
+      - architecture_pattern
+      - design_pattern
+      - tooling_decision
+      - convention
 
 # --- Fields required by BOTH tracks -----------------------------------------
 required_fields:
@@ -57,7 +61,18 @@ required_fields:
       - workflow_issue
       - best_practice
       - documentation_gap
-    description: "Primary category — determines track (bug vs knowledge)"
+      - architecture_pattern
+      - design_pattern
+      - tooling_decision
+      - convention
+    description: >-
+      Primary category — determines track (bug vs knowledge).
+      Prefer the narrowest applicable value; best_practice is the fallback
+      when no narrower knowledge-track value fits.
+      architecture_pattern: structural decisions about how components relate.
+      design_pattern: reusable solutions to recurring design problems.
+      tooling_decision: choices about tools, libraries, or build infrastructure.
+      convention: agreed-upon naming, formatting, or style rules.
 
   component:
     type: enum
@@ -220,3 +235,13 @@ validation_rules:
   - "date must match YYYY-MM-DD format"
   - "rails_version, if provided, must match X.Y.Z format and only applies to bug-track docs"
   - "tags should be lowercase and hyphen-separated"
+  - |-
+    YAML quoting: scalar values that contain ' #' (space-hash) must be
+    double-quoted to prevent silent YAML comment truncation (the YAML parser
+    treats ' #' as an inline comment, silently dropping the rest of the value
+    with parseError: false). Example: problem: "cache miss # under load".
+  - |-
+    YAML quoting: array-of-strings frontmatter items must be double-quoted when
+    the value starts with a YAML reserved indicator (e.g., '{', '[', '|', '>',
+    '!', '&', '*', '?', ':', '-') or contains ': ' (colon-space). Example:
+    symptoms: - "[mdx-js/rollup] Could not parse expression"

package/skills/ce-review/SKILL.md

@@ -477,12 +477,31 @@ Convert multiple reviewer compact JSON returns into one deduplicated, confidence
 10. **Collect coverage data.** Union residual_risks and testing_gaps across reviewers.
 11. **Preserve CE agent artifacts.** Keep the learnings, agent-native, schema-drift, and deployment-verification outputs alongside the merged finding set. Do not drop unstructured agent output just because it does not match the persona JSON schema.
 
+### Stage 5b: Validation pass
+
+Run an independent validation pass over the merged finding set before synthesis. This pass annotates each gated finding `validated: true` or `validated: false` with a one-sentence reason. It never deletes a finding — findings with `validated: false` are surfaced in the "Filtered (not validated)" group in Stage 6, not removed from the report.
+
+**Gating band (default):** Validate only findings that are **P0 or P1 severity**, or that have `requires_verification: true`. Findings outside this band pass through to Stage 6 unvalidated and unfiltered — no validator is dispatched for them. This bounds cost: one validator subagent per gated finding.
+
+**Dispatch:**
+
+1. Identify all gated findings from the Stage 5 merged set.
+2. For each gated finding, spawn one validator subagent in parallel using the validator template at `references/validator-template.md`. Pass the finding fields, the intent summary, the file list, and the full diff.
+3. Collect `{validated, reason}` from each validator. Attach both fields to the finding.
+4. **Never drop a finding.** A finding with `validated: false` is routed to the "Filtered (not validated)" group for Stage 6 presentation. It is not removed from the report, not suppressed, and not excluded from the Coverage count.
+5. Findings with `validated: true` flow through to Stage 6 unchanged — they appear in the normal severity tables.
+6. Findings outside the gating band carry no `validated` annotation and appear in Stage 6 severity tables unchanged.
+
+**Failure handling:** If a validator subagent fails or times out, treat the finding as `validated: true` (conservative fallback — keep it in the actioned set) and note the validator failure in the Coverage section.
+
+**Output-contract compatibility:** This pass is additive. Existing severity tables in Stage 6 keep their structure, headings, and order. The "Filtered (not validated)" group is appended after the existing severity tables. Consumers relying on existing section order are unaffected — new content only ever appears after existing sections.
+
 ### Stage 6: Synthesize and present
 
 Assemble the final report using **pipe-delimited markdown tables for findings** from the review output template included below. The table format is mandatory for finding rows in interactive mode — do not render findings as freeform text blocks or horizontal-rule-separated prose. Other report sections (Applied Fixes, Learnings, Coverage, etc.) use bullet lists and the `---` separator before the verdict, as shown in the template.
 
 1. **Header.** Scope, intent, mode, reviewer team with per-conditional justifications.
-2. **Findings.** Rendered as pipe-delimited tables grouped by severity (`### P0 -- Critical`, `### P1 -- High`, `### P2 -- Moderate`, `### P3 -- Low`). Each finding row shows `#`, file, issue, reviewer(s), confidence, and synthesized route. Omit empty severity levels. Never render findings as freeform text blocks or numbered lists.
+2. **Findings.** Rendered as pipe-delimited tables grouped by severity (`### P0 -- Critical`, `### P1 -- High`, `### P2 -- Moderate`, `### P3 -- Low`). Each finding row shows `#`, file, issue, reviewer(s), confidence, and synthesized route. Omit empty severity levels. Never render findings as freeform text blocks or numbered lists. Only findings with `validated: true` (or no `validated` annotation) appear in these tables.
 3. **Requirements Completeness.** Include only when a plan was found in Stage 2b. For each requirement (R1, R2, etc.) and implementation unit in the plan, report whether corresponding work appears in the diff. Use a simple checklist: met / not addressed / partially addressed. Routing depends on `plan_source`:
    - **`explicit`** (caller-provided or PR body): Flag unaddressed requirements as P1 findings with `autofix_class: manual`, `owner: downstream-resolver`. These enter the residual actionable queue and can become todos.
    - **`inferred`** (auto-discovered): Flag unaddressed requirements as P3 findings with `autofix_class: advisory`, `owner: human`. These stay in the report only — no todos, no autonomous follow-up. An inferred plan match is a hint, not a contract.
@@ -490,12 +509,13 @@ Assemble the final report using **pipe-delimited markdown tables for findings**
 4. **Applied Fixes.** Include only if a fix phase ran in this invocation.
 5. **Residual Actionable Work.** Include when unresolved actionable findings were handed off or should be handed off.
 6. **Pre-existing.** Separate section, does not count toward verdict.
-7. **Learnings & Past Solutions.** Surface learnings-researcher results: if past solutions are relevant, flag them as "Known Pattern" with links to docs/solutions/ files.
-8. **Agent-Native Gaps.** Surface agent-native-reviewer results. Omit section if no gaps found.
-9. **Schema Drift Check.** If schema-drift-detector ran, summarize whether drift was found. If drift exists, list the unrelated schema objects and the required cleanup command. If clean, say so briefly.
-10. **Deployment Notes.** If deployment-verification-agent ran, surface the key Go/No-Go items: blocking pre-deploy checks, the most important verification queries, rollback caveats, and monitoring focus areas. Keep the checklist actionable rather than dropping it into Coverage.
-11. **Coverage.** Suppressed count, residual risks, testing gaps, failed/timed-out reviewers, and any intent uncertainty carried by non-interactive modes.
-12. **Verdict.** Ready to merge / Ready with fixes / Not ready. Fix order if applicable. When an `explicit` plan has unaddressed requirements, the verdict must reflect it — a PR that's code-clean but missing planned requirements is "Not ready" unless the omission is intentional. When an `inferred` plan has unaddressed requirements, note it in the verdict reasoning but do not block on it alone.
+7. **Filtered (not validated).** Include when Stage 5b produced any findings with `validated: false`. Render as a pipe-delimited table with columns `#`, `File`, `Issue`, `Reviewer`, `Confidence`, `Validator reason`. These findings are surfaced for human review — they are not removed from the report. The validator found evidence that the issue may not be real in the code as written, was not introduced by this diff, or is already handled elsewhere; the human reviewer makes the final call. Omit this section when no findings were filtered.
+8. **Learnings & Past Solutions.** Surface learnings-researcher results: if past solutions are relevant, flag them as "Known Pattern" with links to docs/solutions/ files.
+9. **Agent-Native Gaps.** Surface agent-native-reviewer results. Omit section if no gaps found.
+10. **Schema Drift Check.** If schema-drift-detector ran, summarize whether drift was found. If drift exists, list the unrelated schema objects and the required cleanup command. If clean, say so briefly.
+11. **Deployment Notes.** If deployment-verification-agent ran, surface the key Go/No-Go items: blocking pre-deploy checks, the most important verification queries, rollback caveats, and monitoring focus areas. Keep the checklist actionable rather than dropping it into Coverage.
+12. **Coverage.** Suppressed count, residual risks, testing gaps, failed/timed-out reviewers, validator failures, and any intent uncertainty carried by non-interactive modes.
+13. **Verdict.** Ready to merge / Ready with fixes / Not ready. Fix order if applicable. When an `explicit` plan has unaddressed requirements, the verdict must reflect it — a PR that's code-clean but missing planned requirements is "Not ready" unless the omission is intentional. When an `inferred` plan has unaddressed requirements, note it in the verdict reasoning but do not block on it alone.
 
 Do not include time estimates.
 
@@ -539,6 +559,10 @@ Pre-existing issues:
 [P2][gated_auto -> downstream-resolver] File: <file:line> -- <title> (<reviewer>, confidence <N>)
   Why: <why_it_matters>
 
+Filtered (not validated):
+[P1][gated_auto -> downstream-resolver] File: <file:line> -- <title> (<reviewer>, confidence <N>)
+  Validator reason: <one-sentence reason from the validator>
+
 Residual risks:
 - <risk>
 
@@ -559,6 +583,7 @@ Testing gaps:
 
 Coverage:
 - Suppressed: <N> findings below 0.60 confidence (P0 at 0.50+ retained)
+- Filtered (not validated): <N> findings surfaced for human review
 - Untracked files excluded: <file1>, <file2>
 - Failed reviewers: <reviewer>
 
@@ -576,6 +601,7 @@ Review complete
 - The `Artifact:` line gives callers the path to the full run artifact for machine-readable access to the complete findings schema. The text envelope is the primary handoff; the artifact is for debugging and full-fidelity access.
 - Findings with `owner: release` appear in the Advisory section (they are operational/rollout items, not code fixes).
 - Findings with `pre_existing: true` appear in the Pre-existing section regardless of autofix_class.
+- Findings with `validated: false` from Stage 5b appear in the "Filtered (not validated)" section. They are surfaced for human review — not removed. Include the validator reason on the indented `Validator reason:` line.
 - The Verdict appears in the metadata header (deliberately reordered from the interactive format where it appears at the bottom) so programmatic callers get the verdict first.
 - Omit any section with zero items.
 - If all reviewers fail or time out, emit `Code review degraded (headless mode). Reason: 0 of N reviewers returned results.` followed by "Review complete".

package/skills/ce-review/references/review-output-template.md

@@ -59,6 +59,12 @@ Use this **exact format** when presenting synthesized review findings. Findings
 |---|------|-------|----------|
 | 1 | `orders_controller.rb:12` | Broad rescue masking failed permission check | correctness |
 
+### Filtered (not validated)
+
+| # | File | Issue | Reviewer | Confidence | Validator reason |
+|---|------|-------|----------|------------|-----------------|
+| 1 | `orders_controller.rb:55` | Rate limit bypass via header spoofing | security | 0.72 | The `X-Forwarded-For` header is already stripped by the load balancer before reaching the application, so the cited bypass path does not exist in this deployment. |
+
 ### Learnings & Past Solutions
 
 - [Known Pattern] `docs/solutions/export-pagination.md` -- previous export pagination fix applies to this endpoint
@@ -126,6 +132,7 @@ This fails because: no pipe-delimited tables, no severity-grouped `###` headers,
 - **Applied Fixes section** -- include only when a fix phase ran in this review invocation
 - **Residual Actionable Work section** -- include only when unresolved actionable findings were handed off for later work
 - **Pre-existing section** -- separate table, no confidence column (these are informational)
+- **Filtered (not validated) section** -- findings where Stage 5b returned `validated: false`. Rendered as a pipe-delimited table with columns `#`, `File`, `Issue`, `Reviewer`, `Confidence`, `Validator reason`. These findings are surfaced for human review, not removed. Omit this section when Stage 5b produced no filtered findings.
 - **Learnings & Past Solutions section** -- results from learnings-researcher, with links to docs/solutions/ files
 - **Agent-Native Gaps section** -- results from agent-native-reviewer. Omit if no gaps found.
 - **Schema Drift Check section** -- results from schema-drift-detector. Omit if the agent did not run.
@@ -145,4 +152,5 @@ In `mode:headless`, replace the interactive pipe-delimited table report with a s
 - **`Artifact:` line** in metadata header gives callers the path to the full run artifact.
 - **`[needs-verification]` marker** on findings where `requires_verification: true`.
 - **Evidence lines** included per finding.
+- **"Filtered (not validated)" section** included when Stage 5b produced findings with `validated: false`. Uses `[severity][autofix_class -> owner] File: <file:line> -- <title>` format with an indented `Validator reason:` line. These findings are surfaced for human review, not removed.
 - **Completion signal:** "Review complete" as the final line.

package/skills/ce-review/references/validator-template.md

@@ -0,0 +1,96 @@
+# Validator Subagent Prompt Template
+
+This template is used by the Stage 5b orchestrator to spawn one independent validator per gated finding. Variable substitution slots are filled at dispatch time.
+
+A finding is **gated** (eligible for validation) when it is P0 or P1 severity, or when `requires_verification: true`. Findings outside this band pass through to Stage 6 unvalidated and unfiltered — no validator is dispatched for them.
+
+---
+
+## Template
+
+```
+You are an independent finding validator for a code review.
+
+Your sole job is to answer three questions about one specific finding and return a JSON verdict. You do NOT add new findings, suggest fixes, or produce any output other than the JSON object below.
+
+<output-contract>
+Return ONLY valid JSON matching this schema. No prose, no markdown, no explanation outside the JSON object.
+
+{
+  "validated": <boolean>,
+  "reason": "<one sentence explaining why the finding is validated or not>"
+}
+
+Rules:
+- You are a leaf validator inside an already-running review workflow. Do not invoke systematic skills or agents. Perform your analysis directly and return the JSON verdict only.
+- You are operationally read-only. You may use non-mutating inspection tools (file reads, glob, grep, git log, git diff, git show, git blame, gh pr view) to examine the code. Do not edit project files, change branches, commit, push, create PRs, or otherwise mutate the checkout or repository state.
+- Answer the three validation questions below. Set `validated: true` only when all three answers are YES. Set `validated: false` when any answer is NO.
+- The `reason` field must be one sentence. State the specific code evidence that drove your verdict (file name, function name, or line reference when relevant). Do not repeat the finding title verbatim.
+- Be conservative: when evidence is ambiguous, prefer `validated: true` (keep the finding in the actioned set). A false negative that lets a real bug through is worse than a false positive that the human reviewer can dismiss.
+- Do not validate based on general coding principles alone. Ground your verdict in the actual code as written in this diff and the surrounding context.
+</output-contract>
+
+<validation-questions>
+Answer each question YES or NO based on the code evidence you find.
+
+1. **Is the issue real in the code as written?**
+   Read the cited file and line. Does the problem the finding describes actually exist in the current code? A finding is not real if the code already handles the case, the cited line does not contain the described issue, or the issue is in a comment or dead code path.
+
+2. **Was this issue introduced by THIS diff?**
+   Check whether the cited code is new or changed in this diff, or whether it existed before. A finding is not introduced by this diff if the code is unchanged (pre-existing). Exception: if the diff makes a pre-existing issue newly reachable or newly relevant (e.g., a new call site, a removed guard), the finding is still valid — mark it as introduced by this diff.
+
+3. **Is the issue already handled elsewhere?**
+   Check whether the problem is already mitigated by a guard, middleware, framework behavior, type constraint, or other mechanism not visible at the cited line. A finding is not valid if the issue is fully handled at a higher or lower layer that the reviewer missed.
+
+Set `validated: true` only when: the issue is real (Q1 YES), introduced by this diff or newly relevant (Q2 YES), and not already handled elsewhere (Q3 YES).
+Set `validated: false` when any question is NO, and state which question failed and why in `reason`.
+</validation-questions>
+
+<finding>
+Title: {finding_title}
+Severity: {finding_severity}
+File: {finding_file}
+Line: {finding_line}
+Reviewer(s): {finding_reviewers}
+Confidence: {finding_confidence}
+requires_verification: {finding_requires_verification}
+Suggested fix: {finding_suggested_fix}
+</finding>
+
+<review-context>
+Intent: {intent_summary}
+
+Changed files: {file_list}
+
+Diff:
+{diff}
+</review-context>
+```
+
+---
+
+## Variable Reference
+
+| Variable | Source | Description |
+|----------|--------|-------------|
+| `{finding_title}` | Stage 5 merged finding | The finding's title field |
+| `{finding_severity}` | Stage 5 merged finding | P0, P1, P2, or P3 |
+| `{finding_file}` | Stage 5 merged finding | File path cited by the finding |
+| `{finding_line}` | Stage 5 merged finding | Line number cited by the finding |
+| `{finding_reviewers}` | Stage 5 merged finding | Reviewer(s) that flagged this finding |
+| `{finding_confidence}` | Stage 5 merged finding | Confidence score (0.0–1.0) |
+| `{finding_requires_verification}` | Stage 5 merged finding | Boolean from the merged finding |
+| `{finding_suggested_fix}` | Stage 5 merged finding | Suggested fix text, or "none" |
+| `{intent_summary}` | Stage 2 output | 2–3 line description of what the change is trying to accomplish |
+| `{file_list}` | Stage 1 output | List of changed files from the scope step |
+| `{diff}` | Stage 1 output | The actual diff content to review |
+
+---
+
+## Dispatch Notes
+
+- Dispatch one validator subagent per gated finding **in parallel** to keep latency bounded.
+- Pass the full diff and file list so the validator can inspect surrounding context, not just the cited line.
+- The validator returns `{validated, reason}`. Attach both fields to the finding before Stage 6.
+- **Never drop a finding based on the validator verdict.** A finding with `validated: false` moves to the "Filtered (not validated)" presentation group in Stage 6. It is never removed from the report.
+- If a validator subagent fails or times out, treat the finding as `validated: true` (conservative fallback — keep it in the actioned set) and note the validator failure in the Coverage section.

package/skills/claude-permissions-optimizer/scripts/extract-commands.mjs

@@ -93,7 +93,7 @@ function matchGlob(pattern, command) {
   if (normalized.endsWith(' *')) {
     const base = normalized.slice(0, -2)
     const escaped = base.replace(/[.+^${}()|[\]\\]/g, '\\$&')
-    regexStr = '^' + escaped + '($| .*)'
+    regexStr = `^${escaped}($| .*)`
   } else {
     regexStr =
       '^' +
@@ -530,7 +530,7 @@ for (const [command, data] of commands) {
     continue
   }
 
-  const pattern = 'Bash(' + normalize(command) + ')'
+  const pattern = `Bash(${normalize(command)})`
   const { tier, reason } = classify(command)
 
   const existing = patternGroups.get(pattern)

package/skills/claude-permissions-optimizer/scripts/normalize.mjs

@@ -47,20 +47,20 @@ export function normalize(command) {
 
   // Handle pnpm --filter <pkg> <subcommand> specially
   const pnpmFilter = command.match(/^pnpm\s+--filter\s+\S+\s+(\S+)/)
-  if (pnpmFilter) return 'pnpm --filter * ' + pnpmFilter[1] + ' *'
+  if (pnpmFilter) return `pnpm --filter * ${pnpmFilter[1]} *`
 
   // Handle sed specially -- preserve the mode flag to keep safe patterns narrow.
   // sed -i (in-place) is destructive; sed -n, sed -e, bare sed are read-only.
   if (/^sed\s/.test(command)) {
     if (/\s-i\b/.test(command)) return 'sed -i *'
     const sedFlag = command.match(/^sed\s+(-[a-zA-Z])\s/)
-    return sedFlag ? 'sed ' + sedFlag[1] + ' *' : 'sed *'
+    return sedFlag ? `sed ${sedFlag[1]} *` : 'sed *'
   }
 
   // Handle ast-grep specially -- preserve --rewrite flag.
   if (/^(ast-grep|sg)\s/.test(command)) {
     const base = command.startsWith('sg') ? 'sg' : 'ast-grep'
-    return /\s--rewrite\b/.test(command) ? base + ' --rewrite *' : base + ' *'
+    return /\s--rewrite\b/.test(command) ? `${base} --rewrite *` : `${base} *`
   }
 
   // Handle find specially -- preserve key action flags.
@@ -70,12 +70,12 @@ export function normalize(command) {
     if (/\s-exec\s/.test(command)) return 'find -exec *'
     // Extract the first predicate flag for a narrower safe pattern
     const findFlag = command.match(/\s(-(?:name|type|path|iname))\s/)
-    return findFlag ? 'find ' + findFlag[1] + ' *' : 'find *'
+    return findFlag ? `find ${findFlag[1]} *` : 'find *'
   }
 
   // Handle git -C <dir> <subcommand> -- strip the -C <dir> and normalize the git subcommand
   const gitC = command.match(/^git\s+-C\s+\S+\s+(.+)$/)
-  if (gitC) return normalize('git ' + gitC[1])
+  if (gitC) return normalize(`git ${gitC[1]}`)
 
   // Split on compound operators -- normalize the first command only
   const compoundMatch = command.match(/^(.+?)\s*(&&|\|\||;)\s*(.+)$/)
@@ -123,7 +123,7 @@ export function normalize(command) {
   let argStart = 1
 
   if (multiWordBases.includes(base) && parts.length > 1) {
-    prefix = base + ' ' + parts[1]
+    prefix = `${base} ${parts[1]}`
     argStart = 2
   }
 
@@ -141,11 +141,11 @@ export function normalize(command) {
   }
 
   const flagStr =
-    preservedFlags.length > 0 ? ' ' + preservedFlags.join(' ') : ''
+    preservedFlags.length > 0 ? ` ${preservedFlags.join(' ')}` : ''
   const hasVaryingArgs = parts.length > argStart + preservedFlags.length
 
   if (hasVaryingArgs) {
-    return prefix + flagStr + ' *'
+    return `${prefix + flagStr} *`
   }
   return prefix + flagStr
 }

package/skills/onboarding/scripts/inventory.mjs

@@ -120,7 +120,7 @@ async function listDirNames(dir) {
   const entries = await listDir(dir)
   return entries
     .filter((e) => e.isDirectory() && !EXCLUDED_DIRS.has(e.name))
-    .map((e) => e.name + '/')
+    .map((e) => `${e.name}/`)
 }
 
 async function listFileNames(dir, opts) {
@@ -511,7 +511,7 @@ async function getStructure() {
   for (const entry of entries) {
     if (EXCLUDED_DIRS.has(entry.name)) continue
     if (entry.isDirectory()) {
-      topLevel.push(entry.name + '/')
+      topLevel.push(`${entry.name}/`)
     } else {
       topLevel.push(entry.name)
     }

package/skills/writing-skills/scripts/render-graphs.js

@@ -19,9 +19,9 @@
  * Requires: graphviz (dot) installed on system
  */
 
-const fs = require('fs')
-const path = require('path')
-const { execSync } = require('child_process')
+const fs = require('node:fs')
+const path = require('node:path')
+const { execSync } = require('node:child_process')
 
 function extractDotBlocks(markdown) {
   const blocks = []
@@ -61,7 +61,7 @@ function combineGraphs(blocks, skillName) {
     label="${block.name}";
     ${body
       .split('\n')
-      .map((line) => '  ' + line)
+      .map((line) => `  ${line}`)
       .join('\n')}
   }`
   })