@difflab/pi 0.6.0 → 0.7.0-rc.202609271854.6af8600

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.
Files changed (95) hide show
  1. package/README.md +11 -9
  2. package/agents/diffpi-orchestrator.md +6 -4
  3. package/agents/diffpi-plan-reviewer.md +27 -0
  4. package/agents/diffpi-planner.md +5 -5
  5. package/agents/diffpi-reviewer.md +4 -4
  6. package/agents/diffpi-worker.md +1 -1
  7. package/dist/assets.d.ts +0 -1
  8. package/dist/assets.d.ts.map +1 -1
  9. package/dist/cli.js +446 -160
  10. package/dist/commands/plan.d.ts +2 -2
  11. package/dist/commands/plan.d.ts.map +1 -1
  12. package/dist/commands/review.d.ts +2 -2
  13. package/dist/commands/review.d.ts.map +1 -1
  14. package/dist/environment.d.ts +2 -0
  15. package/dist/environment.d.ts.map +1 -1
  16. package/dist/extensions/index.js +1841 -3858
  17. package/dist/extensions/tuicrx.d.ts +8 -1
  18. package/dist/extensions/tuicrx.d.ts.map +1 -1
  19. package/dist/index.d.ts +8 -7
  20. package/dist/index.d.ts.map +1 -1
  21. package/dist/index.js +951 -349
  22. package/dist/plan/markdown.d.ts +4 -1
  23. package/dist/plan/markdown.d.ts.map +1 -1
  24. package/dist/{tools/plan-schema.d.ts → plan/schema.d.ts} +113 -75
  25. package/dist/plan/schema.d.ts.map +1 -0
  26. package/dist/plan/store.d.ts +39 -1
  27. package/dist/plan/store.d.ts.map +1 -1
  28. package/dist/plan/types.d.ts +27 -3
  29. package/dist/plan/types.d.ts.map +1 -1
  30. package/dist/review/github-review-backend.d.ts.map +1 -1
  31. package/dist/review/gitlab-review-backend.d.ts.map +1 -1
  32. package/dist/review/index.d.ts +6 -6
  33. package/dist/review/index.d.ts.map +1 -1
  34. package/dist/review/local-review-backend.d.ts +3 -0
  35. package/dist/review/local-review-backend.d.ts.map +1 -0
  36. package/dist/review/review-backend.d.ts +3 -2
  37. package/dist/review/review-backend.d.ts.map +1 -1
  38. package/dist/review/review-markdown.d.ts +4 -1
  39. package/dist/review/review-markdown.d.ts.map +1 -1
  40. package/dist/review/review-state.d.ts +20 -0
  41. package/dist/review/review-state.d.ts.map +1 -0
  42. package/dist/review/types.d.ts +28 -0
  43. package/dist/review/types.d.ts.map +1 -1
  44. package/dist/store.d.ts +2 -0
  45. package/dist/store.d.ts.map +1 -1
  46. package/dist/tools/index.js +1668 -607
  47. package/dist/tools/plan.d.ts.map +1 -1
  48. package/dist/tools/review.d.ts +38 -0
  49. package/dist/tools/review.d.ts.map +1 -1
  50. package/package.json +2 -4
  51. package/skills/plan/SKILL.md +8 -14
  52. package/skills/plan/references/design-quality.md +30 -0
  53. package/skills/plan/references/workflows/annotate.md +11 -0
  54. package/skills/plan/references/workflows/finalize.md +7 -0
  55. package/skills/plan/references/workflows/go.md +8 -0
  56. package/skills/plan/references/workflows/help.md +10 -0
  57. package/skills/plan/references/workflows/init.md +5 -0
  58. package/skills/plan/references/workflows/new.md +7 -0
  59. package/skills/plan/references/workflows/update.md +7 -0
  60. package/skills/review/SKILL.md +7 -7
  61. package/skills/review/references/review-standards.md +8 -1
  62. package/skills/review/references/workflows/address.md +11 -0
  63. package/skills/review/references/workflows/auto.md +18 -0
  64. package/skills/review/references/workflows/complete.md +7 -0
  65. package/skills/review/references/workflows/edit.md +7 -0
  66. package/skills/review/references/workflows/help.md +36 -0
  67. package/skills/review/references/workflows/merge.md +6 -0
  68. package/skills/review/references/workflows/new.md +19 -0
  69. package/skills/review/references/workflows/open.md +3 -0
  70. package/skills/review/references/workflows/publish.md +8 -0
  71. package/skills/review/references/workflows/status.md +3 -0
  72. package/templates/plan/PLAN.md +17 -11
  73. package/templates/plan/implementation.md +34 -12
  74. package/dist/commands.d.ts +0 -22
  75. package/dist/commands.d.ts.map +0 -1
  76. package/dist/extensions/cmdtsx.d.ts +0 -2
  77. package/dist/extensions/cmdtsx.d.ts.map +0 -1
  78. package/dist/tools/plan-schema.d.ts.map +0 -1
  79. package/dist/workflow.d.ts +0 -80
  80. package/dist/workflow.d.ts.map +0 -1
  81. package/workflows/plan/annotate.md +0 -13
  82. package/workflows/plan/finalize.md +0 -15
  83. package/workflows/plan/go.md +0 -20
  84. package/workflows/plan/help.md +0 -20
  85. package/workflows/plan/init.md +0 -13
  86. package/workflows/plan/new.md +0 -20
  87. package/workflows/plan/update.md +0 -18
  88. package/workflows/review/address.md +0 -8
  89. package/workflows/review/auto.md +0 -8
  90. package/workflows/review/complete.md +0 -7
  91. package/workflows/review/edit.md +0 -7
  92. package/workflows/review/help.md +0 -14
  93. package/workflows/review/merge.md +0 -6
  94. package/workflows/review/new.md +0 -7
  95. package/workflows/review/publish.md +0 -6
@@ -1 +1 @@
1
- {"version":3,"file":"plan.d.ts","sourceRoot":"","sources":["../../src/tools/plan.ts"],"names":[],"mappings":"AAAA,OAAO,KAAK,EAAE,YAAY,EAAE,cAAc,EAAE,MAAM,iCAAiC,CAAC;AAQpF,OAAO,KAAK,EAAE,cAAc,EAAE,MAAM,UAAU,CAAC;AAM/C,OAAO,EAAmB,KAAK,SAAS,EAAE,MAAM,eAAe,CAAC;AAmBhE,MAAM,MAAM,eAAe,GAAG,IAAI,CAAC,YAAY,EAAE,QAAQ,GAAG,iBAAiB,CAAC,GAC5E,OAAO,CAAC,IAAI,CAAC,YAAY,EAAE,aAAa,CAAC,CAAC,CAAC;AAE7C,wBAAgB,eAAe,CAC7B,GAAG,EAAE,eAAe,EACpB,MAAM,EAAE,cAAc,EACtB,KAAK,GAAE,SAA6B,GACnC,SAAS,cAAc,EAAE,CA6W3B"}
1
+ {"version":3,"file":"plan.d.ts","sourceRoot":"","sources":["../../src/tools/plan.ts"],"names":[],"mappings":"AAAA,OAAO,KAAK,EAAE,YAAY,EAAE,cAAc,EAAE,MAAM,iCAAiC,CAAC;AAQpF,OAAO,KAAK,EAAE,cAAc,EAAE,MAAM,UAAU,CAAC;AAM/C,OAAO,EAAmB,KAAK,SAAS,EAAE,MAAM,eAAe,CAAC;AAchE,MAAM,MAAM,eAAe,GAAG,IAAI,CAAC,YAAY,EAAE,QAAQ,GAAG,iBAAiB,CAAC,GAC5E,OAAO,CAAC,IAAI,CAAC,YAAY,EAAE,aAAa,CAAC,CAAC,CAAC;AAE7C,wBAAgB,eAAe,CAC7B,GAAG,EAAE,eAAe,EACpB,MAAM,EAAE,cAAc,EACtB,KAAK,GAAE,SAA6B,GACnC,SAAS,cAAc,EAAE,CAkR3B"}
@@ -1,4 +1,42 @@
1
1
  import { type ToolDefinition } from '@earendil-works/pi-coding-agent';
