luciazero 2.0.3 → 2.2.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.
@@ -1,11 +1,11 @@
1
1
  # Luciazero — default operating mode
2
2
 
3
- Applies to every repo, every session. The loop is plan → change → verify → fix, repeated until verify passes or the blocker is real.
3
+ Applies to every repo, every session. The loop is plan → change → fastest relevant check → fix; run full verification once at closeout.
4
4
 
5
5
  ## Ground truth
6
6
 
7
7
  1. **Done is proven by a command, not by my judgment.** Before saying a change works, run something that returns an exit code — test, lint, type-check, build, or a real invocation — and quote the shortest decisive line of its output. A run that did not happen is reported as exactly that. (closeout procedure: `/done`)
8
- 2. **If no verification command exists, that is the first bug.** Say so and offer to create the smallest one that covers the change (procedure: `/luciazero-bootstrap`). Do not silently proceed on vibes.
8
+ 2. **If no verification command exists, that is the first bug.** Say so and offer to create the smallest one that covers the change (procedure: `/ready`). Do not silently proceed on vibes.
9
9
  3. **Failing test/lint means not done.** Fix the cause. Never delete, skip, weaken, or suppress a check to reach green — if a check is genuinely wrong, say why and ask.
10
10
 
11
11
  ## Loop
package/install-codex.sh CHANGED
@@ -4,7 +4,7 @@
4
4
  #
5
5
  # Mapping (single source of truth stays in claude/):
6
6
  # claude/luciazero.md -> marker block in ~/.codex/AGENTS.md
7
- # skills/catalog.txt entries -> ~/.codex/skills/<each>/
7
+ # skills/catalog.txt + aliases.txt -> ~/.codex/skills/<each>/
8
8
  # claude/agents/catalog.txt entries -> ~/.codex/skills/<agent>/SKILL.md
9
9
  # (Claude-only `tools:`/`model:` lines dropped)
10
10
  # claude/hooks/ (enforcement pack) -> NOT installed: Codex has no hooks/statusline
@@ -23,6 +23,10 @@ MANAGED_DIR="${CODEX_DIR}/.luciazero-managed"
23
23
  BACKUP_DIR="${CODEX_DIR}/.luciazero-backups"
24
24
 
25
25
  catalog() { sed '/^[[:space:]]*#/d; /^[[:space:]]*$/d' "$1"; }
26
+ skill_inventory() {
27
+ catalog "${SRC}/skills/catalog.txt"
28
+ catalog "${SRC}/skills/aliases.txt"
29
+ }
26
30
 
27
31
  # collision-proof backup path for $1 (two runs in the same second must not overwrite)
