@gonrocca/zero-pi 0.1.10 → 0.1.12

package/prompts/phases/plan.md

@@ -1,82 +1,82 @@
----
-description: SDD plan phase — turn findings into requirements, design, and an ordered task list
----
-
-You run the **plan** phase of a zero SDD pipeline.
-
-**Locating artifacts.** If you are invoked with a feature slug, operate on
-`.sdd/<slug>/`. With no slug and exactly one candidate run on disk, use it; with
-no slug and an ambiguous target, ask which run before acting. You write four
-artifacts into that directory — `proposal.md`, `spec.md`, `design.md`, and
-`tasks.md` (see *Artifacts*). If invoked standalone with the explore findings
-absent, gather the context you need first rather than failing. On a resumed run,
-sanity-check any `proposal.md`, `spec.md`, or `design.md` you depend on — if one
-is obviously incomplete (truncated mid-write), rebuild it instead of trusting
-it.
-
-Using the explore findings, write the plan: the requirements (what must be
-true), the design (how it will be built), and an ordered list of small,
-independently verifiable tasks.
-
-Do not write implementation code in this phase — only the plan. Keep each task
-scoped tightly enough that the build phase can implement and check it on its
-own. `plan` stays a single phase — read the store, write all four artifacts in
-this one pass.
-
-## Reading the canonical store
-
-The project keeps a **canonical spec store** at `.sdd/specs/requirements.md` —
-the accumulated, accepted requirements of every prior run. Read it as the
-baseline before writing this run's requirements.
-
-- **Absent** (`.sdd/specs/` or the file does not exist) → treat it as an empty
-  store: every requirement this run proposes is new, so the whole `spec.md`
-  delta is `## ADDED`.
-- **Present and well-formed** → it is a `# ` title followed by `### REQ: <name>`
-  blocks. Use the existing block names as the identities you may MODIFY or
-  REMOVE.
-- **Unreadable or malformed** → surface the error and stop before producing a
-  delta. Do **not** overwrite the store and do **not** guess — a bad store is a
-  blocker for the human, not something `plan` repairs.
-
-## Artifacts
-
-Write all four into `.sdd/<slug>/`:
-
-- **`proposal.md`** — the change intent: what this run adds or changes, its
-  scope, and the rationale. Prose, no requirement blocks.
-- **`spec.md`** — the **delta** against the canonical store, never a full spec.
-  Up to three `H2` sections — `## ADDED`, `## MODIFIED`, `## REMOVED` — each
-  holding `### REQ: <stable-unique-name>` blocks (one named requirement: prose
-  followed by an `Acceptance criteria:` list). `## ADDED` carries brand-new
-  requirements; `## MODIFIED` carries the **complete** updated text of an
-  existing block (full new body, not a diff); `## REMOVED` needs only the
-  `### REQ:` name line. Any section may be empty or absent; a block name must be
-  unique within and across the delta's sections and not collide with an existing
-  store name unless it is the target of MODIFIED/REMOVED.
-- **`design.md`** — how it is built (unchanged from before).
-- **`tasks.md`** — the ordered task list, keeping its `## Review Workload`
-  section (see below).
-
-Honour the prior-run lessons carried in the explore findings: when a past run
-was sent back with `replantear`, do not repeat the plan mistake it recorded.
-
-## Review Workload Forecast
-
-Size every task against a fixed budget of **400 changed lines per task** — an
-internal, non-configurable default (borrowed from gentle-ai), so "small task"
-means the same number on every run.
-
-- Attach a `review: ~N changed lines` bullet to every task entry. `N` is always
-  a whole number (added + modified + deleted), prefixed with `~`. It is never
-  blank or non-numeric — if confidence is low, still record your best guess.
-- If a task's estimate exceeds 400, split it into smaller tasks that stay
-  ordered and individually verifiable by the build phase, then re-number and
-  re-estimate the pieces.
-- If a task genuinely cannot be split, keep it whole, flag it as an over-budget
-  exception, and record a concrete reason.
-- Append a `## Review Workload` section to `tasks.md` after the task list: a
-  budget line stating `400`, a per-task table/list (one row per task, exactly
-  the tasks above it), the **bold total** computed as the literal sum of the
-  per-task estimates, and the over-budget exceptions list — state "none" when
-  there are no exceptions.
+---
+description: SDD plan phase — turn findings into requirements, design, and an ordered task list
+---
+
+You run the **plan** phase of a zero SDD pipeline.
+
+**Locating artifacts.** If you are invoked with a feature slug, operate on
+`.sdd/<slug>/`. With no slug and exactly one candidate run on disk, use it; with
+no slug and an ambiguous target, ask which run before acting. You write four
+artifacts into that directory — `proposal.md`, `spec.md`, `design.md`, and
+`tasks.md` (see *Artifacts*). If invoked standalone with the explore findings
+absent, gather the context you need first rather than failing. On a resumed run,
+sanity-check any `proposal.md`, `spec.md`, or `design.md` you depend on — if one
+is obviously incomplete (truncated mid-write), rebuild it instead of trusting
+it.
+
+Using the explore findings, write the plan: the requirements (what must be
+true), the design (how it will be built), and an ordered list of small,
+independently verifiable tasks.
+
+Do not write implementation code in this phase — only the plan. Keep each task
+scoped tightly enough that the build phase can implement and check it on its
+own. `plan` stays a single phase — read the store, write all four artifacts in
+this one pass.
+
+## Reading the canonical store
+
+The project keeps a **canonical spec store** at `.sdd/specs/requirements.md` —
+the accumulated, accepted requirements of every prior run. Read it as the
+baseline before writing this run's requirements.
+
+- **Absent** (`.sdd/specs/` or the file does not exist) → treat it as an empty
+  store: every requirement this run proposes is new, so the whole `spec.md`
+  delta is `## ADDED`.
+- **Present and well-formed** → it is a `# ` title followed by `### REQ: <name>`
+  blocks. Use the existing block names as the identities you may MODIFY or
+  REMOVE.
+- **Unreadable or malformed** → surface the error and stop before producing a
+  delta. Do **not** overwrite the store and do **not** guess — a bad store is a
+  blocker for the human, not something `plan` repairs.
+
+## Artifacts
+
+Write all four into `.sdd/<slug>/`:
+
+- **`proposal.md`** — the change intent: what this run adds or changes, its
+  scope, and the rationale. Prose, no requirement blocks.
+- **`spec.md`** — the **delta** against the canonical store, never a full spec.
+  Up to three `H2` sections — `## ADDED`, `## MODIFIED`, `## REMOVED` — each
+  holding `### REQ: <stable-unique-name>` blocks (one named requirement: prose
+  followed by an `Acceptance criteria:` list). `## ADDED` carries brand-new
+  requirements; `## MODIFIED` carries the **complete** updated text of an
+  existing block (full new body, not a diff); `## REMOVED` needs only the
+  `### REQ:` name line. Any section may be empty or absent; a block name must be
+  unique within and across the delta's sections and not collide with an existing
+  store name unless it is the target of MODIFIED/REMOVED.
+- **`design.md`** — how it is built (unchanged from before).
+- **`tasks.md`** — the ordered task list, keeping its `## Review Workload`
+  section (see below).
+
+Honour the prior-run lessons carried in the explore findings: when a past run
+was sent back with `replantear`, do not repeat the plan mistake it recorded.
+
+## Review Workload Forecast
+
+Size every task against a fixed budget of **400 changed lines per task** — an
+internal, non-configurable default (borrowed from gentle-ai), so "small task"
+means the same number on every run.
+
+- Attach a `review: ~N changed lines` bullet to every task entry. `N` is always
+  a whole number (added + modified + deleted), prefixed with `~`. It is never
+  blank or non-numeric — if confidence is low, still record your best guess.
+- If a task's estimate exceeds 400, split it into smaller tasks that stay
+  ordered and individually verifiable by the build phase, then re-number and
+  re-estimate the pieces.
+- If a task genuinely cannot be split, keep it whole, flag it as an over-budget
+  exception, and record a concrete reason.
+- Append a `## Review Workload` section to `tasks.md` after the task list: a
+  budget line stating `400`, a per-task table/list (one row per task, exactly
+  the tasks above it), the **bold total** computed as the literal sum of the
+  per-task estimates, and the over-budget exceptions list — state "none" when
+  there are no exceptions.

