@nt-ai-lab/opencode-skillz 0.3.14 → 0.4.1

package/AGENTS.md

@@ -7,6 +7,10 @@ Purpose: package OpenCode workflow assets as a plugin.
 - `index.js`: plugin entrypoint; auto-registers bundled commands and agents.
 - `commands/*.md`: command definitions (frontmatter + template body).
 - `agents/*.md`: custom agent definitions (frontmatter + full prompt body).
+- `src/tools/lint.ts`: OpenCode lint tool entrypoint.
+- `src/tools/*-tool.ts`: other OpenCode tool entrypoints.
+- `src/tools/infra/<concept>/`: support code used by tools but not itself an OpenCode tool.
+- `src/tools/infra/lint/guidance.ts`: lint failure remediation guidance injected by the lint tool.
 
 ## Conventions
 
@@ -19,6 +23,33 @@ Purpose: package OpenCode workflow assets as a plugin.
 - Prefer minimal additions; only add new commands when needed.
 - Do not add `agent:` in command frontmatter unless the command must force a specific agent.
 
+## Lint guidance mechanism
+
+- `src/tools/lint.ts` prepends lint failures with remediation guidance.
+- `src/tools/infra/lint/guidance.ts` owns the generic message and rule-specific guidance.
+- Update `src/tools/infra/lint/guidance.ts` when adding portable lint rules that represent design quality, test quality, type-safety, or security constraints.
+- Guidance must direct agents to fix the underlying problem, not suppress rules, delete coverage, or weaken assertions.
+
+## Lint boundaries: portable tool rules vs repo-only checks
+
+- `scripts/living-architecture-eslint.config.mjs` is bundled into the lint tool and applies to every codebase that uses `nt_skillz_lint`.
+- Do not add opencode-skillz repository organization rules to `scripts/living-architecture-eslint.config.mjs`.
+- Only add rules to `scripts/living-architecture-eslint.config.mjs` when the rule is intentionally portable across all target repositories.
+- Repository-only checks belong in this repo's local validation flow, such as a dedicated script wired into this repo's `package.json` scripts.
+- `scripts/check-tools-folder-boundary.mjs` is a repo-only check. It enforces that top-level `src/tools/*.ts` files are real OpenCode tool entrypoints and support code lives under `src/tools/infra/<concept>/`.
+- Before adding any lint rule, decide whether it is portable product behavior or local repository hygiene. Mixing those two scopes is a release-impacting mistake.
+
+## Command writing rules
+
+### Be eplicit, avoid vagueness
+
+Commands are run by agents that may choose different valid-looking tool calls unless the command removes that choice. A command must include the exact operation, command text, query text, arguments, and expected fields when those details are known. This prevents each run from rediscovering APIs, using different command variants, or failing because the agent guessed a tool shape.
+
+Examples:
+- Bad: Fetch unresolved GitHub review threads.
+- Good: Run `gh pr view "$PR_NUMBER" --json reviewThreads` and read unresolved threads from the returned `reviewThreads` field.
+- Good: If GraphQL is required, include the full `gh api graphql ...` command, the full query, variables, and response path.
+
 ## Versioning strategy
 
 - Use SemVer in `package.json`.

package/agents/default.md

@@ -1,6 +1,7 @@
 ---
 description: Minimal default robot agent
 mode: primary
+temperature: 2
 preload_commands: software-design, writing-tests
 ---
 
@@ -15,6 +16,7 @@ You are a tool that takes user commands and produces responses.
 - Never flatter, or mirror user emotion.
 - Use neutral phrasing such as "That is correct" or "That may not be correct" when confirming or challenging.
 - Keep responses concise, factual, and operational but use simple and clear terminology rather than advanced vocabulary and complex jargon. 
+- Use plain human language. Avoid stacked phrases such as "current PR branch lint config" or "invalid PR description lint output". Name the exact thing instead, such as the file, command, tool result, or PR description section.
 
 
 # Behavior rules (non-negotiable, 100% adherence mandatory)
@@ -27,4 +29,6 @@ You are a tool that takes user commands and produces responses.
 
 - NEVER bypass rules or do workarounds to make a problem go away. If there are lint violations in code, fix the violations don't disable linting. If test coverage thresholds are not met, add tests, don't ignore code from coverage.
 
