@rune-kit/rune 2.3.0 → 2.3.2

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
Files changed (50) hide show
  1. package/README.md +395 -389
  2. package/compiler/__tests__/tier-override.test.js +158 -0
  3. package/compiler/adapters/antigravity.js +3 -8
  4. package/compiler/adapters/codex.js +3 -8
  5. package/compiler/adapters/cursor.js +3 -8
  6. package/compiler/adapters/generic.js +3 -8
  7. package/compiler/adapters/openclaw.js +4 -9
  8. package/compiler/adapters/opencode.js +3 -8
  9. package/compiler/adapters/windsurf.js +3 -8
  10. package/compiler/bin/rune.js +34 -1
  11. package/compiler/emitter.js +94 -5
  12. package/compiler/transforms/branding.js +10 -3
  13. package/docs/ARCHITECTURE.md +3 -3
  14. package/docs/VISION.md +3 -3
  15. package/docs/guides/index.html +14 -14
  16. package/docs/index.html +7 -7
  17. package/docs/skills/index.html +832 -832
  18. package/extensions/ai-ml/PACK.md +7 -0
  19. package/extensions/content/PACK.md +7 -0
  20. package/extensions/mobile/PACK.md +9 -9
  21. package/extensions/zalo/PACK.md +9 -0
  22. package/package.json +2 -2
  23. package/skills/audit/SKILL.md +526 -529
  24. package/skills/ba/SKILL.md +349 -351
  25. package/skills/completion-gate/SKILL.md +260 -263
  26. package/skills/context-engine/SKILL.md +0 -6
  27. package/skills/cook/SKILL.md +2 -11
  28. package/skills/db/SKILL.md +5 -1
  29. package/skills/db/references/scaling-reference.md +271 -0
  30. package/skills/debug/SKILL.md +392 -394
  31. package/skills/deploy/references/post-deploy-integration.md +192 -0
  32. package/skills/fix/SKILL.md +281 -282
  33. package/skills/onboard/SKILL.md +0 -4
  34. package/skills/plan/references/completeness-scoring.md +0 -1
  35. package/skills/plan/references/outcome-block.md +0 -1
  36. package/skills/plan/references/workflow-registry.md +0 -1
  37. package/skills/preflight/SKILL.md +360 -365
  38. package/skills/rescue/SKILL.md +1 -0
  39. package/skills/research/SKILL.md +149 -150
  40. package/skills/review/SKILL.md +489 -495
  41. package/skills/sentinel/SKILL.md +0 -11
  42. package/skills/sentinel/references/destructive-commands.md +0 -1
  43. package/skills/sentinel/references/skill-content-guard.md +0 -1
  44. package/skills/session-bridge/SKILL.md +0 -4
  45. package/skills/skill-forge/SKILL.md +5 -1
  46. package/skills/skill-forge/references/claude-skill-reference.md +182 -0
  47. package/skills/skill-router/{SKILL.md → skill.md} +446 -397
  48. package/skills/team/SKILL.md +1 -2
  49. package/skills/test/SKILL.md +585 -593
  50. package/skills/watchdog/references/webhook-health-checks.md +243 -0
