lastlight 0.16.0 → 0.16.1

package/workflows/demo.yaml

@@ -1,62 +0,0 @@
-kind: demo
-name: demo
-classification:
-  intent: demo
-  description: |
-    DEMO — The user wants you to record a DEMO VIDEO of a feature/PR: "demo this", "record a demo of the new dashboard", "make a video showing the dark-mode toggle", "show me a before/after of the fix". The deliverable is a short screen-recorded mp4 of the running web UI, not a pass/fail report and not a verdict. Prefer DEMO over QATEST/VERIFY when the user explicitly asks for a recording, a video, or "show"/"demo" rather than to test or confirm a behaviour.
-  examples:
-    - '"record a demo of this" with ISSUE TITLE "Add dark-mode toggle" → INTENT: DEMO, REPO: NONE, ISSUE: NONE, REASON: NONE'
-    - '"make a short before/after video of the fix on cliftonc/foo#12" → INTENT: DEMO, REPO: cliftonc/foo, ISSUE: 12, REASON: NONE'
-description: |
-  Record a short demo VIDEO of a PR or feature and post it. Drives the repo's
-  web UI in a real headless browser, screen-records the session, and composites
-  a titled, size-capped mp4 with ffmpeg — delivered inline on the originating
-  issue/PR (and in the dashboard Artifacts view). Does not modify code.
-
-  This workflow's demo phase runs ENTIRELY on the docker backend with the
-  browser-QA image (Playwright + Chromium + ffmpeg baked in). On gondolin, or a
-  docker host without that image, the demo phase is silently SKIPPED (graceful
-  degradation) and the run completes without a video — it never fails the
-  trigger. Compositing is ffmpeg-only (title card, optional before/after,
-  trim/speed, size cap) — there is no Remotion / cinematic pipeline.
-
-  Delivery is a single in-place status comment (`status_checklist`): the run
-  shows its phases ticking off, then the demo phase's report — with the playable
-  video embedded — becomes the comment footer via `final_message`. The agent
-  does NOT post anything itself.
-
-  Triggered by:
-    - a `@last-light demo [notes]` comment on an issue/PR
-    - manual CLI: tsx src/cli.ts demo owner/repo#N [-- "notes"]
-
-status_checklist: true
-final_message: "{{demoResult}}"
-
-phases:
-  - name: phase_0
-    label: Context
-    type: context
-    depends_on: []
-
-  # The demo phase. Gated to the docker backend AND the enriched
-  # `lastlight-sandbox-qa:latest` image (Playwright + Chromium + ffmpeg). On
-  # gondolin, or a docker host without that image, the scheduler silently skips
-  # it (the run still completes — there is no text fallback for a video).
-  - name: demo
-    label: Demo
-    depends_on: [phase_0]
-    prompt: prompts/demo.md
-    # demo: the director procedure + compose-demo.sh wrapper (primary).
-    # browser-qa: the headless driver (agent-browser.mjs) with --record-dir.
-    # building: install + run the repo's dev-server to drive.
-    skills: [demo, browser-qa, building]
-    model: "{{models.demo}}"
-    variant: "{{variants.demo}}"
-    requires_sandbox: docker
-    sandbox_image: qa
-    output_var: demoResult
-    messages:
-      on_start: "Recording a demo — installing, running the app, and capturing the UI..."
-      on_success: "Demo recorded — see the video below."
-      on_failure: "I couldn't record the demo — see the logs for details."
-      on_skipped_done: "Demo unavailable on this host (needs the docker browser-QA image)."

package/workflows/examples/bash-smoke.yaml

@@ -1,41 +0,0 @@
-kind: agent
-name: bash-smoke
-description: "Smoke test for deterministic bash + script phases (run in sandbox)"
-phases:
-  - name: phase_0
-    type: context
-
-  # Deterministic shell command in the sandbox. stdout is captured and exposed
-  # downstream via output_var.
-  - name: emit
-    type: bash
-    command: "echo hello-from-bash"
-    output_var: greeting
-
-  # A second bash phase reads the first phase's output via template substitution
-  # AND via the forwarded LL_OUT_<PHASE> env var.
-  - name: consume
-    type: bash
-    command: "echo template={{phaseOutputs.emit}} ; echo env=$LL_OUT_EMIT"
-
-  # Inline JS via node.
-  - name: js
-    type: script
-    runtime: js
-    script: |
-      console.log("node version:", process.version);
-      console.log("answer:", 6 * 7);
-
-  # Inline Python via uv. The PEP 723 block declares a dependency that uv
-  # resolves from PyPI (pypi.org is on the strict egress allowlist) into a
-  # cached venv. unrestricted_egress is NOT needed for PyPI.
-  - name: py
-    type: script
-    runtime: python
-    timeout_seconds: 120
-    script: |
-      # /// script
-      # dependencies = ["cowsay"]
-      # ///
-      import cowsay
-      cowsay.cow("hello from uv")

