pi-do-always 0.9.0 → 0.12.0
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/README.md +92 -16
- package/extensions/pi-do-always/do-always.json +2 -2
- package/extensions/pi-do-always/index.ts +1364 -167
- package/extensions/pi-do-always/tasks.ts +506 -32
- package/package.json +1 -1
- package/pi.image.png +0 -0
package/README.md
CHANGED
|
@@ -11,26 +11,23 @@ type to filter, scroll or click, or navigate with arrows + Enter → the task's
|
|
|
11
11
|
```text
|
|
12
12
|
do-always — pick a task
|
|
13
13
|
|
|
14
|
+
# TASK DESCRIPTION ORDER
|
|
14
15
|
PLAN
|
|
15
|
-
|
|
16
|
-
|
|
17
|
-
|
|
18
|
-
|
|
19
|
-
|
|
20
|
-
|
|
16
|
+
1 ⚡ Review changes Review the current code changes (Plan) ·
|
|
17
|
+
2 ⚡ Review code Review the whole project's code quality (Plan) [1]
|
|
18
|
+
3 ⚡ Cleanup Clean up dead code and duplicates (Plan) [2]
|
|
19
|
+
4 ⚡ Security Security audit (Plan) ·
|
|
20
|
+
5 ⚡ Performance Performance review (Plan) ►[3]
|
|
21
|
+
6 ⚡ Propose features Propose new features (Plan) ·
|
|
21
22
|
DO
|
|
22
|
-
|
|
23
|
-
|
|
23
|
+
7 Build Test build is ok and fix issues ·
|
|
24
|
+
8 Tests Run tests and fix failures ·
|
|
24
25
|
DOCS
|
|
25
|
-
|
|
26
|
-
OPS
|
|
27
|
-
10. Release Prepare a release (version, changelog, tag)
|
|
28
|
-
11. Commit Prepare a clean commit
|
|
26
|
+
9 Readme Update the README.md ·
|
|
29
27
|
|
|
30
|
-
|
|
31
|
-
|
|
32
|
-
|
|
33
|
-
`git diff` to see what changed, then double-check the changes for bugs, edge …
|
|
28
|
+
──────────────────────────────────────────────────────────────────────────────────────────────────
|
|
29
|
+
Run the chain (3)
|
|
30
|
+
← tasks • ⏎ remove • esc • ctrl+u clear
|
|
34
31
|
|
|
35
32
|
1-9 pick by number • type to filter • ↑↓ navigate • enter select • esc cancel • ⚡ auto-runs
|
|
36
33
|
```
|
|
@@ -59,6 +56,84 @@ not filled): the `Plan` category does this by default, and any task can opt in o
|
|
|
59
56
|
In non-interactive modes (no TUI) there is no editor to fill, so the selected prompt is sent
|
|
60
57
|
as a user message instead.
|
|
61
58
|
|
|
59
|
+
## Chains
|
|
60
|
+
|
|
61
|
+
Run several tasks in a row as a **chain**. The selector shows an `ORDER` column; tasks in
|
|
62
|
+
the chain get a `[n]` marker in execution order, and a pinned row at the bottom of the
|
|
63
|
+
list runs the chain.
|
|
64
|
+
|
|
65
|
+
Building a chain in the selector:
|
|
66
|
+
|
|
67
|
+
- **Enter on a task row** runs just that task (the classic pick — the cursor starts in
|
|
68
|
+
the task column).
|
|
69
|
+
- **→** moves the cursor to the ORDER column on the same row, where **Enter** toggles
|
|
70
|
+
that task's chain membership (`·` → `[n]` → `·`). **←** goes back to the task column.
|
|
71
|
+
- **↑ / ↓** move the cursor in either column. The cursor is a **►** marker in the
|
|
72
|
+
theme's accent color: in the left gutter in the task column, in the ORDER cell in
|
|
73
|
+
the order column (plus a row highlight where your theme makes it visible). From the
|
|
74
|
+
last task row, **↓** lands on the pinned Run row (and **↑** back).
|
|
75
|
+
- **Enter on the `Run the chain (n)` row** — or a mouse click on it — runs the chain.
|
|
76
|
+
The row is dimmed while the chain is empty. The ► marker appears on it only
|
|
77
|
+
while the cursor is on the row (as on task rows).
|
|
78
|
+
- **Backspace** (with no filter typed) undoes the last add; **ctrl+u** clears the whole
|
|
79
|
+
chain; **Esc** cancels and discards it.
|
|
80
|
+
- Clicking an ORDER cell toggles the task's chain membership.
|
|
81
|
+
- The classic fast paths are unchanged: **1-9** runs a task immediately, and clicking a
|
|
82
|
+
task row runs it — both close the selector and discard the chain.
|
|
83
|
+
|
|
84
|
+
Chains are capped at 8 tasks. Reordering is done by removing a task and re-adding it. On narrow terminals the ORDER
|
|
85
|
+
column is dropped and the chain is shown on its own line below the list (keyboard
|
|
86
|
+
chaining still works).
|
|
87
|
+
|
|
88
|
+
Running a chain sends each step as its own turn, strictly one after another — the next
|
|
89
|
+
step starts only after the previous run has fully finished. Before anything is sent,
|
|
90
|
+
every step's guards are checked against the current state (fail fast: the first blocked
|
|
91
|
+
step is reported and the chain doesn't start). All steps share the prompt context
|
|
92
|
+
captured when the chain started, so each step's placeholders and guards see the tree as
|
|
93
|
+
it was at that point. An aborted step (Esc), a step that errors, or a step whose send
|
|
94
|
+
fails to start stops the chain; steps already run are kept.
|
|
95
|
+
|
|
96
|
+
If the first task of a chain is a fill task (no `⚡`) in the TUI, step 1 is put in the
|
|
97
|
+
editor and the rest of the chain starts automatically once you press Enter and that run
|
|
98
|
+
finishes.
|
|
99
|
+
|
|
100
|
+
While a chain is running, a **status widget** is shown below the prompt: the chain's
|
|
101
|
+
tasks with a marker per step and a `(n/N)` progress count — the step the chain is
|
|
102
|
+
currently at.
|
|
103
|
+
|
|
104
|
+
```
|
|
105
|
+
⛓ do-always (2/4)
|
|
106
|
+
✓ Review changes
|
|
107
|
+
▶ Build
|
|
108
|
+
○ Test
|
|
109
|
+
○ Deploy
|
|
110
|
+
```
|
|
111
|
+
|
|
112
|
+
Markers: `✓` completed, `▶` running (or waiting for your Enter on a fill-first step 1),
|
|
113
|
+
`○` pending, `✗` errored / failed to start, `⊘` aborted, `–` skipped because its guards
|
|
114
|
+
no longer hold. The widget is removed when the chain completes; if the chain stops early
|
|
115
|
+
it stays below the prompt as a trace of where it stopped (until your next prompt or a new
|
|
116
|
+
session). Starting a second chain while
|
|
117
|
+
one is running is refused — wait for it to finish or abort the current step with Esc.
|
|
118
|
+
|
|
119
|
+
Every chain run also writes a **report file** in the project root —
|
|
120
|
+
`do-always-report-tasks-YYYY-MM-DD-HHMM.md` (e.g. `do-always-report-tasks-2025-01-15-1432.md`) —
|
|
121
|
+
so earlier steps' results are not lost when later steps' output scrolls them off screen.
|
|
122
|
+
Each step appends a section as it finishes (the step's final assistant message, with its
|
|
123
|
+
outcome and run time), so the file is complete even if the session dies mid-chain; a
|
|
124
|
+
footer with the overall summary is appended when the chain ends, and the completion
|
|
125
|
+
notification carries the file's path. A run that produces nothing worth keeping (no
|
|
126
|
+
completed step and no step result text — e.g. step 1 errors before any output) leaves no
|
|
127
|
+
file behind. Set `"report": false` in the config to disable
|
|
128
|
+
it (the project file's value wins over the global one). See [Report file](#report-file).
|
|
129
|
+
|
|
130
|
+
**Inline report.** When a chain completes fully (all steps done), the full Markdown
|
|
131
|
+
report opens in an editor view so you can read the results without opening the file —
|
|
132
|
+
press Esc to dismiss it. Nothing is persisted to the session: the report lives only in
|
|
133
|
+
that view and in the report file on disk. A run that stops early (aborted, errored, or
|
|
134
|
+
skipped steps) does not show the inline report — only the status trace widget below
|
|
135
|
+
the prompt.
|
|
136
|
+
|
|
62
137
|
## Install
|
|
63
138
|
|
|
64
139
|
Install it from npm as a Pi package, which loads the bundled `index.ts` (and its `tasks.ts`) without
|
|
@@ -117,6 +192,7 @@ In the object form you can also configure the selector shortcut:
|
|
|
117
192
|
|
|
118
193
|
- `shortcut` (optional) — key that opens the selector, e.g. `"f4"`. Set to `null` to disable the shortcut. Defaults to `F4`. The project file's value wins over the global one.
|
|
119
194
|
- `merge` (optional) — how project tasks combine with the global tasks: `"override"` (default) replaces a global task with the same `name`; `"append"` keeps the global tasks and only adds new project task names (a cascade, like CSS). The project file's value wins over the global one; when neither sets it, the default is `override` (the historical behavior).
|
|
195
|
+
- `report` (optional) — whether chain runs write a Markdown report file in the project root (one per run, appended as each step finishes). Default `true`; set `false` to disable. The project file's value wins over the global one. See [Chains](#chains).
|
|
120
196
|
|
|
121
197
|
Example project file that only *adds* tasks without overriding the global set:
|
|
122
198
|
|
|
@@ -6,7 +6,7 @@
|
|
|
6
6
|
"category": "Plan",
|
|
7
7
|
"description": "Review the current code changes (Plan)",
|
|
8
8
|
"requireDirty": true,
|
|
9
|
-
"prompt": "Review the changes on branch {{branch}} ({{files_changed_count}} changed files: {{files_changed}}). Change summary: {{diff_stat}}. Last commit: {{last_commit}}. Check `git status` and `git diff` to see what changed, then double-check the changes for bugs, edge cases, security issues, and consistency with the rest of the codebase. Do a plan proposal for the fixes if needed. Do a summary of your findings"
|
|
9
|
+
"prompt": "Review the changes on branch {{branch}} ({{files_changed_count}} changed files: {{files_changed}}). Change summary: {{diff_stat}}. Last commit: {{last_commit}}. Check `git status` and `git diff` to see what changed, then double-check the changes for bugs, edge cases, security issues, and consistency with the rest of the codebase. Do a plan proposal for the fixes if needed. Do a summary of your findings."
|
|
10
10
|
},
|
|
11
11
|
{
|
|
12
12
|
"name": "Review code",
|
|
@@ -36,7 +36,7 @@
|
|
|
36
36
|
"name": "Propose features",
|
|
37
37
|
"category": "Plan",
|
|
38
38
|
"description": "Propose new features (Plan)",
|
|
39
|
-
"prompt": "Review this project and propose new features that would add value. For each idea, describe the problem it solves, the user benefit, and a rough implementation approach. Prioritize by impact and effort. Do not make any changes yet. Try to evaluate how many lines this will be in
|
|
39
|
+
"prompt": "Review this project and propose new features that would add value. For each idea, describe the problem it solves, the user benefit, and a rough implementation approach. Prioritize by impact and effort. Do not make any changes yet. Try to evaluate how many lines this will be in terms of changes, whether this will break APIs, or introduce compatibility issues."
|
|
40
40
|
},
|
|
41
41
|
{
|
|
42
42
|
"name": "Build",
|