You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: README.md
+3-3Lines changed: 3 additions & 3 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -27,7 +27,7 @@ A single model has systematic blind spots — it tends to miss the same edge cas
27
27
-**Truthful status board** — the PM remains responsive, posts live progress in commentary, and accepts `QUERY`, `ADD`, `CHANGE`, `REPLACE`, and `PRIORITY` messages while work continues.
28
28
-**Two-stage review** — a reviewer checks spec compliance, then a reviewer checks code quality; failures loop back.
29
29
-**Verification gate** — no "done / passing / fixed" claim without freshly-run evidence on the spot.
30
-
-**Read opt-in / write opt-in** — Obsidian memory is never read or written automatically. When history may help, starks asks before reading; after reusable progress, it asks separately before writing.
30
+
-**Scoped shared memory** — Claude and Codex can share cross-project Obsidian facts, but nothing is searched, listed, read, or written automatically. Read access is task-scoped and budgeted; write access is separately enumerated and approved.
31
31
-**Dual-platform** — one `SKILL.md`, symlinked into both Claude Code and Codex.
32
32
-**Anti-recursion guard** — when invoked as a cross-reviewer, starks answers once and exits instead of re-entering its own flow.
33
33
@@ -59,7 +59,7 @@ starks reads a few optional environment variables (all have defaults or degrade
59
59
|`STARKS_REVIEW_MODEL_CODEX`| reviewer model when Codex reviews the plan (Claude→Codex) | unset → codex default |
60
60
|`STARKS_REVIEW_MODEL_CLAUDE`| reviewer model when Claude reviews the plan (Codex→Claude) | unset → claude default |
61
61
|`STARKS_REVIEW_TIMEOUT_SECONDS`| cross-review timeout in seconds |`600`|
62
-
|`STARKS_MEMORY_DIR`| project-memory dir (e.g. an Obsidian vault subfolder); configuration only makes opt-in available | unset |
62
+
|`STARKS_MEMORY_DIR`|shared project-memory root (e.g. an Obsidian vault subfolder); configuration only makes scoped opt-in available | unset |
63
63
|`STARKS_STYLE_NOTE`| optional note the memory writer reads first to match your style | unset |
64
64
65
65
Export sub-agent and memory settings into the primary agent process. Reviewer settings may also live in `.env`; `scripts/cross-review.sh` reads them automatically and already-exported values take precedence.
@@ -72,7 +72,7 @@ starks doesn't run the same heavyweight pipeline on everything. When real work s
72
72
-**light** — a single clear concern across a few files. Do it (or confirm in one line) and skip the parallel / cross-review machinery, but the verification gate still applies.
73
73
-**full** — multi-file, architectural, large behavior change, or genuinely uncertain. This runs the whole flow.
74
74
75
-
For a full-tier task the flow is: **ask whether to recall project memory** when history may help (default: skip; after approval, read the short summary first and expand only as needed) → **grill** the requirements — multiple-choice first, batching independent questions — to surface hidden assumptions, edges, and success criteria → **draft** a plan → **present it for one decision** (a hard gate: start now / cross-review first / revise). Only if you pick cross-review does the plan go to the other model; the revised version comes back for sign-off. After approval the PM uses work-conserving scheduling: whenever a slot opens, safe Ready work from the dependency DAG starts without waiting for the whole wave, but work is never force-split merely to raise concurrency. The PM stays responsive, posts a truthful status board in commentary, and accepts new `QUERY`, `ADD`, `CHANGE`, `REPLACE`, and `PRIORITY` messages while work continues. It then runs the **two-stage review**, holds the **verification gate**, and asks separately before writing reusable progress to project memory. Read approval never implies write approval. See the [PM orchestration reference](references/pm-orchestration.md) for the detailed scheduling protocol.
75
+
For a full-tier task the flow is: **ask whether to route shared project memory** when history may help (default: skip; the task-scoped approval names the metadata scan, files, and context budget) → **grill** the requirements — multiple-choice first, batching independent questions — to surface hidden assumptions, edges, and success criteria → **draft** a plan → **present it for one decision** (a hard gate: start now / cross-review first / revise). Only if you pick cross-review does the plan go to the other model; the revised version comes back for sign-off. After approval the PM uses work-conserving scheduling, runs the **two-stage review**, and holds the **verification gate**. At task end, reusable facts are offered as a separate, enumerated write; read approval never implies write approval. See the [PM orchestration reference](references/pm-orchestration.md) and [memory protocol](references/memory.md) for details.
76
76
77
77
Cross-review uses one stable wrapper; the full plan always travels over stdin:
0 commit comments