audit-work-tracking
Skill0 starsChanged 4 months agoMITView on GitHub
Audit repository backlog, issue-tracker, PRD, workflow-state, implementation-plan, and artifact tracking for unclear ownership, stale status, oversized items, mixed status vocabularies, missing routing, or token-heavy agent workflows. Use when Codex is asked to review, tighten, migrate, or design how a repo tracks work.
In this repository5 other files it gives its agents.
- AGENTS.mdAGENTS.md
- audit-docsSkill
- audit-skillsSkill
- bootstrap-repo-standardsSkill
- ship-changeSkill
The file
We split this skill into the rules it gives an agent
6 rules. About 0 are common, 6 are distinctive, and 0 are very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈6
Distinctive · estimate
This author's own choices. Worth a look.
0
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- could be automatic: a setting could enforce it
- Distinctive: line 14
Start with the smallest relevant entrypoints:
- Distinctive: line 22
Do not read every backlog item unless the audit explicitly needs coverage sampling.
- Distinctive: line 46
Prefer one or two concrete fixes over a new workflow system.
- Distinctive: line 50
Do not invent a file-based backlog for repos that use an external tracker.
- Distinctive: line 51
Do not merge intake, selection, planning, implementation, and review into one skill by default.
- Distinctive: line 52
Do not turn the audit into broad product planning or code review.
≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
Audit Work Tracking
Primary lens: Review.
Goal: review the work-tracking system, not the whole repo. Return findings first; make edits only when the user asks for fixes.
Scope
Start with the smallest relevant entrypoints:
- repo agent guide or contributor guide
- tracker/workflow docs
- backlog or issue indexes
- representative active item, plan, workflow state, and result artifact
- repo-local skills that select, plan, implement, or update work
Do not read every backlog item unless the audit explicitly needs coverage sampling.
Checklist
- Source of truth: work item ownership is clear between tracker, PRD, backlog, plan, workflow state, and chat.
- Lanes: active, done, deferred, bugs/incidents, enhancements, and tech-debt lanes are explicit when file-based tracking is used.
- Status vocabularies: backlog, workflow queue, bug/incident, PR, and process-improvement states are distinct and documented.
- Granularity: executable items are small enough to plan, validate, review, and close independently.
- Routing: intake, selection, planning, implementation, review, and closeout have clear handoffs.
- Artifacts: screenshots, logs, validation, result notes, and residual risks live beside the owning work item or in a named tracker location.
- Token cost: agents can find the next action without loading broad PRDs, old plans, large artifacts, or every historical item.
- Closure: done/deferred items are archived or indexed without staying in active queues.
Output
Return:
Scope reviewed- findings ordered by impact
Why it mattersSuggested fixSkill or docs impact, if anyVerdict:Pass,Pass with gaps, orFail
Prefer one or two concrete fixes over a new workflow system. Recommend a new skill only when the workflow is repeated, narrow, repo-specific, and docs alone are insufficient.
Do Not
- Do not invent a file-based backlog for repos that use an external tracker.
- Do not merge intake, selection, planning, implementation, and review into one skill by default.
- Do not turn the audit into broad product planning or code review.
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.