package/workflows/examples/parallel-review.yaml

@@ -1,36 +0,0 @@
-kind: build
-name: parallel-review
-description: >
-  Parallel architect + security review, then concurrent executor + linter,
-  with a final merge phase. Demonstrates DAG parallelism via depends_on.
-
-phases:
-  - name: phase_0
-    type: context
-
-  - name: architect
-    type: agent
-    prompt: prompts/architect.md
-    depends_on: [phase_0]
-
-  - name: security_review
-    type: agent
-    prompt: prompts/security-review.md
-    depends_on: [phase_0]
-
-  - name: executor
-    type: agent
-    prompt: prompts/executor.md
-    depends_on: [architect, security_review]
-
-  - name: linter
-    type: agent
-    prompt: prompts/linter.md
-    depends_on: [executor]
-
-  - name: pr
-    type: agent
-    prompt: prompts/pr.md
-    depends_on: [executor, linter]
-    on_success:
-      set_phase: complete

package/workflows/examples/tdd-loop.yaml

@@ -1,17 +0,0 @@
-kind: build
-name: tdd-cycle
-description: "Test-driven development loop — write a failing test, then implement until it passes"
-phases:
-  - name: phase_0
-    type: context
-  - name: write-test
-    type: agent
-    prompt: prompts/write-test.md
-  - name: implement
-    type: agent
-    prompt: prompts/implement.md
-    generic_loop:
-      max_iterations: 5
-      until_bash: "npm test"
-      interactive: false
-      fresh_context: false

package/workflows/explore.yaml

@@ -1,80 +0,0 @@
-kind: explore
-name: explore
-classification:
-  intent: explore
-  description: |
-    EXPLORE — The user wants help shaping an idea BEFORE writing code: "help me think through X", "brainstorm Y", "spec this out", "explore an idea for Z". A bare "explore" / "explore this" / "let's explore" is also EXPLORE — especially as a reply on an existing issue (ISSUE TITLE present), where the implicit object is the issue's idea. EXPLORE = shape the idea / write a spec; BUILD = write the code now.
-  examples:
-    - '"explore adding webhooks to cliftonc/drizby" → INTENT: EXPLORE, REPO: cliftonc/drizby, ISSUE: NONE, REASON: NONE'
-    - '"explore" with ISSUE TITLE "Feature: Allow configuration of otel endpoints" → INTENT: EXPLORE, REPO: NONE, ISSUE: NONE, REASON: NONE'
-    - '"explore this" with ISSUE TITLE "Add webhook support" → INTENT: EXPLORE, REPO: NONE, ISSUE: NONE, REASON: NONE'
-description: |
-  Socratic idea-shaping loop: read the existing issue/thread for context, ask
-  clarifying questions in a reply-gated loop until the shape is clear, then
-  synthesize a detailed spec and publish it (as a comment on the originating
-  issue for GitHub-initiated runs, or as a new issue in EXPLORE_DEFAULT_REPO
-  for Slack-initiated runs).
-
-trigger: explore
-# Single in-place task-list comment/message instead of a comment per phase.
-# Reply-gate questions and the published spec still post as standalone notes.
-status_checklist: true
-
-phases:
-  - name: phase_0
-    label: Context
-    type: context
-
-  - name: read_context
-    label: Read existing context
-    prompt: prompts/explore-read.md
-    model: "{{models.explore}}"
-    output_var: baseline
-    unrestricted_egress: true
-    web_search: true
-    messages:
-      on_start: "Cloning `{{owner}}/{{repo}}` and reading the codebase..."
-
-  - name: socratic
-    label: Socratic questioning
-    prompt: prompts/explore-ask.md
-    model: "{{models.explore}}"
-    unrestricted_egress: true
-    web_search: true
-    generic_loop:
-      max_iterations: 8
-      until: "output.contains('READY')"
-      interactive: true
-      gate_kind: reply
-      scratch_key: socratic
-      # A degenerate turn (agent exits with no question) retries once; if it's
-      # still empty, advance to synthesis with the Q&A gathered so far instead
-      # of hard-failing the whole explore run.
-      on_soft_failure:
-        retries: 1
-        then: complete
-      gate_message: |
-        _Just reply to this thread with your answers — no need to @mention me. I'll keep going until we have enough to write this up._
-        _Say `we're done` at any point to jump straight to the spec draft._
-
-  - name: synthesize
-    label: Synthesize spec
-    prompt: prompts/explore-synthesize.md
-    model: "{{models.architect}}"
-    output_var: spec
-    unrestricted_egress: true
-    web_search: true
-    messages:
-      on_start: "Writing up the spec from our conversation..."
-
-  - name: publish
-    label: Publish spec
-    prompt: prompts/explore-publish.md
-    model: "{{models.executor}}"
-    output_var: publishResult
-    on_success:
-      set_phase: complete
-    messages:
-      on_start: "Publishing the spec..."
-      on_success: "{{publishResult}}"
-      on_failure: "Failed to publish the spec — see the logs for details."