2
+ import { run } from '../extensions/processx';
3
+ import { type ReviewComment, type ReviewDraft, type ReviewThreadRecord } from '../review';
4
+ export declare function hasReviewDraft(comments: readonly ReviewComment[], body: string): boolean;
5
+ export declare function reviewBrowserCommand(url: string, platform?: NodeJS.Platform): {
6
+ command: string;
7
+ args: string[];
8
+ };
9
+ export declare function openReviewUrl(url: string, execute?: typeof run, platform?: NodeJS.Platform): Promise<boolean>;
10
+ export declare function partitionReviewComments(comments: readonly ReviewComment[], knownFingerprints: ReadonlySet<string>, model: string): {
11
+ checkpointed: {
12
+ source: ReviewComment;
13
+ published: {
14
+ body: string;
15
+ file: string;
16
+ line?: number;
17
+ side?: import("..").ReviewSide;
18
+ author?: string;
19
+ sourceCommentId?: string;
20
+ };
21
+ fingerprint: string;
22
+ }[];
23
+ candidates: {
24
+ source: ReviewComment;
25
+ published: {
26
+ body: string;
27
+ file: string;
28
+ line?: number;
29
+ side?: import("..").ReviewSide;
30
+ author?: string;
31
+ sourceCommentId?: string;
32
+ };
33
+ fingerprint: string;
34
+ }[];
35
+ };
36
+ export declare function reviewResponseResolution(question: boolean, requested?: boolean): boolean;
37
+ export declare function workingTreeReplyDraft(thread: ReviewThreadRecord, body: string): ReviewDraft;
38
+ export declare function resolveReviewThread(comment: ReviewComment, threads: readonly ReviewThreadRecord[]): ReviewThreadRecord | undefined;
2
39
  export declare function workingTreeDiff(cwd: string): Promise<string>;
3
40
  export declare function createReviewTools(): readonly ToolDefinition[];
41
+ export declare function syncLocalThreadArtifact(path: string, title: string, sessionSlug: string, threads: readonly ReviewThreadRecord[]): Promise<ReviewThreadRecord[]>;
4
42
  //# sourceMappingURL=review.d.ts.map