+- Do not sacrifice code quality or test coverage to satisfy lint rules. These rules are not objectives; they are signs that the code needs to be split, simplified, or clarified.
+
 - Tight feedback loops: validate your work regularly. Don't modify 50 files and then run lint and find 100 errors. Run lint after each file edit. Make small regular commits.

package/agents/tdd.md

@@ -2,5 +2,6 @@
 description: TDD-focused agent with preloaded process commands
 mode: primary
 extends: default
+temperature: 2
 preload_commands: tdd-process, tactical-ddd
 ---

package/commands/plan.md

@@ -2,81 +2,171 @@
 description: Create an implementation plan.
 ---
 
-Plan:
+Plan request:
 $ARGUMENTS
 
-Create a detailed implementation plan broken down into slices of functionality and not layer. Good Example: "Fuzzy searching on first name" is a slice of value. Bad Example: "Add data types" is just a layer of code that needs to be assembled later.
+Create an implementation plan for the request. The plan must sequence value slices, not implementation layers.
 
-Search all relevant existing code. If some of the code is in other repos, look there as well. Don't be lazy, more too much research is better than not enough. If you're unsure ask the user. As a general rule, if the supporting documenting or existing code references another repository, you should almost certainly be looking there.
+## Clarification gate
 
-For each slide of value, challenge if it's needed. Find supporting evidence.
+Before creating the final plan, resolve every question that affects the plan.
 
-## Context
+First try to answer questions through available evidence:
+- existing code
+- source files and tests
+- repository documentation
+- issues and pull requests
+- Notion pages
+- linked design documents
+- external API documentation
+- related repositories mentioned by code or documentation
 
-The plan starts with a context section explaining the problem that is being solved along with any relevant information like constraints. It also references any existing materials like notion pages. Context should be rich so that an engineer has all the information they need.
+Do not ask the user questions already answered by evidence. Use the evidence and cite it in the plan.
 
-## Slices
+Ask the user only when evidence cannot answer a plan-affecting question, or when the answer is a product or business decision.
 
-List each slice of value that needs to be delivered and justify why it is necessary in a table with the column headings `slice`, `description`, `justification`.
+Check for missing information that would change:
+- the problem being solved
+- user value
+- scope
+- explicit out-of-scope behavior
+- constraints
+- related code, docs, issues, Notion pages, or repositories
+- dependencies or external systems
+- acceptance and validation outcomes
+- risks or edge cases
 
-## Task checklist
+If any plan-affecting question remains after research, do not create the final plan. Respond only with this format:
 
-A plan is broken down into tasks. One task for each slice of value like "Fuzzy searching on first name" and each task is broken down into subtask. The task itself and each subtask are checklist items. This is crucial so that progress can be recorded by the engineer.
+```md
+## Clarification needed
 
-Tasks should be detailed so that an engineer has all the information they need to implement the task.
+<brief explanation of what could not be resolved through research>
 
-## Linting
+1. <question>
+   Reason: <why this affects the plan>
+   Why evidence could not answer it: <what was checked and why it was insufficient>
+   Recommended: <optional recommendation with evidence, if available>
+```
 
-Include a lint check before each commit:
-- get the staged changed `.ts` and `.tsx` files
-- run `nt_skillz_lint` on the changed files
-- do not create the commit unless the lint check passes
+Ask at most 5 clarification questions in one response. Ask only questions that materially affect the plan. If more than 5 plan-affecting questions exist, ask the 5 highest-impact questions first.
 
-## Test Coverage
+A recommended answer is not an assumption. Do not proceed with the final plan using a recommended answer until the user confirms it or provides a different answer.
 
-Include a 100% Vitest coverage check before each commit:
-- get the staged changed `.ts` and `.tsx` files
-- ignore tests, declaration files, config files, and fixtures
-- run `/nt-skillz:vitest-coverage <file>` for each remaining file
-- do not create the commit unless every remaining file passes with 100% Vitest coverage
+The final plan must not contain open questions.
 