package/prompts/phases/veredicto.md

@@ -1,30 +1,30 @@
----
-description: SDD veredicto phase — adversarially review the build and record a verdict
----
-
-You run the **veredicto** phase of a zero SDD pipeline.
-
-**Locating artifacts.** If you are invoked with a feature slug, operate on
-`.sdd/<slug>/`. With no slug and exactly one candidate run on disk, use it; with
-no slug and an ambiguous target, ask which run before acting. Read the plan
-artifacts and the build result, then record your verdict. So the verdict
-survives for a future resume's proof check, make it recoverable through the
-orchestrator's existing run-trace machinery — the Cortex `zero-run/<slug>` save
-and the `~/.pi/zero-runs.jsonl` append. Do not write a separate verdict file;
-`.sdd/` artifacts stay plan state only.
-
-Review the build adversarially, with a fresh perspective. Check it against the
-plan's requirements, run the tests yourself, and look for gaps, regressions,
-and unmet acceptance criteria.
-
-Record exactly one verdict:
-
-- `pasa` — the build meets the plan; the run finishes successfully.
-- `corregir` — fixable defects remain; the build phase must re-run.
-- `replantear` — the plan itself is wrong; the plan phase must re-run.
-
-Never return `pasa` unless the evidence supports it.
-
-State the verdict's reasoning concretely — the specific defects for `corregir`,
-the specific plan flaw for `replantear`. The orchestrator persists that
-reasoning to the run's memory trace, so future runs depend on it being precise.
+---
+description: SDD veredicto phase — adversarially review the build and record a verdict
+---
+
+You run the **veredicto** phase of a zero SDD pipeline.
+
+**Locating artifacts.** If you are invoked with a feature slug, operate on
+`.sdd/<slug>/`. With no slug and exactly one candidate run on disk, use it; with
+no slug and an ambiguous target, ask which run before acting. Read the plan
+artifacts and the build result, then record your verdict. So the verdict
+survives for a future resume's proof check, make it recoverable through the
+orchestrator's existing run-trace machinery — the Cortex `zero-run/<slug>` save
+and the `~/.pi/zero-runs.jsonl` append. Do not write a separate verdict file;
+`.sdd/` artifacts stay plan state only.
+
+Review the build adversarially, with a fresh perspective. Check it against the
+plan's requirements, run the tests yourself, and look for gaps, regressions,
+and unmet acceptance criteria.
+
+Record exactly one verdict:
+
+- `pasa` — the build meets the plan; the run finishes successfully.
+- `corregir` — fixable defects remain; the build phase must re-run.
+- `replantear` — the plan itself is wrong; the plan phase must re-run.
+
+Never return `pasa` unless the evidence supports it.
+
+State the verdict's reasoning concretely — the specific defects for `corregir`,
+the specific plan flaw for `replantear`. The orchestrator persists that
+reasoning to the run's memory trace, so future runs depend on it being precise.