@@ -1 +1 @@
1
- {"version":3,"file":"review.d.ts","sourceRoot":"","sources":["../../src/tools/review.ts"],"names":[],"mappings":"AAGA,OAAO,EAAqC,KAAK,cAAc,EAAE,MAAM,iCAAiC,CAAC;AA2EzG,wBAAsB,eAAe,CAAC,GAAG,EAAE,MAAM,GAAG,OAAO,CAAC,MAAM,CAAC,CAalE;AAID,wBAAgB,iBAAiB,IAAI,SAAS,cAAc,EAAE,CAma7D"}
1
+ {"version":3,"file":"review.d.ts","sourceRoot":"","sources":["../../src/tools/review.ts"],"names":[],"mappings":"AAGA,OAAO,EAAqC,KAAK,cAAc,EAAE,MAAM,iCAAiC,CAAC;AAKzG,OAAO,EAAE,GAAG,EAAc,MAAM,wBAAwB,CAAC;AACzD,OAAO,EAwBL,KAAK,aAAa,EAClB,KAAK,WAAW,EAChB,KAAK,kBAAkB,EACxB,MAAM,WAAW,CAAC;AAwEnB,wBAAgB,cAAc,CAAC,QAAQ,EAAE,SAAS,aAAa,EAAE,EAAE,IAAI,EAAE,MAAM,GAAG,OAAO,CAExF;AAED,wBAAgB,oBAAoB,CAAC,GAAG,EAAE,MAAM,EAAE,QAAQ,GAAE,MAAM,CAAC,QAA2B;;;EAM7F;AAED,wBAAsB,aAAa,CACjC,GAAG,EAAE,MAAM,EACX,OAAO,GAAE,OAAO,GAAS,EACzB,QAAQ,GAAE,MAAM,CAAC,QAA2B,GAC3C,OAAO,CAAC,OAAO,CAAC,CAOlB;AAED,wBAAgB,uBAAuB,CACrC,QAAQ,EAAE,SAAS,aAAa,EAAE,EAClC,iBAAiB,EAAE,WAAW,CAAC,MAAM,CAAC,EACtC,KAAK,EAAE,MAAM;;;;;;;;;;;;;;;;;;;;;;;;;EAUd;AAED,wBAAgB,wBAAwB,CAAC,QAAQ,EAAE,OAAO,EAAE,SAAS,CAAC,EAAE,OAAO,GAAG,OAAO,CAExF;AAED,wBAAgB,qBAAqB,CAAC,MAAM,EAAE,kBAAkB,EAAE,IAAI,EAAE,MAAM,GAAG,WAAW,CAY3F;AAED,wBAAgB,mBAAmB,CACjC,OAAO,EAAE,aAAa,EACtB,OAAO,EAAE,SAAS,kBAAkB,EAAE,GACrC,kBAAkB,GAAG,SAAS,CAmBhC;AAED,wBAAsB,eAAe,CAAC,GAAG,EAAE,MAAM,GAAG,OAAO,CAAC,MAAM,CAAC,CAalE;AAID,wBAAgB,iBAAiB,IAAI,SAAS,cAAc,EAAE,CAof7D;AAID,wBAAsB,uBAAuB,CAC3C,IAAI,EAAE,MAAM,EACZ,KAAK,EAAE,MAAM,EACb,WAAW,EAAE,MAAM,EACnB,OAAO,EAAE,SAAS,kBAAkB,EAAE,GACrC,OAAO,CAAC,kBAAkB,EAAE,CAAC,CAwB/B"}
package/package.json CHANGED
@@ -1,6 +1,6 @@
1
1
  {
2
2
  "name": "@difflab/pi",
3
- "version": "0.6.0",
3
+ "version": "0.7.0-rc.202609271854.6af8600",
4
4
  "description": "Tools and skills for the pi coding agent",
5
5
  "repository": {
6
6
  "type": "git",
@@ -34,8 +34,7 @@
34
34
  "agents/",
35
35
  "dist/",
36
36
  "skills/",
37
- "templates/",
38
- "workflows/"
37
+ "templates/"
39
38
  ],
40
39
  "pi": {
41
40
  "extensions": [
@@ -58,7 +57,6 @@
58
57
  },
59
58
  "dependencies": {
60
59
  "@juicesharp/rpiv-ask-user-question": "^2.10.1",
61
- "cmd-ts": "^0.15.0",
62
60
  "commander": "^14.0.0",
63
61
  "mdast-builder": "1.1.1",
64
62
  "pi-mcp-adapter": "^2.33.0",
@@ -1,23 +1,17 @@
1
1
  ---
2
2
  name: plan
3
- description: Route natural-language planning requests to Diffpi's /plan commands. Use when a user wants to create, revise, annotate, finalize, or execute a durable plan, or asks which /plan command to run.
4
- allowed-tools: ask_user_question
3
+ description: Create, revise, annotate, finalize, and execute durable Diffpi plans. Use for /skill:plan, /plan, or natural-language planning requests.
4
+ allowed-tools: read grep find write edit symbol_search module_report read_symbol ask_user_question Agent get_subagent_result steer_subagent plan_context plan_annotate plan_start_execution plan_update_status plan_log_progress plan_run_gates plan_record_ci watch_ci
5
5
  ---
6
6
 
7
- # Plan Command Guide
7
+ # Plan
8
8
 
9
- Use `/plan` commands as the execution boundary. Do not reproduce their workflows, call `plan_*` tools directly, or edit managed plan files.
9
+ This skill owns the workflow. `/plan` only forwards its raw arguments to `/skill:plan`. Do not emit another command to paste or rely on a command handler to select an agent, parse flags, or inject a workflow. For NEW and UPDATE, use ordinary file tools to edit the authoritative live PLAN.md and implementation brief files. Never use file tools to alter immutable legacy snapshots, revisions, reviews, or logs; remaining references to those managed artifacts are transitional guidance pending phase 4.
10
10
 
11
- ## Natural-language routing
11
+ Identify the first explicit verb (`init`, `new`, `update`, `annotate`, `finalize`, `go`, `help`) or infer one from the user's request. For NEW and UPDATE, select one unique repository-root plan by path and its plan files, and read it before acting; ask only for a material decision if the plan remains ambiguous. Read exactly the corresponding [workflow reference](references/workflows/) before acting. Preserve the user's request and intent, including visible completed task information; this is authoring input, not a managed revision transaction.
12
12
 
13
- Map the user's intent to one command:
13
+ `new` creates a complete plan without launching an editor; `init` creates a phase-less draft and opens it. For NEW and UPDATE content changes, write the authoritative live PLAN.md and numbered briefs directly through successive normal read/write/edit calls, then read back each file. Invoke exactly one independently verified frontier/high-thinking `diffpi-plan-reviewer` per iteration; repair actionable findings and rerun it within bounded attempts. If effective model/thinking selection cannot be verified, fail preflight with the exact observed selection and required correction; do not silently promise runtime verification. Phase/task status and execution gates remain managed-tool concerns. The remaining init/annotate/finalize/go references retain old managed-tool calls only as transitional guidance until phase 4 replaces them; they must not be presented as Planner capabilities. `go` calls `plan_start_execution` before any code change; if the plan is draft or on the wrong branch, stop.
14
14
 
15
- - Create an empty plan shell: `/plan init <short-slug> [--branch <name>]`
16
- - Research and author a complete plan: `/plan new <short-slug> [--branch <name>] [--bg] [prompt...]`
17
- - Revise a plan from chat instructions or its current plan review: `/plan update [short-slug] [--branch <name>] [--bg] [instructions...]`
18
- - Review a plan in tuicr and save the result: `/plan annotate [short-slug]`
19
- - Validate and mark a plan ready: `/plan finalize [short-slug]`
20
- - Execute a plan: `/plan go <short-slug> [--mode <no-commit|commit|push>] [--bg]`
21
- - Show command help: `/plan help`
15
+ `--bg` requests one named background agent through `Agent` (Planner for authoring, Orchestrator for execution); pass the verb, exact arguments, cwd, and a `background: true` instruction. Remove `--bg` from the child's request and explicitly forbid redispatch. Return after launching it. A background child must not ask user questions. If `Agent` is unavailable, stop and report that background execution cannot be started; never silently execute inline. Without `--bg`, execute in the current turn: author as Planner, coordinate go as Orchestrator and delegate bounded Worker tasks; do not assume an inline mode switch occurred. Do not launch a multi-agent workflow unless the user explicitly opts into one.
22
16
 
23
- Infer the command, slug, branch, and free-text arguments from recent conversation when they are clear. If a required value cannot be inferred, use `ask_user_question`; do not ask in plain chat. Then give the user one exact, copyable `/plan` command. Explain defaults only when relevant: `go` uses `--mode no-commit` when `--mode` is omitted.
17
+ Operational references: [init](references/workflows/init.md), [new](references/workflows/new.md), [update](references/workflows/update.md), [annotate](references/workflows/annotate.md), [finalize](references/workflows/finalize.md), [go](references/workflows/go.md), [help](references/workflows/help.md). NEW and UPDATE use direct authoritative file writes. The init/annotate/finalize/go references are transitional managed-tool guidance until phase 4 replaces them.
@@ -0,0 +1,30 @@
1
+ # Plan authoring quality
2
+
3
+ Build from repository evidence. Keep the result compact and useful to a Worker.
4
+
5
+ ## PLAN.md
6
+
7
+ - Keep intent, requirements, design, references, and numbered phases in `PLAN.md`.
8
+ - Give each phase a stable ID, title, objective, and prerequisites. Prerequisites belong to phases only.
9
+ - Put each discrete implementation action in a flat task checkbox with a stable task ID and title. Do not put dependency metadata, steps, file scopes, or acceptance criteria under the checkbox.
10
+ - Preserve phase/task ID and order parity in every implementation brief.
11
+
12
+ ## Implementation brief
13
+
14
+ - Give tasks ordered implementation steps. Add nested `Verify` bullets under the relevant task; verification is part of the task, not a separate task.
15
+ - List exact file scopes and acceptance criteria for every task.
16
+ - Put libraries and algorithms under **Implementation Constraints**.
17
+ - Include exactly one fenced `text` phase-level directory tree. Label every file leaf with one of `[ADD]`, `[MODIFY]`, `[REMOVE]`, `[MOVE from: path]`, or `[VERIFY]`.
18
+ - Read back each file after writing it. Normal successive write/edit calls are intentional: incomplete drafts remain visible until the plan is ready.
19
+
20
+ ## Review and repair
21
+
22
+ Template metadata such as revision snapshots and managed markers is not an authoring requirement. Treat their removal as a legacy compatibility change: the existing managed parser will stop recognizing these templates until the follow-on source migration adds a replacement contract. Report that break explicitly; do not preserve metadata in the templates solely to hide it.
23
+
24
+ After writing the current `PLAN.md` and all numbered briefs, independently invoke exactly one VERIFIED frontier/high-thinking `diffpi-plan-reviewer` in read-only mode. The reviewer checks structure and parity, action labels, whole-plan quality, consistency and risk, and whether every task is executable by a lightweight Worker without guessing, in one pass. Do not replace this with cheap separate reviewers or tiered checks.
25
+
26
+ The Planner repairs actionable findings and reruns the same reviewer within bounded attempts. A passing review does not prove that source code implements the plan. `annotate` is optional human review; it does not replace the automated reviewer.
27
+
28
+ ## Contracts and consequences
29
+
30
+ Describe real API or data-flow changes. If there is no public API change, say so and show the relevant internal contract. Explain before/after invocation, what readers or Workers consume, validation and failure visibility, and at least one concrete trade-off. Do not use scaffold placeholders in a plan marked ready.
@@ -0,0 +1,11 @@
1
+ # `/plan annotate`
2
+
3
+ ## PLAN.md task
4
+
5
+ Review the selected plan in tuicr and save one immutable review.
6
+
7
+ ## Brief
8
+
9
+ 1. Call `plan_context` and resolve the exact plan ID from the slug or conversation; ask the user only if candidates remain ambiguous.
10
+ 2. Call `plan_annotate` using the plan file; it owns the tuicr session and review artifact.
11
+ 3. Report the selected plan, launch result, and copyable fallback command. Tell the user to run `/plan update <plan-id>` after closing tuicr.
@@ -0,0 +1,7 @@
1
+ # Finalize
2
+
3
+ 1. Call `plan_context` to resolve exactly one persisted plan. Call `plan_review` once for that plan and revision. If a current annotation exists, incorporate its exact feedback as one content request through `plan_apply_revision` before finalizing; do not mutate the plan per individual comment. A stale review must not be applied.
4
+ 2. Call `plan_validate` with `strict: true` on the resulting revision. Stop if any error remains; this validates plan structure, detailed briefs, and revision snapshots, **not implementation correctness**. Do not mark a plan with empty briefs ready.
5
+ 3. Call `plan_update_status` to mark the draft `ready`. Do not call `plan_start_execution` until the user chooses execution.
6
+ 4. In foreground mode, use one `ask_user_question` for next action (execute now in foreground/background, later, or keep planning); if executing, also obtain commit mode (`no-commit`, `commit`, or `push`; default `no-commit` if already specified). If they choose execution, follow the [go workflow](go.md) directly in the selected mode; background execution launches one child, not another slash command. If they choose later or planning, return the ready state. Background finalization cannot ask and must leave execution for an explicit request.
7
+ 5. No inline mode was selected by a command, so do not unset one as a side effect of finalization.
@@ -0,0 +1,8 @@
1
+ # Go
2
+
3
+ 1. Call `plan_context` with the supplied slug. Accept only `no-commit`, `commit`, or `push`; omitted `--mode` means `no-commit`. Do not ask for a mode if the user already chose it.
4
+ 2. If the resolved plan is `draft`, finalize it inline before execution: call `plan_review` for the current revision and consume only a current review (apply its exact feedback as one `plan_apply_revision` amend when present; ignore stale reviews), then call `plan_validate` with `strict: true`. If validation passes, call `plan_update_status` for the plan from `draft` to `ready`. Do not invoke the finalize workflow or ask its next-action question. An already `ready` or `blocked` plan needs no review or readiness transition; pass it to `plan_start_execution`, which owns restart and blocker eligibility checks.
5
+ 3. Call `plan_start_execution` **before** modifying source, delegating work, or running gates. This enforces ready/blocked status, correct branch, clean worktree when committing, and durable execution ownership. On failure, stop and report the exact blocker; never implement a draft plan speculatively.
6
+ 4. Use the returned execution ID and packet. Read the complete phase briefs, assign bounded tasks in dependency order to Workers, and track progress and status through plan tools. Workers do not commit or restructure the plan. Run `plan_run_gates` when a phase's tasks are complete. Failed gates block that phase until repaired and rerun.
7
+ 5. In `no-commit`, make no commits or pushes. In `commit`, commit once per phase **after** gates pass; do not push or watch CI. In `push`, push each gated phase commit and monitor CI for its exact SHA, collecting the monitor before the next push and all monitors before completion. Persist the observed commit/CI metadata through plan tools.
8
+ 6. Complete the plan only after every task, phase, gate, and required CI settles. Report execution ID, mode, and evidence. Background execution must not affect foreground mode; foreground execution does not require a mode reset because this skill did not select one.
@@ -0,0 +1,10 @@
1
+ # `/plan help`
2
+
3
+ ## PLAN.md task
4
+
5
+ Show the available plan commands and their concise purposes.
6
+
7
+ ## Brief
8
+
9
+ 1. List `init` (phase-less draft), `new` (research and author), `update` (apply review/instructions), `annotate` (tuicr review), `finalize` (validate and mark ready), `go` (start execution), and `help`.
10
+ 2. State that `--branch` records or filters metadata, `go` defaults to `--mode no-commit`, and background workflows do not ask questions.
@@ -0,0 +1,5 @@
1
+ # Init
2
+
3
+ 1. Resolve the supplied short slug and optional branch, title, intent, issue ID, and URL. `--branch` records metadata; it does not switch branches. Call `plan_context` first and stop if the selected plan already exists.
4
+ 2. Call `plan_init` with `open: true` and `request: {kind: "user", text: <exact incoming request>}`. The tool creates one phase-less draft and its initial request-scoped revision snapshot, then opens `PLAN.md` in a supported adjacent editor tab. Do not perform additional content mutations for this request.
5
+ 3. Return the plan ID, clickable path, and actual launch outcome or fallback path. Explain that `annotate` stores a plan review, `update` applies review or further instructions, and `finalize` checks completeness before execution.
@@ -0,0 +1,7 @@
1
+ # New
2
+
3
+ 1. Resolve the initiating nested Git root and the requested slug/branch, then inspect for a plan collision. If a matching plan already exists, stop. Only after confirming no matching plan exists, research and create the plan; do not read a nonexistent plan. If the goal is unspecified in foreground mode, ask one material question; background work must report a blocker instead.
4
+ 2. Research repository files, APIs, tests, and constraints. Follow [plan authoring quality](../design-quality.md). Draft the complete PLAN.md and one numbered brief per phase. Preserve the user's request and intent in the visible plan content, including any visible completed task information; this is authoring input, not a revision transaction.
5
+ 3. Write the plan directory directly with normal `write`/`edit` calls. Write PLAN.md and briefs incrementally so incomplete files remain visible. Do not call `plan_apply_revision`, `plan_validate`, or edit managed snapshots. Include exact scopes, ordered steps, constraints, acceptance criteria, task parity, one action-labeled tree per brief, and nested verification.
6
+ 4. Read back every written file. Invoke exactly one `diffpi-plan-reviewer` over PLAN.md and all numbered briefs in a single pass. Before relying on its result, verify the effective model is the explicit frontier model (prefer `openai-codex/gpt-5.6-sol`, or an available equivalent), thinking is high, and tools are read/search-only. If selection cannot be verified, fail preflight with the exact observed model/thinking/tools and required correction; do not silently promise runtime verification or use a cheap fallback.
7
+ 5. Repair actionable findings directly, then rerun the same reviewer within bounded attempts. A pass checks plan quality only; it does not prove source implementation. Report plan and brief paths, review evidence, and any compatibility caveat. Policy governs the plan-file source scope; this is not a Pi sandbox guarantee.
@@ -0,0 +1,7 @@
1
+ # Update
2
+
3
+ 1. Select exactly one unique repository-root plan by its path and plan files. Read the current PLAN.md, all numbered briefs, and the incoming request. Preserve the user's intent and all visible completed task information, including IDs, ownership, evidence, and dependencies.
4
+ 2. Research affected repository files and follow [plan authoring quality](../design-quality.md). Build the entire resulting PLAN.md and numbered briefs in memory, preserving exact phase/task order parity. Do not guess among plans or rewrite historical records.
5
+ 3. Apply the update through successive direct `write`/`edit` calls to the authoritative plan files. Do not call `plan_apply_revision`, `plan_validate`, or edit managed snapshots. Read back each file after writing. New files remain visible while incomplete.
6
+ 4. Invoke exactly one `diffpi-plan-reviewer` over the current PLAN.md and every numbered brief in one pass. Verify its effective model is the explicit frontier model (prefer `openai-codex/gpt-5.6-sol`, or an available equivalent), thinking is high, and capabilities are read/search-only. If effective selection cannot be verified, fail preflight with the exact observed model/thinking/tools and required correction; never silently promise runtime verification or accept a cheap fallback.
7
+ 5. Repair actionable findings directly and rerun the same reviewer within bounded attempts. Report changed files, review evidence, remaining blocker, and compatibility caveat. A passing review is structural/semantic plan evidence only, not proof source code implements the plan. Policy governs the plan-file source scope; this is not a Pi sandbox guarantee.
@@ -1,15 +1,15 @@
1
1
  ---
2
2
  name: review
3
- description: Code review workflows over GitHub, GitLab, or local tuicr revision dumps. Use for auto reviews, review opening and editing, addressing, publishing, completing, merging, or local review requests.
4
- allowed-tools: ask_user_question review_context review_new review_edit review_diff review_gates review_submit review_add_comment review_comments review_dump review_respond review_publish review_complete review_merge review_launch_ui
3
+ description: Create, edit, review, address, publish, complete, and merge GitHub/GitLab or local tuicr reviews. Use for /skill:review, /review, or natural-language review requests.
4
+ allowed-tools: read ask_user_question Agent get_subagent_result steer_subagent review_context review_status review_new review_open review_edit review_diff review_gates review_submit review_add_comment review_comments review_respond review_publish review_complete review_merge review_launch_ui diffpi_template
5
5
  ---
6
6
 
7
- # review
7
+ # Review
8
8
 
9
- Use the exact package workflow supplied by the `/review` command. Do not look for workflow files inside this skill.
9
+ This skill owns the workflow. `/review` only forwards raw arguments to `/skill:review`; never rely on command-side flag parsing or mode activation. Parse the first non-flag argument as the verb and preserve remaining arguments and their order. Normalize `create`, `draft` → `new`; `launch` → `auto`; `ready` → `publish`; `close` → `complete`; `land` → `merge`. `open` and `status` are first-class lifecycle workflows. Empty/unknown verb shows [help](references/workflows/help.md).
10
10
 
11
- Call `review_context` first. Treat `--local` as a working-tree tuicr flow. A completed local session becomes one immutable review dump; applying feedback starts a new revision. Local reviews have no thread ledger, replies, resolution state, or remote promotion.
11
+ `--local` selects the working-tree tuicr backend and **must be preserved** for the selected workflow; without it, use the forge. `--bg` is an execution flag: remove it from the child request and launch exactly one named background Orchestrator through `Agent`, passing verb, arguments, cwd, and an explicit `background: true` instruction. The child executes the workflow once without redispatch or interactive questions; the current foreground role remains unchanged. Without `--bg`, execute directly in this turn. Do not change inline modes or emit a command for the user to paste. Do not launch a multi-agent workflow unless the user explicitly opts into one.
12
12
 
13
- Without `--local`, use the detected GitHub or GitLab target directly. Stage findings, read forge threads, post replies, publish status, and perform lifecycle actions through the remote review tools.
13
+ Read [the selected reference](references/workflows/) before acting. Every operational workflow calls `review_context` first with the same target and `local` setting. Use `ask_user_question` only for material decisions not derivable from the request; never ask as plain chat text. `auto` and `address` require reviewer judgment and thread classification; if a background Orchestrator is running, delegate that bounded judgment to a Reviewer via `Agent`, then collect the result. Delegate non-overlapping implementation only where useful. Lifecycle verbs retain the coordinator role. Tools own target selection, templates, comment staging, replies, publication, and forge calls; do not reimplement them with shell commands.
14
14
 
15
- Use `ask_user_question` only for decisions that cannot be derived. Inline `auto` and `address` run under Reviewer; lifecycle workflows run under Orchestrator. Background execution is already routed by the command and must not change the foreground mode.
15
+ References: [auto](references/workflows/auto.md), [new](references/workflows/new.md), [open](references/workflows/open.md), [status](references/workflows/status.md), [edit](references/workflows/edit.md), [address](references/workflows/address.md), [publish](references/workflows/publish.md), [complete](references/workflows/complete.md), [merge](references/workflows/merge.md), [help](references/workflows/help.md). Keep publication separate from completion and merge; `review_merge` remains GitHub-only.
@@ -2,6 +2,13 @@
2
2
 
3
3
  Use these rules for review and address workflows.
4
4
 
5
+ ## Operational workflow rules
6
+
7
+ - Each workflow parses its own arguments. Do not assume a parent `/review` command stripped `--bg` or selected a backend.
8
+ - Call `review_context` first, with `local: true` for `--local` and `local: false` for forge-backed work. Pass the same target and backend to every later lifecycle tool.
9
+ - Skill-owned aliases (`open`, `create`, `draft`, `launch`, and `close`) follow their named workflow; they do not bypass argument parsing or safety checks.
10
+ - `--bg` runs the complete workflow in a tracked background Orchestrator. Lifecycle ownership and publication/completion/merge safety remain unchanged.
11
+
5
12
  ## Intent
6
13
 
7
14
  Check that the change serves the stated PR intent. Treat a missing required behavior as blocking.
@@ -20,4 +27,4 @@ Prefer existing package APIs and small public surfaces. Add a dependency when it
20
27
 
21
28
  ## Responses
22
29
 
23
- Respond to every addressed thread. State what changed and include verification evidence. Keep every thread open for the user to resolve. Address workflows must never resolve or delete threads.
30
+ Respond to every thread with an explicit outcome and verification evidence. Apply every relevant requested change now; “deferred”, “later”, and “follow-up” are not acceptable unless the user explicitly requested deferral. Mark a thread unresolved only for a concrete external blocker or material user decision, and include attempted fixes and evidence. Keep every thread open for the user to resolve. Address workflows must never resolve or delete threads.
@@ -0,0 +1,11 @@
1
+ # address
2
+
3
+ 1. Parse an optional PR/MR id or URL and `--local`. The skill owns `--bg` dispatch before this reference is followed; a background child executes these steps directly and must not redispatch.
4
+ 2. Run this workflow as the reviewer coordinator. Call `review_context` first with the same target and `local: true` when `--local` is present, otherwise `local: false`.
5
+ 3. Call `review_comments` with the same target and backend. With `--local`, it synchronizes every comment in the selected tuicr session to `.diffpi/review/<session-slug>.md`. Existing replies and statuses remain; source comments removed by the user become resolved ledger entries.
6
+ 4. Classify every thread, group justified code changes into bounded non-overlapping tasks, and delegate those tasks to lightweight worker agents. Keep questions, outcome decisions, integration, and response text in the reviewer coordinator. With `--local`, workers modify the current working tree without committing. Without `--local`, apply a fix only when the comment requests a change.
7
+ 5. Apply every relevant requested change in this workflow. Do not label a relevant request deferred, later, or follow-up unless the user explicitly requested deferral. Use unresolved only for a concrete external blocker or material user decision, and state the attempted fixes and evidence. Respond to every thread with an explicit outcome and verification evidence. Answer questions and leave them open. For substantive requests, state what changed and whether it is resolved, but leave every thread open for the user to resolve. Do not resolve remote threads or delete local source comments in this workflow, including for trivial requests.
8
+ 6. When a remote address flow changes code, invoke the upstream `/git commit --no-push` workflow after checks pass and before drafting responses. Use `--atomic` when the fixes form separate logical commits.
9
+ 7. Call `review_respond` for each thread with `resolve: false`. With `--local`, every response is posted to tuicr and recorded in the session ledger. Without `--local`, replies post to the forge immediately. The user owns thread resolution.
10
+ 8. With `--local`, call `review_launch_ui` with `local: true` after replies are recorded so the user can inspect the working-tree review in tuicr.
11
+ 9. Report fixed, committed, answered, addressed, unresolved, and skipped counts. Resolved must always be zero in this workflow. Do not publish, complete, or merge.
@@ -0,0 +1,18 @@
1
+ # auto
2
+
3
+ 1. Parse an optional PR/MR id or URL and `--local`. The skill owns `--bg` dispatch before this reference is followed; a background child executes the remaining steps directly and must not redispatch. `launch` aliases this workflow.
4
+ 2. Call `review_context` first with the same target and `local: true` when `--local` is present, otherwise `local: false`.
5
+ 3. Call `review_new` with the same target and backend selection to create the local tuicr review or remote draft PR/MR and open its tuicr UI. A remote branch must be clean and pushed. If the review already exists, use `review_edit` with the same backend instead.
6
+ 4. Before reviewing, run `review_gates` so the project's discovered format-check and lint tasks run first, followed by its other gates. Preserve and report failures; do not substitute visual inspection for failed or skipped checks.
7
+ 5. Run review judgment as the reviewer agent. Inline, the reviewer performs the workflow tool calls directly. In background execution, the orchestrator delegates judgment to the reviewer and retains lifecycle calls. The reviewer fetches the diff with `review_diff` and may launch parallel lightweight subagents for independent areas when useful.
8
+ 6. Review the change for:
9
+ - whether it accomplishes the stated intent;
10
+ - whether the technical approach is the best practical way to accomplish that intent;
11
+ - correctness, including failure paths and edge cases;
12
+ - code quality, readability, and maintainability;
13
+ - minimality and conciseness, including unnecessary agent-generated changes;
14
+ - documentation accuracy and completeness; and
15
+ - reviewer coordination, including keeping lifecycle ownership clear and avoiding duplicate or conflicting findings.
16
+ Use parallel lightweight workers for independent review areas when useful, then reconcile their results before submission.
17
+ 7. Produce only grounded findings, then call `review_submit` with the same target and backend (`local: true` for `--local`, otherwise `local: false`). Remote findings remain pending for `publish` or `complete`.
18
+ 8. Report the artifact or pending-review state, finding count, gate results, backend, and any launch instruction. Do not complete or merge the review.
@@ -0,0 +1,7 @@
1
+ # complete
2
+
3
+ 1. Parse an optional PR/MR id or URL, `--local`, and exactly one remote action: `--approve`, `--reject`, or `--abandon`. The skill-owned `close` alias follows this workflow. Skill-owned `--bg` dispatch has already occurred; a background child must not redispatch or ask questions. If a remote action is missing in foreground mode, ask the user with `header: "Action"`; all question headers must be 16 characters or fewer. In background mode, stop with a blocker instead of guessing.
4
+ 2. Call `review_context` first with the same target and `local: true` when `--local` is present, otherwise `local: false`.
5
+ 3. With `--local`, call `review_complete` with `local: true`. It archives the reply overlay to `.diffpi/reviews/<session-slug>.md`, then deletes the exact persisted tuicr session. This is destructive and prevents its comments from appearing in future tuicr sessions.
6
+ 4. Without `--local`, map `--approve`, `--reject`, or `--abandon` to the `review_complete` action `approve`, `reject`, or `abandon`. The tool applies the remote lifecycle action but does not merge.
7
+ 5. Report the archive path or remote result. Do not call `review_merge`.
@@ -0,0 +1,7 @@
1
+ # edit
2
+
3
+ 1. Parse an optional PR/MR number, URL, or branch target and `--local`. Skill-owned background dispatch has already occurred; a background child follows these steps without redispatch.
4
+ 2. Call `review_context` first with the same target and `local: true` when `--local` is present, otherwise `local: false`.
5
+ 3. Call `review_edit` with the same target and backend. With `--local`, it opens an existing local tuicr session. Without `--local`, it opens an existing PR/MR in tuicr, including a non-draft PR/MR for continued work on its comments.
6
+ 4. If no matching local session or remote PR/MR exists, report the error and direct the user to `new`. Do not create a review, generate findings, publish, complete, or merge.
7
+ 5. Report whether tuicr opened in a mux, prepared a Zed task, or returned a command.
@@ -0,0 +1,36 @@
1
+ # help
2
+
3
+ Print the following help text:
4
+
5
+ ```text
6
+ Workflows for PRs and local review. Use:
7
+
8
+ Create a review and generate findings:
9
+ /review auto [pr-or-branch] [--local] [--bg]
10
+
11
+ Create a local review or remote draft PR/MR:
12
+ /review new [title] [--intent text] [--base branch] [--local] [--bg]
13
+
14
+ Open an existing remote PR/MR in the system browser (never creates one):
15
+ /review open [pr-number|pr-url|branch] [--local]
16
+
17
+ Show review and worktree lifecycle status:
18
+ /review status [pr-number|pr-url|branch] [--local]
19
+
20
+ Open an existing review in tuicr without generating findings:
21
+ /review edit [pr-number|pr-url|branch] [--local] [--bg]
22
+
23
+ Address review comments:
24
+ /review address [pr-number|pr-url|branch] [--local] [--bg]
25
+
26
+ Publish comments and a review status:
27
+ /review publish [pr-number|pr-url|branch] [--local] [--comment|--approve|--request-changes|--close] [--bg]
28
+
29
+ Complete a review without merging:
30
+ /review complete [pr-number|pr-url|branch] [--local|--approve|--reject|--abandon] [--bg]
31
+
32
+ Merge an approved remote review:
33
+ /review merge [pr-number|pr-url|branch] [--bg]
34
+ ```
35
+
36
+ `--local` selects the working-tree tuicr backend. Otherwise, a target is a PR/MR number, URL, or branch; no target means the current branch. `--bg` launches a tracked background Orchestrator and leaves the current chat mode unchanged. `new` creates a review. `open` opens an existing remote URL in the system browser, or directs to `new`; with `--local` it creates/opens the local working-tree review. `status` reports local and remote state without requiring a forge or tuicr binary. `edit` only opens an existing local session or remote PR/MR in tuicr. `auto` creates a review, then delegates findings to the reviewer agent. `create` and `draft` alias `new`; `launch` aliases `auto`; `close` aliases `complete`. `publish` publishes remote draft PR/MR review comments and status or promotes local comments. `complete` makes a lifecycle decision without merging, or archives the local overlay and deletes its tuicr session.
@@ -0,0 +1,6 @@
1
+ # merge
2
+
3
+ 1. Parse an optional PR number, URL, or branch. This workflow is remote-only; reject `--local`. The skill has already handled `--bg`; a background child must not redispatch. Call `review_context` first with the target and `local: false`. Do not query the forge through MCP or duplicate merge-readiness checks: `review_merge` uses the GitHub CLI to confirm the PR is open, non-draft, clean, and its checks are settled before merging. Do not require approval from the current user; authors cannot approve their own PRs. GitHub branch protection remains authoritative.
4
+ 2. If a conventional squash subject is required and the subject is unclear, use `ask_user_question`.
5
+ 3. Call `review_merge` with the chosen subject. Treat its CLI-backed readiness result as authoritative.
6
+ 4. Report the merge result.
@@ -0,0 +1,19 @@
1
+ # new
2
+
3
+ ## Arguments
4
+
5
+ ```text
6
+ /review new [title] [--intent text] [--base branch] [--local] [--bg]
7
+ ```
8
+
9
+ - `title` is the optional first positional argument; quote a title containing spaces.
10
+ - `--intent` and `--base` each consume the following value. `--local` is a boolean backend flag; the skill handles `--bg` before this workflow.
11
+ - Flags may appear in any order. Reject unknown or duplicate flags, missing flag values, and extra positional arguments. Stating this grammar before the procedure is intentional: an explicit argument contract is the best practice for making workflow behavior predictable and preventing ambiguous execution.
12
+
13
+ ## Workflow
14
+
15
+ 1. Parse the arguments using the grammar above after skill-owned background dispatch. A background child follows these steps directly and must not redispatch. A remote target is the current branch; `new` creates a new review rather than opening an existing one.
16
+ 2. Call `review_context` first with `local: true` when `--local` is present, otherwise `local: false`.
17
+ 3. Call `review_new` with the parsed title, intent, base branch, and the same explicit backend selection (`local: true` for `--local`, otherwise `local: false`). With `--local`, it creates and opens a local tuicr working-tree review. Without `--local`, it requires a clean, pushed branch, creates a draft PR/MR, and opens that PR/MR in tuicr.
18
+ 4. If a local session or remote PR/MR already exists, direct the user to `edit` instead.
19
+ 5. Report the PR/MR URL and whether tuicr opened in a mux, prepared a Zed task, or returned a command. Do not generate findings, publish, complete, or merge.
@@ -0,0 +1,3 @@
1
+ # open
2
+
3
+ Call `review_context` first. Without `--local`, call `review_open` to resolve an existing PR/MR and open its URL in the system browser. It must never create a PR/MR; if none exists, direct the user to `/review new`. If browser launch fails, show the plain URL. With `--local`, call `review_new` with `local=true` to preserve local working-tree behavior.
@@ -0,0 +1,8 @@
1
+ # publish
2
+
3
+ 1. Parse an optional PR/MR id or URL, `--local`, and one status: `--comment`, `--approve`, `--request-changes`, or `--close`. The default is comment. The skill has already handled `--bg`; a background child follows these steps without redispatch.
4
+ 2. Call `review_context` first with the target and `local: true` so the exact tuicr PR session can be inspected. If no matching local session exists, continue with `local: false` only for forge-native pending review work. If that session exists and has drafts, publish through the local promotion path even when the user omitted `--local`. Use `local: false` only when no matching tuicr session exists or when the target has forge-native pending review work.
5
+ 3. The local promotion path reads the exact tuicr session. A local line comment on the same file and line as an existing remote thread is treated as a response, not a new comment. A leading `[REOPEN]`, `[RESOLVE]`, or `[DELETE]` changes the thread state; the marker is removed from the response body. `[DELETE]` deletes the matched remote thread when the forge supports it. Other unpublished line comments become new review comments. The tool follows the stored local overlay path, posts unpublished replies to their remote threads, and then publishes the selected status. Question replies remain open. The tool does not post an overall review comment.
6
+ 4. For a forge-native review without a matching tuicr session, call `review_publish` without `local`. Existing pending forge comments already contain provenance, so the tool only publishes them with the selected status and no overall comment.
7
+ 5. Comment, approve, and request-changes mark a draft PR/MR ready before publication. Close publishes pending work as comment status and then closes the PR/MR. GitLab rejects request-changes because it has no equivalent review state.
8
+ 6. Report promoted comment and reply counts, the public status, and the final PR/MR state. Publishing never merges. If a response cannot be matched by file and line, report it as a new comment rather than silently attaching it to the wrong thread.
@@ -0,0 +1,3 @@
1
+ # status
2
+
3
+ Call `review_context` first, then `review_status` with the same target and local setting. Report branch, worktree counts, local and remote review state, URLs, and remote tuicr state. Status must remain useful when no forge or tuicr binary is installed.
@@ -1,13 +1,10 @@
1
- <!-- diffpi-plan: {"schemaVersion":1,"id":"{{id}}","revision":0,"branch":"{{branch}}","status":"draft","createdAt":"{{created_at}}","updatedAt":"{{updated_at}}"} -->
2
-
3
1
  # {{title}}
4
2
 
5
3
  - **Plan ID:** {{id}}
6
4
  - **Branch:** {{branch}}
5
+ - **Status:** draft
7
6
  - **Issue:** {{issue_id}}
8
7
  - **Issue URL:** {{issue_url}}
9
- - **Status:** draft
10
- - **Revision:** 0
11
8
 
12
9
  ## Intent
13
10
 
@@ -15,26 +12,35 @@
15
12
 
16
13
  ## Requirements
17
14
 
18
- <!-- Add requirements. -->
15
+ <!-- Add concrete requirements. -->
19
16
 
20
17
  ## Design
21
18
 
22
19
  ### Big Ideas
23
20
 
24
- <!-- Describe the main approach. -->
21
+ <!-- Describe the outcome-oriented design. -->
25
22
 
26
23
  ### Key API Addition/Updates
27
24
 
28
- <!-- Describe public API changes. -->
25
+ <!-- Describe public or internal contract changes. -->
29
26
 
30
27
  ### Consequences
31
28
 
32
- <!-- Describe trade-offs and limitations. -->
29
+ <!-- Describe before/after behavior, risks, and trade-offs. -->
30
+
31
+ ## Phases
32
+
33
+ <!-- Use numbered phases. State prerequisites on the phase only; do not add task dependencies here. -->
34
+
35
+ ### Phase 1: <!-- phase title -->
33
36
 
34
- ## Implementation
37
+ - **Phase ID:** <!-- assign a stable phase ID -->
38
+ - **Prerequisites:** <!-- list phase IDs, or “None” -->
39
+ - **Objective:** <!-- state the outcome -->
35
40
 
36
- <!-- Add phases with plan_add_phase. -->
41
+ - [ ] <!-- assign a stable task ID --> Task title
42
+ - [ ] <!-- assign a stable task ID --> Another task title
37
43
 
38
44
  ## References
39
45
 
40
- <!-- Add references. -->
46
+ <!-- Add repository or external references. -->
@@ -1,24 +1,46 @@
1
- # Phase {{phase_id}}: {{phase_title}}
1
+ # Phase {{phase_ordinal}}: {{phase_title}}
2
2
 
3
- ## Summary
3
+ - **Phase ID:** {{phase_id}}
4
+ - **Prerequisites:** {{phase_prerequisites}}
4
5
 
5
- <!-- State the change delivered by this phase in one short paragraph or up to three bullets. -->
6
+ ## Objective
6
7
 
7
- ## Scope
8
+ {{phase_objective}}
8
9
 
9
- **Objective:** {{phase_objective}}
10
+ ## Tasks
11
+
12
+ <!-- Keep tasks flat and in phase order. Repeat this shape for each task. -->
13
+
14
+ ### 1. <!-- task title -->
15
+
16
+ - **Task ID:** <!-- stable task ID -->
17
+ - **Steps:**
18
+ 1. <!-- ordered implementation action -->
19
+ 2. <!-- ordered implementation action -->
20
+ - **Verify:**
21
+ - <!-- command or inspection that proves this task -->
22
+ - **File scopes:** `<!-- exact/path/to/file -->`
23
+ - **Acceptance:** <!-- observable result -->
10
24
 
11
- **Tasks:**
12
25
  {{phase_tasks}}
13
26
 
14
- ## Files Changed
27
+ ## Implementation Constraints
15
28
 
16
- <!-- Show the directory tree. Annotate files added, removed, and updated. -->
29
+ ### Libraries and Algorithms
17
30
 
18
- ## API Changes
31
+ {{phase_libraries}}
19
32
 
20
- <!-- Document each public app, library, module, class, or function. Include behavior, data contracts, and imperative or declarative APIs. -->
33
+ ### Constraints
21
34
 
22
- ## Implementation Constraints
35
+ {{phase_constraints}}
36
+
37
+ ## Phase File Tree
38
+
39
+ <!-- Include exactly one tree. Label every file leaf with [ADD], [MODIFY], [REMOVE], [MOVE from: path], or [VERIFY]. -->
23
40
 
24
- <!-- State required libraries, algorithms, patterns, restrictions, and important implementation details. -->
41
+ ```text
42
+ Phase {{phase_ordinal}}/
43
+ ├── [MODIFY] <!-- exact/path/to/implementation-file -->
44
+ └── [VERIFY] <!-- exact/path/to/test-or-check -->
45
+ {{phase_file_tree}}
46
+ ```
@@ -1,22 +0,0 @@
1
- import type { ExtensionAPI, ExtensionContext } from '@earendil-works/pi-coding-agent';
2
- import { type Runner } from './extensions/cmdtsx';
3
- import type { ModeController } from './modes';
4
- import { type PlanWorkflowArguments, type PlanWorkflowName } from './workflow';
5
- export type WorkflowAgent = 'planner' | 'orchestrator' | 'reviewer' | 'worker';
6
- export type WorkflowRuntime = {
7
- pi: ExtensionAPI;
8
- ctx: ExtensionContext;
9
- modes: ModeController;
10
- };
11
- export type WorkflowInvocation = {
12
- [Name in PlanWorkflowName]: {
13
- workflow: Name;
14
- arguments: PlanWorkflowArguments[Name];
15
- agent?: WorkflowAgent;
16
- isBackground?: boolean;
17
- };
18
- }[PlanWorkflowName];
19
- export declare function tokenizeCommandArgs(raw: string): string[];
20
- export declare function generateCommandHelp<Args, Result>(command: Runner<Args, Result>): Promise<string>;
21
- export declare function createWorkflowInvoker(runtime: WorkflowRuntime): (invocation: WorkflowInvocation) => Promise<void>;
22
- //# sourceMappingURL=commands.d.ts.map
@@ -1 +0,0 @@
1
- {"version":3,"file":"commands.d.ts","sourceRoot":"","sources":["../src/commands.ts"],"names":[],"mappings":"AAAA,OAAO,KAAK,EAAE,YAAY,EAAE,gBAAgB,EAAE,MAAM,iCAAiC,CAAC;AACtF,OAAO,EAAU,KAAK,MAAM,EAAE,MAAM,qBAAqB,CAAC;AAE1D,OAAO,KAAK,EAAE,cAAc,EAAE,MAAM,SAAS,CAAC;AAC9C,OAAO,EAAoB,KAAK,qBAAqB,EAAE,KAAK,gBAAgB,EAAE,MAAM,YAAY,CAAC;AAIjG,MAAM,MAAM,aAAa,GAAG,SAAS,GAAG,cAAc,GAAG,UAAU,GAAG,QAAQ,CAAC;AAE/E,MAAM,MAAM,eAAe,GAAG;IAC5B,EAAE,EAAE,YAAY,CAAC;IACjB,GAAG,EAAE,gBAAgB,CAAC;IACtB,KAAK,EAAE,cAAc,CAAC;CACvB,CAAC;AAEF,MAAM,MAAM,kBAAkB,GAAG;KAC9B,IAAI,IAAI,gBAAgB,GAAG;QAC1B,QAAQ,EAAE,IAAI,CAAC;QACf,SAAS,EAAE,qBAAqB,CAAC,IAAI,CAAC,CAAC;QACvC,KAAK,CAAC,EAAE,aAAa,CAAC;QACtB,YAAY,CAAC,EAAE,OAAO,CAAC;KACxB;CACF,CAAC,gBAAgB,CAAC,CAAC;AAIpB,wBAAgB,mBAAmB,CAAC,GAAG,EAAE,MAAM,GAAG,MAAM,EAAE,CAwBzD;AAED,wBAAsB,mBAAmB,CAAC,IAAI,EAAE,MAAM,EAAE,OAAO,EAAE,MAAM,CAAC,IAAI,EAAE,MAAM,CAAC,GAAG,OAAO,CAAC,MAAM,CAAC,CAItG;AAED,wBAAgB,qBAAqB,CAAC,OAAO,EAAE,eAAe,IACvB,YAAY,kBAAkB,KAAG,OAAO,CAAC,IAAI,CAAC,CAwBpF"}
@@ -1,2 +0,0 @@
1
- export { command, dryRun, flag, oneOf, option, optional, positional, restPositionals, string, subcommands, type Runner, } from 'cmd-ts/dist/esm/index.js';
2
- //# sourceMappingURL=cmdtsx.d.ts.map
@@ -1 +0,0 @@
1
- {"version":3,"file":"cmdtsx.d.ts","sourceRoot":"","sources":["../../src/extensions/cmdtsx.ts"],"names":[],"mappings":"AAEA,OAAO,EACL,OAAO,EACP,MAAM,EACN,IAAI,EACJ,KAAK,EACL,MAAM,EACN,QAAQ,EACR,UAAU,EACV,eAAe,EACf,MAAM,EACN,WAAW,EACX,KAAK,MAAM,GACZ,MAAM,0BAA0B,CAAC"}
@@ -1 +0,0 @@
1
- {"version":3,"file":"plan-schema.d.ts","sourceRoot":"","sources":["../../src/tools/plan-schema.ts"],"names":[],"mappings":"AAAA,OAAO,EAAE,CAAC,EAAE,MAAM,KAAK,CAAC;AAMxB,QAAA,MAAM,mBAAmB;;;;;;;kBASd,CAAC;AAEZ,QAAA,MAAM,oBAAoB;;;;;;;;;;;;;kBAQf,CAAC;AAYZ,eAAO,MAAM,2BAA2B;;;;;;;;;;;kBAO7B,CAAC;AAEZ,eAAO,MAAM,wBAAwB;;;;;;;;;kBAW1B,CAAC;AAEZ,eAAO,MAAM,kCAAkC;;;;;;;;;;;;;;;kBAa3C,CAAC;AAEL,eAAO,MAAM,4BAA4B;;;;;;;;;;;;;;;;;;;kBAQ9B,CAAC;AAEZ,eAAO,MAAM,+BAA+B;;;;;;kBAQjC,CAAC;AAEZ,eAAO,MAAM,+BAA+B;;;;;;;;;;;;;;;;;;kBAejC,CAAC;AAEZ,eAAO,MAAM,4BAA4B;;;;kBAE9B,CAAC;AAEZ,eAAO,MAAM,+BAA+B;;;;;;;;;;kBAYjC,CAAC;AAEZ,eAAO,MAAM,4BAA4B;;;;;;;kBAS9B,CAAC;AAEZ,eAAO,MAAM,4BAA4B;;;;;;;;;;;;;;kBAY9B,CAAC;AAEZ,eAAO,MAAM,0BAA0B;;;kBAAkE,CAAC;AAE1G,eAAO,MAAM,kCAAkC;;;;;;;;;kBAOpC,CAAC;AAEZ,eAAO,MAAM,gCAAgC;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;kBA+BlC,CAAC;AAEZ,MAAM,MAAM,aAAa,GAAG,CAAC,CAAC,KAAK,CAAC,OAAO,mBAAmB,CAAC,CAAC;AAChE,MAAM,MAAM,cAAc,GAAG,CAAC,CAAC,KAAK,CAAC,OAAO,oBAAoB,CAAC,CAAC"}