-## Software design & architecture
+## Research expectations
+
+Search all relevant existing code and documentation before finalizing the plan. If code or documentation references another repository that may affect the plan, inspect that repository before finalizing the plan.
+
+If a required repository, document, issue, Notion page, or other evidence source is inaccessible and that evidence affects the plan, stop and report the blocker using the clarification-needed format. Do not guess and do not create the final plan.
+
+Do not search unrelated repositories.
+
+Every factual claim about existing behavior, constraints, dependencies, or related systems must be backed by evidence from code, docs, issues, Notion pages, linked materials, or referenced repositories. If no evidence was found, do not state the claim as fact.
+
+## Planning level
+
+The proposed solution may discuss software and technical direction at a planning level. Include only solution design details that are strictly required to explain the plan or are directly supported by existing code and documentation.
+
+Do not add new design elements just because they seem useful. Leave non-essential component structure, file layout, classes, functions, internal boundaries, and implementation mechanics to the software design and implementation steps.
+
+Validation must describe observable outcomes and required quality gates. Do not prescribe exact test file names, test helper structure, mocks, fixtures, or implementation-level test mechanics unless they already exist and are directly relevant evidence.
+
+## Value slices
+
+A value slice is a user-observable capability or behavior.
+
+Good value slice: "Fuzzy searching on first name".
+Bad value slice: "Add data types".
+
+For each slice, challenge whether it is necessary. The `justification` column must explain the evidence that the slice is necessary. If the evidence is weak or unclear, do not include the slice in the final plan; ask for clarification instead.
+
+Tasks must be organized by value slice so each slice can be implemented and verified independently.
+
+Map technical work to the value slice it supports. For example, models, services, interfaces, schemas, and tests belong inside the value-slice task they enable.
 
-Leave a placeholder `<software design and architecture>`.  This will be filled in by a following command.
+Do not create standalone top-level tasks for technical layers unless that task independently delivers user value.
 
-### Template
+Each value slice must include an independent verification outcome. The outcome must prove that slice works without relying on later slices. If a slice cannot be independently verified, merge it with the slice that makes it valuable or explain why it must remain separate.
+
+## Output format
+
+If the final output does not follow the required template exactly, the plan is invalid.
+
+Do not add extra top-level sections. Do not rename headings. Do not omit required sections.
+
+The final plan may use only these top-level headings:
+- `## Context`
+- `## Slices`
+- `## Software design & architecture`
+- `## Tasks`
+
+Return exactly this Markdown structure:
 
 ```md
 ## Context
 
-- Problem:
-- Constraints:
-- Related materials:
+### Problem
 
-## Software design & architecture
+<prose only; describe the problem being solved, not the solution>
+
+### Evidence reviewed
+
+<prose only; summarize the code, documentation, linked materials, and repositories that informed the plan. Include specific paths, document names, links, or repository names.>
+
+### Constraints
 
+<prose only; describe constraints, dependencies, existing materials, affected systems, and known limits>
 
+### Proposed solution
+
+<prose only; describe the intended technical direction at a planning level. Include only solution design details that are strictly required to explain the plan or are directly supported by existing code and documentation.>
+
+## Slices
+
+| slice | description | justification |
+|---|---|---|
+| <value slice> | <user-observable capability or behavior> | <evidence that this slice is necessary> |
+
+## Software design & architecture
+
+<software design and architecture>
 
 ## Tasks
 
-- [ ] Task 1: <slice of functionality>
-  - [ ] Subtask 1.1
-  - [ ] Subtask 1.2
-  - [ ] Run `nt_skillz_lint` on changed `.ts` and `.tsx` files
-  - [ ] Verify 100% test coverage using  `/nt-skillz:vitest-coverage <file>`
-  - [ ] Commit the changes
-- [ ] Task 2: <slice of functionality>
-  - [ ] Subtask 2.1
-  - [ ] Subtask 2.2
-  - [ ] Run `nt_skillz_lint` on changed `.ts` and `.tsx` files
-  - [ ] Verify 100% test coverage using  `/nt-skillz:vitest-coverage <file>`
-  - [ ] Commit the changes
+- [ ] Task: <value slice>
+  - [ ] Read the software design and architecture section before implementation.
+  - [ ] Implement the value slice according to the software design and architecture.
+  - [ ] Verify outcome: <observable behavior that proves the slice works independently>.
+  - [ ] Verify the implementation aligns with the software design and architecture.
+  - [ ] Run `nt_skillz_lint` on changed `.ts` and `.tsx` files.
+  - [ ] Verify 100% test coverage using `/nt-skillz:vitest-coverage <file>`.
+  - [ ] Commit the changes.
 ```
 
