audit-tools 0.53.0 → 0.55.0

package/skills/audit-code/SKILL.md

@@ -18,8 +18,8 @@ Normal usage should:
 
 audit-tools owns deterministic discovery, planning, persisted state, strict
 result ingestion, and synthesis. When semantic review is ready it emits a
-complete provider-neutral workload. Delegate those bounded items through the
-host's native subagent facilities when available, then return only the bound
+complete provider-neutral workload. Run those bounded items in separate
+contexts when the host can, then return only the bound
 result artifacts requested by the current prompt.
 
 If the host cannot delegate, complete exactly one emitted review item in the
@@ -36,21 +36,14 @@ audit-code ensure --quiet
 audit-code next-step
 ```
 
-When developing audit-tools itself, use the repository-local wrapper:
-
-```bash
-node audit-code.mjs ensure --quiet
-node audit-code.mjs next-step
-```
-
 The target-directory rule has one full statement in
 `skills/audit-code/audit-code.prompt.md` (whose absolute path `audit-code
 prompt-path` prints); follow it as written there. Do not add provider, model,
 quota, routing, or launch flags.
 
-Read the returned JSON only far enough to find `prompt_path`, then read and
-follow only that prompt. Do not inspect workload, result, schema, or state files
-unless the current prompt directs you to them. When it says to continue, call
+The command prints a JSON step record. Read the prompt file at its
+`prompt_path`, then follow only that prompt. Do not inspect workload, result,
+schema, or state files unless the current prompt directs you to them. When it says to continue, call
 `next-step` again. Stop when it says to stop.
 
 The package install seeds command and skill assets. Use `audit-code install`

package/skills/audit-code/audit-code.prompt.md

@@ -16,9 +16,6 @@ First bootstrap current assets:
 audit-code ensure --quiet
 ```
 
-When developing audit-tools itself, use `node audit-code.mjs` from the
-repository root.
-
 Preserve user arguments:
 
 - run from inside the target repository; every command resolves that repository's
@@ -32,12 +29,12 @@ Ask for exactly one step:
 audit-code next-step
 ```
 
-Read the returned JSON only far enough to find `prompt_path`, then read and
-follow only that prompt. Do not inspect workload, result, schema, or state files
-unless the current prompt directs you to them.
+The command prints a JSON step record. Read the prompt file at its
+`prompt_path`, then follow only that prompt. Do not inspect workload, result,
+schema, or state files unless the current prompt directs you to them.
 
-When the prompt emits semantic review items, assign them with the host's native
-subagent facilities when available. Do not send provider, model, quota,
+When the prompt emits semantic review items, run each in a separate context
+when the host can, else yourself, as the prompt directs. Do not send provider, model, quota,
 context-window, routing, or launch configuration to audit-tools. Write the
 prompt-bound result artifacts exactly where requested and let the next backend
 step validate and ingest them.

package/skills/audit-code/opencode-command-template.txt

@@ -3,10 +3,10 @@
 Use `audit-code next-step` as the primary interface to the audit workflow.
 
 1. Run `audit-code next-step` directly when shell access is available.
-2. Read the returned JSON far enough to find `prompt_path`, then read and follow the prompt file it points to.
+2. Read the prompt file at the returned step record's `prompt_path`, then follow it.
 3. When a step completes (not blocked), run `audit-code next-step` again.
 4. Stop when the step instructions say to stop.
 
-Use the `task` tool or equivalent for subagent dispatch when the step tells you to fan out review work.
+When the step tells you to fan out review work, run each lane in a separate context when the host can, else yourself.
 
 If shell access to `audit-code next-step` is unavailable, stop and report that no next-step interface is connected.

package/skills/remediate-code/SKILL.md

@@ -19,8 +19,7 @@ Normal usage should:
 The backend owns intake, contract planning, persisted state, dependency and
 phase safety, strict result ingestion, verification, and closeout. When
 implementation is ready it emits every eligible provider-neutral work item.
-Delegate bounded work through the host's native subagent facilities when
-available. The host returns prompt-bound commit and test evidence; the backend
+Run bounded work in separate contexts when the host can. The host returns prompt-bound commit and test evidence; the backend
 corroborates that evidence before it accepts completion.
 
 If the host cannot delegate, complete exactly one emitted work item in the
@@ -43,13 +42,12 @@ them as written there.
 Do not add capability, provider, model, quota, context-window, or concurrency
 flags.
 
-Read the returned JSON only far enough to find `prompt_path`, then read and
-follow only that prompt. Do not inspect workload, result, schema, or state files
-unless the current prompt directs you to them. When it says to continue, call
+The command prints a JSON step record. Read the prompt file at its
+`prompt_path`, then follow only that prompt. Do not inspect workload, result,
+schema, or state files unless the current prompt directs you to them. When it says to continue, call
 `next-step` again. Stop when it says to stop.
 
-When developing audit-tools itself, prefer `node remediate-code.mjs`. Use
-`remediate-code install` for repair or forced asset refresh.
+Use `remediate-code install` for repair or forced asset refresh.
 
 ## Development rule
 

package/skills/remediate-code/remediate-code.prompt.md

@@ -40,12 +40,12 @@ Then ask for exactly one step:
 remediate-code next-step
 ```
 