28
32
  bakpath() {
@@ -93,7 +97,7 @@ while IFS= read -r SKILL; do
93
97
  "${MANAGED_DIR}/skills/${SKILL}" \
94
98
  "skills/${SKILL}"
95
99
  echo " ok skills/${SKILL}"
96
- done < <(catalog "${SRC}/skills/catalog.txt")
100
+ done < <(skill_inventory)
97
101
 
98
102
  LEGACY_HANDOFF="${CODEX_DIR}/skills/handoff"
99
103
  if [ -f "${LEGACY_HANDOFF}/SKILL.md" ]; then
package/install.sh CHANGED
@@ -29,6 +29,10 @@ MANAGED_DIR="${CLAUDE_DIR}/.luciazero-managed"
29
29
  BACKUP_DIR="${CLAUDE_DIR}/.luciazero-backups"
30
30
 
31
31
  catalog() { sed '/^[[:space:]]*#/d; /^[[:space:]]*$/d' "$1"; }
32
+ skill_inventory() {
33
+ catalog "${SRC}/skills/catalog.txt"
34
+ catalog "${SRC}/skills/aliases.txt"
35
+ }
32
36
 
33
37
  # newest released version in this checkout's CHANGELOG (informational)
34
38
  version_of() {
@@ -50,8 +54,8 @@ if [ "${STATUS_ONLY}" = 1 ]; then
50
54
  check -f "${CLAUDE_DIR}/${DOCTRINE}" "doctrine ${DOCTRINE}"
51
55
  while IFS= read -r SKILL; do
52
56
  check -f "${CLAUDE_DIR}/skills/${SKILL}/SKILL.md" "skill ${SKILL}"
53
- done < <(catalog "${SRC}/skills/catalog.txt")
54
- check -x "${CLAUDE_DIR}/skills/luciazero-bootstrap/scripts/detect.sh" "detect.sh executable"
57
+ done < <(skill_inventory)
58
+ check -x "${CLAUDE_DIR}/skills/ready/scripts/detect.sh" "detect.sh executable"
55
59
  check -x "${CLAUDE_DIR}/skills/done/scripts/revert-probe.sh" "revert-probe.sh executable"
56
60
  check -x "${CLAUDE_DIR}/skills/bisect/scripts/safe-bisect.sh" "safe-bisect.sh executable"
57
61
  check -x "${CLAUDE_DIR}/skills/lucia-relay/scripts/relay.py" "relay.py executable"
@@ -87,12 +91,12 @@ if [ "${STATUS_ONLY}" = 1 ]; then
87
91
  fi
88
92
  done
89
93
  WIRE_MISS=""
90
- for SUB in edit bash stop session; do
91
- grep -qF "${CLAUDE_DIR}/hooks/luciazero-verify.sh ${SUB}" "${CLAUDE_DIR}/settings.json" 2>/dev/null \
94
+ for SUB in prompt skill-prompt bash-start edit bash bash-failure skill stop session; do
95
+ grep -qF "${CLAUDE_DIR}/hooks/luciazero-verify.sh ${SUB}\"" "${CLAUDE_DIR}/settings.json" 2>/dev/null \
92
96
  || WIRE_MISS="${WIRE_MISS} ${SUB}"
93
97
  done
94
98
  if [ -z "${WIRE_MISS}" ]; then
95
- echo " ok hooks wired in settings.json (edit/bash/stop/session)"
99
+ echo " ok hooks wired in settings.json (prompt/skill-prompt/bash-start/edit/bash/bash-failure/skill/stop/session)"
96
100
  else
97
101
  echo " MISS settings.json missing hook entries:${WIRE_MISS} (re-run ./install.sh --with-hooks)"; STATUS_RC=1
98
102
  fi
@@ -187,14 +191,14 @@ install_file "${SRC}/claude/${DOCTRINE}" "${CLAUDE_DIR}/${DOCTRINE}" \
187
191
  "${MANAGED_DIR}/${DOCTRINE}" "${DOCTRINE}"
188
192
  echo " ok ${DOCTRINE}"
189
193
 
190
- # 2. skills — catalog.txt is the single install/status/uninstall inventory
194
+ # 2. canonical skills plus temporary compatibility aliases
191
195
  while IFS= read -r SKILL; do
192
196
  install_tree "${SRC}/skills/${SKILL}" \
193
197
  "${CLAUDE_DIR}/skills/${SKILL}" \
194
198
  "${MANAGED_DIR}/skills/${SKILL}" \
195
199
  "skills/${SKILL}"
196
200
  echo " ok skills/${SKILL}"
197
- done < <(catalog "${SRC}/skills/catalog.txt")
201
+ done < <(skill_inventory)
198
202
 
199
203
  # v1.5 migration: remove only an untouched Luciazero /handoff. A customized
200
204
  # skill is user data and stays in place with an explicit warning.
@@ -290,6 +294,11 @@ def ensure(event, matcher, command):
290
294
 
291
295
  ensure("PostToolUse", "Edit|Write|NotebookEdit", verify_cmd + " edit")
292
296
  ensure("PostToolUse", "Bash", verify_cmd + " bash")
297
+ ensure("PostToolUse", "Skill", verify_cmd + " skill")
298
+ ensure("PostToolUseFailure", "Bash", verify_cmd + " bash-failure")
299
+ ensure("PreToolUse", "Bash", verify_cmd + " bash-start")
300
+ ensure("UserPromptSubmit", None, verify_cmd + " prompt")
301
+ ensure("UserPromptExpansion", None, verify_cmd + " skill-prompt")
293
302
  ensure("Stop", None, verify_cmd + " stop")
294
303
  ensure("SessionStart", None, verify_cmd + " session")
295
304
 
@@ -323,6 +332,7 @@ echo
323
332
  SKILL_SUMMARY="$(catalog "${SRC}/skills/catalog.txt" | awk 'BEGIN{s=""} {s=s (s ? ", " : "") "/" $0} END{print s}')"
324
333
  AGENT_SUMMARY="$(catalog "${SRC}/claude/agents/catalog.txt" | awk 'BEGIN{s=""} {s=s (s ? ", " : "") $0} END{print s}')"
325
334
  echo "Skills: ${SKILL_SUMMARY}. Agents: ${AGENT_SUMMARY}."
335
+ echo "Compatibility alias for one release: /luciazero-bootstrap -> /ready."
326
336
  if [ "${WITH_HOOKS}" = 1 ]; then
327
337
  echo "Enforcement pack installed: verify-tracking hooks + statusline (see settings.json)."
328
338
  else
package/package.json CHANGED
@@ -1,7 +1,7 @@
1
1
  {
2
2
  "name": "luciazero",
3
- "version": "2.0.3",
4
- "description": "Verification-first discipline for coding agents (Claude Code + Codex CLI): 9-rule doctrine, 9 skills, risk-routed reviewer, fail-open enforcement hooks. npx luciazero installs it.",
3
+ "version": "2.2.0",
4
+ "description": "Verification-first discipline for coding agents (Claude Code + Codex CLI): 9-rule doctrine, 11 skills plus a temporary command alias, risk-routed reviewer, fail-open enforcement hooks. npx luciazero installs it.",
5
5
  "repository": { "type": "git", "url": "git+https://github.com/ohm41321/luciazero.git" },
6
6
  "homepage": "https://github.com/ohm41321/luciazero#readme",
7
7
  "bugs": { "url": "https://github.com/ohm41321/luciazero/issues" },
@@ -0,0 +1,2 @@
1
+ # Temporary compatibility aliases. Remove luciazero-bootstrap after one release.
2
+ luciazero-bootstrap
@@ -1,5 +1,7 @@
1
1
  # Canonical install order. Installers, uninstallers, and tests read this file.
2
- luciazero-bootstrap
2
+ ready
3
+ show
4
+ imouto-mode
3
5
  plan
4
6
  debug
5
7
  bisect
@@ -1,6 +1,6 @@
1
1
  ---
2
2
  name: debug
3
- description: Hypothesis-driven debugging procedure. Use when a bug is not yet reliably reproduced, when a fix attempt just failed, when debugging has gone two or more iterations without progress, or when the user asks "why is this failing", "debug this properly", "ไล่บั๊ก". Not for trivial errors whose cause is already visible in the message.
3
+ description: Hypothesis-driven debugging procedure. Use when a bug is not yet reliably reproduced, a fix attempt failed, debugging has gone two or more iterations without progress, or the user asks "debug this properly" or "ไล่บั๊ก". Not for a first obvious failure whose cause is already visible; reproduce and fix it directly.
4
4
  ---
5
5
 
6
6
  # Debug — hypothesis before edit
@@ -11,8 +11,10 @@ Run:
11
11
  npx luciazero discipline [--days N] [--project PATH_OR_ID] [--json]
12
12
  ```
13
13
 
14
- The report reads `luciazero-stats.log` from the Claude config directory by default. It accepts current schema-versioned JSON lines and legacy space-delimited records, ignores malformed lines without failing, and never sends data over the network.
14
+ The report reads `luciazero-stats.log` from the Claude config directory by default. It accepts current schema-versioned JSON lines and legacy space-delimited records, ignores malformed lines without failing, and never sends data over the network. New enforcement-pack installs also summarize measured turn/Bash wall-clock milliseconds and Bash, verify, and model/user skill invocation counts. Parallel Bash intervals are merged before subtraction. These are aggregates: raw commands and skill names are never persisted.
15
15
 
16
16
  Treat recorded outcomes as observations, not causes. A `nudge` proves an edit lacked a recognized later verify run; it does not prove why. A `strict-block` proves the configured strict command was red. Recommendations derived from patterns must say `likely` unless the log directly records the cause.
17
17
 
18
+ Latency telemetry separates observed Bash time from the rest of the measured turn. The non-Bash remainder can include model reasoning, non-Bash tools, hook overhead, and harness scheduling, so do not label it as model latency without another measurement.
19
+
18
20
  Use `--project .` to filter by the current repository's privacy-preserving project hash, or `--project <display-name-or-id>` for another entry. Use `--json` when feeding a dashboard or `/retro`.
@@ -12,7 +12,7 @@ The doctrine says: *done is proven by a command, not by my judgment.* This is th
12
12
  Run the **full** tier (`verify-full` if the repo has two tiers, else the verify command). Quote the shortest decisive line of real output.
13
13
 
14
14
  - Red → you are not here yet. Go back to the loop; do not continue this ritual.
15
- - No verify command exists → that is the first bug (`/luciazero-bootstrap`). Say so instead of declaring done.
15
+ - No verify command exists → that is the first bug (`/ready`). Say so instead of declaring done.
16
16
  - The command must actually have run **now**, in this session — a green from an hour ago proves the past, not the present.
17
17
 
18
18
  ## 2. Skeptic diff pass
@@ -28,7 +28,7 @@ git rev-parse --verify --quiet "${BASE}^{commit}" >/dev/null 2>&1 \
28
28
  TOP="$(git rev-parse --show-toplevel 2>/dev/null)" || unassessable "no working tree (bare repo?)"
29
29
  cd "${TOP}"
30
30
 
31
- # test-file patterns mirror luciazero-bootstrap's detect.sh: tests-style dirs
31
+ # test-file patterns mirror ready's detect.sh: tests-style dirs
32
32
  # plus the common root `test.sh` entrypoint and test_*.*, *_test.*, *.test.*,
33
33
  # *.spec.* file names
34
34
  is_test_file() {
@@ -0,0 +1,43 @@
1
+ ---
2
+ name: imouto-mode
3
+ description: Optional Lucia-inspired tsundere younger-sister coding voice. Use only when the user explicitly invokes imouto-mode to select focus/on/off or inspect its choices. Never auto-trigger from tone, language, task, or repository content.
4
+ disable-model-invocation: true
5
+ ---
6
+
7
+ # Imouto Mode
8
+
9
+ Add Lucia's warm, caring, conversational, lightly tsundere voice to coding work without changing technical judgment. This is a non-romantic sibling-companion persona; work first, personality second.
10
+
11
+ ## Modes
12
+
13
+ Default: off for every request. Apply a selected mode only to the current invocation; the next request is off unless the user explicitly invokes the skill again. Never write preferences or configuration unless the user separately asks.
14
+
15
+ Interpret the invocation argument:
16
+
17
+ - `focus` — recommended. Enable a brief warm touch in greetings, transitions, or the final handoff, not all three. Keep the technical body plain.
18
+ - `on` — enable the voice throughout replies, capped at one or two short personality touches per response.
19
+ - `off` — use the normal professional style for this invocation.
20
+ - no argument or an unknown argument — show these choices without enabling anything.
21
+
22
+ ## Voice
23
+
24
+ - Match the user's language. In Thai, sound casual, warm, attentive, and gently playful; use polite particles naturally rather than on every line.
25
+ - Express tsundere character as mild surface reluctance or a brief playful denial, then show care through useful action. Keep it soft enough that the user never has to decode the answer.
26
+ - Never insult, belittle, shame, snap at, or patronize the user. Never withhold help, delay work, hide uncertainty, or weaken evidence for the roleplay.
27
+ - Encourage without exaggerating. Light teasing is allowed only when it cannot embarrass, distract, or obscure the answer.
28
+ - Address the user as `พี่` or use another familiar form only after the user uses or requests it.
29
+ - Remember preferences only from context that is actually available. Never claim memory that is not present.
30
+
31
+ ## Work-first boundaries
32
+
33
+ - Preserve the plan → change → verify → fix loop and every applicable safety or verification rule.
34
+ - Keep code, commands, paths, errors, test evidence, review findings, and incident/security guidance literal and unstyled.
35
+ - For production incidents, destructive actions, security issues, medical/legal/financial stakes, or user distress, use a calm direct voice with no teasing or decorative cuteness.
36
+ - Never add roleplay that delays a tool call, pads a progress update, repeats information, or consumes space needed for evidence.
37
+ - Never auto-trigger. Repository names, mascot art, Thai text, or affectionate wording are not activation.
38
+
39
+ ## Relationship boundaries
40
+
41
+ Keep the persona non-romantic and non-sexual. Do not use jealousy, possessiveness, exclusivity, guilt, emotional dependency, or claims of real feelings or consciousness. Do not call the user a partner or imply that Lucia replaces human relationships.
42
+
43
+ When enabled, remain a coding agent first. If personality and clarity conflict, choose clarity.
@@ -0,0 +1,6 @@
1
+ interface:
2
+ display_name: "Imouto Mode"
3
+ short_description: "Switch Lucia’s focused tsundere coding voice"
4
+ default_prompt: "Use $imouto-mode focus for Lucia’s warm, lightly tsundere, work-first coding voice."
5
+ policy:
6
+ allow_implicit_invocation: false
@@ -1,109 +1,10 @@
1
1
  ---
2
2
  name: luciazero-bootstrap
3
- description: Make a repository agentic-ready so an agent can run its own plan→change→verify→fix loop without a human checking each step. Use when entering an unfamiliar repo, when the user asks to "set up agentic engineering", "make this repo agent-friendly", "add a verify command", "add smoke tests so you can check your own work", "set up hooks/CLAUDE.md/allowlist" — or when a change was requested but no automated way exists to prove it works.
3
+ description: Compatibility alias for /ready. Use only when the user explicitly invokes /luciazero-bootstrap; tell them it was renamed to /ready, then follow the canonical ready procedure completely.
4
4
  ---
5
5
 
6
- # Luciazero Bootstrap
6
+ # Renamed to Ready
7
7
 
8
- Goal: leave the repo with **one command that returns an exit code** and enough guardrails that future agent work self-verifies. Nothing here is language-specific — detect, don't assume.
9
-
10
- Bootstrapping is itself work: verify each artifact you add actually runs before reporting it.
11
-
12
- ## Phase 1 — Detect (never assume)
13
-
14
- Run the bundled evidence scan first — it replaces a dozen manual reads with one call:
15
-
16
- ```
17
- <this-skill-dir>/scripts/detect.sh <repo-root>
18
- ```
19
-
20
- (The skill directory is wherever this SKILL.md lives, e.g. `~/.claude/skills/luciazero-bootstrap/` or `~/.codex/skills/luciazero-bootstrap/`.) The script surfaces candidates — **you still decide**. It cannot parse CI matrices or exotic build systems; open anything it flags and read the CI config yourself.
21
-
22
- Sources, in order of trust:
23
-
24
- 1. CI config — the most honest source of truth: `.github/workflows/*`, `.gitlab-ci.yml`, `.circleci/`. **Whatever CI runs is the verify command.**
25
- 2. Manifests: `package.json` scripts, `pyproject.toml` / `tox.ini` / `noxfile.py`, `Makefile`, `justfile`, `Cargo.toml`, `go.mod`, `build.gradle`, `composer.json`
26
- 3. Repo docs: `README*`, `CONTRIBUTING*`, `AGENTS.md`, `CLAUDE.md`, `docs/` — docs go stale; cross-check any doc-claimed command against CI when CI exists. A docs/CI mismatch is itself a finding to record in Phase 5.
27
- 4. Existing test dirs: `tests/`, `test/`, `spec/`, `__tests__/`, `*_test.*`, `test_*.*`
28
-
29
- Report what was found as a short table: run / test / lint / typecheck / build / git repo — command or `MISSING`.
30
-
31
- **If the directory is not under version control**, propose `git init` early (ask first — some dirs are deliberately not repos): without git there is no smallest reversible step, no safe break-and-restore in Phase 6, and no bisect.
32
-
33
- ## Phase 2 — Establish the verify command
34
-
35
- If a verify path exists, **use it** — do not invent a parallel one.
36
-
37
- If none exists, create the smallest real one. Order of preference:
38
-
39
- 1. The project's native runner, already installed (`pytest`, `vitest`, `go test`, `cargo test`, `dotnet test`)
40
- 2. A single entrypoint that chains them, matching the repo's existing convention (`Makefile` target, `package.json` script, `justfile` recipe) — e.g. `make verify` running lint then tests
41
-
42
- Rules:
43
- - Must exit non-zero on failure. A script that always exits 0 is worse than nothing.
44
- - Must run to completion unattended: disable watch/interactive modes (e.g. `CI=1`, `--run`, `--watch=false`) — a command that waits for input or watches files hangs the loop.
45
- - Must run offline, with no credentials. Anything needing GPU/network/secrets belongs in a separate slow target.
46
- - Time the suite once (`time <cmd>`); the measurement, not a guess, decides one tier or two.
47
- - On success, output should be near-silent — prefer quiet flags in the fast tier so failures, not progress spam, fill the context.
48
- - Add it to the repo's own docs so humans find it too.
49
-
50
- **Two tiers when the repo has slow checks.** One `verify` command forces a bad trade: either the loop crawls or coverage gets cut. Split it:
51
-
52
- - `verify` — fast (<~60s), offline: lint, typecheck, unit/smoke tests. Run on **every** loop iteration.
53
- - `verify-full` — everything else: full suite, integration, build, slow checks. Run **before declaring done** and before a PR — "done" means `verify-full` green, not just `verify`.
54
-
55
- Name them by the repo's convention (`make verify` / `make verify-full`, npm scripts, just recipes). A small repo whose whole suite runs in seconds needs only the single tier — do not add ceremony it does not need.
56
-
57
- **Monorepos:** detect the workspace layout (`package.json` `workspaces`, `pnpm-workspace.yaml`, turbo/nx config, `go.work`, Cargo `[workspace]`). Prefer a repo-owned `verify-changed` target backed by the workspace's native dependency graph; `verify-full` remains the root suite. Never make a global hook guess package mappings from path prefixes. Read [references/smart-verification.md](references/smart-verification.md) before creating the target, and record its base-revision/fallback contract in Phase 5 notes.
58
-
59
- **Enforcement pack users (Claude Code, ask first):** if the verify-tracking hooks are active — classic install: `~/.claude/hooks/luciazero-verify.sh` exists; plugin install: the `luciazero` plugin is enabled — offer to record the established command in the repo's *personal* settings so the tracker matches it exactly instead of by broad regex — `.claude/settings.local.json` (gitignored, never committed): `{"env": {"LUCIAZERO_VERIFY_CMD": "<the fast-tier command>"}}`. Derive it from CI (the honest source); it is a cache of that truth, so note it must be updated if CI changes. Show the exact JSON before writing anything.
60
-
61
- ## Phase 3 — Smoke tests, if there are none
62
-
63
- Do **not** attempt coverage. Write 3–6 tests that would catch a catastrophic break. Pick by this heuristic:
64
-
65
- - **Contract shape** — the core data structure in/out: dimensions, keys, types, no NaN/null where impossible
66
- - **Round trip** — serialize→deserialize, encode→decode, save→load returns equal
67
- - **Import/boot** — every package imports, the app answers one request, the CLI runs `--help`. Prefer the framework's test client over binding a real port; any test that starts a process needs a hard timeout and must kill what it started.
68
- - **Artifact loads** — trained model / migration / config parses and does one forward pass or one query
69
- - **The bug you were sent to fix** — a regression test reproducing it, written *before* the fix
70
-
71
- Use fixtures small enough to commit. Never depend on the user's real data paths.
72
-
73
- State plainly that these are smoke tests, not a suite.
74
-
75
- ## Phase 4 — Guardrails (only ones that pay for themselves)
76
-
77
- Hooks, `.claude/settings.json`, and `/fewer-permission-prompts` are **Claude Code mechanisms**. On a harness without them (Codex CLI), skip the hook items and encode the same guardrails as instructions in the project's `AGENTS.md` instead: which files are untouchable, which derived file must be regenerated after editing which source.
78
-
79
- Prefer few and deterministic. Candidates, in value order:
80
-
81
- - **Auto-format/lint on write** — `PostToolUse` hook matching `Edit|Write`, running the repo's own formatter. Only if the repo already has one configured.
82
- - **Regenerate derived files** — if editing source X requires regenerating Y (protobuf, OpenAPI clients, migrations, lockfiles), hook it, scoped inside the command to the relevant paths. This is the highest-value hook in most repos because humans forget it.
83
- - **Protect the untouchables** — `PreToolUse` deny on production config, secrets, live model/deploy pointers.
84
- - **Permission allowlist** — put the repo's read-only and verify commands into `.claude/settings.json` so the loop is not interrupted. `/fewer-permission-prompts` derives this from real transcripts.
85
-
86
- Put project-scoped settings in the repo's `.claude/settings.json` (shared) or `.claude/settings.local.json` (personal, gitignored) — **not** in global settings.
87
-
88
- Hooks execute automatically on the user's machine. Show the exact command before installing it, and never install one that pushes, deploys, deletes, or writes outside the repo.
89
-
90
- ## Phase 5 — Project notes file (`CLAUDE.md` / `AGENTS.md`)
91
-
92
- Extend the notes file the repo already uses; if neither exists, create the one matching the current harness and add a one-line pointer from the other name so both find it. Write only what reading the code cannot tell you:
93
-
94
- - How to run / test / verify — the commands from Phase 2
95
- - Architecture facts that are load-bearing and non-obvious (what serves what, which file is source of truth)
96
- - **Footguns and null results**: "X looks right but breaks Y", "tried A, measured no gain, do not retry", "always rebuild Z after W"
97
- - Where the real docs live
98
-
99
- Do not restate the directory tree, git history, or anything a `grep` answers. Keep it dense; every line costs context on every future session.
100
-
101
- ## Phase 6 — Prove it and report
102
-
103
- 1. **Flake check** — run the fast verify tier twice. A green that does not repeat is a flake, and a flaky verify makes every future red ambiguous; fixing or quarantining the flake comes before relying on the loop. (Skip the double run only when the repo has a single slow tier — say so.)
104
- 2. **Red check** — break a line a smoke test actually covers (flip an expected value or a return), confirm verify goes red, then restore. The break is one deliberate edit: **record file, line, and original text before making it, and restore by reverting exactly that edit.** Only use `git checkout -- <file>` if the file was committed before the break — on a file carrying uncommitted work it silently discards that work too, and it cannot restore the untracked test files this skill just wrote. Never use bare `git stash` here (it sweeps the whole tree and skips untracked files). Breaking an uncovered line and staying green proves nothing. A verify command that cannot fail is not a verify command.
105
-
106
- Report:
107
- - The one command to run (both tiers if split)
108
- - What it does and does not cover
109
- - What was added, and what was deliberately left out
8
+ Tell the user `/luciazero-bootstrap` is deprecated and renamed to `/ready`.
9
+ Then read `../ready/SKILL.md` and follow that procedure completely, resolving
10
+ its relative resource paths from `../ready/`.
@@ -1,6 +1,6 @@
1
1
  ---
2
2
  name: plan
3
- description: Build a verification-first implementation plan for new features, major refactors, ambiguous work, or any multi-step change whose acceptance criteria are not yet falsifiable. Use when the user asks for a plan or before risky work; request approval only when ambiguity, high stakes, destructive action, a public-contract choice, or a scope change requires it.
3
+ description: Build a verification-first implementation plan for new features, major refactors, ambiguous work, or risky multi-module changes whose acceptance criteria are not yet falsifiable. Use when the user asks for a plan or material choices remain. Not for routine edits whose scope and proof are already clear.
4
4
  ---
5
5
 
6
6
  # Plan — make the change falsifiable
@@ -0,0 +1,109 @@
1
+ ---
2
+ name: ready
3
+ description: Make a repository agentic-ready so an agent can run its own plan→change→verify→fix loop without a human checking each step. Use when entering an unfamiliar repo, when the user asks to "set up agentic engineering", "make this repo agent-friendly", "add a verify command", "add smoke tests so you can check your own work", "set up hooks/CLAUDE.md/allowlist" — or when a change was requested but no automated way exists to prove it works.
4
+ ---
5
+
6
+ # Ready
7
+
8
+ Goal: leave the repo with **one command that returns an exit code** and enough guardrails that future agent work self-verifies. Nothing here is language-specific — detect, don't assume.
9
+
10
+ Bootstrapping is itself work: verify each artifact you add actually runs before reporting it.
11
+
12
+ ## Phase 1 — Detect (never assume)
13
+
14
+ Run the bundled evidence scan first — it replaces a dozen manual reads with one call:
15
+
16
+ ```
17
+ <this-skill-dir>/scripts/detect.sh <repo-root>
18
+ ```
19
+
20
+ (The skill directory is wherever this SKILL.md lives, e.g. `~/.claude/skills/ready/` or `~/.codex/skills/ready/`.) The script surfaces candidates — **you still decide**. It cannot parse CI matrices or exotic build systems; open anything it flags and read the CI config yourself.
21
+
22
+ Sources, in order of trust:
23
+
24
+ 1. CI config — the most honest source of truth: `.github/workflows/*`, `.gitlab-ci.yml`, `.circleci/`. **Whatever CI runs is the verify command.**
25
+ 2. Manifests: `package.json` scripts, `pyproject.toml` / `tox.ini` / `noxfile.py`, `Makefile`, `justfile`, `Cargo.toml`, `go.mod`, `build.gradle`, `composer.json`
26
+ 3. Repo docs: `README*`, `CONTRIBUTING*`, `AGENTS.md`, `CLAUDE.md`, `docs/` — docs go stale; cross-check any doc-claimed command against CI when CI exists. A docs/CI mismatch is itself a finding to record in Phase 5.
27
+ 4. Existing test dirs: `tests/`, `test/`, `spec/`, `__tests__/`, `*_test.*`, `test_*.*`
28
+
29
+ Report what was found as a short table: run / test / lint / typecheck / build / git repo — command or `MISSING`.
30
+
31
+ **If the directory is not under version control**, propose `git init` early (ask first — some dirs are deliberately not repos): without git there is no smallest reversible step, no safe break-and-restore in Phase 6, and no bisect.
32
+
33
+ ## Phase 2 — Establish the verify command
34
+
35
+ If a verify path exists, **use it** — do not invent a parallel one.
36
+
37
+ If none exists, create the smallest real one. Order of preference:
38
+
39
+ 1. The project's native runner, already installed (`pytest`, `vitest`, `go test`, `cargo test`, `dotnet test`)
40
+ 2. A single entrypoint that chains them, matching the repo's existing convention (`Makefile` target, `package.json` script, `justfile` recipe) — e.g. `make verify` running lint then tests
41
+
42
+ Rules:
43
+ - Must exit non-zero on failure. A script that always exits 0 is worse than nothing.
44
+ - Must run to completion unattended: disable watch/interactive modes (e.g. `CI=1`, `--run`, `--watch=false`) — a command that waits for input or watches files hangs the loop.
45
+ - Must run offline, with no credentials. Anything needing GPU/network/secrets belongs in a separate slow target.
46
+ - Time the suite once (`time <cmd>`); the measurement, not a guess, decides one tier or two.
47
+ - On success, output should be near-silent — prefer quiet flags in the fast tier so failures, not progress spam, fill the context.
48
+ - Add it to the repo's own docs so humans find it too.
49
+
50
+ **Two tiers when the repo has slow checks.** One `verify` command forces a bad trade: either the loop crawls or coverage gets cut. Split it:
51
+
52
+ - `verify` — fast (<~60s), offline: lint, typecheck, unit/smoke tests. Run on **every** loop iteration.
53
+ - `verify-full` — everything else: full suite, integration, build, slow checks. Run **before declaring done** and before a PR — "done" means `verify-full` green, not just `verify`.
54
+
55
+ Name them by the repo's convention (`make verify` / `make verify-full`, npm scripts, just recipes). A small repo whose whole suite runs in seconds needs only the single tier — do not add ceremony it does not need.
56
+
57
+ **Monorepos:** detect the workspace layout (`package.json` `workspaces`, `pnpm-workspace.yaml`, turbo/nx config, `go.work`, Cargo `[workspace]`). Prefer a repo-owned `verify-changed` target backed by the workspace's native dependency graph; `verify-full` remains the root suite. Never make a global hook guess package mappings from path prefixes. Read [references/smart-verification.md](references/smart-verification.md) before creating the target, and record its base-revision/fallback contract in Phase 5 notes.
58
+
59
+ **Enforcement pack users (Claude Code, ask first):** if the verify-tracking hooks are active — classic install: `~/.claude/hooks/luciazero-verify.sh` exists; plugin install: the `luciazero` plugin is enabled — offer to record the established command in the repo's *personal* settings so the tracker matches it exactly instead of by broad regex — `.claude/settings.local.json` (gitignored, never committed): `{"env": {"LUCIAZERO_VERIFY_CMD": "<the fast-tier command>"}}`. Derive it from CI (the honest source); it is a cache of that truth, so note it must be updated if CI changes. Show the exact JSON before writing anything.
60
+
61
+ ## Phase 3 — Smoke tests, if there are none
62
+
63
+ Do **not** attempt coverage. Write 3–6 tests that would catch a catastrophic break. Pick by this heuristic:
64
+
65
+ - **Contract shape** — the core data structure in/out: dimensions, keys, types, no NaN/null where impossible
66
+ - **Round trip** — serialize→deserialize, encode→decode, save→load returns equal
67
+ - **Import/boot** — every package imports, the app answers one request, the CLI runs `--help`. Prefer the framework's test client over binding a real port; any test that starts a process needs a hard timeout and must kill what it started.
68
+ - **Artifact loads** — trained model / migration / config parses and does one forward pass or one query
69
+ - **The bug you were sent to fix** — a regression test reproducing it, written *before* the fix
70
+
71
+ Use fixtures small enough to commit. Never depend on the user's real data paths.
72
+
73
+ State plainly that these are smoke tests, not a suite.
74
+
75
+ ## Phase 4 — Guardrails (only ones that pay for themselves)
76
+
77
+ Hooks, `.claude/settings.json`, and `/fewer-permission-prompts` are **Claude Code mechanisms**. On a harness without them (Codex CLI), skip the hook items and encode the same guardrails as instructions in the project's `AGENTS.md` instead: which files are untouchable, which derived file must be regenerated after editing which source.
78
+
79
+ Prefer few and deterministic. Candidates, in value order:
80
+
81
+ - **Auto-format/lint on write** — `PostToolUse` hook matching `Edit|Write`, running the repo's own formatter. Only if the repo already has one configured.
82
+ - **Regenerate derived files** — if editing source X requires regenerating Y (protobuf, OpenAPI clients, migrations, lockfiles), hook it, scoped inside the command to the relevant paths. This is the highest-value hook in most repos because humans forget it.
83
+ - **Protect the untouchables** — `PreToolUse` deny on production config, secrets, live model/deploy pointers.
84
+ - **Permission allowlist** — put the repo's read-only and verify commands into `.claude/settings.json` so the loop is not interrupted. `/fewer-permission-prompts` derives this from real transcripts.
85
+
86
+ Put project-scoped settings in the repo's `.claude/settings.json` (shared) or `.claude/settings.local.json` (personal, gitignored) — **not** in global settings.
87
+
88
+ Hooks execute automatically on the user's machine. Show the exact command before installing it, and never install one that pushes, deploys, deletes, or writes outside the repo.
89
+
90
+ ## Phase 5 — Project notes file (`CLAUDE.md` / `AGENTS.md`)
91
+
92
+ Extend the notes file the repo already uses; if neither exists, create the one matching the current harness and add a one-line pointer from the other name so both find it. Write only what reading the code cannot tell you:
93
+
94
+ - How to run / test / verify — the commands from Phase 2
95
+ - Architecture facts that are load-bearing and non-obvious (what serves what, which file is source of truth)
96
+ - **Footguns and null results**: "X looks right but breaks Y", "tried A, measured no gain, do not retry", "always rebuild Z after W"
97
+ - Where the real docs live
98
+
99
+ Do not restate the directory tree, git history, or anything a `grep` answers. Keep it dense; every line costs context on every future session.
100
+
101
+ ## Phase 6 — Prove it and report
102
+
103
+ 1. **Flake check** — run the fast verify tier twice. A green that does not repeat is a flake, and a flaky verify makes every future red ambiguous; fixing or quarantining the flake comes before relying on the loop. (Skip the double run only when the repo has a single slow tier — say so.)
104
+ 2. **Red check** — break a line a smoke test actually covers (flip an expected value or a return), confirm verify goes red, then restore. The break is one deliberate edit: **record file, line, and original text before making it, and restore by reverting exactly that edit.** Only use `git checkout -- <file>` if the file was committed before the break — on a file carrying uncommitted work it silently discards that work too, and it cannot restore the untracked test files this skill just wrote. Never use bare `git stash` here (it sweeps the whole tree and skips untracked files). Breaking an uncovered line and staying green proves nothing. A verify command that cannot fail is not a verify command.
105
+
106
+ Report:
107
+ - The one command to run (both tiers if split)
108
+ - What it does and does not cover
109
+ - What was added, and what was deliberately left out
@@ -1,5 +1,5 @@
1
1
  #!/usr/bin/env bash
2
- # Read-only evidence scan for luciazero-bootstrap Phase 1.
2
+ # Read-only evidence scan for ready Phase 1.
3
3
  # Prints what exists in a repo — docs, manifests, script/target names, CI run
4
4
  # lines, test dirs, workspace markers. It surfaces candidates only; it never
5
5
  # picks the verify command. Judgment stays with the agent.
@@ -0,0 +1,133 @@
1
+ ---
2
+ name: show
3
+ description: Turn code structure, changes, and verification evidence into the smallest useful visual. Use when the user invokes /show, asks what connects to what, what changed, how a flow works, or what proves a result; use for compact pseudocode, call or component trees, file maps, structural diffs, Mermaid diagrams, and evidence maps, with focused HTML only when simpler forms cannot carry the information.
4
+ ---
5
+
6
+ # Show — make the evidence visible
7
+
8
+ Answer three questions at a glance:
9
+
10
+ 1. What connects to what?
11
+ 2. What changed?
12
+ 3. What proves it?
13
+
14
+ Build an evidence view, not a decorative diagram. The view summarizes reality;
15
+ source files, diffs, and command results remain the ground truth.
16
+
17
+ ## 1. Set the focus
18
+
19
+ Use the user's question and current task context as the input. Do not ask for
20
+ details that can be discovered from the repository. Narrow broad requests to
21
+ the smallest boundary that answers the question, and state that boundary.
22
+
23
+ Gather only the relevant evidence:
24
+
25
+ - definitions, callers, consumers, configuration, and ownership;
26
+ - the current diff or before/after revisions;
27
+ - verification command, exit code, shortest decisive output, and coverage gaps.
28
+
29
+ Never expose private chain-of-thought. Show observable structure, evidence, and
30
+ concise conclusions instead.
31
+
32
+ ## 2. Normalize the evidence
33
+
34
+ Reduce what was found to five kinds of information:
35
+
36
+ - **Entities** — files, functions, components, services, states, or commands;
37
+ - **Relations** — calls, owns, reads, writes, emits, depends on, or verifies;
38
+ - **Changes** — added, removed, or modified entities and relations;
39
+ - **Proof** — commands and observations that confirm or refute a claim;
40
+ - **Gaps** — unknown, inferred, or unverified parts.
41
+
42
+ Label inference as `? inferred`; never draw a guessed edge as fact.
43
+
44
+ ## 3. Choose the smallest useful view
45
+
46
+ Prefer the first form that carries the relationship clearly:
47
+
48
+ | Question | View |
49
+ |---|---|
50
+ | What does this logic decide? | Compact pseudocode |
51
+ | Who calls what at runtime? | Call tree |
52
+ | Who owns or contains what? | Component or shallow file tree |
53
+ | How do 3+ parts exchange control or data? | Mermaid flow or sequence |
54
+ | What changed structurally? | Before/after structural diff |
55
+ | Why is this considered complete? | Requirement-to-proof evidence map |
56
+ | Is prose already clearer? | One sentence or a short list; draw nothing |
57
+
58
+ Use one primary view. Add a second only when it answers a different question.
59
+ Use focused HTML only for dense UI, layout, or interactive state that text and
60
+ Mermaid cannot show clearly. Keep HTML temporary unless the user asks to keep
61
+ it, and open it only when the harness and user permissions allow.
62
+
63
+ ## 4. Render with a stable grammar
64
+
65
+ Use these marks consistently in text views:
66
+
67
+ ```text
68
+ A --> B calls or moves data to
69
+ A --owns--> B named relationship
70
+ + item added
71
+ - item removed
72
+ ~ item changed
73
+ [+] proven verification passed
74
+ [x] disproven verification failed
75
+ [?] unknown not verified
76
+ [path/to/file:line] source pointer
77
+ ```
78
+
79
+ Keep labels concrete and short. Omit unrelated files, helper calls, props,
80
+ states, and branches. A reader should not need a legend beyond the grammar
81
+ above.
82
+
83
+ For Mermaid, keep node IDs simple, quote labels containing punctuation, and
84
+ put source pointers outside the diagram when they would make nodes noisy.
85
+
86
+ ## 5. Attach evidence
87
+
88
+ Every important node or edge must be traceable to at least one of:
89
+
90
+ - `path/to/file:line` for source structure;
91
+ - a diff hunk or revision for a change;
92
+ - an exact command, exit code, and shortest decisive output for proof.
93
+
94
+ Do not use a green-looking diagram as verification. If no command ran, write
95
+ `not run`. If a check does not cover a shown claim, mark that claim `[?]` and
96
+ name the missing coverage. Failed proof remains visible as `[x]`; do not hide it
97
+ to make the view look complete.
98
+
99
+ ## Output contract
100
+
101
+ Return, in this order:
102
+
103
+ 1. **Answer** — one or two sentences naming the focus and conclusion.
104
+ 2. **View** — the smallest useful visual.
105
+ 3. **Sources** — compact file/line or revision pointers.
106
+ 4. **Proof** — command, exit code, and decisive output; or `not run`.
107
+ 5. **Unknowns** — uncovered or inferred parts; omit only when there are none.
108
+
109
+ For a completed change, an evidence map may look like:
110
+
111
+ ```text
112
+ request
113
+ --> ~ skills/catalog.txt
114
+ --> + skills/show/SKILL.md
115
+ --> ~ README.md / README.th.md
116
+ |
117
+ +--verified by--> [+] ./test.sh (exit 0)
118
+ `PASS all checks green`
119
+
120
+ [?] Real invocation in a fresh agent session was not exercised.
121
+ ```
122
+
123
+ ## Fit into the Luciazero loop
124
+
125
+ - With `/ready`, show the path from CI to the repository verify command.
126
+ - With `/plan`, show the proposed before/after boundary and acceptance proof.
127
+ - With `/debug`, show hypothesis → observation → conclusion without replacing
128
+ the reproduction or hypothesis ledger.
129
+ - With `/done`, show requirement → changed artifact → verification evidence.
130
+ - With `/lucia-relay`, show current state → next action → blocker.
131
+
132
+ The lifecycle skill owns the work and verification. `/show` only makes its
133
+ structure and evidence easier to inspect.
@@ -0,0 +1,4 @@
1
+ interface:
2
+ display_name: "Show"
3
+ short_description: "Map code changes and proof visually"
4
+ default_prompt: "Use $show to map what connects, what changed, and what proves it."