-## Important Notes
+Tasks must be planning-level only. They must describe the value slice, intended outcome, and required validation. They must not prescribe internal design, files, components, classes, functions, or modules unless those details already exist and are directly relevant evidence.
+
+## Final self-check
+
+Before returning the final plan, verify:
+- The output uses exactly the required top-level headings.
+- The output does not add extra top-level sections.
+- The Problem section contains no solution language.
+- The Context subsections are prose, not bullet lists.
+- The Evidence reviewed section names specific sources.
+- The Slices table exists and every slice includes evidence-backed justification.
+- Every task maps to exactly one value slice.
+- Every task stays at planning level and avoids premature design details.
+- Every task includes an observable verification outcome.
+- The software design and architecture section contains only `<software design and architecture>`.
+- No assumptions are presented as facts.
+- No open questions remain.
 
-- Stop if you cannot implement the plan as described. If the proposed design or functionality will not work in practice, discuss with the user
+After producing the final plan, stop. Do not implement. Do not run the software design and architecture step. Wait for the user to invoke the next command.
 
-- Ensure you mark of each subtask when complete
+## Important notes
 
-- If parts of the plan are incomplete, missing, or placeholders refuse to implement and tell the user. Do not implement a flawed plan
+- Stop if the plan cannot be completed without unanswered plan-affecting questions.
+- If parts of a plan are incomplete, missing, or placeholders other than `<software design and architecture>` remain, refuse to implement and tell the user.
+- During implementation, ensure each subtask is marked off when complete.

package/commands/resolve-pr-feedback.md

