Execute Task Command

You are implementing taskmanager:execute-task.

Arguments

• $1 (required): Task ID to execute (e.g., 1.2.3)
• --memory "description" or -gm "description": Add a global memory (persists to memories.json)
• --task-memory "description" or -tm "description": Add a task-scoped memory (temporary, reviewed at task end)
• --debug or -d: Enable verbose debug logging to .taskmanager/logs/debug.log

Behavior

0. Initialize logging session

1. Generate a unique session ID using timestamp: sess-$(date +%Y%m%d%H%M%S) (e.g., sess-20251212103045).
2. Check for --debug / -d flag.
3. Update .taskmanager/state.json:
   • Set logging.sessionId to the generated ID.
   • Set logging.debugEnabled = true if --debug flag present, else false.
4. Log to decisions.log:

   <timestamp> [DECISION] [<session-id>] Started execute-task command for task $1
   

1. Parse arguments

• $1 must be provided (e.g., 1.2.3).
• If not provided, ask the user to specify an ID or suggest running taskmanager:next-task.
• Extract --memory / -gm value if provided.
• Extract --task-memory / -tm value if provided.
• Extract --debug / -d flag if provided.

2. Process memory arguments:

   • If --memory is provided:
     • Use the taskmanager-memory skill to create a new global memory in .taskmanager/memories.json.
     • Set source.type = "user", source.via = "execute-task".
     • Set reasonable defaults: importance = 3, confidence = 0.9, status = "active".
   • If --task-memory is provided:
     • Add to .taskmanager/state.json → taskMemory[]:

       {
         "content": "<the description>",
         "addedAt": "<current ISO timestamp>",
         "taskId": "$1",
         "source": "user"
       }
       

3. Load task:

   • Token-efficient option: For large tasks.json files (> 25k tokens), use taskmanager:get-task $1 to retrieve the task without loading the full file.
   • Standard approach: Ask the taskmanager skill to load .taskmanager/tasks.json and find the task with id == $1.
   • If not found, inform the user and stop.

4. Check dependencies:

   • If the task has dependencies that are not "done", "canceled", or "duplicate":
     • Use the AskUserQuestion tool to ask how to proceed, with options such as:
       • "Execute a dependency task first"
       • "Mark dependencies as done and continue"
       • "Abort execution of this task"
     • Act according to the user's answer.

5. Load and apply memories (PRE-EXECUTION):

   • Use the taskmanager-memory skill to query relevant memories for this task.
   • Load global memories from .taskmanager/memories.json:
     • Filter for status = "active".
     • Match by scope.tasks, scope.domains, scope.files, importance >= 3.
   • Load task-scoped memories from state.json.taskMemory[]:
     • Filter for taskId == $1 or taskId == "*".
   • Run conflict detection on all loaded memories:
     • Check for file/pattern obsolescence.
     • Check for implementation divergence.
     • If conflicts detected, resolve using the conflict resolution workflow.
   • Display summary of applicable memories.
   • Store applied memory IDs in state.json.appliedMemories[].
   • Increment useCount and update lastUsedAt for each applied memory.

6. Start execution:

   • Update the task status to "in-progress" if appropriate.
   • Update .taskmanager/state.json:
     • currentStep = "execution"
     • mode = "interactive"
     • currentTaskId = $1
     • currentSubtaskPath = $1
     • lastUpdate and lastDecision.

7. Execute the task:

   • Perform the code changes, file edits, or other work implied by the task.
   • Apply loaded memories as constraints during implementation.

8. Post-execution memory review (before marking done):

   • Run conflict detection again on all applied memories.
   • If conflicts detected, resolve using the conflict resolution workflow.
   • Review task-scoped memories:
     • If any task memories exist for this task (taskId == $1):
       • Ask the user: "Should any task memories be promoted to global memory?"
       • For each: "Promote to global memory" or "Discard".
       • Create global memories for promoted items.
       • Clear task memories for this task from taskMemory[].
   • Clear state.json.appliedMemories[].

9. Complete execution:

   • Update the leaf task status based on outcome:
     • "done", "blocked", "paused", or "needs-review".
   • Recompute the macro status for all ancestor tasks using the Status propagation helper rules below.
   • Archive if terminal status: If the final status is "done", "canceled", or "duplicate":
     • Follow the archival procedure from SKILL.md section 8.7.
     • Archive the task to .taskmanager/tasks-archive.json.
     • Replace with stub in tasks.json.
     • Check and archive parent if all its children are now archived.
   • Write the updated files back to disk.
   • Update .taskmanager/state.json:
     • currentTaskId = null
     • currentSubtaskPath = null
     • currentStep = "idle" (or "done" if requested by the user)
     • lastUpdate / lastDecision.

10. Summarize for the user

• Final status of the task.
• Memories that were applied and any conflicts resolved.
• Any follow-up tasks or dependencies suggested.

11. Cleanup logging session

1. Log to decisions.log:

   <timestamp> [DECISION] [<session-id>] Completed execute-task command for task $1 with status "<final-status>"
   

2. Reset .taskmanager/state.json:
   • Set logging.debugEnabled = false
   • Set logging.sessionId = null

---

Logging Requirements

Throughout execution, this command MUST log:

To errors.log (ALWAYS):

• Any errors encountered (file not found, parse errors, validation failures)
• Conflict detection results when conflicts are found

To decisions.log (ALWAYS):

• Command start and completion
• Task status transitions
• Memory application and conflict resolutions
• Any user decisions made

To debug.log (ONLY when --debug enabled):

• Detailed argument parsing
• Task tree loading details
• Memory matching algorithm steps
• Conflict detection intermediate steps

---

Status propagation helper (macro parent status)

Whenever this command changes the status of any leaf task (the specific ID the user asked to execute), it MUST also update the status of all its ancestor tasks so that parents reflect the aggregate state of their subtasks.

Conceptual algorithm (per parent, based on its direct children):

1. For the parent, collect the status of all its direct subtasks.

2. Apply these precedence rules in order:

   1. If any child is "in-progress"
      → parent status = "in-progress".

   2. Else if no child is "in-progress" and any child is "blocked"
      → parent status = "blocked".

   3. Else if no child is "in-progress" or "blocked" and any child is "needs-review"
      → parent status = "needs-review".

   4. Else if no child is "in-progress", "blocked", or "needs-review" and any child is in:
      "planned", "draft", "todo", "paused"
      → parent status = "planned" (macro “not-started / planned” state).

   5. Else if all children are in {"done", "canceled", "duplicate"}:

      • If at least one child is "done" → parent status = "done".
      • Else (all "canceled" or "duplicate") → parent status = "canceled".

3. After computing the parent’s new status, repeat this algorithm for its parent, and so on, up to the root.

Implementation notes:

• This helper should walk bottom-up from the executed leaf task to the root.
• You MUST NOT set a parent's status by hand; always derive it from its children using these rules.
• Always write back .taskmanager/tasks.json after propagation so other commands (like /dashboard and /next-task) see a consistent, macro view of progress.

---

Related Commands

• taskmanager:get-task <id> [key] - Token-efficient way to retrieve task properties without loading full tasks.json
• taskmanager:update-status <status> <id1> [id2...] - Batch status updates without status propagation (use for quick updates when propagation is not needed)
• taskmanager:stats - Token-efficient statistics and task summaries

Note: Unlike taskmanager:update-status, this command (execute-task) performs full status propagation to parent tasks. Use execute-task when you need proper status cascading; use update-status only for quick batch updates where you'll handle propagation separately.