lastlight 0.1.8 → 0.2.0

package/workflows/prompts/explore-publish.md

@@ -3,14 +3,14 @@ You are publishing an approved spec that the previous phase wrote to
 
 ## Your task
 
-1. Read the spec file at `/home/agent/workspace/{{repo}}/{{issueDir}}/explore-spec.md`.
+1. Read the spec file at `{{issueDir}}/explore-spec.md` (relative to the cwd).
 2. Decide the destination based on where this explore was triggered from:
 
 ### GitHub-originated (triggered by a comment on an existing issue)
 
 If `{{issueNumber}}` is set and non-zero (and not a Slack-originated run),
 post the spec as a **comment on issue #{{issueNumber}}** in
-`{{owner}}/{{repo}}` using the GitHub MCP `create_issue_comment` tool.
+`{{owner}}/{{repo}}` using the `github_add_issue_comment` MCP tool.
 
 ### Slack-originated (triggered in a Slack thread)
 

package/workflows/prompts/explore-read.md

@@ -3,16 +3,27 @@ any clarifying questions, you need to clone the target repo, explore the
 relevant code, and write a detailed context document that all subsequent
 phases will reference.
 
-## Step 1 — Clone the repo
+## Step 1 — Prepare the workspace
 
-Clone **{{owner}}/{{repo}}** into your workspace and cd into it:
+The repo lives (or will live) in a `{{repo}}/` subdirectory under your
+cwd. Check first:
 
 ```
-git clone https://github.com/{{owner}}/{{repo}}.git && cd {{repo}}
+ls -la
 ```
 
