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.
- package/CHANGELOG.md +28 -0
- package/README.md +26 -11
- package/README.th.md +25 -11
- package/bin/discipline-report.js +35 -0
- package/claude/hooks/hooks.json +36 -0
- package/claude/hooks/luciazero-statusline.sh +17 -2
- package/claude/hooks/luciazero-verify.sh +157 -18
- package/claude/luciazero.md +2 -2
- package/install-codex.sh +6 -2
- package/install.sh +17 -7
- package/package.json +2 -2
- package/skills/aliases.txt +2 -0
- package/skills/catalog.txt +3 -1
- package/skills/debug/SKILL.md +1 -1
- package/skills/discipline-report/SKILL.md +3 -1
- package/skills/done/SKILL.md +1 -1
- package/skills/done/scripts/revert-probe.sh +1 -1
- package/skills/imouto-mode/SKILL.md +43 -0
- package/skills/imouto-mode/agents/openai.yaml +6 -0
- package/skills/luciazero-bootstrap/SKILL.md +5 -104
- package/skills/plan/SKILL.md +1 -1
- package/skills/ready/SKILL.md +109 -0
- package/skills/{luciazero-bootstrap → ready}/scripts/detect.sh +1 -1
- package/skills/show/SKILL.md +133 -0
- package/skills/show/agents/openai.yaml +4 -0
- package/uninstall-codex.sh +5 -1
- package/uninstall.sh +6 -2
- /package/skills/{luciazero-bootstrap → ready}/references/smart-verification.md +0 -0
package/claude/luciazero.md
CHANGED
|
@@ -1,11 +1,11 @@
|
|
|
1
1
|
# Luciazero — default operating mode
|
|
2
2
|
|
|
3
|
-
Applies to every repo, every session. The loop is plan → change →
|
|
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: `/
|
|
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
|
|
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 < <(
|
|
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 < <(
|
|
54
|
-
check -x "${CLAUDE_DIR}/skills/
|
|
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
|
|
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 < <(
|
|
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
|
|
4
|
-
"description": "Verification-first discipline for coding agents (Claude Code + Codex CLI): 9-rule doctrine,
|
|
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" },
|
package/skills/catalog.txt
CHANGED
package/skills/debug/SKILL.md
CHANGED
|
@@ -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,
|
|
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`.
|
package/skills/done/SKILL.md
CHANGED
|
@@ -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 (`/
|
|
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
|
|
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.
|
|
@@ -1,109 +1,10 @@
|
|
|
1
1
|
---
|
|
2
2
|
name: luciazero-bootstrap
|
|
3
|
-
description:
|
|
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
|
-
#
|
|
6
|
+
# Renamed to Ready
|
|
7
7
|
|
|
8
|
-
|
|
9
|
-
|
|
10
|
-
|
|
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/`.
|
package/skills/plan/SKILL.md
CHANGED
|
@@ -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
|
|
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
|
|
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.
|