Long-Running Task Memory
- Keep task control state, authorization, evidence, and next action in a repository-external agent directory. Code, Git, configuration, and runtime results remain the technical source of truth.
- Maintain
CURRENT_TASK.md and PROGRESS.md; add PLAN.md for multi-stage work.
- Write event-driven checkpoints at recoverable nodes, before and after high-risk actions, and before pause or context compaction.
- Use content fingerprints to deduplicate unchanged checkpoints. Archive older active checkpoints after the bounded hot set grows beyond 20.
- Use a single shared-memory writer. Subagents return structured facts and do not edit shared memory.
- Recover from the current task, current plan stage, three recent checkpoints, Project Binding, live Git, and runtime state.
- Task checkpoints do not automatically become Project Memory; project records do not automatically become cross-project knowledge.
- Scan for credentials and maintain retention and access boundaries.
- For initial nontrivial development onboarding, index recovery, or shared-capability maintenance, follow the capability-index workflow. The index stores invalidatable factual locators; task summaries link IDs and evidence. The coordinator merges increments, while stable memory still requires projection and human review.
Persist verified facts, evidence grade, authorization, state, blockers, risk, and next action—not hidden reasoning. This Skill normally uses Luna and does not create subagents by itself.
Controlled-Evolution Boundary
This Skill supplies reviewed checkpoints and recovery evidence to cross-task analysis; it does not maintain the evolution contract. Route governance of repeated failures, model cost, Reviewer yield, or Skill-routing deviation to controlled-evolution-governance. Ordinary long-running work must not load evolution rules.
1---2name: long-running-task-memory-23description: Use for cross-session, multi-stage, multi-module, multi-repository, multi-agent, observation-window, and context-compaction work that needs recoverable checkpoints.4---56# Long-Running Task Memory781. Keep task control state, authorization, evidence, and next action in a repository-external agent directory. Code, Git, configuration, and runtime results remain the technical source of truth.92. Maintain `CURRENT_TASK.md` and `PROGRESS.md`; add `PLAN.md` for multi-stage work.103. Write event-driven checkpoints at recoverable nodes, before and after high-risk actions, and before pause or context compaction.114. Use content fingerprints to deduplicate unchanged checkpoints. Archive older active checkpoints after the bounded hot set grows beyond 20.125. Use a single shared-memory writer. Subagents return structured facts and do not edit shared memory.136. Recover from the current task, current plan stage, three recent checkpoints, Project Binding, live Git, and runtime state.147. Task checkpoints do not automatically become Project Memory; project records do not automatically become cross-project knowledge.158. Scan for credentials and maintain retention and access boundaries.169. For initial nontrivial development onboarding, index recovery, or shared-capability maintenance, follow the [capability-index workflow](../engineering-quality-delivery/references/capability-index-workflow.md). The index stores invalidatable factual locators; task summaries link IDs and evidence. The coordinator merges increments, while stable memory still requires projection and human review.1718Persist verified facts, evidence grade, authorization, state, blockers, risk, and next action—not hidden reasoning. This Skill normally uses Luna and does not create subagents by itself.1920## Controlled-Evolution Boundary2122This Skill supplies reviewed checkpoints and recovery evidence to cross-task analysis; it does not maintain the evolution contract. Route governance of repeated failures, model cost, Reviewer yield, or Skill-routing deviation to `controlled-evolution-governance`. Ordinary long-running work must not load evolution rules.
JimmyVGDY