The init-task-persistence Skill — Operator Intent as the Source of Truth
How init-task-persistence captures the operator's original prompt verbatim at /dr-init time, keeps it append-only across the pipeline, and makes every subsequent command reconcile against it.
Every artifact a pipeline produces is a paraphrase. The PRD paraphrases the brief. The plan paraphrases the PRD. By the time implementation starts, the original request has passed through several layers of interpretation. The init-task-persistence skill exists to keep one unparaphrased record: the exact text the operator typed at /dr-init time.
That record lives at datarim/tasks/{TASK-ID}-init-task.md. It is created once and never overwritten — operators may append to it, but the verbatim brief at the top stays intact. Every subsequent pipeline command reads the whole file, including any amendments, and must surface divergences in its own output.
File shape and frontmatter
The file has a closed frontmatter schema: task ID, artifact type, schema version, creation date, operator name, and a status field that starts at canonical and flips to amended on the first operator addition. The body has three sections: a source command block, the verbatim operator brief, and an append-log that starts empty.
The append-log is the growth surface. Operators add amendments there; pipeline commands append Q&A blocks there for every clarification they obtained. Each Q&A block records the question, the answer, who decided, and a summary of how the decision changes the initial conditions. When the decision was made by the agent rather than the operator, a rationale of at least 50 characters is required, naming the framework rule or prior example it relied on.
Why Q&A round counts matter
For L3+ tasks — epics that span multiple sessions — the canonical decomposition pattern produces five or more rounds across three groups: one round at /dr-init for scope clarification, one round at /dr-prd for decomposition into milestones and sub-tasks, and one or more rounds during /dr-do sessions for mid-implementation clarifications. A seven-round trail across a five-session epic is normal, not a sign of indecision. The concern signal is the opposite: an L3+ epic with fewer than two Q&A rounds typically hides implicit decisions that were never surfaced and are more likely to need a rework cycle later.
For L1-L2 tasks, four or more rounds usually signals scope misestimation or questions the operator's brief already answered.
Validation and backwards compatibility
The validator at dev-tools/check-init-task-presence.sh checks one task or all tasks. Each task gets a 30-day soft window from its creation date: absence of the init-task file within that window is an info finding, not a blocker. After 30 days it becomes a warn. Tasks with status: archived or a legacy: true marker are never flagged.
If a pipeline stage needs the file and it does not exist because /dr-init was skipped, the stage creates a minimal version inline, using the task description as a proxy for the verbatim brief and marking the provenance as a retroactive backfill. The file is never deleted at archive time — the record of when the init-task was missing and when it was recovered is part of the task's history.
Read what Datarim is for broader context, or see the related post on the human-summary skill for how the pipeline surfaces operator intent in plain language at the end of each phase.