package/workflows/issue-comment.yaml

@@ -1,15 +0,0 @@
-kind: comment
-name: issue-comment
-description: |
-  Respond conversationally to a comment on an issue. Used when a maintainer
-  comments on an issue without explicitly asking for a build — the bot
-  replies in-thread without invoking the full Architect → Executor cycle.
-
-  Triggered by:
-    - issue_comment.created webhook (when classifier returns "lightweight")
-
-phases:
-  - name: respond
-    label: Respond
-    skill: issue-comment
-    model: "{{models.comment}}"

package/workflows/issue-triage.yaml

@@ -1,22 +0,0 @@
-kind: triage
-name: issue-triage
-classification:
-  intent: triage
-  description: |
-    TRIAGE — The user wants to scan/triage issues on a repo: "triage cliftonc/repo", "scan for new issues", "can you triage <repo>?".
-  examples:
-    - '"could you triage https://github.com/foo/bar?" → INTENT: TRIAGE, REPO: foo/bar, ISSUE: NONE, REASON: NONE'
-description: |
-  Triage a GitHub issue: read it, classify it, label it, and act on stale or
-  incomplete reports. Single agent invocation, no PR creation.
-
-  Triggered by:
-    - issue.opened webhook
-    - cron scan over managed repos
-    - manual CLI: tsx src/cli.ts cliftonc/owner/repo#N
-
-phases:
-  - name: triage
-    label: Triage
-    skill: issue-triage
-    model: "{{models.triage}}"

package/workflows/pr-comment.yaml

@@ -1,16 +0,0 @@
-kind: comment
-name: pr-comment
-description: |
-  Answer a maintainer's question about an open PR with concrete, code-cited
-  evidence. The PR-side counterpart to `issue-comment` — distinguished
-  because PR questions need the diff and a higher file-read cap.
-
-  Triggered by:
-    - issue_comment.created webhook on a PR (when classifier returns a
-      non-build intent and prNumber is set)
-
-phases:
-  - name: respond
-    label: Respond
-    skill: pr-comment
-    model: "{{models.comment}}"

package/workflows/pr-fix.yaml

@@ -1,17 +0,0 @@
-kind: pr-fix
-name: pr-fix
-description: "Lightweight PR fix — no architect/reviewer, just fix and push"
-trigger: pr-fix
-# Single in-place task-list comment/message instead of a comment per phase.
-status_checklist: true
-
-phases:
-  - name: fix
-    label: Fix
-    prompt: prompts/pr-fix.md
-    skill: building
-    model: "{{models.pr-fix}}"
-    messages:
-      on_start: "On it — fixing PR #{{prNumber}}..."
-      on_success: "**Fix pushed** to `{{branch}}`. CI should re-run automatically."
-      on_failure: "**Fix failed** — I wasn't able to resolve this automatically."

package/workflows/pr-review.yaml

