skills/tt-workflow-audit/SKILL.md
Tasktracker-native project-wide parallel audit using the Claude Code Workflow tool (dynamic workflows). Partitions a repo / backlog / architecture and fans out read-only agents (one per partition) that return schema-checked findings, aggregates them into a deduplicated, ranked risk register, and OPTIONALLY writes fixes back as tasks under a Bug Fix phase — with all tasktracker writes done by the PARENT, never the parallel agents (single global active-task pointer). Journaled and resumable, so a rate-limit or crash mid-audit resumes without re-running completed partitions. Use for large, embarrassingly-parallel, read/analyze-heavy jobs where each unit is self-contained and the output aggregates — audit every file/component for risk, find all architecture drift (scanArchitectureDrift) or duplicate tasks (detectDuplicates/auditDuplicates), per-file tech-debt sweep, test-coverage or security-surface scan across a whole project. Triggers on "/tt-workflow-audit", "audit the whole repo", "parallel audit", "scan every file/component", "find all drift/duplicates", "tech-debt sweep (tasktracker)", or any whole-project analyze-at-scale request inside a session with a tasktracker project. Prefer this over /codebase-audit or /code-quality-audit when the project is tracked in tasktracker AND you want the findings written back as tasks; prefer it over team-* modes when the units don't need to negotiate live (they just report).
npx skillsauth add mhylle/claude-skills-collection tt-workflow-auditInstall this skill globally with one command. Works with Claude Code, Cursor, and Windsurf.
3 of 9 scanners reported clean
Some scanners were skipped, did not run, or reported a non-clean status. Review each row below.
A tasktracker-native, Workflow-tool-backed project-wide audit. It is the first concrete skill in the tt-workflow-* tier — the "parallel and tasktracker-correct" quadrant that neither the sequential tt-* skills nor the tasktracker-blind team-* skills covered.
The shape is a hybrid: the parent (this session) scouts and partitions inline, fans the analysis out through one Workflow run, then does all writes in the tail. The parallel agents only read and report.
Read
references/workflow-tasktracker-contract.mdbefore running. It is the shared contract for everytt-workflow-*skill, grounded in verified facts about the live system.
The one rule you cannot break:
The Workflow SCRIPT orchestrates.
Parallel agent() calls are READ/ANALYZE-ONLY and return schema output.
The PARENT (this main-loop session) performs ALL tasktracker writes — serially.
Why (verified): the active task is a single process-global pointer, parallel workflow agents share one session id + one MCP process, and the shared stdio MCP cannot attribute a tool call to a specific agent. So no agent may call setActiveTask or any write-gated tool — it would clobber the shared pointer and bill time to the wrong task. Reads are fine (gate-exempt and reachable in background runs, probe-verified).
| DO (parent) | DON'T |
|---|---|
| Read project-invariant context once, pass it down | Let agents re-fetch the same context N× |
| Partition the audit scope | Let agents call setActiveTask |
| Fan out read-only agents via Workflow | Let agents call logDefect/updateTaskStatus/batchCreate* |
| Aggregate findings → risk register | Edit a locked phase body |
| Write fixes back in the tail (with an active task set) | Write back destructively without a dry-run + confirmation |
| | /code-quality-audit | /codebase-audit, /adversarial-reviewer --codebase | /tt-workflow-audit (this) |
|---|---|---|---|
| Engine | metrics tools | sequential / small Task fan-out | Workflow tool — deterministic parallel fan-out, journaled, resumable |
| Output | metrics report | written report / risk register | schema-checked risk register + optional tasktracker tasks |
| Tasktracker | none | none | native — write-back as Bug-Fix-phase tasks, insight logging, all parent-owned |
| Resumes after crash/rate-limit | no | no | yes (completed partitions cached) |
Use this when the project is in tasktracker AND you want findings to become tracked work. Use the others for pure-report or metrics-only runs.
Use it when the job is large, embarrassingly parallel, read/analyze-heavy, with aggregable per-unit output: audit every file/component, find all architecture drift or duplicate tasks, a per-file tech-debt sweep, a coverage/security-surface scan.
Don't use it when the work is sequential or must branch on results mid-run (a deterministic script can't adapt mid-flight — use plain subagents), or when a few agents must debate live (use /team-*), or when the project isn't in tasktracker (use /codebase-audit).
1. tasktracker_listProjects({search}) (or use the argument hint) → project id.
2. tasktracker_getProject({projectId}) → understand the project.
3. Decide the AUDIT MODE (argument or ask):
- architecture-drift → inputs from scanArchitectureDrift / listArchitectureComponents
- duplicate-backlog → detectDuplicates / auditDuplicates over the task tree
- file-risk → per-file tech-debt / complexity / smell sweep
- coverage-gaps → per-module test-coverage analysis
- security-surface → per-entrypoint security review
- (compose modes if the user wants a full sweep)
Read the things every agent would otherwise re-fetch (principles, architecture components, the task tree, the file list) once, in the parent, and pass them into the agents as data (contract R3). Then build the partition list — the unit of parallelism:
This is the discover-the-work-list scouting the Workflow tool docs call for: scope the partitions inline, then fan out.
Invoke the Workflow tool directly — it's a top-level main-loop BUILT-IN (like Bash/Edit/Agent), NOT an MCP tool, so it never shows up in ToolSearch; don't look for it there and don't read a ToolSearch miss as "unavailable" (see the contract's "Tool availability" section). Give it a script that parallel()s (or pipeline()s) one read-only agent per partition, each returning schema-checked findings. The agent prompt MUST forbid setActiveTask and every write tool. Skeleton:
export const meta = {
name: 'tt-workflow-audit-run',
description: 'Read-only parallel audit fan-out; parent does all tasktracker writes',
phases: [{ title: 'Audit' }],
}
const FINDING = {
type: 'object', additionalProperties: false,
required: ['partition', 'findings'],
properties: {
partition: { type: 'string' },
findings: {
type: 'array',
items: {
type: 'object', additionalProperties: false,
required: ['title', 'severity', 'location', 'detail'],
properties: {
title: { type: 'string' },
severity: { type: 'string', enum: ['CRITICAL', 'HIGH', 'MEDIUM', 'LOW'] },
location: { type: 'string', description: 'file:line or component/task id' },
detail: { type: 'string' },
suggestedFix: { type: 'string' },
},
},
},
},
}
phase('Audit')
// `args` carries {partitions, invariantContext} passed in by the parent.
const results = await parallel(
args.partitions.map((p) => () =>
agent(
`Audit partition "${p.id}" of project ${args.projectName}. Mode: ${args.mode}.
Context (already read — do NOT re-fetch): ${JSON.stringify(args.invariantContext)}
Scope: ${JSON.stringify(p.scope)}
READ ONLY. Report findings against the schema. You MUST NOT call setActiveTask or ANY tasktracker write tool (no create/update/log/batch). Reads are fine.`,
{ label: `audit:${p.id}`, phase: 'Audit', schema: FINDING }
)
)
)
return { findings: results.filter(Boolean).flatMap((r) => r.findings) }
Pass args as real JSON ({partitions, invariantContext, projectName, mode}). For a write-heavy variant that edits code, add isolation: 'worktree' and have agents return integrationIntents (contract R6) — but a pure audit is read-only and needs no worktrees.
No Date.now() / Math.random() / new Date() in the script (contract R5). Vary agent labels by partition id, not RNG.
Collect the workflow's return, dedupe (same file:line / same component) and rank by severity. This is ordinary parent-side work — not an agent, not a write.
Show the user the ranked register: counts by severity, the top findings with location + suggestedFix. If coverage was bounded (sampled, top-N), log/state what was dropped (contract R8) — never imply full coverage silently.
If the user wants findings tracked:
1. Confirm with the user (this writes to PRODUCTION).
2. Ensure a "Bug Fix" phase exists (or create one — createTask/createPhaseFromTemplate are planning-exempt).
3. tasktracker_setActiveTask(<Bug Fix phase or coordination task>) ← parent owns the pointer
4. tasktracker_batchCreateTasks(register.map(toFixTask)) ← planning-exempt, atomic
5. For findings worth an insight: tasktracker_logDefect(...) ← gated; needs the active task set in (3)
6. tasktracker_clearActiveTask()
Dry-run/report mode is the default for any first run; only create tasks after the user sees the register and confirms. Never batchDelete* from an audit.
The audit is journaled. If a run is interrupted (rate-limit, crash, network), resume it with Workflow({scriptPath, resumeFromRunId}) — completed partitions return cached results; only the unfinished ones re-run. This is the main reason to prefer a workflow over a sequential audit for large scopes.
setActiveTask or any write tool. Agents read and report; the parent writes.Date.now()/Math.random()/new Date() in the workflow script (breaks resume).Agent-dispatched subagent — the Workflow tool is main-loop-only; invoke this skill in the main session.setActiveTask + all write tools; agents returned schema findings only.Date.now()/RNG in the script; labels vary by partition id.resumeFromRunId rather than re-run from scratch.workflow-tasktracker-contract.md — the shared contract every tt-workflow-* skill obeys (parent-owns-writes, read-only agents, locked body, no Date/RNG, worktree intents, prod safety, MCP reachability). Read it first./workflow-guide — routes here when the work is analyze-at-scale (Question 0 = B)./codebase-audit, /adversarial-reviewer --codebase, /code-quality-audit — non-tasktracker / report-only audit alternatives./tt-create-plan, /tt-implement-plan — where the fix tasks this audit creates get planned and executed.testing
One-command issue-to-merge pipeline orchestrator. Drives a GitHub issue through nine stages (preflight, plan, implement, review, ci, cloud_review, deploy, e2e, logs) with two human gates, persisting all run state to files so a crashed or interrupted run resumes losslessly. Triggers on "/ship-issue" with an issue number or URL. User-invoked only.
tools
--- name: tt-workflow-build description: Tasktracker-native trigger for a PARALLEL build via the Claude Code Workflow tool. Thin by design — it does two things, then drives to done: (1) ensure a tasktracker project exists (use the existing one, or create one), then (2) start a dynamic `Workflow` that builds it, tracking the work in tasktracker and using the build + verify skills. It does NOT analyze parallelism up front, ask the user to choose a mode, hand back, or fall back to a sequential skil
tools
--- name: grumpy-reviewer description: A single grumpy, nitpicky structural code reviewer that runs as an isolated subagent and treats the code as third-party work submitted by a junior programmer for validation. It cares about exactly one thing — maintainability — judged through separation of concerns, service-oriented design, helper-method extraction, small files, and the rule of 7 (as any grouping nears 7 members, it pushes for sub-groupings). It is deliberately kept OUT of the implementation
development
--- name: tt-workflow-run description: Tasktracker-native autonomous build-loop orchestrator. Drives a first-class `workflow_run` end-to-end — create the run (Gate 1 lifecycle completeness + Gate 2 zero-defects-in), then loop while `getNextReadyTask(projectId)` returns a slice — `setActiveTask` → record a pre-slice `scanArchitectureDrift` baseline → delegate the slice to `/tt-implement-phase` (which does the code work, registers the architecture delta in-slice, and auto-logs defects/learnings/fr