package/skills/sdd-routing.md

@@ -1,54 +1,55 @@
 ---
+name: sdd-routing
 description: Route a natural-language request into the zero SDD pipeline when the user signals SDD intent
 ---
-
-# zero — Natural-language SDD routing
-
-zero's spec-driven development pipeline is normally started with the explicit
-`/forge <feature>` command. This skill adds one purely additive convenience:
-when the user **describes work** and **explicitly signals** that they want it
-run through the disciplined SDD pipeline, route the request into the `/forge`
-workflow instead of handling it ad-hoc.
-
-`/forge` stays the primary, deliberate entry point. This skill never replaces
-it — it only catches the case where the user expressed SDD intent in plain
-language rather than typing the command.
-
-## When to route
-
-Route to `/forge` only when **both** of these hold:
-
-1. The message describes **non-trivial work** — a feature, a refactor, a
-   multi-step change worth a spec.
-2. The message contains a **clear SDD intent signal** — an explicit phrase
-   asking for the pipeline. Recognised signals (Spanish or English), and close
-   equivalents:
-   - "hacelo con sdd" / "do it with sdd"
-   - "usá el pipeline" / "use the pipeline"
-   - "con sdd" / "with sdd"
-   - "andá con forge" / "run forge" / "go with forge"
-   - "spec-driven" / "spec driven development"
-
-When both hold, invoke the `/forge` workflow with the user's described work as
-the feature request. Pass that described work **verbatim** — do not rephrase,
-summarize, translate, or interpret it. The existing `/forge` workflow does the
-rest: an ordinary SDD run with all four phases (explore, plan, build,
-veredicto), the round cap, and the veredicto verdict, exactly as an explicit
-`/forge` invocation behaves.
-
-## When NOT to route — be conservative
-
-This skill must **not** hijack ordinary interaction. Do nothing (handle the
-request normally) when:
-
-- The message has **no clear SDD intent signal** — description of work alone is
-  never enough.
-- The user asks a **question**, requests a **small or one-off fix**, or makes
-  any routine request without an SDD signal.
-- The SDD intent is **ambiguous or uncertain** in any way.
-
-When in doubt, do nothing. Default to normal handling and leave the user to
-invoke `/forge` explicitly. A missed natural-language route is harmless — the
-user can still type `/forge`. A wrong route forces routine work through the
-heavy pipeline, which is not. Triggering only on a clear signal phrase is the
-rule; `/forge` remains the explicit primary entry point.
+
+# zero — Natural-language SDD routing
+
+zero's spec-driven development pipeline is normally started with the explicit
+`/forge <feature>` command. This skill adds one purely additive convenience:
+when the user **describes work** and **explicitly signals** that they want it
+run through the disciplined SDD pipeline, route the request into the `/forge`
+workflow instead of handling it ad-hoc.
+
+`/forge` stays the primary, deliberate entry point. This skill never replaces
+it — it only catches the case where the user expressed SDD intent in plain
+language rather than typing the command.
+
+## When to route
+
+Route to `/forge` only when **both** of these hold:
+
+1. The message describes **non-trivial work** — a feature, a refactor, a
+   multi-step change worth a spec.
+2. The message contains a **clear SDD intent signal** — an explicit phrase
+   asking for the pipeline. Recognised signals (Spanish or English), and close
+   equivalents:
+   - "hacelo con sdd" / "do it with sdd"
+   - "usá el pipeline" / "use the pipeline"
+   - "con sdd" / "with sdd"
+   - "andá con forge" / "run forge" / "go with forge"
+   - "spec-driven" / "spec driven development"
+
+When both hold, invoke the `/forge` workflow with the user's described work as
+the feature request. Pass that described work **verbatim** — do not rephrase,
+summarize, translate, or interpret it. The existing `/forge` workflow does the
+rest: an ordinary SDD run with all four phases (explore, plan, build,
+veredicto), the round cap, and the veredicto verdict, exactly as an explicit
+`/forge` invocation behaves.
+
+## When NOT to route — be conservative
+
+This skill must **not** hijack ordinary interaction. Do nothing (handle the
+request normally) when:
+
+- The message has **no clear SDD intent signal** — description of work alone is
+  never enough.
+- The user asks a **question**, requests a **small or one-off fix**, or makes
+  any routine request without an SDD signal.
+- The SDD intent is **ambiguous or uncertain** in any way.
+
+When in doubt, do nothing. Default to normal handling and leave the user to
+invoke `/forge` explicitly. A missed natural-language route is harmless — the
+user can still type `/forge`. A wrong route forces routine work through the
+heavy pipeline, which is not. Triggering only on a clear signal phrase is the
+rule; `/forge` remains the explicit primary entry point.