@@ -0,0 +1,138 @@
+---
+description: Resolve approved GitHub pull request feedback with local evidence, validation, replies, and thread resolution
+---
+
+Resolve GitHub pull request feedback for:
+$ARGUMENTS
+
+## Required PR input
+
+1. Extract both values from `$ARGUMENTS`:
+   - pull request number
+   - full pull request URL
+2. If either value is missing, stop and ask for the missing value.
+3. Do not fetch repository metadata with `gh repo view`; use the local worktree and the provided pull request values.
+
+## Feedback discovery
+
+1. Call the `nt_skillz_pr_feedback` tool with exactly these arguments:
+
+```json
+{
+  "pullRequestNumber": "<pull request number>",
+  "pullRequestUrl": "<full pull request URL>"
+}
+```
+
+2. Use the tool output as the feedback source of truth.
+3. Do not replace the tool with ad hoc `gh pr view`, `gh pr diff`, `gh api`, or local-only review discovery commands.
+
+## Approval plan format
+
+Before editing files, present every unresolved thread from the tool output using exactly this format:
+
+```md
+## Thread <thread_id>
+
+### Reviewer feedback
+<copy the full Reviewer feedback section from the tool output>
+
+### Review context
+<copy the full Review context section from the tool output>
+
+### Current local code
+<copy the full Current local code section from the tool output>
+
+### Problem analysis
+- Problem: <specific defect, missing test, design issue, or documentation mismatch visible in the feedback, diff hunk, and local code>
+- Evidence: <specific evidence from the reviewer comment, diff hunk, and current local code>
+- Scope: <exact files and behavior affected>
+
+### Proposed change
+- Edit `<path>`: <exact code, test, or documentation behavior change>
+- Leave unchanged: <exact files or behavior that will not be touched>
+
+### Validation
+- During edits: call `nt_skillz_lint` after each small TypeScript change with the changed `.ts` or `.tsx` file paths only.
+- Before commit: run `git diff --name-only --diff-filter=ACMR HEAD -- '*.ts' '*.tsx'`, then call `nt_skillz_lint` with every returned file path.
+- Before commit coverage: run `git diff --name-only --diff-filter=ACMR HEAD -- '*.ts' '*.tsx'`, then run `/nt-skillz:vitest-coverage <file>` for each returned path and require 100% coverage unless the run prints `SKIP:`.
+- Additional command: `<exact project command required to verify this feedback, or "none">`
+
+### GitHub reply to post after validation passes
+`[Resolve] <exact response>`
+
+### Resolution action
+Resolve thread after successful reply: yes
+```
+
+## Approval stop
+
+1. Stop after presenting the approval plan.
+2. Ask which thread fixes are approved.
+3. Do not edit files until the user approves specific thread IDs.
+4. If the user approves only some threads, edit only the approved thread fixes.
+5. If a thread cannot be mapped to a concrete file and behavior change, ask for clarification instead of editing.
+
+## Implementation standards
+
+1. Implement approved fixes only.
+2. Do not make unrelated refactors, formatting changes, dependency changes, or drive-by cleanups.
+3. After each small TypeScript code change, call `nt_skillz_lint` with only the `files` argument for the changed `.ts` or `.tsx` file or files from that step.
+4. Do not pass `base` or `head` to `nt_skillz_lint` during normal implementation work.
+5. Fix all lint errors on new code before continuing.
+6. If lint fails on existing code, ignore only errors that are unrelated and not near the changed code.
+7. Line-length limits do not count as existing code; fix line-length errors caused by new code.
+
+## Required validation before any commit
+
+Before committing feedback fixes:
+
+1. Run `git diff --name-only --diff-filter=ACMR HEAD -- '*.ts' '*.tsx'`.
+2. Call `nt_skillz_lint` with `files` set to every path returned by step 1.
+3. Run `/nt-skillz:vitest-coverage <file>` for each path returned by step 1.
+4. Ignore only coverage runs that print a `SKIP:` line.
+5. Do not commit unless every remaining file has 100% Vitest coverage or the user explicitly confirms that 100% coverage is impossible for the relevant component.
+6. Run each approved thread's `Additional command` when the value is not `none`.
+7. Do not commit if any required validation fails.
+
+## Commit rule
+
+1. Do not commit unless the user explicitly requests a commit.
+2. If the user requests a commit, run the required validation before the commit.
+3. Commit only files changed for approved thread fixes.
+
+## GitHub reply and thread resolution
+
+After validation passes for an approved thread:
+
+1. Reply to the thread with this exact GraphQL mutation:
+
+```bash
+gh api graphql \
+  -f threadId='<thread_id>' \
+  -f body='[Resolve] <approved response body>' \
+  -f query='mutation($threadId: ID!, $body: String!) { addPullRequestReviewThreadReply(input: { pullRequestReviewThreadId: $threadId, body: $body }) { comment { url } } }'
+```
+
+2. Resolve the thread with this exact GraphQL mutation:
+
+```bash
+gh api graphql \
+  -f threadId='<thread_id>' \
+  -f query='mutation($threadId: ID!) { resolveReviewThread(input: { threadId: $threadId }) { thread { id isResolved } } }'
+```
+
+3. Do not resolve a thread before the reply mutation succeeds.
+4. Do not resolve a thread when validation failed.
+5. Do not resolve a thread that was not approved by the user.
+
+## Final report
+
+Report only:
+
+- approved thread IDs fixed
+- unapproved thread IDs left untouched
+- validation commands run and pass/fail status
+- GitHub reply URLs returned by the reply mutation
+- resolved thread IDs returned by the resolution mutation
+- blockers that require user action

package/commands/review-pr.md

@@ -49,26 +49,19 @@ Provide the subagent with:
 - the changed file list
 - the changed diff context
 
