lastlight 0.13.0 → 0.15.0

package/workflows/pr-review.yaml

@@ -1,5 +1,13 @@
 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

package/workflows/prompts/classifier.md

@@ -0,0 +1,60 @@
+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

@@ -0,0 +1,17 @@
+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

package/workflows/qa-test.yaml

@@ -1,5 +1,12 @@
 kind: qa-test
 name: qa-test
+classification:
+  intent: qa-test
+  description: |
+    QATEST — The user wants you to drive an app or CLI through a flow and report step-level pass/fail: "qa test the signup flow", "run through login and tell me what breaks", "smoke-test the CLI commands", "exercise the checkout flow". The deliverable is a step-by-step QA report. Prefer QATEST over VERIFY when it's a multi-step flow to exercise rather than a single claim to confirm.
+  examples:
+    - '"qa test the login flow on this PR" with ISSUE TITLE "Add login" → INTENT: QATEST, REPO: NONE, ISSUE: NONE, REASON: NONE'
+    - '"run through the signup flow and tell me what breaks" with ISSUE TITLE "Signup v2" → INTENT: QATEST, REPO: NONE, ISSUE: NONE, REASON: NONE'
 description: |
   Run an automated QA flow against a repo's CLI or locally-served app and report
   step-level pass/fail with evidence. It installs and runs the code in the

package/workflows/security-review.yaml

@@ -1,5 +1,13 @@
 kind: health
 name: security-review
+classification:
+  intent: security
+  description: |
+    SECURITY — The user wants a security scan/review of a repo: "security review cliftonc/repo", "scan for vulnerabilities", "check security", "can you do a security review of <repo>?".
+  examples:
+    - '"run a security review on cliftonc/lastlight" → INTENT: SECURITY, REPO: cliftonc/lastlight, ISSUE: NONE, REASON: NONE'
+    - '"can you do a security review of https://github.com/cliftonc/lastlight" → INTENT: SECURITY, REPO: cliftonc/lastlight, ISSUE: NONE, REASON: NONE'
+    - '"scan https://github.com/cliftonc/lastlight for vulnerabilities" → INTENT: SECURITY, REPO: cliftonc/lastlight, ISSUE: NONE, REASON: NONE'
 description: |
   Scan the target repository for security issues using open-source tools
   (npm audit, semgrep, gitleaks) plus AI code review. Files ONE summary

package/workflows/verify.yaml

@@ -1,5 +1,13 @@
 kind: verify
 name: verify
+classification:
+  intent: verify
+  description: |
+    VERIFY — The user wants you to TEST whether a specific claim or behaviour is actually true and report the evidence: "verify that the rate limiter blocks", "does this PR really fix the crash?", "confirm X actually works", "check that Y no longer happens", "prove the --fork flag creates a new session". The deliverable is a CONFIRMED/REFUTED verdict backed by RUNNING the code — not a code change and not a code-quality review. Prefer VERIFY over REVIEW when the user wants proof a behaviour works/is fixed, rather than an assessment of the diff.
+  examples:
+    - '"verify that the --fork flag creates a new session in cliftonc/foo#12" → INTENT: VERIFY, REPO: cliftonc/foo, ISSUE: 12, REASON: NONE'
+    - '"does this actually fix the crash?" with ISSUE TITLE "Fix null deref on resize" → INTENT: VERIFY, REPO: NONE, ISSUE: NONE, REASON: NONE'
+    - '"can you confirm the rate limiter actually blocks at 100 req/s?" with ISSUE TITLE "Add rate limiter" → INTENT: VERIFY, REPO: NONE, ISSUE: NONE, REASON: NONE'
 description: |
   Verify a behaviour claim against a repo or PR and report whether the evidence
   confirms or refutes it. It installs and runs the code in the sandbox, captures