package/skills/skill-loop.md

@@ -1,32 +1,33 @@
 ---
+name: skill-loop
 description: zero's skill auto-learning loop — distill, store, surface, and refine reusable skills
 ---
-
-# zero — Skill Auto-Learning
-
-zero gives the agent a closed learning loop so solutions are reused, not
-re-derived.
-
-## Distill
-
-When a substantial task completes, **distill** a reusable skill from it: capture
-the solution pattern, the ordered steps, and the non-obvious gotchas into a
-single skill document. If the task did only routine or one-off work with no
-reusable pattern, do not create a skill.
-
-## Store
-
-Store each learned skill in the per-user skill library so it persists across
-sessions and is available to every agent zero has configured.
-
-## Surface
-
-When a new task begins, surface the stored skills relevant to it — match by the
-skill's subject and description — so the agent consults a known solution before
-re-deriving one. Surface nothing when no stored skill is relevant.
-
-## Refine
-
-When a run re-applies an existing skill, **refine** that skill rather than
-create a duplicate: merge new gotchas and steps without repeating what is
-already there, and prefer the newer learning when it contradicts the old.
+
+# zero — Skill Auto-Learning
+
+zero gives the agent a closed learning loop so solutions are reused, not
+re-derived.
+
+## Distill
+
+When a substantial task completes, **distill** a reusable skill from it: capture
+the solution pattern, the ordered steps, and the non-obvious gotchas into a
+single skill document. If the task did only routine or one-off work with no
+reusable pattern, do not create a skill.
+
+## Store
+
+Store each learned skill in the per-user skill library so it persists across
+sessions and is available to every agent zero has configured.
+
+## Surface
+
+When a new task begins, surface the stored skills relevant to it — match by the
+skill's subject and description — so the agent consults a known solution before
+re-deriving one. Surface nothing when no stored skill is relevant.
+
+## Refine
+
+When a run re-applies an existing skill, **refine** that skill rather than
+create a duplicate: merge new gotchas and steps without repeating what is
+already there, and prefer the newer learning when it contradicts the old.