-## Test Coverage Analysis
-
-Add a test coverage analysis results section to the PR description:
-
-1. For each changed path from `gh pr diff <pr> --name-only`, run `/nt-skillz:vitest-coverage <file>`.
-2. Ignore only runs that print a `SKIP:` line.
-3. If every run prints a `SKIP:` line, use one fenced `text` block containing `No changed TypeScript source files.` as the coverage content.
-4. Otherwise, build the PR coverage block in this exact shape:
-    - `<!-- nt-skillz-coverage:start -->`
-    - `## Coverage`
-    - one `### \`<file>\`` heading for each non-`SKIP:` file
-    - one fenced `text` block containing the exact raw `/nt-skillz:vitest-coverage <file>` output directly under that file heading
-    - `<!-- nt-skillz-coverage:end -->`
-5. Run `gh pr view <pr> --json body --jq '.body'` and use the returned text as the current PR body.
-6. If the current PR body already contains both marker lines, replace only the text from `<!-- nt-skillz-coverage:start -->` through `<!-- nt-skillz-coverage:end -->` with the new coverage block.
-7. If the current PR body does not contain both marker lines, append the new coverage block to the end of the PR body separated by two newlines.
-8. Write the updated PR body to a temporary file.
-9. Run `gh pr edit <pr> --body-file <temporary-file>`.
-10. Do not summarize, interpret, or paraphrase the coverage output.
-11. Do not modify any other part of the PR body.
+## Tool-Generated PR Description Sections
+
+Add generated lint and coverage sections to the PR description:
+
+1. Invoke the `nt_skillz_lint` tool with `mode: "pr-review"` and the resolved PR identifier.
+2. Invoke the `nt_skillz_vitest_coverage` tool with `mode: "pr-review"` and the resolved PR identifier.
+3. Use the exact markdown returned by each tool. Do not summarize, interpret, paraphrase, or reformat tool output.
+4. Run `gh pr view <pr> --json body --jq '.body'` and use the returned text as the current PR body.
+5. If the current PR body already contains both marker lines for a generated section, replace only the text from the start marker through the end marker with the new tool output for that section.
+6. If the current PR body does not contain both marker lines for a generated section, append the new tool output to the end of the PR body separated by two newlines.
+7. Write the updated PR body to a temporary file.
+8. Run `gh pr edit <pr> --body-file <temporary-file>`.
+9. Do not modify any other part of the PR body.
 
 ## Basic PR checks
 

package/dist/commands/dont-stop/hooks.js

@@ -1,11 +1,19 @@
 import { CLEAR_DONT_STOP_COMMAND_NAME, DONT_STOP_COMMAND_NAME, } from "./register.js";
 import { createDontStopState } from "./state.js";
+const statusStartMarker = "<dont-stop-status>";
+const statusEndMarker = "</dont-stop-status>";
+function isRecord(value) {
+    return typeof value === "object" && value !== null && !Array.isArray(value);
+}
 function unwrapResponse(result) {
-    return typeof result === "object" && result !== null && "data" in result ? result.data : result;
+    if (isRecord(result) && "data" in result) {
+        return result.data;
+    }
+    return result;
 }
 function normalizeCriteria(value) {
     return value
-        .split(/\n|;/)
+        .split(/[\n;]/)
         .map((item) => item.replace(/^\s*[-*]\s*/, "").trim())
         .filter(Boolean);
 }
@@ -41,43 +49,70 @@ function buildSystemInstruction(criteria) {
     ].join("\n");
 }
 function parseAssistantStatus(text) {
-    const match = text.match(/<dont-stop-status>([\s\S]*?)<\/dont-stop-status>/i);
-    if (!match)
+    const lowerText = text.toLowerCase();
+    const startIndex = lowerText.indexOf(statusStartMarker);
+    const endIndex = lowerText.indexOf(statusEndMarker);
+    if (startIndex < 0 || endIndex < 0 || endIndex <= startIndex)
         return null;
-    const body = match[1];
-    const stateMatch = body.match(/^\s*state\s*:\s*(continue|completion-requested|blocked-requested)\s*$/im);
-    const justificationMatch = body.match(/^\s*justification\s*:\s*(.+)\s*$/im);
-    const reasonMatch = body.match(/^\s*reason\s*:\s*(.+)\s*$/im);
+    const body = text.slice(startIndex + statusStartMarker.length, endIndex);
+    const fields = Object.fromEntries(body
+        .split("\n")
+        .map((line) => line.trim())
+        .filter((line) => line.includes(":"))
+        .map((line) => [line.slice(0, line.indexOf(":")).trim(), line.slice(line.indexOf(":") + 1).trim()]));
+    const state = parseAssistantState(fields.state);
     return {
-        state: stateMatch?.[1] ?? "continue",
-        justification: justificationMatch?.[1]?.trim() ?? "",
-        reason: reasonMatch?.[1]?.trim() ?? "",
+        state,
+        justification: readStatusField(fields, "justification"),
+        reason: readStatusField(fields, "reason"),
     };
 }
