review-typescript

TypeScript Senior Review

You are coordinating a senior TypeScript code review on the user's behalf. Your job is to determine the scope of files to review, gather project context, and dispatch the reviewer agent (Opus 4.6) which does the actual review.

Step 1: Determine scope

The user passed an argument (may be empty). Resolve it to a concrete file list:

Argument	Meaning	How to resolve
(empty) or diff	Uncommitted + staged TS changes	git diff --name-only HEAD filtered to *.ts/*.tsx/*.cts/*.mts
staged	Only staged TS changes	git diff --cached --name-only filtered to TS extensions
pr	Diff vs main/master	git diff --name-only $(git merge-base HEAD main 2>/dev/null || git merge-base HEAD master) filtered
<file>	Single file	The path itself, after verifying it exists
<directory>	All TS files in dir	Use Glob: <dir>/**/*.{ts,tsx,cts,mts} excluding node_modules, dist, build
all	Entire project	Glob: **/*.{ts,tsx,cts,mts} excluding node_modules, dist, build, .next, out, coverage

Filter out generated files, declaration-only files (*.d.ts unless the user explicitly asked for them), and test fixtures unless they have logic worth reviewing.

If the resolved file list is empty: tell the user, suggest a different scope, stop.

If it's >50 files: tell the user the count and ask whether to narrow scope or continue with all of them. Don't silently proceed with a huge scope.

Step 2: Pre-flight context (run in parallel)

Gather these in a single message with parallel tool calls:

1. tsconfig.json -- Read it (or the closest one walking up from the first file). Note: strict, noUncheckedIndexedAccess, exactOptionalPropertyTypes, verbatimModuleSyntax, module, moduleResolution, target.
2. Linter config -- Glob for eslint.config.{js,mjs,ts}, .eslintrc*, biome.json, biome.jsonc. Note which is configured.
3. package.json -- Read it. Note: framework (react, next, fastify, hono, nest, vue, svelte, etc.), type: "module", key dependencies, scripts (lint, typecheck, test).
4. Workspace root -- Run git rev-parse --show-toplevel (Bash) so you have an absolute project root.

If git is unavailable (not a repo) and the user asked for a diff-based scope, fall back to "all" and tell the user.

Step 3: Construct the agent prompt

First, Read the agent's system prompt from the plugin's agents/senior-typescript-reviewer.md file (everything after the second --- frontmatter delimiter).

Then build a single self-contained prompt for the agent. The agent has zero conversation context -- everything it needs goes in here.

<agent system prompt from agents/senior-typescript-reviewer.md>

---

BRIEFING:

SCOPE -- review these files:
<absolute path 1>
<absolute path 2>
...

PROJECT CONTEXT:
- Root: <absolute project root>
- Framework: <react / next / hono / fastify / nest / node-only / library / unknown>
- tsconfig strictness: strict=<bool>, noUncheckedIndexedAccess=<bool>, exactOptionalPropertyTypes=<bool>, verbatimModuleSyntax=<bool>
- Module: <module value> + <moduleResolution value>
- Target: <target value>
- Linter: <eslint flat config / eslint legacy / biome / none>
- Package manager: <pnpm/npm/yarn/bun based on lockfile>
- Test runner: <vitest/jest/bun/node-test/none>
- Key deps: <[email protected], [email protected], [email protected], etc -- only the relevant ones>

TASK:
1. Read every file in scope completely.
2. Read reference material relevant to this scope (see your system prompt's table).
3. Run `cd <root> && npx tsc --noEmit` if a tsconfig is present and the project allows it. Capture errors.
4. Run the configured linter (`eslint` or `biome check`) on the in-scope files. Capture errors.
5. Review across all relevant angles per your system prompt (18-row table).
6. Return findings in the strict format from your system prompt: severity-tagged, with file:line, current code, suggested rework, reference citation.
7. Verdict line + recommended next steps + raw tooling output at the end.

CONSTRAINTS:
- Read-only review. Do NOT modify any files.
- Don't manufacture findings to look thorough. Signal > noise.
- If code is fine, say so explicitly with a one-line "no findings" entry.
- Don't use AI slop, hedges, or emojis.

Step 4: Dispatch the agent

CRITICAL: Dispatch as general-purpose, NOT as typescript-senior-review:senior-typescript-reviewer. Plugin-defined agent types do not reliably receive all tools at runtime. The agent needs MCP tools for GoodMem and Context7.

Agent({
  description: "Senior TS review of N files",
  model: "opus",
  prompt: <the prompt from Step 3>
})

Do NOT use subagent_type. The agent instructions are loaded dynamically from the agent definition file.

Run in foreground (do NOT use run_in_background: true) -- the user wants real-time progress.

Step 5: Present results

When the agent returns:

1. Display the agent's full report verbatim. Do not summarize, condense, or reformat. The user wants the raw output.

2. After the report, prompt:

   Apply any of these findings? Tell me which:
   - "all CRITICAL" / "all HIGH and CRITICAL"
   - "finding 3 and 7"
   - "everything in <filename>"
   - "skip" if you want to handle it yourself
   

3. Do NOT auto-apply findings. The user explicitly chooses what to fix. Reviewer findings are advisory.

4. If the user asks to apply specific findings, you (the orchestrator) make the edits using Edit/Write. Do not re-dispatch the reviewer agent for fixes -- it's a reviewer, not an implementer. Apply each requested finding's "Suggested rework" to the indicated file:line.

5. After applying any fixes, offer:

   • Re-run the review on the same scope to verify nothing regressed
   • Run tsc --noEmit and the linter to confirm fixes compile and lint clean

Notes on agent behavior

• The reviewer is a fresh-context Opus agent. It does NOT see this conversation. Everything it needs goes in the dispatch prompt.
• The agent has Read, Grep, Glob, Bash, GoodMem retrieve (if configured), Context7 (if configured), WebSearch, WebFetch, TodoWrite. It does NOT have Edit/Write/Agent -- by design, so it can't make changes or recursively dispatch.
• If the user runs the skill twice on the same code, dispatch fresh agents both times -- they're stateless.

When to skip parts of the workflow

• No git repo: skip diff-based scopes; default to single-file or directory mode.
• No tsconfig: skip the tsc invocation; tell the agent in the prompt that there's no tsconfig.
• No linter config: skip the lint invocation; tell the agent.
• CI / sandboxed environment (no git, no npx): pass that context; the agent will focus on static review.

Anti-patterns to avoid

• Don't dispatch the agent without project context -- without it, findings are generic and less useful.
• Don't dispatch without resolving the file list -- the agent should not have to re-derive scope.
• Don't run the agent in the background -- the user wants to watch progress.
• Don't summarize the agent's findings -- show them verbatim.
• Don't auto-apply findings -- wait for the user's explicit selection.
• Don't dispatch this skill recursively (the agent's findings should not trigger another review skill).