-Read the returned JSON only far enough to find `prompt_path`, then read and
-follow only that prompt. Do not inspect workload, result, schema, or state files
-unless the current prompt directs you to them.
+The command prints a JSON step record. Read the prompt file at its
+`prompt_path`, then follow only that prompt. Do not inspect workload, result,
+schema, or state files unless the current prompt directs you to them.
 
-When the prompt emits implementation items, assign them using the host's native
-subagent facilities when available. Do not send provider, model, quota,
+When the prompt emits implementation items, run each in a separate context
+when the host can, else yourself, as the prompt directs. Do not send provider, model, quota,
 context-window, routing, launch, or concurrency configuration to audit-tools.
 Write the bound result artifacts exactly where requested; the next backend step
 validates workload identity, worktree and commit evidence, changed files, and

package/dispatch/lens-definitions.json

@@ -1,46 +0,0 @@
-{
-  "correctness": {
-    "description": "Logic errors, incorrect algorithm implementations, off-by-one bugs, type mismatches, wrong return values, incorrect state transitions, missing null/undefined guards, misuse of APIs. Focus on code that does the wrong thing.",
-    "do_not_report": "Style issues, naming problems, missing tests, or findings that belong to other lenses."
-  },
-  "maintainability": {
-    "description": "Code that is hard to change safely: excessive function length, deep nesting, tight coupling between unrelated modules, poor naming, magic constants, duplicated logic, inconsistent abstractions, unclear public APIs. A specific high-value smell: the same logic, format, or contract implemented in two or more places and kept consistent by a test or by convention instead of extracted to one shared source — flag the duplication and recommend single-sourcing it (the sync test is a workaround for the missing abstraction, not the fix). The change-cost tell is 'every edit must be made in N places to stay correct.'",
-    "do_not_report": "Correctness bugs, test gaps, or operational concerns."
-  },
-  "tests": {
-    "description": "Test coverage gaps for important paths, tests that assert incorrect behavior (pinning bugs as expected), fragile or non-deterministic tests, missing negative/edge-case tests, tests that silently pass on stale builds (e.g. importing compiled dist/ rather than source). Also flag a test whose purpose is to keep two copies of logic/format/output in sync (a drift guard): the real defect is the duplication it polices, which should be extracted to one shared source so the guard is unnecessary — report the test as the symptom and call out the duplication to single-source.",
-    "do_not_report": "Source code bugs — report only issues with the tests themselves."
-  },
-  "security": {
-    "description": "Injection vulnerabilities (SQL, shell, path traversal), authentication/authorization flaws, secret exposure, insecure deserialization, privilege escalation, unsafe use of eval or child processes with user input.",
-    "do_not_report": "Performance or correctness issues that are not security-relevant."
-  },
-  "reliability": {
-    "description": "Failure modes without recovery, missing timeouts, unhandled promise rejections, race conditions, resource leaks (file handles, sockets, timers), incorrect retry logic, cascading failure risks.",
-    "do_not_report": "Correctness bugs that do not affect reliability under failure conditions."
-  },
-  "performance": {
-    "description": "Algorithmic inefficiencies (O(n²) where O(n) is possible), unnecessary re-computation, missing caching, synchronous blocking in hot paths, excessive memory allocation.",
-    "do_not_report": "Correctness bugs unrelated to performance."
-  },
-  "data_integrity": {
-    "description": "Missing input validation at trust boundaries, schema violations, inconsistent field naming across related schemas, data loss scenarios, missing required fields, enum values that are present in some schemas but not others.",
-    "do_not_report": "UI or presentation issues; operational or deployment concerns."
-  },
-  "operability": {
-    "description": "Missing or low-quality log output, error messages that don't help operators diagnose problems, missing progress indicators for long operations, no elapsed-time reporting, lack of dry-run or preview modes for destructive operations.",
-    "do_not_report": "Correctness bugs or deployment configuration."
-  },
-  "config_deployment": {
-    "description": "CI/CD pipeline correctness (wrong triggers, missing branch filters, floating version pins), deployment safety (no gate before publish, missing rollback), insecure secret handling in configs, mutable action tags that should be pinned to commit SHAs.",
-    "do_not_report": "Runtime code issues; findings that belong to other lenses."
-  },
-  "architecture": {
-    "description": "Big-picture design, conceptual elegance, over-engineering, under-engineering, appropriate use of abstractions, and identifying opportunities where custom code should be replaced by third-party tools or standard libraries. Flag a missing single source of truth: the same logic, format, or contract realized in multiple components where it should live in one shared module — the durable fix is extraction to that shared source, not a test or convention that keeps the copies in sync. Flag structural findings that span multiple components as 'systemic: true'.",
-    "do_not_report": "Minor style issues, localized logic bugs, or formatting."
-  },
-  "observability": {
-    "description": "Logging quality, telemetry, distributed tracing context, meaningful metrics, and error reporting context.",
-    "do_not_report": "Correctness bugs or deployment configuration."
-  }
-}