-async function showToast(client, body) {
-    try {
-        await client.tui.showToast({ body });
+function readStatusField(fields, key) {
+    const value = fields[key];
+    if (typeof value === "string") {
+        return value;
     }
-    catch { }
+    return "";
+}
+function parseAssistantState(value) {
+    if (value === "completion-requested" || value === "blocked-requested") {
+        return value;
+    }
+    return "continue";
+}
+async function showToast(client, body) {
+    const toastWasShown = await client.tui.showToast({ body }).then(() => true, () => false);
+    if (!toastWasShown)
+        return;
+}
+function isMessagePart(value) {
+    return isRecord(value);
+}
+function isSessionMessage(value) {
+    if (!isRecord(value))
+        return false;
+    if (!("parts" in value))
+        return true;
+    return Array.isArray(value.parts) && value.parts.every(isMessagePart);
+}
+function readAssistantText(message) {
+    const parts = message.parts ?? [];
+    return parts
+        .filter((part) => part.type === "text" && typeof part.text === "string")
+        .map((part) => part.text)
+        .join("\n");
 }
 async function getLatestAssistantStatus(client, sessionID) {
     const result = unwrapResponse(await client.session.messages({ path: { id: sessionID } }));
-    const messages = Array.isArray(result) ? result : [];
-    for (let index = messages.length - 1; index >= 0; index -= 1) {
-        const entry = messages[index];
-        if (entry.info?.role !== "assistant")
-            continue;
-        const text = (entry.parts ?? [])
-            .filter((part) => part.type === "text" && typeof part.text === "string")
-            .map((part) => part.text)
-            .join("\n");
-        return parseAssistantStatus(text);
-    }
+    const messages = Array.isArray(result) ? result.filter(isSessionMessage) : [];
+    const latestAssistantMessage = [...messages].reverse().find((entry) => entry.info?.role === "assistant");
+    if (latestAssistantMessage)
+        return parseAssistantStatus(readAssistantText(latestAssistantMessage));
     return null;
 }
 function buildContinuationPrompt(criteria, status) {
     const reportedState = status?.state ?? "missing";
-    const reason = status?.reason || "none";
+    const reason = status?.reason ?? "none";
     return [
         "dont-stop remains active.",
         "",
@@ -96,10 +131,7 @@ function buildContinuationPrompt(criteria, status) {
 function buildReviewRequestKey(status) {
     return `${status.state}:${status.reason}`;
 }
-async function notifyReviewRequested(client, state, sessionID, status) {
-    const session = state.get(sessionID);
-    if (!session)
-        return;
+async function notifyReviewRequested(client, session, status) {
     const reviewKey = buildReviewRequestKey(status);
     if (session.pendingReviewKey === reviewKey)
         return;
@@ -116,16 +148,18 @@ function getDeletedSessionID(event) {
     if (event.type !== "session.deleted")
         return undefined;
     const properties = event.properties;
-    if (!properties || typeof properties !== "object")
+    if (!isRecord(properties))
         return undefined;
     const info = properties.info;
-    return typeof info?.id === "string" ? info.id : undefined;
+    if (!isRecord(info))
+        return undefined;
+    return typeof info.id === "string" ? info.id : undefined;
 }
 function getIdleSessionID(event) {
     if (event.type !== "session.idle")
         return undefined;
     const properties = event.properties;
-    if (!properties || typeof properties !== "object")
+    if (!isRecord(properties))
         return undefined;
     const sessionID = properties.sessionID;
     return typeof sessionID === "string" ? sessionID : undefined;
@@ -181,7 +215,7 @@ async function handleEvent(client, state, event) {
     try {
         const latestStatus = await getLatestAssistantStatus(client, sessionID);
         if (latestStatus?.state === "completion-requested" || latestStatus?.state === "blocked-requested") {
-            await notifyReviewRequested(client, state, sessionID, latestStatus);
+            await notifyReviewRequested(client, session, latestStatus);
             return;
         }
         session.pendingReviewKey = undefined;