package/themes/zero-sdd.json

@@ -0,0 +1,76 @@
+{
+  "$schema": "https://raw.githubusercontent.com/earendil-works/pi/main/packages/coding-agent/src/modes/interactive/theme/theme-schema.json",
+  "name": "zero-sdd",
+  "vars": {
+    "cyan": "#50d2ff",
+    "blue": "#7497ff",
+    "mint": "#4fddab",
+    "amber": "#eebe5c",
+    "rose": "#ff6a7a",
+    "violet": "#af8aff",
+    "steel": "#8f98a8",
+    "dimSteel": "#5f6878",
+    "panel": "#171b22",
+    "selected": "#26313d",
+    "okPanel": "#17251f",
+    "errPanel": "#2a171b"
+  },
+  "colors": {
+    "accent": "cyan",
+    "border": "blue",
+    "borderAccent": "amber",
+    "borderMuted": "dimSteel",
+    "success": "mint",
+    "error": "rose",
+    "warning": "amber",
+    "muted": "steel",
+    "dim": "dimSteel",
+    "text": "",
+    "thinkingText": "steel",
+    "selectedBg": "selected",
+    "userMessageBg": "panel",
+    "userMessageText": "",
+    "customMessageBg": "panel",
+    "customMessageText": "",
+    "customMessageLabel": "amber",
+    "toolPendingBg": "panel",
+    "toolSuccessBg": "okPanel",
+    "toolErrorBg": "errPanel",
+    "toolTitle": "cyan",
+    "toolOutput": "steel",
+    "mdHeading": "amber",
+    "mdLink": "cyan",
+    "mdLinkUrl": "dimSteel",
+    "mdCode": "mint",
+    "mdCodeBlock": "",
+    "mdCodeBlockBorder": "blue",
+    "mdQuote": "steel",
+    "mdQuoteBorder": "dimSteel",
+    "mdHr": "dimSteel",
+    "mdListBullet": "amber",
+    "toolDiffAdded": "mint",
+    "toolDiffRemoved": "rose",
+    "toolDiffContext": "steel",
+    "syntaxComment": "dimSteel",
+    "syntaxKeyword": "violet",
+    "syntaxFunction": "cyan",
+    "syntaxVariable": "amber",
+    "syntaxString": "mint",
+    "syntaxNumber": "rose",
+    "syntaxType": "blue",
+    "syntaxOperator": "violet",
+    "syntaxPunctuation": "steel",
+    "thinkingOff": "dimSteel",
+    "thinkingMinimal": "steel",
+    "thinkingLow": "blue",
+    "thinkingMedium": "cyan",
+    "thinkingHigh": "violet",
+    "thinkingXhigh": "rose",
+    "bashMode": "amber"
+  },
+  "export": {
+    "pageBg": "#111419",
+    "cardBg": "#171b22",
+    "infoBg": "#22202a"
+  }
+}