lastlight 0.16.0 → 0.16.2

package/skills/security-review/references/issue-format.md

@@ -1,302 +0,0 @@
-# § Issue format
-
-This is the **contract** between `security-review` (producer) and
-`security-feedback` (consumer). Every rule here is machine-parsed; do not
-deviate. `security-feedback` is staged into a separate workspace and cannot read
-this file, so it keeps its own copy of the row/severity grammar — **if you change
-the grammar here, update `skills/security-feedback/SKILL.md` in lockstep.**
-
-## Title
-
-```
-Security scan — YYYY-MM-DD
-```
-
-- Exactly one em-dash (` — `, U+2014), surrounded by single spaces.
-- Date is the scan's UTC date in ISO form.
-- Same-day re-scans produce a second issue with the same title. GitHub disambiguates by issue number; the scanner never edits a prior-run issue.
-
-## Body
-
-The body is assembled from eight blocks, in this exact order, separated by blank lines:
-
-```
-{header comments}
-
-{intro paragraph}
-
-{how-to-respond section}
-
-{summary table}
-
-{suppression note}
-
-{scope note}
-
-{overflow note — omitted when overflow == 0}
-
-{findings sections}
-```
-
-### Block 1 — header comments
-
-Three HTML comments, each on its own line, in this exact order:
-
-```
-<!-- lastlight-security-scan-version: 1 -->
-<!-- lastlight-security-scan-date: YYYY-MM-DD -->
-<!-- lastlight-security-scan-ts: YYYY-MM-DDTHH:MM:SSZ -->
-```
-
-- `version` is a format version. Bump if the structure changes incompatibly — `security-feedback` will check this and refuse to parse unknown versions.
-- `date` matches the title.
-- `ts` is an ISO-8601 UTC timestamp with second precision (no milliseconds).
-
-### Block 2 — intro paragraph
-
-Exactly one paragraph, with the commit count and short-SHA range substituted:
-
-```
-Reviewing {N} commits since {priorScanDate} ({firstShortSha}..{lastShortSha}). Findings here focus on SDLC and workflow changes — Dependabot, GitHub Code Scanning, and Renovate handle the rest. Tick the box once the underlying issue is resolved or recorded in `SECURITY.md`.
-```
-
-`{N}` is the size of `commitsReviewed`. `{priorScanDate}` is the YYYY-MM-DD of the prior scan (or the bootstrap floor). When `N == 1`, both short SHAs are the same — render as `({onlyShortSha})` rather than `({sha}..{sha})`.
-
-### Block 3 — how-to-respond section
-
-Verbatim, including the heading:
-
-```
-## How to respond
-
-**Preferred flow** — tick the boxes on the findings you want broken out, then comment:
-
-- `@last-light create issues` — files one issue per **ticked** finding (default)
-
-**Other shortcuts:**
-
-- `@last-light create issues for the criticals` — every Critical finding (ticked or not)
-- `@last-light create issues for the highs` — same, for High
-- `@last-light create issues for items 1, 3, 5` — specific items by number (1-based, top to bottom)
-- `@last-light create issues for all` — every finding in this scan
-- `@last-light accept-risk for item N: <reason>` — suppress this finding in future scans
-- `@last-light false-positive for item N: <reason>` — suppress this finding in future scans
-- Comment freely to ask questions or discuss
-```
-
-(Item positions in commands map to the `item:N` HTML-comment markers defined below. Ticking a box in GitHub's UI rewrites the row from `[ ]` to `[x]` — the feedback skill treats that as your selection.)
-
-### Block 4 — summary table
-
-Verbatim header, with numbers substituted. Always include all four severity rows, even when the count is 0.
-
-`{nC}`, `{nH}`, `{nM}`, `{nL}` and `{nTotal}` are **TRUE counts** (post-filtering, pre-cap) — i.e. how many findings of each severity actually survived the SECURITY.md filtering, regardless of whether each individual row is listed below the cap. The same numbers appear in the `### 🔴 Critical ({nC})` etc. section headers. The overflow note (Block 6) communicates how many of those counts were truncated from the listed rows.
-
-```
-## Summary
-
-| Severity | Count |
-|----------|------:|
-| Critical | {nC} |
-| High     | {nH} |
-| Medium   | {nM} |
-| Low      | {nL} |
-| **Total**| **{nTotal}** |
-```
-
-### Block 5 — suppression note
-
-A single line:
-
-```
-Suppressed by `SECURITY.md`: {nSuppressed} (accepted: {nA}, false-positives: {nFP}). Below severity floor: {nFloor}.
-```
-
-Set each count to 0 when N/A. Emit the line unconditionally so the structure is stable.
-
-### Block 6 — scope note
-
-Always emit, immediately after the suppression note. Lists the human (non-bot) commits actually reviewed, so a maintainer can see what diff produced these findings:
-
-```
-> Commits reviewed: {short-sha-1} {subject-1}, {short-sha-2} {subject-2}, …
-```
-
-Cap at 10 entries; if there are more, append ` +{N} more` after the last item. Subjects are truncated to 60 chars with `…` if longer. Renovate/Dependabot commits are filtered out at § 1.5 and never appear here.
-
-### Block 7 — overflow note
-
-Emit **only** when `overflow > 0`:
-
-```
-> **Note** — {overflow} lower-severity findings are not listed here. The cap is: ALL critical and high, plus the first 10 medium/low (after sort). Tighten `SECURITY.md` severity floors or break out items from this scan, then re-run to surface the rest.
-```
-
-### Block 8 — findings sections
-
-Four sections, in this **exact order** (Critical → High → Medium → Low). Always emit all four headers, even when a section has zero findings — the feedback skill relies on stable anchors.
-
-The header counts (`{nC}` etc.) are the **true** post-filter counts, identical to those in Block 4's summary table. The rows listed under each header are subject to the § 7 cap: critical and high are always complete; medium + low are truncated to the first 10 combined. When a section is partially listed, append `(showing first N of {nM})` after the marker — see the per-section header rule below.
-
-```
-## Findings
-
-### 🔴 Critical ({nC})
-
-{rows or "_No findings._"}
-
-### 🟠 High ({nH})
-
-{rows or "_No findings._"}
-
-### 🟡 Medium ({nM}){if truncated: " (showing first {kM} of {nM})"}
-
-{rows or "_No findings._"}
-
-### 🟢 Low ({nL}){if truncated: " (showing first {kL} of {nL})"}
-
-{rows or "_No findings._"}
-```
-
-Where `kM` and `kL` are the actual rows listed in this issue (sum of the two ≤ 10). When `kM == nM` or `kL == nL` (no truncation in that section), omit the parenthetical.
-
-### Finding-row grammar
-
-Every finding is exactly two lines: a task-list row, then a `<details>` block (one blank line between rows within a section).
-
-The task-list row is **one physical line** with this exact shape:
-
-```
-- [ ] <!-- item:N fp:FINGERPRINT --> **TITLE** — `FILE:LINE` (TOOL · `RULE`)
-```
-
-Matched by this canonical regex (multiline, case-sensitive) — covers all three row states:
-
-```
-/^- \[([ x])\] <!-- item:(\d+) fp:([0-9a-f]{8,}) --> (?:~~)?\*\*(.+?)\*\* — `([^`]+):(\d+)` \(([a-z][a-z0-9-]*) · `([^`]+)`\)(?:~~ → #(\d+))?$/m
-```
-
-Capture groups, in order:
-
-1. `checkbox` — `" "` (unticked) or `"x"` (ticked or broken-out)
-2. `itemNumber` (1-based across all severities)
-3. `fingerprint` (lowercase hex, ≥ 8 chars)
-4. `title` (plain text; no backticks, no asterisks)
-5. `file` (no backticks, forward-slash path)
-6. `line` (integer; use `0` when not line-scoped)
-7. `tool` (lowercase, hyphenated — e.g. `npm-audit`, `semgrep`, `gitleaks`, `claude`)
-8. `rule` (the tool's native rule id; may contain dots, hyphens)
-9. `subIssueNumber` — present **only** when the row has been broken out to a sub-issue; `undefined` otherwise
-
-Derived state (the feedback skill computes these from the captures):
-
-| State | Written as | `checkbox` | `subIssueNumber` |
-|-------|------------|------------|------------------|
-| **pending** | `- [ ] <!-- item:N fp:FP --> **TITLE** — …` | `" "` | `undefined` |
-| **user-ticked** (maintainer clicked the box in GitHub's UI) | `- [x] <!-- item:N fp:FP --> **TITLE** — …` | `"x"` | `undefined` |
-| **broken-out** (feedback skill created a sub-issue) | `- [x] <!-- item:N fp:FP --> ~~**TITLE** — …~~ → #SUBISSUE` | `"x"` | the sub-issue number |
-
-Rules:
-
-- `alreadyBrokenOut` ≡ `subIssueNumber != null`. Broken-out rows are immutable — the feedback skill never re-opens them, never touches their checkbox, never re-creates sub-issues from them.
-- `userTicked` ≡ `checkbox === "x" && subIssueNumber == null`. These are the candidates the default `@last-light create issues` command selects.
-- When creating sub-issues from ticked rows, the feedback skill transitions each row from **user-ticked** → **broken-out** by wrapping the visible text in `~~…~~` and appending ` → #{subIssueNumber}`. The checkbox stays `[x]`; the strikethrough + link is the canonical broken-out marker.
-- Un-ticking (moving a user-ticked row back to `[ ]`) is fine — the row just becomes pending again. The scanner doesn't police this.
-
-The per-finding detail block follows immediately on the next line:
-
-````
-<details><summary>Details</summary>
-
-```{LANGUAGE}
-{SNIPPET}
-```
-
-{EXPLANATION}
-
-**Suggested fix:** {SUGGESTED_FIX}
-
-</details>
-````
-
-Rules:
-- `LANGUAGE` is the fenced-code language tag; empty string when unknown.
-- `SNIPPET` is the code excerpt; no surrounding fences, no trailing blank line inside the fence.
-- `EXPLANATION` and `SUGGESTED_FIX` are markdown strings; they may contain their own fenced code blocks and line breaks.
-- The `<details>` block ends with `</details>` on its own line.
-
-## Worked example
-
-A scan with 1 critical + 1 high finding renders like:
-
-````markdown
-<!-- lastlight-security-scan-version: 1 -->
-<!-- lastlight-security-scan-date: 2026-04-21 -->
-<!-- lastlight-security-scan-ts: 2026-04-21T10:00:00Z -->
-
-Reviewing 3 commits since 2026-04-14 (a1b2c3d..f9e8d7c). Findings here focus on SDLC and workflow changes — Dependabot, GitHub Code Scanning, and Renovate handle the rest. Tick the box once the underlying issue is resolved or recorded in `SECURITY.md`.
-
-## How to respond
-
-- `@last-light create issues for the criticals` — file individual issues for every Critical finding
-- `@last-light create issues for the highs` — same, for High
-- `@last-light create issues for items 1, 3, 5` — file issues for specific items by number (1-based, top to bottom)
-- `@last-light create issues for all` — every finding in this scan
-- `@last-light accept-risk for item N: <reason>` — suppress this finding in future scans
-- `@last-light false-positive for item N: <reason>` — suppress this finding in future scans
-- Comment freely to ask questions or discuss
-
-## Summary
-
-| Severity | Count |
-|----------|------:|
-| Critical | 1 |
-| High     | 1 |
-| Medium   | 0 |
-| Low      | 0 |
-| **Total**| **2** |
-
-Suppressed by `SECURITY.md`: 0 (accepted: 0, false-positives: 0). Below severity floor: 0.
-
-> Commits reviewed: a1b2c3d wire user-supplied repo into git clone, e5f6a7b add admin shell endpoint, f9e8d7c rotate webhook secret
-
-## Findings
-
-### 🔴 Critical (1)
-
-- [ ] <!-- item:1 fp:abc123def4567890 --> **Command injection in git clone** — `mcp-github-app/src/index.js:42` (semgrep · `javascript.lang.security.exec-shell-command`)
-<details><summary>Details</summary>
-
-```javascript
-execSync(`git clone ${userInput}`)
-```
-
-`userInput` originates from an HTTP request and is concatenated directly into a shell command, allowing arbitrary command execution.
-
-**Suggested fix:** use `execFileSync('git', ['clone', userInput])` so arguments aren't re-parsed by a shell.
-
-</details>
-
-### 🟠 High (1)
-
-- [ ] <!-- item:2 fp:def456abc7890123 --> **Hardcoded API key in config** — `src/config.ts:18` (gitleaks · `generic-api-key`)
-<details><summary>Details</summary>
-
-```typescript
-const API_KEY = "sk_live_abc123..."
-```
-
-A live API key is committed to the repo. Anyone with read access to the repo (or the git history of a former branch) can use it.
-
-**Suggested fix:** move the key to an environment variable (`process.env.API_KEY`) and rotate the exposed one immediately.
-
-</details>
-
-### 🟡 Medium (0)
-
-_No findings._
-
-### 🟢 Low (0)
-
-_No findings._
-````

package/skills/verify/SKILL.md

@@ -1,118 +0,0 @@
----
-name: verify
-description: Test a behaviour claim as an investigator and report whether the evidence confirms or refutes it — CONFIRMED / REFUTED / INCONCLUSIVE with bash-captured evidence. Use when asked to verify a claim, prove a fix works, or check that a PR does what it says.
-version: 1.0.0
-tags: [github, verify, testing, evidence]
----
-
-# Verify
-
-Test a specific claim about behaviour and report whether the evidence supports
-or refutes it. The deliverable is a **verdict with evidence**, not an opinion.
-
-This skill uses the **building** skill for installing dependencies and running
-the repo's build/test commands in the sandbox.
-
-> **Scope (text-evidence path).** In the default text phase the sandbox agent
-> has bash, file read, and the github tools — no browser, no screenshots, no
-> video. Prove claims with what bash can capture: test output, command
-> stdout/stderr, `curl` against a dev-server you start, log excerpts, file
-> contents, exit codes. Driving a real browser and attaching screenshots is the
-> separate `browser-qa` skill, which is staged only in the gated browser phase
-> running on the docker QA image (Playwright + Chromium). If that skill isn't in
-> your catalogue and a claim genuinely can only be shown in a rendered UI, say
-> so under **INCONCLUSIVE** rather than guessing — the browser phase will pick
-> it up when available.
-
-## Ground rule — investigator, not advocate
-
-Your job is to find out whether the claim is **true**, not to make it look true.
-A conclusive "this is broken" with clear evidence is exactly as valuable as a
-"this works". Specifically:
-
-- **Never fabricate, hardcode, mock, or stage evidence** to match an expected
-  outcome. Do not edit the code under test to make a result appear.
-- If the behaviour you observe **contradicts** the claim, that is the result —
-  report it as REFUTED with the evidence inline. Don't bury it.
-- **Don't retry a failing test hoping for a different answer.** Retry only after
-  *changing* the environment or procedure (wrong branch, missing build step),
-  and only when you have reason to believe the test setup — not the code — was
-  wrong. One unexpected result that reproduces is a finding.
-
-## Parse the target
-
-The Context block gives you the claim and (usually) a PR or issue. The claim may
-arrive as:
-
-- A **direct claim** — "ESC cancels streaming in bash mode", "the `--fork` flag
-  creates a new session".
-- A **PR reference + claim** — verify the claim against that PR's head.
-- A **PR reference only** — read the PR description + diff and identify the most
-  important, most testable claim it makes; state which claim you chose.
-
-When a PR/issue is given, read its description and diff for context (from the
-local checkout — see the **building** skill's workspace notes; don't pull the
-diff through the API).
-
-## Decide what would convince a skeptic
-
-Name the single behaviour to observe and the evidence that settles it:
-
-- **Functional claim** (a feature works, a flow completes) → run it and capture
-  the output / exit code / resulting state.
-- **Regression / fix claim** ("no longer clears the screen", "stops erroring") →
-  show the **before and after**: reproduce on the base ref, then show it gone on
-  the head ref. Both states must appear in the evidence — an off-camera "it's
-  fixed" doesn't count.
-- **Output/encoding claim** → capture the exact bytes/text (`xxd`, `od -c`, raw
-  stdout) rather than describing them.
-
-## Run the test
-
-Follow the **building** skill to install and build. Then exercise the claim with
-the minimal sequence that demonstrates it, capturing evidence at the decisive
-step. Start a dev-server in the background and `curl` it when the claim is about
-a running service; run the CLI directly when it's a CLI claim; run the targeted
-test when the repo already encodes the behaviour as a test.
-
-If the environment blocks a clean test (missing dependency the sandbox can't
-provide, build failure you can't resolve, infra that won't run), capture what
-blocked it — that drives an **INCONCLUSIVE** result, not a guess.
-
-## Report
-
-Produce your report as your **final message** in this shape — the workflow posts
-it for you (don't `github_add_issue_comment` yourself; that would double-post).
-**Keep it concise**: a one-line environment summary, the decisive evidence
-(commands + key output, not every line), and a one-paragraph conclusion — not an
-exhaustive walkthrough.
-
-```
-## Verify: <claim>
-
-**Environment:** <branch / commit, package manager, how the app was run>
-
-### Evidence
-<commands run + their captured output — fenced. Include both states for a
-before/after claim.>
-
-### Conclusion
-**CONFIRMED** | **REFUTED** | **INCONCLUSIVE**
-
-<one paragraph: what the evidence shows and why it settles the claim.>
-```
-
-- **REFUTED** — state the expected behaviour (from the claim), the observed
-  behaviour (from the evidence), include the evidence inline, and note any
-  environmental factors (branch, commit, OS). This is a valuable finding, not a
-  failed run.
-- **INCONCLUSIVE** — report exactly what blocked the test and what would be
-  needed to resolve it. Do not guess at the outcome.
-
-## Do NOT
-
-- Retry a failing test more than once without changing the environment/procedure.
-- Hardcode expected output, mock responses, or edit the code under test to force
-  a result.
-- Assume unexpected behaviour means *you* made a mistake — it may be a real bug.
-- Omit evidence that contradicts the claim.

package/workflows/answer.yaml

@@ -1,44 +0,0 @@
-kind: answer
-name: answer
-classification:
-  intent: question
-  description: |
-    QUESTION — The user is asking a substantive INFORMATIONAL question that warrants research to answer well: "how does X work?", "what's the difference between X and Y?", "how does <repo> compare to <other tool>?", "is it possible to do Z?", "why does X happen?". The deliverable is an ANSWER, not code and not a spec. QUESTION is for real questions that benefit from reading docs/code or searching the web — NOT casual chat, thanks, or one-word replies (those stay CHAT). EXPLORE shapes a NEW idea into a spec; QUESTION answers an EXISTING question about how something works or compares.
-  examples:
-    - '"how does cliftonc/lastlight compare to Vercel''s Eve framework?" → INTENT: QUESTION, REPO: cliftonc/lastlight, ISSUE: NONE, REASON: NONE'
-    - '"what''s the difference between a sandbox phase and a chat session in cliftonc/lastlight?" → INTENT: QUESTION, REPO: cliftonc/lastlight, ISSUE: NONE, REASON: NONE'
-description: |
-  Answer a question issue directly. Used when a newly-opened issue asks for
-  information, an explanation, or a comparison rather than a code change — the
-  bot researches (repo docs + web search) and posts a single sourced answer
-  comment, labels the issue `question`, and leaves it open. No agent brief, no
-  ready-for-agent, no PR.
-
-  Delivery is uniform: the agent's final message (the answer) is captured as
-  `answerResult` and posted by the harness via `postComment` — as a comment on
-  the originating issue for GitHub-initiated runs, or into the Slack thread for
-  Slack-initiated runs. The skill therefore does NOT post the answer itself; it
-  only applies the `question` label when answering a GitHub issue.
-
-  Triggered by:
-    - issue.opened webhook when the router classifies the issue as a question
-    - a Slack message classified as a question against a managed repo
-    - manual override via routes.github.issue_answer / routes.slack.answer
-
-phases:
-  - name: phase_0
-    label: Context
-    type: context
-
-  - name: answer
-    label: Answer
-    prompt: prompts/answer.md
-    skill: issue-answer
-    model: "{{models.answer}}"
-    web_search: true
-    unrestricted_egress: true
-    output_var: answerResult
-    messages:
-      on_start: "Researching and drafting an answer..."
-      on_success: "{{answerResult}}"
-      on_failure: "I couldn't put together an answer — see the logs for details."

package/workflows/build.yaml

@@ -1,129 +0,0 @@
-kind: build
-name: build
-classification:
-  intent: build
-  description: |
-    BUILD — The user is ASKING YOU (the bot) to make code changes NOW in a GitHub repo: implement a feature, fix a bug, create/send a PR, resolve an issue with code. BUILD requires a GitHub target — either an explicit repo reference (owner/name or github.com URL) in the message, OR an ISSUE TITLE context line indicating the comment is a reply on an existing issue/PR. If neither is present, classify as CHAT — local filesystem operations ("delete files in ~/foo", "clean up my downloads"), shell-style commands, or vague "build something" with no target are NOT BUILD.
-      BUILD is a REQUEST for NEW work directed at you. A comment that merely REPORTS work the human has ALREADY done is NOT BUILD — it is CHAT. Tells: past-tense ("fixed", "done", "implemented", "added a test", "pushed a fix", "handled it"), a reference to a commit the human made ("addressed in <sha>", "see commit abc123"), thanking you, or explaining/justifying a change they made in response to your review. These are status reports, not requests — classify them CHAT even when the comment is on a PR and even when it @-mentions you. Only classify BUILD when the human asks you to do NEW work (imperative request: "fix X", "now also handle Y", "can you update Z").
-  examples:
-    - '"build cliftonc/drizzle-cube#42" → INTENT: BUILD, REPO: cliftonc/drizzle-cube, ISSUE: 42, REASON: NONE'
-    - '"lets build this!" with ISSUE TITLE "Security Review" → INTENT: BUILD, REPO: NONE, ISSUE: NONE, REASON: NONE'
-    - '"go ahead" with ISSUE TITLE "Add CSV export" → INTENT: BUILD, REPO: NONE, ISSUE: NONE, REASON: NONE'
-    - '"now also handle the GET /sql case please" with ISSUE TITLE "Port adapters" → INTENT: BUILD, REPO: NONE, ISSUE: NONE, REASON: NONE'
-    - '"Thanks @last-light — addressed in 49ccadf. Fixed the nested body in the core and added a regression test; point 3 is intentional, confirmed with the maintainer." with ISSUE TITLE "Port fastify/hono/nextjs adapters" → INTENT: CHAT, REPO: NONE, ISSUE: NONE, REASON: NONE'
-    - '"done, pushed a fix for the type error in 1a2b3c4" with ISSUE TITLE "Fix build" → INTENT: CHAT, REPO: NONE, ISSUE: NONE, REASON: NONE'
-    - '"delete any files in ~/work/lastlight/docs" → INTENT: CHAT, REPO: NONE, ISSUE: NONE, REASON: NONE'
-    - '"can you remove the old docs folder for me" (no ISSUE TITLE, no repo) → INTENT: CHAT, REPO: NONE, ISSUE: NONE, REASON: NONE'
-    - '"build something cool" (no repo, no ISSUE TITLE) → INTENT: CHAT, REPO: NONE, ISSUE: NONE, REASON: NONE'
-description: "Architect -> Executor -> Reviewer build cycle"
-trigger: build
-# Render progress as a single in-place task-list comment/message that updates
-# as phases run, instead of a new comment per phase. The per-phase
-# `messages.on_*` below become the one-line detail on each checklist step.
-status_checklist: true
-
-phases:
-  - name: phase_0
-    label: Context
-    type: context
-
-  - name: guardrails
-    label: Guardrails
-    prompt: prompts/guardrails.md
-    model: "{{models.guardrails}}"
-    variant: "{{variants.guardrails}}"
-    on_output:
-      contains_BLOCKED:
-        action: fail
-        message: "Guardrails check: BLOCKED"
-        unless_label: "lastlight:bootstrap"
-        unless_title_matches: "^(guardrails:|\\[guardrails\\])"
-        bypass_message: |
-          **Guardrails check: BLOCKED** — but this is a bootstrap task
-          (label `lastlight:bootstrap` or "guardrails:" title prefix detected).
-          Proceeding with the build cycle so the architect can plan, and the
-          executor can install, the missing tooling. The guardrails report at
-          `{{issueDir}}/guardrails-report.md` lists what's missing.
-      contains_READY:
-        action: continue
-    messages:
-      on_success: "READY — foundational tooling verified — [guardrails-report.md]({{artifactUrl guardrails-report.md}})"
-      on_blocked: |
-        **Guardrails check: BLOCKED** — missing foundational tooling.
-
-        See the guardrails report on branch `{{branch}}` at `{{issueDir}}/guardrails-report.md`.
-        Once you've added the missing tooling, ask me to build this issue again — the check will re-run against the current repo state.
-
-  - name: architect
-    label: Architect
-    prompt: prompts/architect.md
-    model: "{{models.architect}}"
-    variant: "{{variants.architect}}"
-    approval_gate: post_architect
-    approval_artifact: architect-plan.md
-    approval_gate_message: |
-      **Architect analysis complete** — approval required before implementation.
-
-      - Branch: `{{branch}}`
-      - Plan: `{{issueDir}}/architect-plan.md`
-
-      **Review & decide:** {{approvalUrl}}
-      **Or comment:** `{{botMention}} approve` / `{{botMention}} reject [reason]`
-    messages:
-      # Single-line messages become the one-line detail on the checklist step,
-      # so keep them concise and link the artifact on the branch.
-      on_success: "Plan ready — [architect-plan.md]({{artifactUrl architect-plan.md}})"
-
-  - name: executor
-    label: Executor
-    prompt: prompts/executor.md
-    skill: building
-    model: "{{models.executor}}"
-    variant: "{{variants.executor}}"
-    messages:
-      on_start: "implementing the architect's plan…"
-      on_skipped_done: "already completed"
-      on_success: "Implemented — [executor-summary.md]({{artifactUrl executor-summary.md}})"
-
-  - name: reviewer
-    label: Reviewer
-    prompt: prompts/reviewer.md
-    # code-review: rubric for the review + re-review prompts.
-    # building: the fix cycle (fix.md) runs under this node and needs the gate.
-    skills: [code-review, building]
-    model: "{{models.reviewer}}"
-    variant: "{{variants.reviewer}}"
-    output_var: review
-    loop:
-      max_cycles: 2
-      on_request_changes:
-        fix_prompt: prompts/fix.md
-        fix_model: "{{models.fix}}"
-        fix_variant: "{{variants.fix}}"
-        re_review_prompt: prompts/re-reviewer.md
-      approval_gate: post_reviewer
-      approval_artifact: reviewer-verdict.md
-      messages:
-        on_cycle_start: "independent verification (cycle {{cycle}})…"
-        on_approved: "Approved — [reviewer-verdict.md]({{artifactUrl reviewer-verdict.md}})"
-        on_request_changes: "**Review: REQUEST_CHANGES** — [reviewer-verdict.md]({{artifactUrl reviewer-verdict.md}}) — fixing issues (cycle {{cycle}}/{{maxCycles}})..."
-        on_fix_start: "**Starting fix loop** (cycle {{cycle}}/{{maxCycles}}) — addressing reviewer feedback..."
-        on_fix_failed: "Fix cycle {{cycle}} failed. Proceeding to PR with known issues."
-        on_max_cycles: "**Review: REQUEST_CHANGES** after {{maxCycles}} fix cycles — see [reviewer-verdict.md]({{artifactUrl reviewer-verdict.md}}). Proceeding with remaining issues noted."
-        on_pause_for_approval: |
-          **Review: REQUEST_CHANGES** — approval required before fix loop.
-
-          - Verdict: `{{issueDir}}/reviewer-verdict.md`
-
-          **Review & decide:** {{approvalUrl}}
-          **Or comment:** `{{botMention}} approve` / `{{botMention}} reject [reason]`
-
-  - name: pr
-    label: PR
-    prompt: prompts/pr.md
-    model: "{{models.pr}}"
-    variant: "{{variants.pr}}"
-    on_success:
-      set_phase: complete
-    messages:
-      on_start: "packaging changes for review…"

package/workflows/cron-health.yaml

@@ -1,6 +0,0 @@
-kind: cron
-name: weekly-health-report
-schedule: "0 9 * * 1"
-workflow: repo-health
-context:
-  mode: report

package/workflows/cron-review.yaml

@@ -1,8 +0,0 @@
-kind: cron
-name: check-prs-awaiting-review
-schedule: "*/30 * * * *"
-workflow: pr-review
-context:
-  mode: scan
-condition:
-  unless: webhooksEnabled

package/workflows/cron-security.yaml

@@ -1,6 +0,0 @@
-kind: cron
-name: weekly-security-scan
-schedule: "0 10 * * 1"
-workflow: security-review
-context:
-  deliverSlackSummary: true

package/workflows/cron-triage.yaml

@@ -1,8 +0,0 @@
-kind: cron
-name: triage-new-issues
-schedule: "*/15 * * * *"
-workflow: issue-triage
-context:
-  mode: scan
-condition:
-  unless: webhooksEnabled