@@ -1,529 +1,526 @@
1
- ---
2
- name: audit
3
- description: Comprehensive project audit — security, dependencies, code quality, architecture, performance, infra, docs, and mesh analytics. Delegates to specialist skills and generates an 8-dimension health score.
4
- metadata:
5
- author: runedev
6
- version: "0.3.0"
7
- layer: L2
8
- model: sonnet
9
- group: quality
10
- tools: "Read, Bash, Glob, Grep"
11
- ---
12
-
13
- # audit
14
-
15
- ## Purpose
16
-
17
- Comprehensive project health audit across 8 dimensions (7 project + 1 mesh analytics). Delegates security scanning to `sentinel`, dependency analysis to `dependency-doctor`, and code complexity to `autopsy`, then directly audits architecture, performance, infrastructure, and documentation. Applies framework-specific checks (React/Next.js, Node.js, Python, Go, Rust, React Native/Flutter) based on detected stack. Produces a consolidated health score and prioritized action plan saved to `AUDIT-REPORT.md`.
18
-
19
- ## Triggers
20
-
21
- - `/rune audit` — manual invocation
22
- - User says "audit", "review project", "health check", "project assessment"
23
-
24
- ## Calls (outbound)
25
-
26
- - `scout` (L2): Phase 0 — project structure and stack discovery
27
- - `dependency-doctor` (L3): Phase 1 — vulnerability scan and outdated dependency check
28
- - `sentinel` (L2): Phase 2 — security audit (OWASP Top 10, secrets, config)
29
- - `autopsy` (L2): Phase 3 — code quality and complexity assessment
30
- - `perf` (L2): Phase 4 — performance regression check
31
- - `db` (L2): Phase 5 — database health dimension (schema, migrations, indexes)
32
- - `journal` (L3): record audit date, overall score, and verdict
33
- - `constraint-check` (L3): audit HARD-GATE compliance across project skills
34
- - `sast` (L3): Phase 2 — deep static analysis (Semgrep, Bandit, ESLint security rules)
35
- - `retro` (L2): Phase 6 — engineering velocity and health dimension (rune:retro)
36
-
37
- ## Called By (inbound)
38
-
39
- - `cook` (L1): pre-implementation audit gate
40
- - `launch` (L1): pre-launch health check
41
- - User: `/rune audit` direct invocation
42
-
43
- ## Executable Instructions
44
-
45
- ### Phase 0: Project Discovery
46
-
47
- Call `rune:scout` for a full project map. Then use `Read` on:
48
- - `README.md`, `CLAUDE.md`, `CONTRIBUTING.md`, `.editorconfig` (if they exist)
49
-
50
- Determine:
51
- - Language(s) and version(s)
52
- - Framework(s) — determines which Framework-Specific Checks below apply
53
- - Package manager, build tool(s), test framework(s), linter/formatter config
54
- - Project type: `API/backend` | `frontend/SPA` | `fullstack` | `CLI tool` | `library` | `mobile` | `infra/IaC`
55
- - Monorepo setup (workspaces, turborepo, nx, etc.)
56
-
57
- **Output before proceeding:** Brief project profile, stack summary, and which Framework-Specific Checks will be applied.
58
-
59
- ### Phase 0.5: Context-Building (Pure Understanding)
60
-
61
- <HARD-GATE>
62
- This phase is FORBIDDEN from producing findings. No BLOCKs, no WARNs, no issues. Context-building only.
63
- Rushed context = hallucinated vulnerabilities. Slow is fast.
64
- </HARD-GATE>
65
-
66
- For each critical module (entry points, auth, data layer, core business logic):
67
- 1. Read line-by-line. Note at minimum:
68
- - **3 invariants**: What MUST always be true for this code to work? (e.g., "user is authenticated before reaching this handler")
69
- - **5 assumptions**: What does this code assume about its inputs, environment, and callers?
70
- - **3 risks**: What could break if assumptions are violated?
71
- 2. Record findings as context notes — these feed into Phases 1-7, NOT into the final report directly
72
-
73
- **Why**: Without this phase, the auditor pattern-matches against known vulnerability lists and hallucinates findings that don't exist in THIS specific codebase. The invariants + assumptions ground all later analysis in reality.
74
-
75
- > Source: trailofbits/skills (3.7k★) — mandatory pure context phase before findings.
76
-
77
- ---
78
-
79
- ### Phase 1: Dependency Audit
80
-
81
- Delegate to `dependency-doctor`. The dependency-doctor report covers:
82
- - Vulnerability scan (CVEs by severity)
83
- - Outdated packages (patch / minor / major)
84
- - Unused dependencies
85
- - Dependency health score
86
-
87
- Pass the full dependency-doctor report through to the final audit.
88
-
89
- ---
90
-
91
- ### Phase 2: Security Audit
92
-
93
- Delegate to `sentinel`. Request a full security scan covering:
94
- - Hardcoded secrets, API keys, tokens, passwords in source code
95
- - OWASP Top 10: injection, broken auth, sensitive data exposure, XSS, CSRF, insecure deserialization, broken access control
96
- - Configuration security (debug mode in prod, CORS `*`, missing HTTP security headers)
97
- - Input validation at API boundaries
98
- - `.gitignore` coverage of sensitive files
99
-
100
- Pass the full sentinel report through to the final audit.
101
-
102
- ---
103
-
104
- ### Phase 3: Code Quality Audit
105
-
106
- Delegate to `autopsy` for codebase health (complexity, coupling, hotspots, dead code, health score per module).
107
-
108
- In addition, use `Grep` to find supplementary issues autopsy may not cover:
109
-
110
- ```bash
111
- # console.log in production code
112
- grep -r "console\.log" src/ --include="*.ts" --include="*.js" -l
113
-
114
- # TypeScript any types
115
- grep -r ": any" src/ --include="*.ts" -n
116
-
117
- # Empty catch blocks
118
- grep -rn "catch.*{" src/ --include="*.ts" --include="*.js" -A 1 | grep -E "^\s*}"
119
-
120
- # Python print() in production
121
- grep -r "^print(" . --include="*.py" -l
122
-
123
- # Rust .unwrap() outside tests
124
- grep -rn "\.unwrap()" src/ --include="*.rs"
125
- ```
126
-
127
- Merge autopsy report + supplementary findings.
128
-
129
- ---
130
-
131
- ### Phase 4: Architecture Audit
132
-
133
- Use `Read` and `Grep` to evaluate structural health directly.
134
-
135
- **4.1 Project Structure**
136
- - Logical folder organization (business logic vs infrastructure vs presentation separated?)
137
- - Circular dependencies between modules (A imports B, B imports A)
138
- - Barrel file analysis (excessive re-exports causing bundle bloat)
139
-
140
- **4.2 Design Patterns & Principles**
141
- - Single Responsibility violations (route handlers with direct DB calls, fat controllers)
142
- - Tight coupling between layers
143
-
144
- ```typescript
145
- // BAD route handler directly coupled to database
146
- app.get('/users/:id', async (req, res) => {
147
- const user = await db.query('SELECT * FROM users WHERE id = $1', [req.params.id]);
148
- res.json(user);
149
- });
150
- // GOOD layered architecture
151
- app.get('/users/:id', async (req, res) => {
152
- const user = await userService.getUser(req.params.id);
153
- res.json(user);
154
- });
155
- ```
156
-
157
- **4.3 API Design** (if applicable)
158
- - Consistent naming conventions (camelCase vs snake_case in JSON responses)
159
- - Correct HTTP method usage (GET reads, POST creates, PUT/PATCH updates, DELETE removes)
160
- - Consistent error response format across endpoints
161
- - Pagination on collection endpoints
162
- - API versioning strategy
163
-
164
- **4.4 Database Patterns** (if applicable)
165
- - N+1 query patterns
166
-
167
- ```typescript
168
- // BAD N+1
169
- const users = await db.query('SELECT * FROM users');
170
- for (const user of users) {
171
- user.posts = await db.query('SELECT * FROM posts WHERE user_id = $1', [user.id]);
172
- }
173
- // GOOD single JOIN
174
- const usersWithPosts = await db.query(`
175
- SELECT u.*, json_agg(p.*) as posts
176
- FROM users u LEFT JOIN posts p ON p.user_id = u.id
177
- GROUP BY u.id
178
- `);
179
- ```
180
-
181
- - Missing indexes (check schema/migrations for columns used in WHERE/JOIN)
182
- - Missing `LIMIT` on user-facing queries
183
-
184
- **4.5 State Management** (frontend only)
185
- - Global state pollution (local state handled globally)
186
- - Prop drilling (>3 levels deep — use Context or composition)
187
- - Data fetching patterns (caching, deduplication, stale-while-revalidate)
188
-
189
- ---
190
-
191
- ### Phase 5: Performance Audit
192
-
193
- **5.1 Build & Bundle** (frontend)
194
- - Tree-shaking effectiveness (importing entire libraries vs specific modules)
195
-
196
- ```typescript
197
- // BADimports entire library
198
- import _ from 'lodash';
199
- // GOOD — tree-shakeable import
200
- import get from 'lodash/get';
201
- ```
202
-
203
- - Code splitting / lazy loading for routes
204
- - Large unoptimized assets
205
-
206
- **5.2 Runtime Performance**
207
- - Synchronous operations that should be async (file I/O, network calls)
208
- - Memory leak patterns (event listeners not cleaned up, growing caches, unclosed streams)
209
- - Expensive operations in hot paths
210
-
211
- ```typescript
212
- // BAD — regex compiled on every call
213
- function validate(input: string) {
214
- return /^[a-zA-Z0-9._%+-]+@[a-zA-Z0-9.-]+\.[a-zA-Z]{2,}$/.test(input);
215
- }
216
- // GOOD compile once at module level
217
- const EMAIL_REGEX = /^[a-zA-Z0-9._%+-]+@[a-zA-Z0-9.-]+\.[a-zA-Z]{2,}$/;
218
- function validate(input: string) { return EMAIL_REGEX.test(input); }
219
- ```
220
-
221
- **5.3 Database & I/O**
222
- - Missing connection pooling
223
- - Unbounded queries (no `LIMIT` on user-facing endpoints)
224
- - Sequential I/O that could be parallel
225
-
226
- ```typescript
227
- // BAD sequential when independent
228
- const users = await fetchUsers();
229
- const products = await fetchProducts();
230
- // GOOD — parallel
231
- const [users, products] = await Promise.all([fetchUsers(), fetchProducts()]);
232
- ```
233
-
234
- ---
235
-
236
- ### Phase 6: Infrastructure & DevOps Audit
237
-
238
- Use `Glob` and `Read` to check:
239
-
240
- **6.1 CI/CD Pipeline**
241
- - CI config exists (`.github/workflows/`, `.gitlab-ci.yml`, `.circleci/`, `Jenkinsfile`)
242
- - Tests running in CI
243
- - Linting enforced in CI
244
- - Security scanning in pipeline (Dependabot, Snyk, CodeQL)
245
-
246
- **6.2 Environment Configuration**
247
- - `.env.example` exists with placeholder values (not real secrets)
248
- - Environment variables validated at startup
249
-
250
- ```typescript
251
- // BADsilently undefined
252
- const port = process.env.PORT;
253
- // GOOD validate at startup
254
- const port = process.env.PORT;
255
- if (!port) throw new Error('PORT environment variable is required');
256
- ```
257
-
258
- **6.3 Containerization** (if applicable)
259
- - Dockerfile: multi-stage build, non-root user, minimal base image
260
- - `.dockerignore` covers `node_modules`, `.git`, `.env`
261
-
262
- **6.4 Logging & Monitoring**
263
- - Structured logging (JSON format, not raw `console.log`)
264
- - Error tracking integration (Sentry, Datadog, etc.)
265
- - Health check endpoints (`/health`, `/ready`)
266
- - No sensitive data in logs (passwords, tokens, PII)
267
-
268
- ---
269
-
270
- ### Phase 7: Documentation Audit
271
-
272
- Use `Glob` and `Read` to check:
273
-
274
- **7.1 Project Documentation**
275
- - README completeness: description, prerequisites, setup, usage, deployment, contributing
276
- - API documentation (OpenAPI/Swagger spec, or documented endpoints)
277
- - Can a new developer get running from README alone?
278
- - Architecture Decision Records (ADRs) for non-obvious choices
279
-
280
- **7.2 Code Documentation**
281
- - Public API / exported functions documented
282
- - Complex business logic with explanatory comments
283
- - `CHANGELOG.md` maintained
284
- - `LICENSE` file present
285
-
286
- ---
287
-
288
- ### Framework-Specific Checks
289
-
290
- Apply **only** if the framework was detected in Phase 0. Skip entirely if not relevant.
291
-
292
- **React / Next.js** (detect: `react` or `next` in `package.json`)
293
- - `useEffect` with missing dependencies (stale closures)
294
- - State updates during render (infinite loop pattern)
295
- - List items using index as key on reorderable lists
296
- - Props drilled through 3+ levels
297
- - Client-side hooks in Server Components (Next.js App Router)
298
- - Components exceeding 200 JSX lines
299
-
300
- **Node.js / Express / Fastify** (detect: `express`, `fastify`, `koa`, `@nestjs/core`)
301
- - Missing rate limiting on public endpoints
302
- - Missing request timeout configuration
303
- - Error messages leaking internal details to clients
304
- - Unbounded `SELECT *` without pagination
305
- - Missing authentication middleware on protected routes
306
- - Synchronous operations blocking the event loop
307
-
308
- **Python (Django / Flask / FastAPI)** (detect: `django`, `flask`, `fastapi` in requirements)
309
- - Django: missing `permission_classes`, `DEBUG=True` in production, missing CSRF middleware
310
- - Flask: `app.run(debug=True)` without environment check
311
- - FastAPI: missing Pydantic models for request/response
312
- - Mutable default arguments (`def func(items=[])`)
313
- - Missing type hints on public functions (if project uses mypy/pyright)
314
-
315
- **Go** (detect: `go.mod`)
316
- - Ignored errors (`file, _ := os.Open(filename)`)
317
- - Goroutine leaks (goroutines without cancellation context)
318
- - Missing `defer` for resource cleanup (files, locks, connections)
319
- - Race conditions (shared state without mutex or channels)
320
-
321
- **Rust** (detect: `Cargo.toml`)
322
- - `.unwrap()` / `.expect()` in non-test production code (use `?` operator)
323
- - `unsafe` blocks without safety comments
324
-
325
- **Mobile (React Native / Flutter)** (detect: `react-native` in `package.json` or `pubspec.yaml`)
326
- - FlatList without `keyExtractor` or `getItemLayout`
327
- - Missing `React.memo` on list item components
328
- - Flutter: missing `const` constructors, missing `dispose()` for controllers and streams
329
-
330
- ---
331
-
332
- ### Phase 8: Mesh Analytics (H3 Intelligence)
333
-
334
- **Goal**: Surface insights about skill usage, chain patterns, and mesh health from accumulated metrics.
335
-
336
- **Data source**: `.rune/metrics/` directory (populated by hooks automatically).
337
-
338
- 1. Check if `.rune/metrics/` exists. If not, emit INFO: "No metrics data yet — run a few cook sessions first."
339
- 2. Read `.rune/metrics/skills.json` — extract per-skill invocation counts, last used dates
340
- 3. Read `.rune/metrics/sessions.jsonl` extract session count, avg duration, avg tool calls
341
- 4. Read `.rune/metrics/chains.jsonl` — extract most common skill chains
342
- 5. Read `.rune/metrics/routing-overrides.json` (if exists) — list active routing overrides
343
-
344
- Compute and report:
345
- - **Top 10 most-used skills** (by total invocations)
346
- - **Unused skills** (0 invocations across all tracked sessions) — potential dead nodes
347
- - **Most common skill chains** (top 5 patterns from chains.jsonl)
348
- - **Average session stats** (duration, tool calls, skill invocations)
349
- - **Active routing overrides** and their application count
350
- - **Mesh density check**: cross-reference invocation data with declared connections skills that are declared as "Called By" but never actually invoked may indicate broken mesh paths
351
-
352
- **Propose routing overrides**: If patterns suggest inefficiency (e.g., debug consistently called 3+ times in a chain for the same session), propose a new routing override for user approval.
353
-
354
- Output as a section in the final audit report:
355
-
356
- ```
357
- ### Mesh Analytics
358
- | Skill | Invocations | Last Used | Chains Containing |
359
- |-------|-------------|-----------|-------------------|
360
- | cook | 47 | 2026-02-28| 34 |
361
- | scout | 89 | 2026-02-28| 42 |
362
- | ... | ... | ... | ... |
363
-
364
- **Common Chains**:
365
- 1. cook → scout → plan → test → fix → quality → verify (34x)
366
- 2. debug scout fix verification (12x)
367
-
368
- **Session Stats**: 23 sessions, avg 35min, avg 52 tool calls
369
- **Unused Skills**: [list or "none"]
370
- **Routing Overrides**: [count] active
371
- ```
372
-
373
- **Shortcut**: `/rune metrics` invokes ONLY this phase, not the full 7-phase audit.
374
-
375
- ---
376
-
377
- ### Final Report
378
-
379
- After all phases complete:
380
-
381
- Use `Write` to save `AUDIT-REPORT.md` to the project root with the full findings from all phases.
382
-
383
- Call `rune:journal` to record: audit date, overall health score, verdict, and CRITICAL count.
384
-
385
- ## Weighted Composite Scoring
386
-
387
- Each dimension score feeds into a weighted composite formula that produces a single comparable health score. Use this formula to compute **Overall Health** — not a simple average.
388
-
389
- ### Scoring Formula
390
-
391
- ```
392
- Overall = (Security × 0.25) + (Code Quality × 0.20) + (Architecture × 0.15)
393
- + (Dependencies × 0.15) + (Performance × 0.10) + (Infrastructure × 0.08)
394
- + (Documentation × 0.07)
395
- ```
396
-
397
- Mesh Analytics (Phase 8) is advisory — it contributes 0 to the weighted score but informs the verdict narrative.
398
-
399
- ### Grade Thresholds
400
-
401
- | Score Range | Grade | Verdict | Action |
402
- |-------------|-------|---------|--------|
403
- | 90100 | Excellent | PASS | Routine audit in 3 months |
404
- | 7589 | Good | PASS | Address MEDIUM items next sprint |
405
- | 6074 | Fair | WARNING | Fix HIGH items within 2 weeks |
406
- | 40–59 | Poor | FAIL | Fix CRITICAL + HIGH within 1 week |
407
- | 0–39 | Critical | FAIL | Emergency response — CRITICAL items block all new work |
408
-
409
- ### Why Weighted (not average)
410
-
411
- Security issues cause exponential blast — a 3/10 security score with all other dimensions at 9/10 = overall 72 (Fair), not 8.1 (Good). The formula ensures security and code quality dominate the verdict. Comparable across runs: if Overall moves from 68 → 74 after fixes, the project measurably improved.
412
-
413
- > Source: zubair-trabzada/geo-seo-claude (2.7k★) — explicit weighted formula with 5-tier grade thresholds.
414
-
415
- ## Severity Levels
416
-
417
- ```
418
- CRITICAL Must fix immediately. Security vulnerabilities, data loss, broken builds.
419
- HIGHShould fix soon. Performance bottlenecks, CVEs, major code smells.
420
- MEDIUM — Plan to fix. Code duplication, missing tests, outdated deps.
421
- LOW — Nice to have. Style inconsistencies, minor refactors, doc gaps.
422
- INFO — Observation only. Architecture notes, tech debt acknowledgment.
423
- ```
424
-
425
- Apply confidence filtering: only report findings with >80% confidence. Consolidate similar issues (e.g., "12 functions missing error handling in src/services/" — not 12 separate findings). Adapt judgment to project type (a `console.log` in a CLI tool is fine; in a production API handler, it's not).
426
-
427
- ## Output Format
428
-
429
- ```
430
- ## Audit Report: [Project Name]
431
-
432
- - **Verdict**: PASS | WARNING | FAIL
433
- - **Overall Health**: [score]/10
434
- - **Total Findings**: [n] (CRITICAL: [n], HIGH: [n], MEDIUM: [n], LOW: [n])
435
- - **Framework Checks Applied**: [list]
436
-
437
- ### Health Score
438
- | Dimension | Score | Notes |
439
- |----------------|:--------:|--------------------|
440
- | Security | ?/10 | [brief note] |
441
- | Code Quality | ?/10 | [brief note] |
442
- | Architecture | ?/10 | [brief note] |
443
- | Performance | ?/10 | [brief note] |
444
- | Dependencies | ?/10 | [brief note] |
445
- | Infrastructure | ?/10 | [brief note] |
446
- | Documentation | ?/10 | [brief note] |
447
- | Mesh Analytics | ?/10 | [brief note] |
448
- | **Overall** | **?/10** | **[verdict]** |
449
-
450
- ### Phase Breakdown
451
- | Phase | Issues |
452
- |----------------|--------|
453
- | Dependencies | [n] |
454
- | Security | [n] |
455
- | Code Quality | [n] |
456
- | Architecture | [n] |
457
- | Performance | [n] |
458
- | Infrastructure | [n] |
459
- | Documentation | [n] |
460
- | Mesh Analytics | [n] |
461
-
462
- ### Composite Score
463
- - **Formula**: (Security×0.25) + (Code Quality×0.20) + (Architecture×0.15) + (Dependencies×0.15) + (Performance×0.10) + (Infrastructure×0.08) + (Documentation×0.07)
464
- - **Weighted Score**: [computed value] Grade: [Excellent/Good/Fair/Poor/Critical]
465
-
466
- ### Top Priority Actions
467
- 1. [action] [file:line] [why it matters]
468
-
469
- ### Positive Findings
470
- - [at least 3 things the project does well]
471
-
472
- ### Follow-up Timeline
473
- - FAIL → re-audit in 1-2 weeks after CRITICAL fixes
474
- - WARNING re-audit in 1 month
475
- - PASS → routine audit in 3 months
476
-
477
- Report saved to: AUDIT-REPORT.md
478
- ```
479
-
480
- ## Constraints
481
-
482
- 1. MUST complete all 8 phases (Phase 8 may report "no data" if .rune/metrics/ doesn't exist yet) — if any phase is skipped, state explicitly which phase and why
483
- 2. MUST delegate Phase 1 to dependency-doctor and Phase 2 to sentinel no manual replacements
484
- 3. MUST apply confidence filteronly report findings with >80% confidence; consolidate similar issues
485
- 4. MUST include at least 3 positive findings — an audit with no positives is incomplete
486
- 5. MUST produce quantified health scores (1-10 per dimension) — not vague "needs work"
487
- 6. MUST NOT fabricate findings — every finding requires a specific file:line citation
488
- 7. MUST save AUDIT-REPORT.md before declaring completion
489
-
490
- ## Mesh Gates
491
-
492
- | Gate | Requires | If Missing |
493
- |------|----------|------------|
494
- | Discovery Gate | Phase 0 project profile completed before Phase 1 | Run scout and read config files first |
495
- | Security Gate | sentinel report received before assembling final report | Invoke rune:sentinel — do not skip |
496
- | Deps Gate | dependency-doctor report received before assembling final report | Invoke rune:dependency-doctor — do not skip |
497
- | Report Gate | All 8 phases completed before writing AUDIT-REPORT.md | Complete all phases, note skipped ones |
498
-
499
- ## Returns
500
-
501
- | Artifact | Format | Location |
502
- |----------|--------|----------|
503
- | Audit report | Markdown | `AUDIT-REPORT.md` (project root) |
504
- | 8-dimension health score | Markdown table | `AUDIT-REPORT.md` + inline |
505
- | Weighted composite score + grade | Markdown | inline + `AUDIT-REPORT.md` |
506
- | Mesh analytics section | Markdown table | inline + `AUDIT-REPORT.md` |
507
- | Journal entry | Text | `.rune/adr/` (via `rune:journal`) |
508
-
509
- ## Sharp Edges
510
-
511
- | Failure Mode | Severity | Mitigation |
512
- |---|---|---|
513
- | Generating health scores from file name patterns instead of actual reads | CRITICAL | Phase 0 scout run is mandatory never score without reading actual code |
514
- | Skipping a phase because "there are no changes in that area" | HIGH | All 7 phases run for every audit — partial audits produce misleading scores |
515
- | Health score inflation — no negative findings in any dimension | MEDIUM | CONSTRAINT: minimum 3 positive AND 3 improvement areas required |
516
- | Dependency-doctor or sentinel sub-call times out → skipped silently | MEDIUM | Mark phase as "incomplete — tool timeout" with N/A score, do not fabricate |
517
-
518
- ## Done When
519
-
520
- - All 8 phases completed (or explicitly marked N/A with reason)
521
- - Health score calculated from actual file reads per dimension (not estimated)
522
- - At least 3 positive findings and 3 improvement areas documented
523
- - AUDIT-REPORT.md written to project root
524
- - Journal entry recorded with audit date, score, and CRITICAL count
525
- - Structured report emitted with overall health score and verdict
526
-
527
- ## Cost Profile
528
-
529
- ~8000-20000 tokens input, ~3000-6000 tokens output. Sonnet orchestrating; sentinel (sonnet/opus) and autopsy (opus) are the expensive sub-calls. Full audit runs 4 sub-skills. Most thorough L2 skill — run on demand, not on every cycle.
1
+ ---
2
+ name: audit
3
+ description: Comprehensive project audit — security, dependencies, code quality, architecture, performance, infra, docs, and mesh analytics. Delegates to specialist skills and generates an 8-dimension health score.
4
+ metadata:
5
+ author: runedev
6
+ version: "0.3.0"
7
+ layer: L2
8
+ model: sonnet
9
+ group: quality
10
+ tools: "Read, Bash, Glob, Grep"
11
+ ---
12
+
13
+ # audit
14
+
15
+ ## Purpose
16
+
17
+ Comprehensive project health audit across 8 dimensions (7 project + 1 mesh analytics). Delegates security scanning to `sentinel`, dependency analysis to `dependency-doctor`, and code complexity to `autopsy`, then directly audits architecture, performance, infrastructure, and documentation. Applies framework-specific checks (React/Next.js, Node.js, Python, Go, Rust, React Native/Flutter) based on detected stack. Produces a consolidated health score and prioritized action plan saved to `AUDIT-REPORT.md`.
18
+
19
+ ## Triggers
20
+
21
+ - `/rune audit` — manual invocation
22
+ - User says "audit", "review project", "health check", "project assessment"
23
+
24
+ ## Calls (outbound)
25
+
26
+ - `scout` (L2): Phase 0 — project structure and stack discovery
27
+ - `dependency-doctor` (L3): Phase 1 — vulnerability scan and outdated dependency check
28
+ - `sentinel` (L2): Phase 2 — security audit (OWASP Top 10, secrets, config)
29
+ - `autopsy` (L2): Phase 3 — code quality and complexity assessment
30
+ - `perf` (L2): Phase 4 — performance regression check
31
+ - `db` (L2): Phase 5 — database health dimension (schema, migrations, indexes)
32
+ - `journal` (L3): record audit date, overall score, and verdict
33
+ - `constraint-check` (L3): audit HARD-GATE compliance across project skills
34
+ - `sast` (L3): Phase 2 — deep static analysis (Semgrep, Bandit, ESLint security rules)
35
+ - `retro` (L2): Phase 6 — engineering velocity and health dimension (rune:retro)
36
+
37
+ ## Called By (inbound)
38
+
39
+ - `cook` (L1): pre-implementation audit gate
40
+ - `launch` (L1): pre-launch health check
41
+ - User: `/rune audit` direct invocation
42
+
43
+ ## Executable Instructions
44
+
45
+ ### Phase 0: Project Discovery
46
+
47
+ Call `rune:scout` for a full project map. Then use `Read` on:
48
+ - `README.md`, `CLAUDE.md`, `CONTRIBUTING.md`, `.editorconfig` (if they exist)
49
+
50
+ Determine:
51
+ - Language(s) and version(s)
52
+ - Framework(s) — determines which Framework-Specific Checks below apply
53
+ - Package manager, build tool(s), test framework(s), linter/formatter config
54
+ - Project type: `API/backend` | `frontend/SPA` | `fullstack` | `CLI tool` | `library` | `mobile` | `infra/IaC`
55
+ - Monorepo setup (workspaces, turborepo, nx, etc.)
56
+
57
+ **Output before proceeding:** Brief project profile, stack summary, and which Framework-Specific Checks will be applied.
58
+
59
+ ### Phase 0.5: Context-Building (Pure Understanding)
60
+
61
+ <HARD-GATE>
62
+ This phase is FORBIDDEN from producing findings. No BLOCKs, no WARNs, no issues. Context-building only.
63
+ Rushed context = hallucinated vulnerabilities. Slow is fast.
64
+ </HARD-GATE>
65
+
66
+ For each critical module (entry points, auth, data layer, core business logic):
67
+ 1. Read line-by-line. Note at minimum:
68
+ - **3 invariants**: What MUST always be true for this code to work? (e.g., "user is authenticated before reaching this handler")
69
+ - **5 assumptions**: What does this code assume about its inputs, environment, and callers?
70
+ - **3 risks**: What could break if assumptions are violated?
71
+ 2. Record findings as context notes — these feed into Phases 1-7, NOT into the final report directly
72
+
73
+ **Why**: Without this phase, the auditor pattern-matches against known vulnerability lists and hallucinates findings that don't exist in THIS specific codebase. The invariants + assumptions ground all later analysis in reality.
74
+
75
+ ---
76
+
77
+ ### Phase 1: Dependency Audit
78
+
79
+ Delegate to `dependency-doctor`. The dependency-doctor report covers:
80
+ - Vulnerability scan (CVEs by severity)
81
+ - Outdated packages (patch / minor / major)
82
+ - Unused dependencies
83
+ - Dependency health score
84
+
85
+ Pass the full dependency-doctor report through to the final audit.
86
+
87
+ ---
88
+
89
+ ### Phase 2: Security Audit
90
+
91
+ Delegate to `sentinel`. Request a full security scan covering:
92
+ - Hardcoded secrets, API keys, tokens, passwords in source code
93
+ - OWASP Top 10: injection, broken auth, sensitive data exposure, XSS, CSRF, insecure deserialization, broken access control
94
+ - Configuration security (debug mode in prod, CORS `*`, missing HTTP security headers)
95
+ - Input validation at API boundaries
96
+ - `.gitignore` coverage of sensitive files
97
+
98
+ Pass the full sentinel report through to the final audit.
99
+
100
+ ---
101
+
102
+ ### Phase 3: Code Quality Audit
103
+
104
+ Delegate to `autopsy` for codebase health (complexity, coupling, hotspots, dead code, health score per module).
105
+
106
+ In addition, use `Grep` to find supplementary issues autopsy may not cover:
107
+
108
+ ```bash
109
+ # console.log in production code
110
+ grep -r "console\.log" src/ --include="*.ts" --include="*.js" -l
111
+
112
+ # TypeScript any types
113
+ grep -r ": any" src/ --include="*.ts" -n
114
+
115
+ # Empty catch blocks
116
+ grep -rn "catch.*{" src/ --include="*.ts" --include="*.js" -A 1 | grep -E "^\s*}"
117
+
118
+ # Python print() in production
119
+ grep -r "^print(" . --include="*.py" -l
120
+
121
+ # Rust .unwrap() outside tests
122
+ grep -rn "\.unwrap()" src/ --include="*.rs"
123
+ ```
124
+
125
+ Merge autopsy report + supplementary findings.
126
+
127
+ ---
128
+
129
+ ### Phase 4: Architecture Audit
130
+
131
+ Use `Read` and `Grep` to evaluate structural health directly.
132
+
133
+ **4.1 Project Structure**
134
+ - Logical folder organization (business logic vs infrastructure vs presentation separated?)
135
+ - Circular dependencies between modules (A imports B, B imports A)
136
+ - Barrel file analysis (excessive re-exports causing bundle bloat)
137
+
138
+ **4.2 Design Patterns & Principles**
139
+ - Single Responsibility violations (route handlers with direct DB calls, fat controllers)
140
+ - Tight coupling between layers
141
+
142
+ ```typescript
143
+ // BAD — route handler directly coupled to database
144
+ app.get('/users/:id', async (req, res) => {
145
+ const user = await db.query('SELECT * FROM users WHERE id = $1', [req.params.id]);
146
+ res.json(user);
147
+ });
148
+ // GOOD — layered architecture
149
+ app.get('/users/:id', async (req, res) => {
150
+ const user = await userService.getUser(req.params.id);
151
+ res.json(user);
152
+ });
153
+ ```
154
+
155
+ **4.3 API Design** (if applicable)
156
+ - Consistent naming conventions (camelCase vs snake_case in JSON responses)
157
+ - Correct HTTP method usage (GET reads, POST creates, PUT/PATCH updates, DELETE removes)
158
+ - Consistent error response format across endpoints
159
+ - Pagination on collection endpoints
160
+ - API versioning strategy
161
+
162
+ **4.4 Database Patterns** (if applicable)
163
+ - N+1 query patterns
164
+
165
+ ```typescript
166
+ // BAD — N+1
167
+ const users = await db.query('SELECT * FROM users');
168
+ for (const user of users) {
169
+ user.posts = await db.query('SELECT * FROM posts WHERE user_id = $1', [user.id]);
170
+ }
171
+ // GOOD single JOIN
172
+ const usersWithPosts = await db.query(`
173
+ SELECT u.*, json_agg(p.*) as posts
174
+ FROM users u LEFT JOIN posts p ON p.user_id = u.id
175
+ GROUP BY u.id
176
+ `);
177
+ ```
178
+
179
+ - Missing indexes (check schema/migrations for columns used in WHERE/JOIN)
180
+ - Missing `LIMIT` on user-facing queries
181
+
182
+ **4.5 State Management** (frontend only)
183
+ - Global state pollution (local state handled globally)
184
+ - Prop drilling (>3 levels deep — use Context or composition)
185
+ - Data fetching patterns (caching, deduplication, stale-while-revalidate)
186
+
187
+ ---
188
+
189
+ ### Phase 5: Performance Audit
190
+
191
+ **5.1 Build & Bundle** (frontend)
192
+ - Tree-shaking effectiveness (importing entire libraries vs specific modules)
193
+
194
+ ```typescript
195
+ // BAD — imports entire library
196
+ import _ from 'lodash';
197
+ // GOODtree-shakeable import
198
+ import get from 'lodash/get';
199
+ ```
200
+
201
+ - Code splitting / lazy loading for routes
202
+ - Large unoptimized assets
203
+
204
+ **5.2 Runtime Performance**
205
+ - Synchronous operations that should be async (file I/O, network calls)
206
+ - Memory leak patterns (event listeners not cleaned up, growing caches, unclosed streams)
207
+ - Expensive operations in hot paths
208
+
209
+ ```typescript
210
+ // BAD — regex compiled on every call
211
+ function validate(input: string) {
212
+ return /^[a-zA-Z0-9._%+-]+@[a-zA-Z0-9.-]+\.[a-zA-Z]{2,}$/.test(input);
213
+ }
214
+ // GOOD — compile once at module level
215
+ const EMAIL_REGEX = /^[a-zA-Z0-9._%+-]+@[a-zA-Z0-9.-]+\.[a-zA-Z]{2,}$/;
216
+ function validate(input: string) { return EMAIL_REGEX.test(input); }
217
+ ```
218
+
219
+ **5.3 Database & I/O**
220
+ - Missing connection pooling
221
+ - Unbounded queries (no `LIMIT` on user-facing endpoints)
222
+ - Sequential I/O that could be parallel
223
+
224
+ ```typescript
225
+ // BAD — sequential when independent
226
+ const users = await fetchUsers();
227
+ const products = await fetchProducts();
228
+ // GOOD parallel
229
+ const [users, products] = await Promise.all([fetchUsers(), fetchProducts()]);
230
+ ```
231
+
232
+ ---
233
+
234
+ ### Phase 6: Infrastructure & DevOps Audit
235
+
236
+ Use `Glob` and `Read` to check:
237
+
238
+ **6.1 CI/CD Pipeline**
239
+ - CI config exists (`.github/workflows/`, `.gitlab-ci.yml`, `.circleci/`, `Jenkinsfile`)
240
+ - Tests running in CI
241
+ - Linting enforced in CI
242
+ - Security scanning in pipeline (Dependabot, Snyk, CodeQL)
243
+
244
+ **6.2 Environment Configuration**
245
+ - `.env.example` exists with placeholder values (not real secrets)
246
+ - Environment variables validated at startup
247
+
248
+ ```typescript
249
+ // BAD — silently undefined
250
+ const port = process.env.PORT;
251
+ // GOODvalidate at startup
252
+ const port = process.env.PORT;
253
+ if (!port) throw new Error('PORT environment variable is required');
254
+ ```
255
+
256
+ **6.3 Containerization** (if applicable)
257
+ - Dockerfile: multi-stage build, non-root user, minimal base image
258
+ - `.dockerignore` covers `node_modules`, `.git`, `.env`
259
+
260
+ **6.4 Logging & Monitoring**
261
+ - Structured logging (JSON format, not raw `console.log`)
262
+ - Error tracking integration (Sentry, Datadog, etc.)
263
+ - Health check endpoints (`/health`, `/ready`)
264
+ - No sensitive data in logs (passwords, tokens, PII)
265
+
266
+ ---
267
+
268
+ ### Phase 7: Documentation Audit
269
+
270
+ Use `Glob` and `Read` to check:
271
+
272
+ **7.1 Project Documentation**
273
+ - README completeness: description, prerequisites, setup, usage, deployment, contributing
274
+ - API documentation (OpenAPI/Swagger spec, or documented endpoints)
275
+ - Can a new developer get running from README alone?
276
+ - Architecture Decision Records (ADRs) for non-obvious choices
277
+
278
+ **7.2 Code Documentation**
279
+ - Public API / exported functions documented
280
+ - Complex business logic with explanatory comments
281
+ - `CHANGELOG.md` maintained
282
+ - `LICENSE` file present
283
+
284
+ ---
285
+
286
+ ### Framework-Specific Checks
287
+
288
+ Apply **only** if the framework was detected in Phase 0. Skip entirely if not relevant.
289
+
290
+ **React / Next.js** (detect: `react` or `next` in `package.json`)
291
+ - `useEffect` with missing dependencies (stale closures)
292
+ - State updates during render (infinite loop pattern)
293
+ - List items using index as key on reorderable lists
294
+ - Props drilled through 3+ levels
295
+ - Client-side hooks in Server Components (Next.js App Router)
296
+ - Components exceeding 200 JSX lines
297
+
298
+ **Node.js / Express / Fastify** (detect: `express`, `fastify`, `koa`, `@nestjs/core`)
299
+ - Missing rate limiting on public endpoints
300
+ - Missing request timeout configuration
301
+ - Error messages leaking internal details to clients
302
+ - Unbounded `SELECT *` without pagination
303
+ - Missing authentication middleware on protected routes
304
+ - Synchronous operations blocking the event loop
305
+
306
+ **Python (Django / Flask / FastAPI)** (detect: `django`, `flask`, `fastapi` in requirements)
307
+ - Django: missing `permission_classes`, `DEBUG=True` in production, missing CSRF middleware
308
+ - Flask: `app.run(debug=True)` without environment check
309
+ - FastAPI: missing Pydantic models for request/response
310
+ - Mutable default arguments (`def func(items=[])`)
311
+ - Missing type hints on public functions (if project uses mypy/pyright)
312
+
313
+ **Go** (detect: `go.mod`)
314
+ - Ignored errors (`file, _ := os.Open(filename)`)
315
+ - Goroutine leaks (goroutines without cancellation context)
316
+ - Missing `defer` for resource cleanup (files, locks, connections)
317
+ - Race conditions (shared state without mutex or channels)
318
+
319
+ **Rust** (detect: `Cargo.toml`)
320
+ - `.unwrap()` / `.expect()` in non-test production code (use `?` operator)
321
+ - `unsafe` blocks without safety comments
322
+
323
+ **Mobile (React Native / Flutter)** (detect: `react-native` in `package.json` or `pubspec.yaml`)
324
+ - FlatList without `keyExtractor` or `getItemLayout`
325
+ - Missing `React.memo` on list item components
326
+ - Flutter: missing `const` constructors, missing `dispose()` for controllers and streams
327
+
328
+ ---
329
+
330
+ ### Phase 8: Mesh Analytics (H3 Intelligence)
331
+
332
+ **Goal**: Surface insights about skill usage, chain patterns, and mesh health from accumulated metrics.
333
+
334
+ **Data source**: `.rune/metrics/` directory (populated by hooks automatically).
335
+
336
+ 1. Check if `.rune/metrics/` exists. If not, emit INFO: "No metrics data yet — run a few cook sessions first."
337
+ 2. Read `.rune/metrics/skills.json` — extract per-skill invocation counts, last used dates
338
+ 3. Read `.rune/metrics/sessions.jsonl` extract session count, avg duration, avg tool calls
339
+ 4. Read `.rune/metrics/chains.jsonl` — extract most common skill chains
340
+ 5. Read `.rune/metrics/routing-overrides.json` (if exists) list active routing overrides
341
+
342
+ Compute and report:
343
+ - **Top 10 most-used skills** (by total invocations)
344
+ - **Unused skills** (0 invocations across all tracked sessions) — potential dead nodes
345
+ - **Most common skill chains** (top 5 patterns from chains.jsonl)
346
+ - **Average session stats** (duration, tool calls, skill invocations)
347
+ - **Active routing overrides** and their application count
348
+ - **Mesh density check**: cross-reference invocation data with declared connections — skills that are declared as "Called By" but never actually invoked may indicate broken mesh paths
349
+
350
+ **Propose routing overrides**: If patterns suggest inefficiency (e.g., debug consistently called 3+ times in a chain for the same session), propose a new routing override for user approval.
351
+
352
+ Output as a section in the final audit report:
353
+
354
+ ```
355
+ ### Mesh Analytics
356
+ | Skill | Invocations | Last Used | Chains Containing |
357
+ |-------|-------------|-----------|-------------------|
358
+ | cook | 47 | 2026-02-28| 34 |
359
+ | scout | 89 | 2026-02-28| 42 |
360
+ | ... | ... | ... | ... |
361
+
362
+ **Common Chains**:
363
+ 1. cook → scout → plan → test → fix → quality → verify (34x)
364
+ 2. debug → scout → fix → verification (12x)
365
+
366
+ **Session Stats**: 23 sessions, avg 35min, avg 52 tool calls
367
+ **Unused Skills**: [list or "none"]
368
+ **Routing Overrides**: [count] active
369
+ ```
370
+
371
+ **Shortcut**: `/rune metrics` invokes ONLY this phase, not the full 7-phase audit.
372
+
373
+ ---
374
+
375
+ ### Final Report
376
+
377
+ After all phases complete:
378
+
379
+ Use `Write` to save `AUDIT-REPORT.md` to the project root with the full findings from all phases.
380
+
381
+ Call `rune:journal` to record: audit date, overall health score, verdict, and CRITICAL count.
382
+
383
+ ## Weighted Composite Scoring
384
+
385
+ Each dimension score feeds into a weighted composite formula that produces a single comparable health score. Use this formula to compute **Overall Health** — not a simple average.
386
+
387
+ ### Scoring Formula
388
+
389
+ ```
390
+ Overall = (Security × 0.25) + (Code Quality × 0.20) + (Architecture × 0.15)
391
+ + (Dependencies × 0.15) + (Performance × 0.10) + (Infrastructure × 0.08)
392
+ + (Documentation × 0.07)
393
+ ```
394
+
395
+ Mesh Analytics (Phase 8) is advisory — it contributes 0 to the weighted score but informs the verdict narrative.
396
+
397
+ ### Grade Thresholds
398
+
399
+ | Score Range | Grade | Verdict | Action |
400
+ |-------------|-------|---------|--------|
401
+ | 90–100 | Excellent | PASS | Routine audit in 3 months |
402
+ | 75–89 | Good | PASS | Address MEDIUM items next sprint |
403
+ | 6074 | Fair | WARNING | Fix HIGH items within 2 weeks |
404
+ | 4059 | Poor | FAIL | Fix CRITICAL + HIGH within 1 week |
405
+ | 039 | Critical | FAIL | Emergency response — CRITICAL items block all new work |
406
+
407
+ ### Why Weighted (not average)
408
+
409
+ Security issues cause exponential blast — a 3/10 security score with all other dimensions at 9/10 = overall 72 (Fair), not 8.1 (Good). The formula ensures security and code quality dominate the verdict. Comparable across runs: if Overall moves from 68 → 74 after fixes, the project measurably improved.
410
+
411
+
412
+ ## Severity Levels
413
+
414
+ ```
415
+ CRITICAL Must fix immediately. Security vulnerabilities, data loss, broken builds.
416
+ HIGH — Should fix soon. Performance bottlenecks, CVEs, major code smells.
417
+ MEDIUM — Plan to fix. Code duplication, missing tests, outdated deps.
418
+ LOW Nice to have. Style inconsistencies, minor refactors, doc gaps.
419
+ INFOObservation only. Architecture notes, tech debt acknowledgment.
420
+ ```
421
+
422
+ Apply confidence filtering: only report findings with >80% confidence. Consolidate similar issues (e.g., "12 functions missing error handling in src/services/" — not 12 separate findings). Adapt judgment to project type (a `console.log` in a CLI tool is fine; in a production API handler, it's not).
423
+
424
+ ## Output Format
425
+
426
+ ```
427
+ ## Audit Report: [Project Name]
428
+
429
+ - **Verdict**: PASS | WARNING | FAIL
430
+ - **Overall Health**: [score]/10
431
+ - **Total Findings**: [n] (CRITICAL: [n], HIGH: [n], MEDIUM: [n], LOW: [n])
432
+ - **Framework Checks Applied**: [list]
433
+
434
+ ### Health Score
435
+ | Dimension | Score | Notes |
436
+ |----------------|:--------:|--------------------|
437
+ | Security | ?/10 | [brief note] |
438
+ | Code Quality | ?/10 | [brief note] |
439
+ | Architecture | ?/10 | [brief note] |
440
+ | Performance | ?/10 | [brief note] |
441
+ | Dependencies | ?/10 | [brief note] |
442
+ | Infrastructure | ?/10 | [brief note] |
443
+ | Documentation | ?/10 | [brief note] |
444
+ | Mesh Analytics | ?/10 | [brief note] |
445
+ | **Overall** | **?/10** | **[verdict]** |
446
+
447
+ ### Phase Breakdown
448
+ | Phase | Issues |
449
+ |----------------|--------|
450
+ | Dependencies | [n] |
451
+ | Security | [n] |
452
+ | Code Quality | [n] |
453
+ | Architecture | [n] |
454
+ | Performance | [n] |
455
+ | Infrastructure | [n] |
456
+ | Documentation | [n] |
457
+ | Mesh Analytics | [n] |
458
+
459
+ ### Composite Score
460
+ - **Formula**: (Security×0.25) + (Code Quality×0.20) + (Architecture×0.15) + (Dependencies×0.15) + (Performance×0.10) + (Infrastructure×0.08) + (Documentation×0.07)
461
+ - **Weighted Score**: [computed value] → Grade: [Excellent/Good/Fair/Poor/Critical]
462
+
463
+ ### Top Priority Actions
464
+ 1. [action] [file:line] [why it matters]
465
+
466
+ ### Positive Findings
467
+ - [at least 3 things the project does well]
468
+
469
+ ### Follow-up Timeline
470
+ - FAIL re-audit in 1-2 weeks after CRITICAL fixes
471
+ - WARNING → re-audit in 1 month
472
+ - PASS → routine audit in 3 months
473
+
474
+ Report saved to: AUDIT-REPORT.md
475
+ ```
476
+
477
+ ## Constraints
478
+
479
+ 1. MUST complete all 8 phases (Phase 8 may report "no data" if .rune/metrics/ doesn't exist yet) — if any phase is skipped, state explicitly which phase and why
480
+ 2. MUST delegate Phase 1 to dependency-doctor and Phase 2 to sentinel — no manual replacements
481
+ 3. MUST apply confidence filter — only report findings with >80% confidence; consolidate similar issues
482
+ 4. MUST include at least 3 positive findings an audit with no positives is incomplete
483
+ 5. MUST produce quantified health scores (1-10 per dimension) not vague "needs work"
484
+ 6. MUST NOT fabricate findingsevery finding requires a specific file:line citation
485
+ 7. MUST save AUDIT-REPORT.md before declaring completion
486
+
487
+ ## Mesh Gates
488
+
489
+ | Gate | Requires | If Missing |
490
+ |------|----------|------------|
491
+ | Discovery Gate | Phase 0 project profile completed before Phase 1 | Run scout and read config files first |
492
+ | Security Gate | sentinel report received before assembling final report | Invoke rune:sentinel — do not skip |
493
+ | Deps Gate | dependency-doctor report received before assembling final report | Invoke rune:dependency-doctor — do not skip |
494
+ | Report Gate | All 8 phases completed before writing AUDIT-REPORT.md | Complete all phases, note skipped ones |
495
+
496
+ ## Returns
497
+
498
+ | Artifact | Format | Location |
499
+ |----------|--------|----------|
500
+ | Audit report | Markdown | `AUDIT-REPORT.md` (project root) |
501
+ | 8-dimension health score | Markdown table | `AUDIT-REPORT.md` + inline |
502
+ | Weighted composite score + grade | Markdown | inline + `AUDIT-REPORT.md` |
503
+ | Mesh analytics section | Markdown table | inline + `AUDIT-REPORT.md` |
504
+ | Journal entry | Text | `.rune/adr/` (via `rune:journal`) |
505
+
506
+ ## Sharp Edges
507
+
508
+ | Failure Mode | Severity | Mitigation |
509
+ |---|---|---|
510
+ | Generating health scores from file name patterns instead of actual reads | CRITICAL | Phase 0 scout run is mandatory — never score without reading actual code |
511
+ | Skipping a phase because "there are no changes in that area" | HIGH | All 7 phases run for every audit — partial audits produce misleading scores |
512
+ | Health score inflation — no negative findings in any dimension | MEDIUM | CONSTRAINT: minimum 3 positive AND 3 improvement areas required |
513
+ | Dependency-doctor or sentinel sub-call times out skipped silently | MEDIUM | Mark phase as "incomplete tool timeout" with N/A score, do not fabricate |
514
+
515
+ ## Done When
516
+
517
+ - All 8 phases completed (or explicitly marked N/A with reason)
518
+ - Health score calculated from actual file reads per dimension (not estimated)
519
+ - At least 3 positive findings and 3 improvement areas documented
520
+ - AUDIT-REPORT.md written to project root
521
+ - Journal entry recorded with audit date, score, and CRITICAL count
522
+ - Structured report emitted with overall health score and verdict
523
+
524
+ ## Cost Profile
525
+
526
+ ~8000-20000 tokens input, ~3000-6000 tokens output. Sonnet orchestrating; sentinel (sonnet/opus) and autopsy (opus) are the expensive sub-calls. Full audit runs 4 sub-skills. Most thorough L2 skill — run on demand, not on every cycle.