Track — Prevent Agents From Redoing Work

Core Problem

When an agent audits principles, triages compactions, aligns UX intents, or runs any repeatable sweep — if they don't LOG that work was done, the next agent will redo it from scratch. This is the #1 source of wasted agent cycles.

The Rule: Track Before You Move On

Before completing ANY item in a sweep/audit/triage, log it. A small tracker ships with this skill (track.js, in this skill's folder) so there is never a reason to skip this for lack of somewhere to log to.

Quick Start (the default — no setup needed)

# Log the result of auditing one item
node <path-to-this-skill>/track.js log <work-type> <item-id> pass --leverage 80 --notes "matches the principle"
node <path-to-this-skill>/track.js log <work-type> <item-id> fail --leverage 80 --notes "violates X, see line 42"

# Ask what to look at next — pass it the full candidate list (id + optional leverage score)
node <path-to-this-skill>/track.js next <work-type> --items /path/to/candidates.json
# candidates.json: [{"id": "principle-3", "leverage": 70}, {"id": "principle-4", "leverage": 40}, ...]
# Never-audited items come back first; after that, highest leverage × longest-since-last-check wins.

# See what's been done so far for a work type
node <path-to-this-skill>/track.js status <work-type>

Each work type gets its own log file — one JSON array of {itemId, outcome, notes, leverage, agentSessionId, timestamp} entries — in the folder alignment-harness records track prints. No database, no server, no auth. This is real, working infrastructure, not a protocol to re-derive each time.

If you have your own admin API for this (see /alignment-harness:harness-setup), you can point tracking there instead once it exists — the shape (item id, outcome, leverage, timestamp) carries over — but the local tracker above is the default and needs nothing extra to start using right now.

Protocol

Phase 1: Check what's already tracked

Before starting any sweep task, run status for this work type. If a log already exists, you're resuming a sweep, not starting one — read what's already been done before touching anything.

Phase 2: Execute the Sweep

1. Build (or gather) the candidate list — every item this sweep could look at, with a leverage score if you can estimate one (default to 50 if you can't)
2. Call track.js next <work-type> --items <candidates.json> to get the next item to look at
3. Perform the audit/triage/alignment check on that item
4. Log the result with track.js log
5. If issues found → fix them, then log the fix as its own entry (or update via a fresh log call)
6. Repeat until the sweep is complete or your context budget is spent

Phase 3: Parallelize with Subagents

ONLY after Phase 2 has been proven with at least 1 manual item (confirm next returns a different item afterward — that's the loop actually working, not just looking right):

1. Give each subagent the work-type name and the path to track.js
2. Each subagent calls next, does the work, calls log — same protocol, no special coordination needed since the log file is shared
3. Main agent monitors completion and aggregates results via status

Anti-Patterns

• Completing audit items without logging → next agent redoes everything
• Deploying subagents before proving the loop works manually → multiplies bugs
• Assuming a work type has never been tracked without checking status first → redoing a sweep that's already in progress
• Building a bespoke tracking mechanism per sweep when this one already exists and works

Integration Points

• Discoverability: /run-discoverability-audit
• Proposals for human review: /how-to-submit-and-track-proposals
• Subagent deployment: /superpowers-dispatching-parallel-agents
• Your own admin tooling, if you have any (see /alignment-harness:harness-setup) — an optional upgrade over the local file store, same shape