1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
|
# Agent Plan Mode
Task-backed planning for Pi.
This extension keeps planning and execution separate:
- use `/plan` to enter read-only planning mode
- ask Pi to produce a numbered `Plan:`
- convert the extracted plan into tasks explicitly
- leave planning mode and continue execution against real tasks
Tasks remain the source of truth. This extension does not keep a private
todo list.
## Commands
- `/plan`
Enter read-only planning mode. The active tool set is reduced to safe
exploration tools.
- `/plan-exit`
Leave planning mode and restore the previous tool set.
- `/plan-create-tasks [sequential|independent]`
Create tasks from the last extracted `Plan:`.
- `/task-sync [sequential|independent]`
Legacy alias for `/plan-create-tasks`.
- `/task-update <selector> :: <new description>`
Replace a task description.
- `/task-modify <selector> :: <mods>`
Apply `ask modify` arguments to a task.
- `/tasks`
Show started and `+READY` tasks for the current repo.
- `/task-next [run]`
Focus the started task, or start the next `+READY` task.
- `/task-exit`
Leave focus mode.
- `/task-unfocus`
Alias for `/task-exit`.
- `/work-on-tasks [strategy] [max]`
Kick off the task workflow for this repo.
## Rules
- all task operations go through `ask`, never raw `task`
- tasks are scoped to the current git repo through the `ask` wrapper
- use UUIDs for stable references
- planning mode is read-only by design
- the extracted plan is session-local, so `/plan`, the planning prompt,
`/plan-create-tasks`, and `/plan-exit` should happen in the same interactive
or continued Pi session
## Usage Flows
### Flow 1: Turn a plan into tasks
1. Start Pi in the project.
2. Run:
```text
/plan
```
3. Ask for analysis and a numbered `Plan:`. Example:
```text
Analyze the current repo and propose a concise Plan: for fixing the SSH bootstrap trust model.
```
4. After Pi replies with a `Plan:`, create tasks:
```text
/plan-create-tasks sequential
```
5. Leave planning mode:
```text
/plan-exit
```
Use `sequential` when each step should depend on the previous one. Use
`independent` when the planned tasks can be worked separately.
### Flow 2: Adjust a task after planning
Rewrite a task description:
```text
/task-update uuid:12345678-1234-1234-1234-123456789abc :: Restore SSH host verification during bootstrap
```
Apply standard modify arguments:
```text
/task-modify uuid:12345678-1234-1234-1234-123456789abc :: priority:H +security
```
Use task modification syntax:
```text
/task-modify uuid:12345678-1234-1234-1234-123456789abc :: /bootstrap/provisioning/
```
### Flow 3: Start executing the real tasks
See what is active:
```text
/tasks
```
Focus the current task:
```text
/task-next
```
Focus and immediately start execution:
```text
/task-next run
```
Leave focus mode again:
```text
/task-exit
```
Run the full repo task loop:
```text
/work-on-tasks highest-impact
```
### Flow 4: Planning session pattern
This is the cleanest end-to-end interactive pattern:
```text
/plan
```
```text
Analyze the repo and give me a Plan: for the next implementation slice.
```
```text
/plan-create-tasks sequential
```
```text
/plan-exit
```
```text
/work-on-tasks
```
## Notes And Limits
- Planning mode is read-only by design.
- All task operations still go through `ask`, never raw `task`.
- `ask` uses subcommand syntax. It is not a natural-language
task assistant and should never be called like `ask agent-task-management ...`.
- Execution mode injects the current task back into the agent prompt
so the model works against the real task rather than an in-memory checklist.
- Execution mode treats the focused task as the already-selected starting
point and blocks repeated identical `ask info uuid:<uuid>` lookups until the
agent has moved on to repo inspection, implementation, tests, review, or a
different command.
- Full `/plan` state is not meant to be passed across unrelated one-shot `pi -p`
invocations. Use a real interactive or continued session for planning.
|
