fix: mark no-source skill scans not applicable

[BunsDev]

Summary

• add native status: "not_applicable" audit results when CodeQL reports no analyzable source
• make console output distinguish not-applicable scans from clean passes
• keep --fail-on-high from failing not-applicable scans
• document CodeQL CLI install, markdown-only skill handling, and next release checklist

Closes #2.

Verification

• pnpm exec jest tests/audit.test.ts --runInBand --testPathIgnorePatterns='/.comux/'
• pnpm build
• pnpm lint
• node dist/cli.js audit /Users/buns/.openclaw/workspace/skills/linear-issue-management --format json --output /tmp/linear-scan.json --fail-on-high → status: not_applicable

---

Note

Medium Risk
Changes the auditSkill contract and CLI exit behavior by introducing a new not_applicable status when CodeQL can’t index any source, which could affect downstream consumers that assume only pass/fail semantics.

Overview
Adds first-class handling for skills with no CodeQL-analyzable source: auditSkill now detects the CodeQL “no supported languages” error, returns status: 'not_applicable' (with notApplicableReason), and still writes JSON/SARIF output when requested.

Updates CLI and console reporting to clearly distinguish not applicable from a clean pass and prevents --fail-on-high from failing these skipped scans; also refactors output writing into a shared helper and adds a unit test for the new behavior.

Documentation is expanded with a static interactive demo (examples/demo), guidance on markdown-only/no-source scans and CodeQL CLI installation, plus a release checklist; dev tooling deps are bumped and a pnpm-lock.yaml is added.

^{Reviewed by Cursor Bugbot for commit 05dd0f8. Bugbot is set up for automated code reviews on this repo. Configure here.}

[gemini-code-assist]

Code Review

This pull request introduces a 'not applicable' status for skill audits when CodeQL detects no analyzable source code, updating the core logic, CLI, and reporters to handle this state. It also adds an interactive web demo for generating audit snippets and updates the project documentation and dependencies. Review feedback highlights that several dependency versions in package.json appear to be incorrect or non-existent (e.g., TypeScript 5.9.3) and suggests refactoring duplicated report-writing logic in src/audit.ts for better maintainability.

[cursor]

Cursor Bugbot has reviewed your changes and found 1 potential issue.

Autofix Details

Bugbot Autofix prepared a fix for the issue found in the latest run.

• ✅ Fixed: Console reporter prints identical not-applicable message twice
  • The verdict line for not_applicable now prints a distinct message ('Audit skipped — no analyzable source.') instead of duplicating the findings-section text.

Or push these changes by commenting:

@cursor push 56cd6bc990

Preview (56cd6bc990)

diff --git a/src/reporters/console-reporter.ts b/src/reporters/console-reporter.ts
--- a/src/reporters/console-reporter.ts
+++ b/src/reporters/console-reporter.ts
@@ -117,7 +117,7 @@
   }
 
   if (result.status === 'not_applicable') {
-    console.log(chalk.yellow.bold('  ⚪  Audit NOT APPLICABLE — no analyzable source code detected.'));
+    console.log(chalk.yellow.bold('  ⚪  Audit skipped — no analyzable source.'));
   } else if (passed) {
     console.log(chalk.green.bold('  ✅  Audit PASSED — no critical or high severity issues.'));
   } else {

_{You can send follow-ups to the cloud agent here.}

[BunsDev]

Resolved all review threads:

• Dependency-version thread: verified typescript@5.9.3, ts-jest@29.4.9, and @types/node@20.19.39 exist in the npm registry, so no dependency change was needed.
• src/audit.ts: refactored duplicated output-file handling into shared writeAuditOutput(...).
• src/reporters/console-reporter.ts: changed the final not-applicable verdict to Audit skipped — no analyzable source. so the console report no longer repeats the same message twice.

Verification rerun locally:

• pnpm exec jest tests/audit.test.ts --runInBand --testPathIgnorePatterns='/.comux/'
• pnpm build
• pnpm lint
• node dist/cli.js audit /Users/buns/.openclaw/workspace/skills/linear-issue-management --format json --output /tmp/linear-scan.json --fail-on-high
• node dist/cli.js audit /Users/buns/.openclaw/workspace/skills/linear-issue-management

[cursor]

Cursor Bugbot has reviewed your changes and found 1 potential issue.

Bugbot Autofix prepared a fix for the issue found in the latest run.

• ✅ Fixed: parseSarifFile omits newly introduced status field
  • Added the same status derivation as auditSkill (passed vs failed from critical/high counts) to the parseSarifFile return value.

Or push these changes by commenting:

@cursor push 3966e531f0

Preview (3966e531f0)

diff --git a/src/audit.ts b/src/audit.ts
--- a/src/audit.ts
+++ b/src/audit.ts
@@ -309,5 +309,6 @@
     findings,
     summary,
     passed: summary.critical === 0 && summary.high === 0,
+    status: summary.critical === 0 && summary.high === 0 ? 'passed' : 'failed',
   };
 }

_{You can send follow-ups to the cloud agent here.}

^{Reviewed by Cursor Bugbot for commit 05dd0f8. Configure here.}

[cursor]

parseSarifFile omits newly introduced status field

Medium Severity

auditSkill now always populates result.status ('passed', 'failed', or 'not_applicable'), but parseSarifFile still returns an AuditResult without setting status. Downstream consumers (including the console reporter which branches on result.status) will see undefined for parsed SARIF results instead of the expected 'passed'/'failed' value. This inconsistency means the two code paths that produce AuditResult behave differently for the new field, which can lead to confusing output or silent logic mismatches.

 

^{Reviewed by Cursor Bugbot for commit 05dd0f8. Configure here.}