@@ -1,50 +0,0 @@
-kind: review
-name: pr-review
-classification:
-  intent: review
-  description: |
-    REVIEW — The user wants a code review. Either repo-wide ("review cliftonc/repo", "check PRs", "can you review PRs on <repo>?") OR, when the comment is a reply on a PR (ISSUE TITLE present), a request to review THIS PR: "review this", "can you review this?", "please review", "take a look at this PR", "give this a review". The deliverable is a formal PR review (inline comments on the diff). Prefer REVIEW over CHAT whenever there's a clear "review"/"take a look" request on a PR.
-  examples:
-    - '"please review https://github.com/foo/bar/pull/42" → INTENT: REVIEW, REPO: foo/bar, ISSUE: 42, REASON: NONE'
-    - '"can you review this?" with ISSUE TITLE "Add HTML sanitizer for messages" → INTENT: REVIEW, REPO: NONE, ISSUE: NONE, REASON: NONE'
-    - '"take a look at this PR when you get a chance" with ISSUE TITLE "Port fastify adapter" → INTENT: REVIEW, REPO: NONE, ISSUE: NONE, REASON: NONE'
-description: |
-  Review a single GitHub pull request: read the diff, check for issues, and
-  post structured feedback. Does not run a full build cycle and does not
-  modify code.
-
-  Triggered by:
-    - pr.opened webhook
-    - cron scan over managed repos
-    - manual CLI: tsx src/cli.ts review owner/repo#N
-
-phases:
-  - name: review
-    label: Review
-    # pr-review: the PR procedure (primary). code-review: the finding-tier +
-    # what-to-check rubric. No `building` — pr-review is a pure code review; CI
-    # validates that the change builds/runs.
-    #
-    # The agent does NOT submit the review itself — it writes structured
-    # findings (content only: skip? / summary / event / findings[]) to
-    # .lastlight/pr-review/findings.json. The first-class `post-review` action
-    # below reads that file and posts one formal review.
-    skills: [pr-review, code-review]
-    model: "{{models.review}}"
-    variant: "{{variants.review}}"
-
-  # First-class, in-process submission (type: post-review → PhaseExecutor.
-  # runPostReview). Reads the agent's findings.json for the review *content*
-  # (skip? / summary / event / findings[]) and supplies everything else from
-  # the harness itself — PR number (run context), base ref (baseBranch), head
-  # SHA + diff (the pre-cloned checkout) — so the AI never hand-copies metadata.
-  # It anchors each finding to a changed line, demotes off-diff findings to the
-  # body (GitHub 422s on off-diff lines), and posts ONE review via GitHubClient
-  # (App auth in prod; token + githubApiBaseUrl against the eval mock). A
-  # genuine failure — missing findings after a real review, or a GitHub error
-  # that survives the body-only retry — FAILS this phase visibly; a legitimate
-  # `skip` succeeds without posting. Idempotent on resume (no-op if a bot review
-  # already exists on the head SHA).
-  - name: post-review
-    label: Post inline review
-    type: post-review

package/workflows/prompts/answer.md

