lastlight 0.16.0 → 0.16.2

package/workflows/prompts/demo.md

@@ -1,125 +0,0 @@
-You are recording a short **demo video** of a PR or feature — driving the
-repo's web UI in a **real headless browser**, screen-recording the session, and
-compositing a titled mp4. Read the `demo` skill for the director procedure and
-the `compose-demo.sh` wrapper, the `browser-qa` skill for the driver contract,
-and the `building` skill for install/run — then follow them.
-
-**Stay in the browser.** Your deliverable is a *moving* demonstration of
-behaviour, not a code walkthrough. Don't quote or analyse source files — show
-what the running app does.
-
-## What to demo
-
-{{#if commentBody}}
-**Request / notes:**
-{{commentBody}}
-{{/if}}
-{{#if issueTitle}}**Issue/PR title:** {{issueTitle}}{{/if}}
-{{#if issueBody}}
-**Issue/PR body:**
-{{issueBody}}
-{{/if}}
-
-Target repo: **{{owner}}/{{repo}}** at branch {{branch}}
-{{#if issueNumber}}Target issue/PR: **#{{issueNumber}}**{{/if}}
-
-Read the PR (description, diff, linked issue) from the context above. Decide the
-single thing the video must prove — the moment that only happens if the change
-works as claimed — and whether the story is a `single` walkthrough (default) or a
-`side-by-side` before/after comparison (only for a genuine regression/refactor).
-
-## First: confirm the browser + ffmpeg are available
-
-Run the driver's probe before anything else (the `browser-qa` skill is staged
-into this phase's bundle — find its absolute path from the available-skills
-catalogue):
-
-```
-node <browser-qa skill dir>/scripts/agent-browser.mjs doctor
-```
-
-If `doctor` exits non-zero, the toolchain isn't present: say so plainly and
-stop — **do not fake a recording.** This phase only runs on the docker QA image,
-so `doctor` should pass.
-
-## Workspace + run the app
-
-You are already inside the **{{repo}}** repo — the harness pre-cloned it and your
-cwd is the repo root (no `cd`){{#if baseBranch}}, **checked out at the PR head
-branch `{{branch}}`**, so the workspace already holds the PR's code: this checkout
-*is* your "after" state{{/if}}. Follow the `building` skill to install
-dependencies and start the dev-server in the background; poll with `curl` until
-it answers on `localhost:<port>`.
-
-{{#if baseBranch}}**This is a PR → record a `side-by-side` before/after.** Record
-the **after** first, straight from the current checkout (`{{branch}}`) — do not
-re-checkout for it. Then record the **before** from the base branch
-`{{baseBranch}}`. The pre-clone is shallow + single-branch, so the base isn't
-present locally yet — fetch it explicitly by ref (never trust an ambiguously
-named local branch):
-
-```
-git fetch --depth 1 origin {{baseBranch}}
-git checkout -B {{baseBranch}}-base FETCH_HEAD
-```
-
-Re-run `building`'s install + restart the dev-server after switching. When you
-composite, the **first** clip is the left/BEFORE panel and the **second** is the
-right/AFTER panel.
-
-**Verify before you ship:** the disambiguating change must actually appear in the
-*after* recording and be absent from the *before* (use the driver's `text`/
-`assertText` to read it on both). If both states look identical, your checkout is
-wrong — STOP and fix it; do not ship a side-by-side that proves nothing.{{/if}}
-
-## Capture and compose
-
-Author a `flow.json` (shape in the `browser-qa` skill) that scripts the
-interaction like a director — record the baseline first, hold after state
-changes (use `{"pause": 1200}` steps), verify between steps. Recording
-auto-enables the driver's demo mode, so a **visible cursor** animates to each
-target and a beat is held between steps — prefer `type` over `fill` so typing
-shows on screen. Record with `--record-dir`:
-
-```
-node <browser-qa skill dir>/scripts/agent-browser.mjs run flow.json \
-  --base-url http://localhost:<port> --record-dir /tmp/demo-cap
-```
-
-Then composite the raw webm into the final mp4 with the `demo` skill's wrapper,
-writing it into **`{{issueDir}}/demo.mp4`** (the harness harvests that dir):
-
-```
-<demo skill dir>/scripts/compose-demo.sh \
-  --output {{issueDir}}/demo.mp4 --title "<PR # — what it does>" \
-  --subtitle "<one line>" --layout single --speed 1 --target-size-mb 5 \
-  /tmp/demo-cap/session.webm
-```
-
-Self-check the result with `ffprobe` (the wrapper prints a summary): resolution
-sane, duration watchable (~15–90s), and **size ≤ 5 MB** so GitHub embeds it. If
-it's over, re-run with a lower `--target-size-mb` or a higher `--speed`.
-
-## 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}}.
-Use the `demo` skill's report shape — a one-line environment summary, a sentence
-on what the video shows and the moment to watch, the video, and a one-line
-"not covered". **Keep it tight.**
-
-**Embed the video inline so it plays in the comment.**
-{{#if artifactBaseUrl}}Your `{{issueDir}}/demo.mp4` is served publicly at
-`{{artifactBaseUrl}}/demo.mp4`. Include a raw HTML video tag on its own line —
-`<video src="{{artifactBaseUrl}}/demo.mp4" controls></video>` — plus a plain
-link beneath it as a fallback: `[demo.mp4]({{artifactBaseUrl}}/demo.mp4)`. GitHub
-renders `<video>` in comments. Do **NOT** wrap the tag in backticks or a code
-fence (inside a code span it shows as literal text instead of playing).{{/if}}{{#if !artifactBaseUrl}}No
-public URL is configured, so reference the video by filename (`demo.mp4`) 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 stage or fabricate a result the feature didn't produce; if
-something doesn't work, the honest demo shows it. If the video couldn't be
-recorded or persisted (no server-mode build assets), say so plainly and describe
-what you observed instead of pretending a clip exists.

package/workflows/prompts/executor.md

@@ -1,42 +0,0 @@
-You are the EXECUTOR. Implement precisely what the architect's plan requires.
-
-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.
-
-Start by reading {{issueDir}}/architect-plan.md.
-
-WORK FROM THE PLAN — it contains an exhaustive file manifest and the exact
-commands:
-- Implement the plan's file manifest directly. Read a file only immediately
-  before you edit it; do NOT re-explore areas the plan already mapped.
-- Use grep/find only to fill genuine gaps the plan didn't cover (if the plan
-  is missing a sibling file, fix it there and proceed).
-- Use the test/lint/typecheck commands the plan copied from the guardrails
-  report — no need to re-open guardrails-report.md unless the plan omitted them.
-
-Follow the **building** skill for the mechanics: install dependencies first,
-write the failing test before implementing (TDD), and run the full
-test/lint/typecheck gate once before committing — all of it must pass before you
-commit or claim done.
-
-Before committing, also honour the building skill's **decomposition budget** and
-**type-safety** rules: keep functions under ~15 cyclomatic complexity (a
-function that parses, validates, and emits is three functions — extract helpers),
-and never use `as any` or other compiler-silencing assertions to pass the gate or
-to skip a validator the same code defines. If the repo's only test path needs an
-unavailable external service, add a runnable unit/CLI test with in-memory
-fixtures rather than declaring the change unverified.
-
-AFTER THE GATE PASSES:
-1. Write {{issueDir}}/executor-summary.md:
-   - What was done, files changed
-   - Test / lint / typecheck results (paste actual output)
-   - Any deviations from the plan, known issues
-2. Update {{issueDir}}/status.md: current_phase = executor
-3. git add -A && git commit -m "feat: implement #{{issueNumber}}
-
-Tested: {test command} -> {result}
-Scope-risk: {low|medium|high}"
-4. git push origin HEAD
-
-OUTPUT: List of files changed, test/lint/typecheck results, commit hash.

package/workflows/prompts/explore-ask.md

@@ -1,99 +0,0 @@
-You are running a socratic questioning loop to help a maintainer shape a
-half-formed idea into a detailed spec. This is iteration {{iteration}} of
-{{maxIterations}}.
-
-The **{{owner}}/{{repo}}** repo is checked out at `{{repo}}/` (a
-subdirectory of your cwd) — the previous read phase ensured it.
-
-**Important paths** (relative to the workspace cwd):
-- Repo root: `{{repo}}/` (cd into it to use git)
-- Context doc: `{{issueDir}}/explore-context.md`
-
-Start by reading the context doc for architecture, key code excerpts, and
-existing patterns. Only read additional source files if the context doc
-doesn't cover what you need.
-
-## Baseline from the initial read
-
-{{baseline}}
-
-## Q&A accumulated so far in this thread
-
-{{#if scratch.socratic.qa}}
-```
-{{scratch.socratic.qa}}
-```
-{{/if}}
-{{#if !scratch.socratic.qa}}
-_(no questions answered yet — this is the first round)_
-{{/if}}
-
-## Your task
-
-One of two things, depending on whether you have enough signal to write a
-good spec:
-
-### If you DON'T have enough signal yet
-
-Walk down the design tree one branch at a time, resolving dependencies
-between decisions in order — answering an upstream decision often changes
-what the downstream questions even are.
-
-**First, try to answer the question yourself.** If reading the code would
-settle it, read the code instead of asking. Only put a question to the user
-when the codebase genuinely can't decide it.
-
-**Then, of the questions that remain, only ASK about the high-stakes ones**
-— decisions where guessing wrong would be costly or hard to reverse, or
-where the design genuinely forks. **Low-stakes decisions you decide
-yourself**: pick the sensible default (usually "follow the existing
-pattern"), and record it in `{{issueDir}}/explore-context.md` under a
-`## Decisions made during exploration` section (create it if absent), as
-`<decision> → <what you chose> (<one-line why>)`. The user can override
-any of these later; surfacing them in the spec is enough.
-
-When you do ask, ask **one primary question per turn**, and **always give
-your recommended answer** with a one-line rationale grounded in the code
-you read. If a second question is trivially coupled to the first (you can't
-sensibly answer one without the other), you may tack it on as a short
-follow-up — but never a flat list of unrelated questions. Keep it
-conversational; the user replies in the same thread.
-
-Shape of a good turn:
-
-> I see `FooService` already handles this today. I'd **extend** it rather
-> than add a parallel service — it already owns the auth path. Sound right?
-> ↳ If we extend, I'd reuse its existing 5-min cache rather than add a new
-> one (assuming that's fine).
-
-Good questions pin down scope ("only X, or also Y?"), surface hidden
-constraints ("must this stay backwards-compatible with Z?"), flush out
-users / success criteria ("who uses this, and what makes them say it
-worked?"), and reference specific code you found.
-
-If you discover new relevant code, **append it to
-`{{issueDir}}/explore-context.md`** so the synthesize phase has it too.
-
-**Do NOT output the word READY** on this path. Just the question.
-
-### If you DO have enough signal
-
-Output the literal word `READY` on its own line at the very end of your
-message, optionally preceded by a short "I think I have enough to write
-this up — moving to draft." note. The `READY` marker ends the loop and
-advances to the synthesis phase.
-
-## Rules
-
-- Never ask the same question twice — check the accumulated Q&A first.
-- Ask **one** primary question per turn (plus an optional tightly-coupled
-  follow-up). Never dump a list of unrelated questions.
-- Every question carries your recommended answer — never ask open-endedly
-  without saying what you'd do.
-- Prefer deciding low-stakes items yourself (recorded in the context doc)
-  over asking. Only escalate genuinely high-stakes / forking decisions.
-- If the user says "we're done", "just write it up", or "your
-  recommendations look good" in their most recent answer, output READY
-  immediately.
-- Don't preamble or recap — the user can see the thread already.
-- Use the cloned repo to make your questions specific and grounded.

package/workflows/prompts/explore-publish.md

@@ -1,31 +0,0 @@
-You are publishing an approved spec that the previous phase wrote to
-`{{issueDir}}/explore-spec.md`.
-
-## Your task
-
-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_add_issue_comment` MCP tool.
-
-### Slack-originated (triggered in a Slack thread)
-
-If there's no `{{issueNumber}}` (or it's `0`), the run originated from a
-Slack mention. Create a **new GitHub issue** in the configured destination
-repo — check the environment variable `EXPLORE_DEFAULT_REPO` for the
-`owner/name` to use, unless the baseline identified a specific target repo.
-The new issue body should be the spec contents plus a trailer line crediting
-the Slack thread as the source.
-
-## Rules
-
-- Read the spec file first — don't paraphrase it from memory.
-- On success, output a short message with the link. For example:
-  `**Spec published:** https://github.com/owner/repo/issues/123`
-  This output is sent directly to the user in Slack/GitHub, so make it
-  useful — include the URL.
-- On failure, output the error plainly. Don't retry silently.

package/workflows/prompts/explore-read.md

@@ -1,120 +0,0 @@
-You are helping a maintainer think through a half-formed idea. Before we ask
-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 — Prepare the workspace
-
-The repo lives (or will live) in a `{{repo}}/` subdirectory under your
-cwd. Check first:
-
-```
-ls -la
-```
-
-- 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
-
-Fetch issue #{{issueNumber}} using the GitHub MCP tools to get the latest
-title, body, and comments.
-{{/if}}
-
-## Source material
-
-{{#if issueTitle}}**Issue title:** {{issueTitle}}{{/if}}
-{{#if issueBody}}
-**Issue body:**
-
-```
-{{issueBody}}
-```
-{{/if}}
-{{#if commentBody}}
-**Most recent comment / Slack message that triggered this explore:**
-
-```
-{{commentBody}}
-```
-{{/if}}
-
-## Step 3 — Deep codebase exploration
-
-Read the source material above, then explore the codebase thoroughly to
-understand everything relevant to the idea. Look at:
-
-- Directory structure and key entry points
-- Files, modules, and types that relate to the idea
-- Existing patterns, conventions, and abstractions the idea would build on
-- Database schemas, API routes, or config that would be affected
-- Tests and how they're structured in the relevant areas
-
-## Step 4 — Write the context document
-
-First create the scratch directory at the WORKSPACE root (alongside
-`{{repo}}/`, not inside it):
-
-```
-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 **`{{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:
-
-```markdown
-# Explore context: <short description of the idea>
-
-## Idea summary
-<2-3 sentences distilling what the user wants>
-
-## Codebase overview
-<Brief description of the repo's purpose and structure>
-
-## Relevant architecture
-<How the parts of the codebase that matter for this idea fit together.
-Include file paths, key types/interfaces, function signatures, data flow.>
-
-## Key code excerpts
-<Paste the most relevant snippets (with file paths and line numbers) that
-a later agent would need to understand the design space. Don't be shy —
-include enough that the next phase doesn't have to re-read these files.>
-
-## Existing patterns to follow
-<Conventions, naming, testing approach, etc. from the codebase that the
-new work should match.>
-
-## What we know
-- <bullet>
-
-## What's unclear
-- <bullet>
-```
-
-Be thorough — the quality of the socratic questions and the final spec
-depend entirely on how well this document captures the relevant code.
-
-## Step 5 — Output the baseline
-
-After writing the context file, output a brief baseline summary (the
-"What we know" and "What's unclear" sections) as your reply. This is what
-the socratic loop will see as `{{baseline}}`.
-
-Do not ask questions yet. Do not write a spec yet.

package/workflows/prompts/explore-synthesize.md

@@ -1,88 +0,0 @@
-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 checked out at `{{repo}}/` (a
-subdirectory of your cwd).
-
-**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
-updated during the socratic loop. Only read additional source files if the
-context doc doesn't cover what you need.
-
-## Baseline understanding
-
-{{baseline}}
-
-## Full Q&A transcript
-
-```
-{{scratch.socratic.qa}}
-```
-
-## Your task
-
-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 `{{issueDir}}/explore-spec.md` using the Write tool.
-
-```
-# <short title summarizing the idea>
-
-## Problem
-<2-4 sentences — what's broken or missing today, whose pain this fixes>
-
-## Users
-<who will use this and in what context>
-
-## Goals
-- <goal 1>
-- <goal 2>
-
-## Non-goals
-- <explicit non-goal 1>
-- <explicit non-goal 2>
-
-## Proposed design
-<prose description — the how. Reference specific files, modules, and
-patterns from the codebase. Break into subsections if useful.>
-
-## Key files to modify
-| File | Change |
-|------|--------|
-| 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>
-
-## Open questions
-- <anything the Q&A didn't resolve>
-
-## Out of scope
-- <things that are related but intentionally deferred>
-```
-
-## Rules
-
-- 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
-  the spec covers. The next phase (post-approval publish) will read the
-  file, not your reply.
-- Don't invent facts that aren't grounded in the Q&A or codebase. If a
-  section is uncertain, write "To be decided during implementation" rather
-  than guessing.

package/workflows/prompts/fix.md

@@ -1,18 +0,0 @@
-You are the EXECUTOR (fix cycle {{fixCycle}}). Fix ONLY the issues reported by the reviewer.
-
-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.
-
-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).
-
-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
-
-OUTPUT: What was fixed, test/lint/typecheck results.

package/workflows/prompts/guardrails.md

@@ -1,96 +0,0 @@
-You are running a PRE-FLIGHT GUARDRAILS CHECK before implementation work begins.
-
-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.
-
-INSTALL DEPENDENCIES FIRST (do this before running ANY check command):
-The harness pre-clones the repo but does NOT install dependencies, so the
-test/lint/typecheck binaries (vitest, oxlint, tsc, eslint, ruff, …) will not
-resolve until you install them. Detect the ecosystem and run the install:
-- Node — pick the package manager from the lockfile: `pnpm-lock.yaml` → `pnpm install`,
-  `yarn.lock` → `yarn install`, `package-lock.json` (or none) → `npm ci`
-  (fall back to `npm install` if `npm ci` fails for a lockfile mismatch).
-- Python — `pip install -e .` / `pip install -r requirements.txt`, or `poetry install` / `uv sync`.
-- Rust — cargo fetches on first build; no separate step.
-Only AFTER a successful install should you judge whether a command "runs". A
-binary that is missing *after* dependencies installed cleanly is a real gap; a
-binary missing *because deps were never installed* is NOT — do not BLOCK on it.
-If the install itself fails (bad lockfile, missing manifest), that IS a blocking
-guardrail — report it as such.
-
-CHECK THESE GUARDRAILS:
-
-The rule for each check below: **if it is present, it MUST pass; if it is not
-present, that's fine.** A configured command that FAILS is a blocker. A command
-that simply doesn't exist is NOT a blocker.
-
-1. **Test Framework** — Does the repo have a test runner (vitest, jest, pytest,
-   cargo test, etc.)? Do test files exist? Does the test command run AND pass?
-   (Tests are the primary signal — a repo with no test framework at all is the
-   one absent-tooling case that still blocks, since there's nothing to verify
-   the build against.)
-
-2. **Linting** — Is a linter configured (eslint, biome, ruff, clippy, etc.)?
-   If configured, the lint command MUST pass → a failing lint BLOCKS. If no
-   linter is configured at all, that's fine — note it and do NOT block.
-
-3. **Type Checking** — Is type checking configured (tsconfig.json + tsc, mypy,
-   cargo check, etc.)? If configured, the typecheck command MUST pass → a
-   failing typecheck BLOCKS. If not configured at all, that's fine — note it
-   and do NOT block.
-
-4. **CI Pipeline** (informational only) — Does .github/workflows/ exist with test/lint steps?
-
-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
-{{#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):
-
-Apply the present-must-pass rule. BLOCK if ANY of these hold:
-- there is no test framework at all, or the test command is broken / fails;
-- a linter IS configured but the lint command fails;
-- type checking IS configured but the typecheck command fails;
-- the dependency install itself failed.
-
-A check that is simply ABSENT (no linter configured, no typecheck configured) is
-NOT a blocker — note it in the report and proceed. Do not create a guardrails
-issue merely because lint or typecheck tooling is missing.
-
-IF A BLOCKING CONDITION ABOVE HOLDS:
-- 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 github_add_issue_comment on issue #{{issueNumber}} to link the guardrails issue
-- OUTPUT must include: BLOCKED
-
-OTHERWISE — every check that EXISTS passes (absent lint/typecheck is fine):
-- OUTPUT must include: READY
-
-OUTPUT: Exactly one of READY or BLOCKED, followed by a brief summary of what was found.

package/workflows/prompts/pr-fix.md

@@ -1,26 +0,0 @@
-You are fixing a PR based on a maintainer's request.
-
-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}}
-- Maintainer request: {{commentBody}}
-{{ciSection}}
-{{#if ciSection}}
-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 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}}
-
-{{commentBody}}"
-2. git push origin HEAD
-
-OUTPUT: Brief summary of what was fixed and test results.