reviewing-typescript

<accessing_skill_files> When this skill is invoked, Claude Code provides the base directory in the loading message:

Base directory for this skill: {skill_dir}

Use this path to access skill files:

• •References: {skill_dir}/references/
• •Workflows: {skill_dir}/workflows/
• •Templates: {skill_dir}/templates/
• •Rules: {skill_dir}/rules/

IMPORTANT: Do NOT search the project directory for skill files. </accessing_skill_files>

<essential_principles> TRUST NO ONE. REJECT MOCKING. ZERO TOLERANCE.

• •If you cannot verify something is correct, it is incorrect
• •REJECT any use of mocking — only dependency injection is acceptable
• •"It works on my machine" is not evidence. Tool output is evidence.
• •Tool outputs are truth. Your subjective opinion is secondary.
• •Absence = Failure. If you cannot run a verification tool, the code fails.

</essential_principles>

<test_verification> This reviewer enforces testing principles from /testing-typescript skill.

When reviewing tests, verify:

1. •REJECT any mocking — vi.mock(), jest.mock() = REJECTED
2. •Verify dependency injection — External deps must be injected, not mocked
3. •Verify behavior testing — Tests must verify outcomes, not implementation
4. •Verify correct test level — Unit/Integration/E2E assignment per /testing-typescript

Rejection Criteria:

// ❌ REJECT: Mocking
vi.mock("execa", () => ({ execa: vi.fn() }));

// ✅ ACCEPT: Dependency Injection
const deps: CommandDeps = {
  execa: vi.fn().mockResolvedValue({ exitCode: 0 }),
};
const result = await runCommand(args, deps);
expect(result.success).toBe(true); // Tests behavior

</test_verification>

<context_loading> For spx-based work items: Verify context was loaded before reviewing.

If you're reviewing code for a spec-driven work item (story/feature/capability), verify the implementation has complete context:

1. •Check that spx:understanding-specs was invoked - Look for context loading in implementation
2. •Verify all ADRs are referenced - Implementation should follow architectural decisions (interleaved in containers)
3. •Verify feature spec requirements met - Code should satisfy documented requirements

The spx:understanding-specs skill provides:

• •Complete ADR hierarchy (product/capability/feature decisions)
• •Feature spec with validation strategy and acceptance criteria
• •Story/feature/capability spec with functional requirements

Review focus:

• •Does implementation honor all ADRs in hierarchy?
• •Does implementation satisfy feature spec validation strategy?
• •Does implementation meet story/feature acceptance criteria?

If NOT working on spx-based work item: Proceed directly with code review using provided specification. </context_loading>

<verdict_definitions>

APPROVED Criteria (all must be true):

1. •tsc reports zero errors
2. •eslint reports zero error-level violations
3. •Semgrep reports zero findings
4. •All tests pass
5. •Manual review checklist satisfied
6. •No security concerns identified

REJECTED Criteria (any triggers rejection):

• •Any real type error (tsc)
• •Any true-positive security violation
• •Any test failure
• •Missing type annotations on public functions
• •Empty catch blocks
• •Hardcoded secrets
• •eval() or new Function() usage
• •child_process.exec() with untrusted input
• •Deep relative imports (2+ levels of ../) to stable locations

</verdict_definitions>

<review_phases> Execute these phases IN ORDER. Do not skip phases.

If verdict is APPROVED: Continue to Phase 6. If verdict is NOT APPROVED: Skip verification and commit, return feedback. </review_phases>

<reference_index>

</reference_index>

<workflows_index>

</workflows_index>

<tool_resources>

</tool_resources>

<output_format>

## Review: {target}

### Verdict: [APPROVED / CONDITIONAL / REJECTED / BLOCKED]

[One-sentence summary]

### Static Analysis

| Tool    | Status    | Issues                           |
| ------- | --------- | -------------------------------- |
| tsc     | PASS/FAIL | [count] errors                   |
| eslint  | PASS/FAIL | [count] errors, [count] warnings |
| Semgrep | PASS/FAIL | [count] findings                 |

### Tests

| Metric   | Value      |
| -------- | ---------- |
| Passed   | [count]    |
| Failed   | [count]    |
| Coverage | [percent]% |

### Blocking Issues (if REJECTED)

1. **[file:line]** - [category] - [description]

### Report Location

Full report: `reports/review_{name}_{timestamp}.md`

</output_format>

<success_criteria> Review is complete when:

• • All static analysis tools run (tsc, eslint, Semgrep)
• • All tests executed with coverage measured
• • Manual review checklist completed
• • Verdict determined and documented
• • If APPROVED: tests verified, outcomes committed, changes committed
• • If REJECTED: actionable feedback provided with file:line references

Your job is to protect the codebase from defects. A rejected review that catches a bug is worth infinitely more than an approval that lets one through. </success_criteria>