@@ -1,68 +0,0 @@
-You are answering a **question** — the user wants information, an explanation,
-or a comparison, not a code change. Read the `issue-answer` skill for the full
-procedure and rules, then follow it. This prompt gives you the specific question
-and how your answer is delivered.
-
-## The question
-
-{{#if issueTitle}}**Issue title:** {{issueTitle}}{{/if}}
-{{#if issueBody}}
-**Issue body:**
-{{issueBody}}
-{{/if}}
-{{#if commentBody}}
-**Question:**
-{{commentBody}}
-{{/if}}
-
-Target repo: **{{owner}}/{{repo}}**
-{{#if issueNumber}}Originating GitHub issue: **#{{issueNumber}}**{{/if}}
-
-## Workspace
-
-The repo is (or will be) in a `{{repo}}/` subdirectory under your cwd:
-
-```
-ls -la
-```
-
-If you see `{{repo}}/.git/`, the harness pre-cloned it — `cd {{repo}}`.
-Otherwise `git clone https://github.com/{{owner}}/{{repo}}.git {{repo}}` and
-`cd` in. Read what the question needs (`CONTEXT.md`, `README`, `docs/`,
-`spec/`, code) — don't survey the whole tree. Use the `web_search` /
-`web_fetch` tools for anything outside this repo (other tools, frameworks,
-"X vs Y" comparisons); cite what you use.
-
-## How your answer is delivered — read carefully
-
-Your **final message is the answer**, and the harness posts it for you:
-{{#if issueNumber}}
-- as a comment on issue #{{issueNumber}}.
-{{/if}}
-{{#if !issueNumber}}
-- back into the Slack thread this question came from.
-{{/if}}
-
-So make your final message the complete, self-contained answer in clean
-markdown — no "here's what I'll do" preamble, no meta-commentary.
-
-**Converge — don't get cut off.** Your tool budget is bounded. The moment you
-think "I have enough" or "let me just confirm one more thing", stop researching
-and write the answer in that same turn — do **not** fire another tool call
-first. A reply truncated mid-research is worse than one that omits a minor
-detail; flag anything unverified as unverified rather than chasing it with your
-last turn.
-
-**Do NOT post the answer yourself** (no `github_add_issue_comment`) — that would
-double-post. The only GitHub write you make is the label:
-
-{{#if issueNumber}}
-- Apply the `question` label to issue #{{issueNumber}} with `github_add_labels`
-  (ensure it exists first with one `github_ensure_labels` call —
-  `[{name: "question", color: "d876e3"}]`; it's idempotent, no 422 to handle).
-  Leave the issue open.
-{{/if}}
-{{#if !issueNumber}}
-- This is a Slack-initiated question — there is no issue to label. Just produce
-  the answer.
-{{/if}}

package/workflows/prompts/architect.md

@@ -1,44 +0,0 @@
-You are the ARCHITECT. Analyze the codebase and produce an implementation plan.
-
-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 planning:
-1. Read CLAUDE.md (and CONTRIBUTING.md if present) for project-specific guidance.
-2. Read {{issueDir}}/guardrails-report.md for the test/lint/typecheck commands.
-
-CONTEXT:
-{{contextSnapshot}}
-
-OUTPUT — write the plan to {{issueDir}}/architect-plan.md:
-- Problem Statement (2-5 sentences with file:line references)
-- Summary of what needs to change
-- Files to modify — an EXHAUSTIVE manifest the executor implements verbatim:
-  - List EVERY file to change, with the exact path, line/symbol anchor, and what
-    to change. The executor should not need to go hunting for files.
-  - Enumerate ALL members of any multi-file group. If a change touches one
-    member of a set, glob/`ls` the set and list them ALL — e.g. every i18n
-    locale under the locales dir, every adapter/provider variant, every test
-    file for the touched module. Name the exact keys/identifiers to add (e.g.
-    the precise i18n keys). Missing a sibling here forces the executor to
-    rediscover it mid-implementation.
-- Commands — copy the exact test / lint / typecheck commands from
-  guardrails-report.md into the plan so the executor uses them directly.
-- Implementation approach (step-by-step)
-- Risks and edge cases
-  - For every input the design does NOT fully support, specify **warn-and-skip**
-    or **warn-and-surface** behaviour explicitly. A silent default, a silently
-    skipped case, or a dropped output is a correctness bug — never plan for one.
-    If an input can't be handled, the plan must say how the user is told (a
-    warning, a surfaced error), not let it disappear.
-- Test strategy
-- Estimated complexity: simple / medium / complex
-
-AFTER WRITING:
-1. mkdir -p {{issueDir}}
-2. Write architect-plan.md
-3. Write status.md with current_phase: architect
-{{#if !externalizeArtifacts}}4. git add .lastlight/ && git commit -m "docs: architect plan 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}}
-
-OUTPUT: The branch name and a brief summary (3-5 lines).

package/workflows/prompts/classifier.md

@@ -1,60 +0,0 @@
-You are a router for messages directed at a GitHub/Slack bot.
-Classify the user's message into exactly one category, and extract any repository or issue references.
-
-Categories:
-{{categories}}
-APPROVE — The user is approving a pending gate: "approve", "go ahead", "looks good, continue", "yes proceed".
-REJECT — The user is rejecting a pending gate: "reject", "abort", "cancel this", "no don't proceed". Extract any reason given.
-STATUS — The user wants to know what's running: "status", "what's running", "any tasks active?".
-RESET — The user wants to start a fresh session: "new", "reset", "start over", "fresh session".
-CHAT — Anything else: questions, conversation, thanks, general discussion, and status reports of work the human already did ("thanks, fixed in <sha>", "addressed your comments", "done — added tests").
-
-Polite or question phrasings are still clear intent. "Can you do a security review of X?",
-"could you triage <repo>?", "please review PRs on <repo>" are SECURITY, TRIAGE, REVIEW
-respectively — not CHAT. The "prefer CHAT when ambiguous" rule only applies when the
-message has no clear action verb. Presence of "security review", "triage", "review PRs",
-"scan for vulnerabilities", etc. makes the intent unambiguous regardless of politeness.
-
-When ambiguous between EXPLORE and CHAT, prefer CHAT. Only pick EXPLORE when the user is explicitly asking for brainstorming / spec-shaping / design exploration — OR gives a bare "explore"/"explore this" command (see the issue-reply rule below), which is unambiguous, not chat.
-When ambiguous between QUESTION and CHAT, prefer CHAT — only pick QUESTION for a substantive informational question that genuinely benefits from research (reading docs/code or a web search). Casual conversation, greetings, thanks, and trivial one-liners stay CHAT.
-When ambiguous between BUILD and CHAT, prefer CHAT.
-When ambiguous between VERIFY/QATEST and REVIEW/CHAT, prefer the existing category — only pick VERIFY or QATEST when the user explicitly asks you to test, run, confirm, or exercise a behaviour/flow.
-When ambiguous between DEMO and VERIFY/QATEST, prefer the existing category — only pick DEMO when the user explicitly asks for a video, a recording, or to "demo"/"show" the feature.
-When ambiguous between APPROVE/REJECT and CHAT, prefer CHAT — only classify as APPROVE/REJECT when the intent is clearly about a pending workflow gate.
-
-Repo extraction: always emit REPO as "owner/name" (never a URL). If the message contains
-a github.com URL, convert it: https://github.com/cliftonc/lastlight → cliftonc/lastlight.
-URL paths like /issues/42 or /pull/5 should populate ISSUE as well.
-
-When the message is a reply on an existing issue/PR, the issue title is provided
-as ISSUE TITLE. Short imperative replies classify by their verb, with the issue
-as the implicit object — the "prefer CHAT when ambiguous" rule does NOT apply to
-a clear command directed at the issue's subject:
-- "lets build this", "build it", "go ahead", "ship it", "do it", "implement
-  this", "make it so" → BUILD (write the code now).
-- "explore", "explore this", "let's explore", "think this through", "spec this
-  out", "brainstorm this" → EXPLORE (shape the idea / write a spec first).
-- "review this", "can you review this", "please review", "take a look",
-  "give this a review" → REVIEW (do a real code review now; on a PR this means
-  review the current PR's diff).
-A bare command word ("explore", "build", "review") on an existing issue/PR is a
-clear command, NOT ambiguous chat.
-This verb rule is for IMPERATIVE requests only. A PR/issue reply that REPORTS
-already-completed work or responds to your review — "thanks, fixed in <sha>",
-"addressed in commit abc123", "done, added a regression test", "this is
-intentional, confirmed with the maintainer" — is a status report, NOT a
-command. Classify it CHAT regardless of the ISSUE TITLE or an @mention. Do not
-let words like "fix"/"build"/"add" inside a past-tense report flip it to BUILD.
-
-Respond in exactly this format (each on its own line, no extra text):
-INTENT: {{intentTokens}}
-REPO: owner/name or NONE
-ISSUE: number or NONE
-REASON: text or NONE
-
-Examples:
-{{examples}}
-"thanks, that makes sense!" → INTENT: CHAT, REPO: NONE, ISSUE: NONE, REASON: NONE
-"approve" → INTENT: APPROVE, REPO: NONE, ISSUE: NONE, REASON: NONE
-"reject, the plan is too complex" → INTENT: REJECT, REPO: NONE, ISSUE: NONE, REASON: the plan is too complex
-"what's running?" → INTENT: STATUS, REPO: NONE, ISSUE: NONE, REASON: NONE

package/workflows/prompts/classify-adds-info.md

@@ -1,17 +0,0 @@
-You are deciding whether a new comment on a GitHub issue,
-written by the issue's reporter, should re-open triage of that issue.
-
-ADDS_INFO — the comment adds NEW substantive information that changes the problem
-statement: extra details, reproduction steps, environment specifics, a concrete
-example, clarification of the request, a scope change, or an answer to a question
-triage previously asked. The kind of comment that would make a maintainer re-read
-and re-classify the issue.
-
-NOISE — the comment adds nothing that changes triage: thanks, acknowledgement,
-agreement ("sounds good", "yes please"), a "+1"/me-too, a status update with no
-new specifics, a question directed back at the maintainer, or general chatter.
-
-When genuinely unsure, answer NOISE — re-triage should only fire on a clear
-addition of information.
-
-Respond with exactly one word on its own line: ADDS_INFO or NOISE