Doc-harness doc-harness
Document-based project control that lets any AI agent or human resume work from files alone — no external memory needed. Use this skill whenever the user wants to structure a long-running project, track progress across sessions, recover state after context loss, coordinate multiple agents on the same project, audit project documentation health, or stop forgetting what was done last session. Triggers include: '/doc-harness init' and '/doc-harness check' (explicit slash commands); requests like 'help me set up this project', 'I keep losing track', 'my agent forgets between sessions', 'organize my project docs', 'audit this project', 'check the documentation', 'what did we do last time'; multi-week projects (theses, research, analyses, software modules) that span many sessions; cross-project coordination (inbox/outbox for file-based messages between projects).
git clone https://github.com/cilidinezy-commits/doc-harness
T=$(mktemp -d) && git clone --depth=1 https://github.com/cilidinezy-commits/doc-harness "$T" && mkdir -p ~/.claude/skills && cp -r "$T/skill" ~/.claude/skills/cilidinezy-commits-doc-harness-doc-harness-e3edb2 && rm -rf "$T"
skill/SKILL.mdDoc Harness — Document-Based Project Control
Doc Harness is a documentation system that enables any AI agent or human collaborator to understand and resume project work purely from reading files — no external memory needed.
It creates and maintains five documents per project:
- CLAUDE.md — Project entry point (overview, recovery chain, iron rules, operational rules)
- CURRENT_STATUS.md — Active state (tire tracks / car body / headlights / driving manual)
- FILE_INDEX.md — File catalog organized by category
- WORKLOG.md — Permanent work history (append-only)
- DOC_HARNESS_SPEC.md — Complete specification (reference document)
Two optional documents may be added when a project accumulates such content (see spec.md Chapter 13):
- PARKING_LOT.md — Deferred items with preconditions for revival
- PHILOSOPHY.md — Principles forged by this project's practice
One optional mechanism may be adopted when a project coordinates with others (see spec.md Chapter 14):
- Inter-project inbox/outbox — self-contained file-based messaging protocol.
andinbox/
directories; YAML-frontmatter Markdown messages; lifecycleoutbox/
. Fully described inside doc-harness itself; no external spec needed.unread → read → actioned
Commands
/doc-harness init [project-name] [description]
/doc-harness init [project-name] [description]Initialize Doc Harness for a new project. Creates all 5 files in the current directory.
→ See init.md for full instructions and templates.
/doc-harness check
/doc-harness checkAudit the current project's documentation health and reflect on working principles.
→ See check.md for full check procedures.
/doc-harness
(no arguments)
/doc-harnessInspect the current directory and suggest the right next step:
- All 4 core files present (CLAUDE.md, CURRENT_STATUS.md, FILE_INDEX.md, WORKLOG.md) → suggest
./doc-harness check - No Doc Harness files at all → suggest
(clean init or mid-project adoption per/doc-harness init
Step 2).init.md - Partial state (some files present, others missing or malformed) → suggest
in mid-project adoption mode (see/doc-harness init
Step 2 branch (b)/(c)); do NOT suggestinit.md
on a broken installation.check
Then show this help summary.
Core Principle: "Write It Down or Lose It"
Information in context will eventually be completely lost. Important information must be written to a file and registered in FILE_INDEX. Not written = lost. Not registered = undiscoverable = effectively lost.
Context-aware corollary: if your runtime exposes a context-window usage metric (percentage or token count), treat low remaining context (~<20%) as an immediate trigger to flush CURRENT_STATUS before the next tool call, and consider a phase transition if the car body holds substantial unsaved work (see
spec.md §11.2 bullet 4 for the concrete threshold). Compression is involuntary session end — preemptive writes are the only defense.
Reference Documents
- init.md — Read when executing
. Covers clean init, mid-project adoption, partial-state repair, and optional inter-project inbox/outbox setup./doc-harness init - check.md — Read when executing
. Audit procedures for file health, recovery-chain soundness, mid-transition detection, and inbox status./doc-harness check - operational_rules.md — The operational rules embedded verbatim into every project's CLAUDE.md at
time. Carries theinit
version tag so the check command can detect stale embeddings.<!-- doc-harness-ops-version --> - spec.md — Complete Doc Harness specification (14 chapters + 5 appendices). Authoritative — all other files derive from it. Has a Table of Contents at the top for navigation without full-read.