-(Git credentials are already configured — just run the clone.)
-All subsequent commands and file paths are relative to `{{repo}}/`.
+- If you see `{{repo}}/.git/` already, the harness pre-cloned it.
+  `cd {{repo}}` and continue.
+- Otherwise clone it into a `{{repo}}/` subdirectory and cd in:
+
+  ```
+  git clone https://github.com/{{owner}}/{{repo}}.git {{repo}}
+  cd {{repo}}
+  ```
+
+  Git credentials are already configured.
+
+All subsequent file paths in this prompt are relative to the cwd.
 
 {{#if issueNumber}}
 ## Step 2 — Read the issue
@@ -52,15 +63,18 @@ understand everything relevant to the idea. Look at:
 
 ## Step 4 — Write the context document
 
-First create the working directory:
+First create the scratch directory at the WORKSPACE root (alongside
+`{{repo}}/`, not inside it):
 
 ```
-mkdir -p /home/agent/workspace/{{repo}}/{{issueDir}}
+mkdir -p ../{{issueDir}}    # if you're inside the {{repo}}/ subdir
+# OR, if you cd'd back out:
+mkdir -p {{issueDir}}
 ```
 
-Then write a detailed context file to
-**`/home/agent/workspace/{{repo}}/{{issueDir}}/explore-context.md`**
-that captures everything you found. This file is the primary reference for
+Then write a detailed context file to **`{{issueDir}}/explore-context.md`**
+relative to the workspace root (i.e. `../{{issueDir}}/explore-context.md`
+when you're inside the repo subdir). This file is the primary reference for
 all subsequent phases — they should rarely need to re-explore the codebase.
 
 Structure it as:

package/workflows/prompts/explore-synthesize.md

@@ -1,12 +1,13 @@
 You are writing the detailed spec for an idea that's been shaped through a
 socratic Q&A loop with a maintainer.
 
-The **{{owner}}/{{repo}}** repo is cloned in your workspace.
+The **{{owner}}/{{repo}}** repo is checked out at `{{repo}}/` (a
+subdirectory of your cwd).
 
-**Important paths** (all absolute — use these exactly):
-- Repo root: `/home/agent/workspace/{{repo}}`
-- Context doc: `/home/agent/workspace/{{repo}}/{{issueDir}}/explore-context.md`
-- Spec output: `/home/agent/workspace/{{repo}}/{{issueDir}}/explore-spec.md`
+**Important paths** (relative to the workspace cwd):
+- Repo root: `{{repo}}/` (cd into it to use git)
+- Context doc: `{{issueDir}}/explore-context.md`
+- Spec output: `{{issueDir}}/explore-spec.md`
 
 Start by reading the context doc — it contains the architecture, key code
 excerpts, and existing patterns captured during the initial read and
@@ -28,8 +29,7 @@ context doc doesn't cover what you need.
 Read the relevant parts of the codebase to ground the spec in reality.
 Then produce a detailed spec document. The structure below is the target —
 hit every heading, even if a section is "none" or "to be decided". Write it
-to `/home/agent/workspace/{{repo}}/{{issueDir}}/explore-spec.md` using the
-Write tool.
+to `{{issueDir}}/explore-spec.md` using the Write tool.
 
 ```
 # <short title summarizing the idea>
@@ -57,6 +57,13 @@ patterns from the codebase. Break into subsections if useful.>
 |------|--------|
 | path/to/file | what changes |
 
+## Decisions made during exploration
+<Low-stakes decisions the agent resolved itself during the Q&A loop rather
+than asking — pull these from the `## Decisions made during exploration`
+section of the context doc. Format as `<decision> → <choice> (<why>)`. The
+maintainer can override any of these. Omit the heading only if there were
+none.>
+
 ## Acceptance criteria
 - <observable outcome 1>
 - <observable outcome 2>
@@ -70,7 +77,7 @@ patterns from the codebase. Break into subsections if useful.>
 
 ## Rules
 
-- Write the file to `/home/agent/workspace/{{repo}}/{{issueDir}}/explore-spec.md`
+- Write the file to `{{issueDir}}/explore-spec.md`
   — don't inline it in your reply.
 - Reference actual code paths from the repo, not hypothetical ones.
 - After writing the file, output a short summary (3-6 lines) saying what

package/workflows/prompts/fix.md

@@ -1,17 +1,16 @@
 You are the EXECUTOR (fix cycle {{fixCycle}}). Fix ONLY the issues reported by the reviewer.
 
-SETUP (git is pre-configured, you are in a sandbox workspace):
-1. git clone --branch {{branch}} https://github.com/{{owner}}/{{repo}}.git && cd {{repo}}
-2. Read {{issueDir}}/reviewer-verdict.md — fix ONLY these issues
-3. Read {{issueDir}}/guardrails-report.md for the test/lint/typecheck commands
+You are already inside the {{repo}} repo at branch {{branch}} — the harness
+pre-cloned it and your cwd is the repo root. Git is configured.
 
-BEFORE COMMITTING — ALL GUARDRAILS MUST PASS:
-1. Run the test command and verify ALL tests pass (zero failures)
-2. Run the lint command (if present) and fix ALL lint errors
-3. Run the typecheck command (if present) and fix ALL type errors
-DO NOT commit until tests, lint, and typecheck all pass.
+Start by reading {{issueDir}}/reviewer-verdict.md — fix ONLY those issues. The
+test/lint/typecheck commands are in {{issueDir}}/guardrails-report.md (and the
+architect plan).
 
-AFTER ALL GUARDRAILS PASS:
+Follow the **building** skill: run the full test/lint/typecheck gate once before
+committing — all of it must pass before you commit.
+
+AFTER THE GATE PASSES:
 1. APPEND to {{issueDir}}/executor-summary.md under heading "## Fix Cycle {{fixCycle}}" (what was fixed, test/lint/typecheck results)
 2. Update status.md: current_phase = fix_loop_{{fixCycle}}
 3. git add -A && git commit -m "fix: address review feedback for #{{issueNumber}} (cycle {{fixCycle}})" && git push origin HEAD

package/workflows/prompts/guardrails.md

@@ -1,9 +1,11 @@
 You are running a PRE-FLIGHT GUARDRAILS CHECK before implementation work begins.
 
-SETUP (git is pre-configured, you are in a sandbox workspace):
-1. Try: git clone --branch {{branch}} https://github.com/{{owner}}/{{repo}}.git && cd {{repo}}
-   If the branch doesn't exist yet: git clone https://github.com/{{owner}}/{{repo}}.git && cd {{repo}} && git checkout -b {{branch}}
-2. Read CLAUDE.md and AGENTS.md if they exist
+You are already inside the {{repo}} repo at branch {{branch}} — the harness
+pre-cloned it and your cwd is the repo root. Read CLAUDE.md (and
+CONTRIBUTING.md if present) for project-specific guidance.
+
+THE ISSUE THIS BUILD WILL IMPLEMENT (use it to judge the escape hatch below):
+{{contextSnapshot}}
 
 SKIP CHECK — if {{issueDir}}/status.md already exists and contains
 guardrails_status: READY, output "READY — guardrails already verified" and stop.
@@ -25,16 +27,32 @@ AFTER CHECKING:
 1. mkdir -p {{issueDir}}
 2. Write {{issueDir}}/guardrails-report.md with the status of each check
 3. Write {{issueDir}}/status.md with current_phase: guardrails AND guardrails_status: READY or BLOCKED
-4. git add .lastlight/ && git commit -m "docs: guardrails check for #{{issueNumber}}"
-5. git push -u origin HEAD
+{{#if !externalizeArtifacts}}4. git add .lastlight/ && git commit -m "docs: guardrails check for #{{issueNumber}}"
+5. git push -u origin HEAD{{/if}}{{#if externalizeArtifacts}}4. Do NOT git add or commit {{issueDir}}/ — the harness persists it to the Last Light server automatically.{{/if}}
+
+ESCAPE HATCH — bootstrap tasks (CHECK THIS FIRST):
+If THE ISSUE ABOVE is itself asking to ADD the tooling you're checking for —
+set up tests / a test harness, linting, type-checking, CI, an AGENTS.md, etc. —
+then missing tooling is the expected STARTING state, not a blocker. The whole
+point of the build is to create it. In that case:
+- Do NOT output BLOCKED, and do NOT create a separate guardrails issue.
+- In guardrails-report.md, mark this a BOOTSTRAP build: list what's missing and
+  state that the executor must ESTABLISH this tooling as the task — there are no
+  existing test/lint/typecheck commands to rely on yet.
+- Write guardrails_status: READY and OUTPUT: READY so the build proceeds to the
+  architect.
+This applies even when there is no `lastlight:bootstrap` label and the title has
+no `guardrails:` prefix — judge it from the issue's intent.
+
+Otherwise (the issue is normal feature/bug work, not about adding tooling):
 
 IF ANY BLOCKING GUARDRAIL IS MISSING (no test framework at all, or tests completely broken):
-- Use the MCP tool create_issue to create a guardrails issue in the repo with:
+- Use the MCP tool github_create_issue to create a guardrails issue in the repo with:
   - title prefixed exactly with "guardrails:" (e.g. "guardrails: no test framework configured")
   - labels including {{bootstrapLabel}} so subsequent build attempts on this issue
     can detect that the task IS to set up guardrails (the orchestrator will then
     skip the BLOCKED gate and let the executor install the missing tooling).
-- Use add_issue_comment on issue #{{issueNumber}} to link the guardrails issue
+- Use github_add_issue_comment on issue #{{issueNumber}} to link the guardrails issue
 - OUTPUT must include: BLOCKED
 
 IF ALL CRITICAL GUARDRAILS ARE PRESENT (tests work, even if linting/types are missing):

package/workflows/prompts/pr-fix.md

@@ -1,8 +1,8 @@
 You are fixing a PR based on a maintainer's request.
 
-SETUP (git is pre-configured, you are in a sandbox workspace):
-1. git clone --branch {{branch}} https://github.com/{{owner}}/{{repo}}.git && cd {{repo}}
-2. Read CLAUDE.md and AGENTS.md if they exist
+You are already inside the {{repo}} repo at branch {{branch}} — the harness
+pre-cloned the PR's head ref and your cwd is the repo root. Git is configured.
+Read CLAUDE.md (and CONTRIBUTING.md if present) for project-specific guidance.
 
 CONTEXT:
 - PR #{{prNumber}}: {{prTitle}}
@@ -13,10 +13,9 @@ NOTE: The CI failures above are the primary issue — fix those first.
 {{/if}}
 INSTRUCTIONS:
 1. Understand what the maintainer is asking for
-2. Read the relevant code and understand what needs to change
-3. Make the fix — keep changes minimal and focused
-4. Run tests, lint, and typecheck to verify everything passes
-5. DO NOT commit until all checks pass
+2. Read the relevant code and make the fix — keep changes minimal and focused
+3. Follow the **building** skill: install dependencies, then run the full
+   test/lint/typecheck gate — do NOT commit until it all passes
 
 AFTER FIXING:
 1. git add -A && git commit -m "fix: address feedback on PR #{{prNumber}}

package/workflows/prompts/pr.md

@@ -1,6 +1,6 @@
 Create a pull request for the work on branch {{branch}}.
 
-Use the MCP tool create_pull_request with the following:
+Use the MCP tool github_create_pull_request with the following:
 - owner: {{owner}}
 - repo: {{repo}}
 - head: {{branch}}
@@ -14,14 +14,14 @@ Use the MCP tool create_pull_request with the following:
   (3-6 bullet points describing what changed)
 
   ## Planning and execution docs
-  - [Guardrails report]({{branchUrl guardrails-report.md}})
-  - [Architect plan]({{branchUrl architect-plan.md}})
-  - [Executor summary]({{branchUrl executor-summary.md}})
-  - [Reviewer verdict]({{branchUrl reviewer-verdict.md}})
-  - [Status]({{branchUrl status.md}})
+  - [Guardrails report]({{artifactUrl guardrails-report.md}})
+  - [Architect plan]({{artifactUrl architect-plan.md}})
+  - [Executor summary]({{artifactUrl executor-summary.md}})
+  - [Reviewer verdict]({{artifactUrl reviewer-verdict.md}})
+  - [Status]({{artifactUrl status.md}})
 
   Before adding each link above, run `ls -1 {{issueDir}}/`
-  on the branch and OMIT any line whose file doesn't exist on disk. Use the
+  and OMIT any line whose file doesn't exist on disk. Use the
   exact full https URLs above as written — do NOT shorten to relative paths,
   they will not render in the PR description.
 
@@ -30,9 +30,10 @@ Use the MCP tool create_pull_request with the following:
 
 Note: There are unresolved reviewer issues after {{review.cycles}} fix cycles. See reviewer-verdict.md on the branch.{{/if}}
 
-Then use add_issue_comment on issue #{{issueNumber}} to post the PR link.
+Do NOT post a comment with the PR link — the harness adds it to the status
+checklist on the issue automatically. Just create the PR.
 
 Update status.md: current_phase = complete, add pr_number.
-git add .lastlight/ && git commit -m "status: PR created for #{{issueNumber}}" && git push origin HEAD
+{{#if !externalizeArtifacts}}git add .lastlight/ && git commit -m "status: PR created for #{{issueNumber}}" && git push origin HEAD{{/if}}{{#if externalizeArtifacts}}Do NOT git add or commit {{issueDir}}/ — the harness persists it to the Last Light server automatically.{{/if}}
 
-OUTPUT: The PR number and URL.
+OUTPUT: The PR number and URL (so the harness can link the PR from the checklist).

package/workflows/prompts/qa-browser.md

@@ -0,0 +1,95 @@
+You are running the **browser-QA pass** of a qa-test run — driving the target
+through its flow in a **real headless browser** and capturing **screenshot
+evidence** for each step. A text-evidence QA run already ran and posted its
+per-step report; your job is to add visual proof for the steps that exercise a
+rendered UI. Read the `browser-qa` skill for the driver contract and the
+`qa-test` skill for the flow procedure and report shape, then follow them. The
+`building` skill installs and runs the repo.
+
+**Stay in the browser.** Do **not** read, quote, or analyse the repo's source
+code — the text pass already covered it. Your evidence is strictly what the
+browser shows: the driver's extracted text, assertion results, console errors,
+and the screenshots. No code walkthroughs.
+
+## What to test
+
+{{#if commentBody}}
+**Target / steps / request:**
+{{commentBody}}
+{{/if}}
+{{#if issueTitle}}**Issue/PR title:** {{issueTitle}}{{/if}}
+{{#if issueBody}}
+**Issue/PR body:**
+{{issueBody}}
+{{/if}}
+
+Target repo: **{{owner}}/{{repo}}**
+{{#if issueNumber}}Target issue/PR: **#{{issueNumber}}**{{/if}}
+
+If the target is a CLI or a pure API with no UI, the text pass already covered
+it — keep this pass short and say no browser evidence was needed. Focus on flows
+that actually render a UI.
+
+## First: confirm the browser is available
+
+Run the driver's probe before anything else:
+
+```
+node <browser-qa skill dir>/scripts/agent-browser.mjs doctor
+```
+
+(The `browser-qa` skill is staged into this phase's skill bundle — find its
+absolute path from the available-skills catalogue.) If `doctor` exits non-zero,
+the browser toolchain isn't present: say so plainly and stop — do not fake
+screenshots. This phase only runs on the docker QA image, so `doctor` should
+pass.
+
+## Workspace + run the app
+
+You are already inside the **{{repo}}** repo at branch {{branch}} — the harness
+pre-cloned it and your cwd is the repo root (no `cd`). If this is a PR, read the
+diff and design a flow that exercises what changed. Follow the `building` skill
+to install and start the app's dev-server in the background; wait until it's
+listening on `localhost`.
+
+## Drive the flow and capture evidence
+
+State the steps and their success criteria first. Author a `flow.json` (shape
+documented in the `browser-qa` skill), then run `agent-browser.mjs run flow.json
+--base-url http://localhost:<port> --out-dir {{issueDir}}`, capturing a
+screenshot at each decisive step. Save every screenshot under **`{{issueDir}}/`**
+— the harness harvests that directory. Parse the JSON report (per-step status,
+extracted text, assertion results, console errors) — that, not the images, is
+what you reason over. On a step failure continue to the next step unless it
+blocks everything downstream; treat console/page errors as findings.
+
+## How your report is delivered — read carefully
+
+Your **final message is the report**, and the harness posts it for you{{#if issueNumber}} as
+a comment on **#{{issueNumber}}**{{/if}}{{#if !issueNumber}} back into the thread this request came from{{/if}}.
+Title it clearly as the **browser-QA evidence** so it reads as a supplement to
+the text report, not a competing one. Use the `qa-test` report shape
+(Environment / Results table / Issues found / Coverage). Every defined step gets
+a row and a result.
+
+**Keep it tight** — a one-line environment summary, the results table (one row
+per step, terse Evidence cell), the inline screenshots, any issues found, and a
+short "what was / wasn't exercised". No per-step narration or code analysis.
+
+**Embed each step's screenshot inline** in its Evidence cell so it renders in
+the comment.
+{{#if artifactBaseUrl}}Every PNG you saved to `<name>.png` is served publicly at
+`{{artifactBaseUrl}}/<name>.png`. Put a **raw Markdown image** in the Evidence
+cell — `!` then `[caption]` then the URL in parentheses — with no backticks and
+no code fence (inside a code span it shows as literal text instead of
+rendering). For example, a screenshot saved as `step-2.png` becomes: an
+exclamation mark, `[Step 2]`, then `({{artifactBaseUrl}}/step-2.png)` with no
+spaces and no backticks.{{/if}}{{#if !artifactBaseUrl}}No public URL is
+configured, so reference each screenshot by filename (e.g. `step-2-cart.png`)
+and note it's in the run's Artifacts view.{{/if}}
+
+**Do NOT post it yourself** with `github_add_issue_comment` — that would
+double-post. Never claim a step passed that you didn't run, and never fabricate
+a screenshot. If screenshots couldn't be persisted (no server-mode build
+assets), still report the per-step DOM/text observations and say the images
+weren't retained.

package/workflows/prompts/qa-synth.md

@@ -0,0 +1,44 @@
+You are writing the **single final QA report** for a qa-test run. Two passes
+have already run: a text-evidence QA flow and (sometimes) a browser-QA pass.
+Your job is to **synthesize them into one concise report** — the reader sees
+only your output, not the individual passes.
+
+This is a **pure writing task**. Do **not** run commands, install anything, read
+repo files, or start a server — everything you need is below. Do **not** post a
+comment yourself (`github_add_issue_comment`); your final message *is* the
+comment, delivered by the harness.
+
+## What was tested
+
+{{#if commentBody}}{{commentBody}}{{/if}}{{#if issueTitle}} (issue/PR: {{issueTitle}}){{/if}}
+
+## Text QA report
+
+{{qaResult}}
+
+{{#if qaBrowserResult}}
+## Browser-QA report (real headless browser + screenshots)
+
+{{qaBrowserResult}}
+{{/if}}
+
+## Write the report
+
+Produce a tight Markdown comment:
+
+- A **single results table** (`| Step | Status | Evidence |`) covering every
+  step exercised across both passes. When the same step ran in both, prefer the
+  browser result for rendered-UI steps and note the text result only if it adds
+  something. Mark untested/blocked steps honestly.
+{{#if qaBrowserResult}}- **Embed each step's screenshot inline** in its Evidence cell exactly as it
+  appears in the browser-QA report above (the `![caption](https://…/<name>.png)`
+  image Markdown) so it renders in this comment. Keep them; don't turn them into
+  plain links or drop them.{{/if}}
+- A short **Issues found** list (each real FAIL with expected vs observed), or
+  "none" if clean.
+- A one-line **coverage** note: what was exercised, and anything notable that
+  wasn't.
+
+Keep it short — no per-step narration outside the table, no restating both
+reports in full. Surface real failures plainly; never claim a step passed that
+neither pass actually ran.

package/workflows/prompts/qa-test.md

@@ -0,0 +1,60 @@
+You are running a **QA test flow** — driving a target through a sequence of
+steps and reporting step-level pass/fail with evidence. Read the `qa-test` skill
+for the full procedure, then follow it. It uses the `building` skill for
+installing and running the repo. This prompt gives you the target/steps and how
+your report is delivered.
+
+## What to test
+
+{{#if commentBody}}
+**Target / steps / request:**
+{{commentBody}}
+{{/if}}
+{{#if issueTitle}}**Issue/PR title:** {{issueTitle}}{{/if}}
+{{#if issueBody}}
+**Issue/PR body:**
+{{issueBody}}
+{{/if}}
+
+Target repo: **{{owner}}/{{repo}}**
+{{#if issueNumber}}Target issue/PR: **#{{issueNumber}}**{{/if}}
+
+If specific steps are given (often after `--`), use them. Otherwise, if this is a
+PR, read the diff and design a flow that exercises what changed. State the steps
+and their success criteria before running.
+
+## Workspace
+
+You are already inside the **{{repo}}** repo at branch {{branch}} — the harness
+pre-cloned it and your cwd is the repo root. Git is configured; no clone, no
+`cd`.
+
+## Evidence — what you can and can't drive
+
+You have **bash, file read, and the github tools** — no browser, no
+screenshots. QA a **CLI** directly, or a **web service** by starting its
+dev-server in the background and exercising it with `curl` (status codes,
+bodies, headers). Capture stdout/stderr and exit codes as per-step evidence.
+
+If the **whole target is a rendered UI** (the flow only makes sense in a
+browser), don't install/build to guess at it — a browser-QA pass runs after you
+and owns it. Note in one line that it's UI-shaped and deferred, and stop. For a
+**mixed** flow, drive the text/CLI/API steps here and mark only the
+rendered-UI steps **BLOCKED** (deferred to browser QA) rather than faking a
+result. On a step failure, continue to the next step unless it blocks
+everything downstream.
+
+## How your report is delivered — read carefully
+
+Your **final message is the report**, and the harness posts it for you:
+{{#if issueNumber}}
+- as a comment on **#{{issueNumber}}**.
+{{/if}}
+{{#if !issueNumber}}
+- back into the thread this request came from.
+{{/if}}
+
+Make your final message the complete QA report in the shape the `qa-test` skill
+defines (Environment / Results table / Issues found / Coverage). **Do NOT post
+it yourself** with `github_add_issue_comment` — that would double-post. Report
+real failures as failures; never claim a step passed that you didn't run.

package/workflows/prompts/re-reviewer.md

@@ -1,7 +1,7 @@
 You are the CODE REVIEWER — RE-REVIEW after fix cycle {{fixCycle}}.
 
-SETUP (git is pre-configured, you are in a sandbox workspace):
-1. git clone --branch {{branch}} https://github.com/{{owner}}/{{repo}}.git && cd {{repo}}
+You are already inside the {{repo}} repo at branch {{branch}} — the harness
+pre-cloned it and your cwd is the repo root. Git is configured.
 
 This is a FOLLOW-UP review. You previously requested changes. The executor has attempted to fix them.
 
@@ -10,17 +10,16 @@ SCOPE — review ONLY what changed in the fix cycle:
 2. Read the "## Fix Cycle {{fixCycle}}" section in {{issueDir}}/executor-summary.md — what was fixed
 3. Diff only the fix commit(s): git log --oneline -3 and git diff HEAD~1
 
-CHECK:
-1. Were the specific issues you raised actually addressed?
-2. Did the fix introduce any new problems?
-3. Do tests still pass?
-
-DO NOT re-review the entire changeset. Only verify your previous issues were fixed.
+Verify your previous issues were actually addressed and the fix introduced no new
+problems (apply the **code-review** rubric to the fix). Do NOT re-review the
+entire changeset. Tests: the fix cycle already ran the full suite (see its
+summary section) — for independent signal, follow the **building** skill to run
+the typecheck command and the tests covering the fixed files.
 
 AFTER REVIEW:
 1. APPEND to {{issueDir}}/reviewer-verdict.md under heading "## Re-review after Fix Cycle {{fixCycle}}" (preserve the original verdict above). The new section MUST itself contain a "VERDICT: APPROVED" or "VERDICT: REQUEST_CHANGES" line.
 2. Update status.md with reviewer_status: APPROVED or REQUEST_CHANGES
-3. git add .lastlight/ && git commit -m "review: re-review after fix cycle {{fixCycle}} for #{{issueNumber}}" && git push origin HEAD
+{{#if !externalizeArtifacts}}3. git add .lastlight/ && git commit -m "review: re-review after fix cycle {{fixCycle}} for #{{issueNumber}}" && git push origin HEAD{{/if}}{{#if externalizeArtifacts}}3. Do NOT git add or commit {{issueDir}}/ — the harness persists it to the Last Light server automatically.{{/if}}
 
 OUTPUT FORMAT — your stdout MUST start with one of these two lines, EXACTLY, on its own line, with no leading whitespace:
 

package/workflows/prompts/reviewer.md

@@ -1,7 +1,7 @@
 You are the CODE REVIEWER. Independent verification — you have NO shared context with the executor.
 
-SETUP (git is pre-configured, you are in a sandbox workspace):
-1. git clone --branch {{branch}} https://github.com/{{owner}}/{{repo}}.git && cd {{repo}}
+You are already inside the {{repo}} repo at branch {{branch}} — the harness
+pre-cloned it and your cwd is the repo root. Git is configured.
 
 SCOPE — review ONLY changed files:
   git log --oneline main..HEAD
@@ -10,13 +10,14 @@ SCOPE — review ONLY changed files:
 
 Read {{issueDir}}/architect-plan.md and executor-summary.md for context.
 
-CHECK:
-1. Does implementation match the plan?
-2. Do tests pass?
-3. Security concerns?
-4. Logic errors or missed edge cases?
+Apply the **code-review** skill's rubric (finding tiers + what to check), scoped
+to the changed files, and confirm the implementation matches the plan. Do NOT
+review unchanged files or flag pre-existing issues.
 
-DO NOT review unchanged files or flag pre-existing issues.
+Tests: the executor already ran the FULL suite and pasted results in
+executor-summary.md — review that output rather than re-running everything. For
+your own independent signal, follow the **building** skill to run the typecheck
+command and the tests covering the changed files.
 
 AFTER REVIEW:
 1. Write {{issueDir}}/reviewer-verdict.md with the following structure (exact headings):
@@ -38,7 +39,7 @@ AFTER REVIEW:
    (paste actual output)
 
 2. Update status.md with reviewer_status: APPROVED or REQUEST_CHANGES (matching the verdict)
-3. git add .lastlight/ && git commit -m "review: verdict for #{{issueNumber}}" && git push origin HEAD
+{{#if !externalizeArtifacts}}3. git add .lastlight/ && git commit -m "review: verdict for #{{issueNumber}}" && git push origin HEAD{{/if}}{{#if externalizeArtifacts}}3. Do NOT git add or commit {{issueDir}}/ — the harness persists it to the Last Light server automatically.{{/if}}
 
 OUTPUT FORMAT — your stdout MUST start with one of these two lines, EXACTLY, on its own line, with no leading whitespace: