Tasks

Runtime Configuration (Step 0, before any processing)

Read these files to configure domain-specific behavior:

1. ops/derivation-manifest.md, vocabulary mapping

   • Use vocabulary.notes for the notes folder name
   • Use vocabulary.note / vocabulary.note_plural for note type references
   • Use vocabulary.topic_map for MOC references
   • Use vocabulary.cmd_reflect / vocabulary.cmd_reweave / vocabulary.cmd_verify for phase command names

2. ops/config.yaml, pipeline chaining mode, automation settings

If no derivation file exists, use universal terms.

---

EXECUTE NOW

Target: $ARGUMENTS

Parse the operation:

• No arguments or status: show task stack + queue state (combined view)
• add [description]: add a task to the stack
• done [task-number]: mark a task as completed
• drop [task-number]: remove a task without completing
• reorder [number] [position]: move a task to a different position in the stack
• discoveries: show only the Discoveries section

START NOW. Execute the requested operation.

---

Philosophy

Two systems, one view.

The task stack (ops/tasks.md) and the pipeline queue (ops/queue/queue.yaml or ops/queue/queue.json) serve different purposes:

System	Purpose	Managed By	Updated By
Task stack	Human priorities, what YOU want to work on	You (via /tasks)	Manual: /tasks add, /tasks done
Pipeline queue	Automated processing state, what the SYSTEM needs to process	Pipeline skills	Automatic: /reduce, /ralph, /reflect

/tasks shows BOTH so you always have a unified view of all pending work. The task stack is your working memory. The pipeline queue is the system's working memory. Together they answer: "What should I do next?"

---

Operations

/tasks (or /tasks status)

Show both the human task stack and the automated queue.

Step 1: Read task stack