diff --git a/AGENTS.md b/AGENTS.md
index 03bf49c..4f2a7e3 100644
--- a/AGENTS.md
+++ b/AGENTS.md
@@ -31,7 +31,7 @@ Installing skills for end use is `npx skills add TypeFox/agent-skills` (see READ
 
 ## Conventions
 
-- Every skill ships evals in `evals/evals.json` (missing for ts-code-reviewer; adding them is planned as a standalone task).
+- Every skill ships evals in `evals/evals.json`.
 - Python scripts stay stdlib-only so they run anywhere with bare Python 3.8+ — they are run from the skill, never copied into target repos (registry distribution, e.g. PyPI, is a possible later step).
 - Node is used only to build the website and stays confined to `website/` (its own `package.json`); no skill depends on it.
 - Skills that persist per-user state (write-like-me's style profile) keep it under `$HOME/.agents/<skill-name>/`, never in the target repo or the skill folder; the skill's schema reference documents the format and carries a version number.
diff --git a/skills/ts-code-reviewer/SKILL.md b/skills/ts-code-reviewer/SKILL.md
deleted file mode 100644
index 7ae4bdb..0000000
--- a/skills/ts-code-reviewer/SKILL.md
+++ /dev/null
@@ -1,152 +0,0 @@
----
-name: ts-code-reviewer
-description: Perform a senior-level TypeScript/JavaScript code review and produce an actionable REVIEW.md report using Conventional Comments notation. Use this skill for code reviews, PR reviews, diff reviews, or feedback on TS/JS code (.ts, .tsx, .js, .jsx, .mts, .cts files). Do not use for non-TypeScript languages or for one-line syntax questions.
----
-
-# TypeScript Code Review
-
-Produce a thorough, actionable code review of TypeScript/JavaScript code at the level of a principal engineer. The review should be rigorous on substance (correctness, types, security, performance) while remaining respectful and educational in tone — every reviewer's feedback lands on a person, not a compiler.
-
-## Workflow
-
-Follow these steps in order:
-
-1. **Gather the code.** Identify what is being reviewed — a file, a diff, a PR, pasted snippets. If only a fragment is provided and surrounding context would change the review (e.g. a function whose callers aren't visible), ask the user briefly before proceeding.
-
-2. **Confirm the output location.** Ask the user where to write the review file. Default suggestion: the same directory as the code being reviewed, named `REVIEW.md`. Do not write the file until the location is confirmed. A short question like "I'll write the review to `<path>/REVIEW.md` — does that work, or would you prefer somewhere else?" is enough.
-
-3. **Analyze.** Walk the code against the dimensions in the [Analysis framework](#analysis-framework) below. Do not include this analysis in the output — it is internal scaffolding to form the review.
-
-4. **Write the review** to the confirmed path using the structure in [Output format](#output-format). All feedback items must use Conventional Comments notation (see `conventional-comments.md`).
-
-5. **Surface the file** to the user with a short summary of the verdict and the top 1–3 priorities. Do not restate the whole review in chat — the file is the deliverable.
-
-## Review philosophy
-
-These principles shape how feedback is written. They matter because a review that is technically correct but tonally off will be ignored or resented, and a review that is gentle but vague will not improve the code.
-
-- **Assume good intent.** The author made reasonable choices given context you may not have. Seek to understand before critiquing.
-- **Be specific and actionable.** Vague feedback wastes everyone's time. Every issue gets a clear path to resolution — usually a concrete code suggestion.
-- **Balance criticism with praise.** Acknowledge what is done well. Good review is mentorship, not gatekeeping. Include at least one `praise:` when the code earns it.
-- **Prioritize ruthlessly.** Not everything matters equally. Distinguish blocking issues from polish.
-- **Teach, don't just correct.** Explain the *why* so the author learns the principle, not just the fix.
-- **Prefer questions over accusations when uncertain.** If you don't know whether something is a bug or intentional, use `question:` rather than `issue:`.
-
-## Analysis framework
-
-Systematically consider the code along these dimensions. Not every dimension produces feedback for every review — use judgment about what is worth raising.
-
-**Correctness** — logic errors, off-by-one mistakes, incorrect conditionals, race conditions, async/await misuse, unhandled promise rejections, null/undefined handling, type assertions hiding bugs.
-
-**Type safety** — appropriate use of strict typing vs `any`/`unknown`, correct generic constraints and inference, discriminated unions and exhaustiveness checks, type guards and narrowing, sensible use of utility types (`Partial`, `Required`, `Pick`, `Omit`, etc.).
-
-**Security** — injection vulnerabilities (SQL, XSS, command injection), improper handling of user input or sensitive data, secrets in code, insecure dependencies, authentication/authorization gaps.
-
-**Performance** — unnecessary re-renders (React), expensive computations in hot paths, memory leaks (event listeners, subscriptions, closures), N+1 queries, inefficient algorithms, bundle size concerns, missed caching opportunities.
-
-**Readability and maintainability** — clear naming, appropriate function/module size, single responsibility, comments where they help (and absence of misleading ones), consistent style.
-
-**Idiomatic TypeScript** — modern ES/TS features used appropriately, sensible module organization, interface vs type alias choices, enum vs `as const`, functional vs class-based patterns.
-
-**Error handling** — comprehensive handling and propagation, meaningful error messages, graceful degradation, edge cases.
-
-**Testing** — testability of the code, missing coverage on critical paths, test design issues if tests are included.
-
-## Conventional Comments
-
-Refer to `references/conventional-comments.md` for the full label and decoration reference. Read it before starting a review.
-
-## Output format
-
-Use this exact structure for `REVIEW.md`:
-
-```markdown
-# Code Review: [Brief description or filename]
-
-## Summary
-
-A 2–4 sentence high-level assessment. What does this code do well? What are the primary areas for improvement?
-
-**Verdict:** `APPROVE` | `APPROVE_WITH_SUGGESTIONS` | `REQUEST_CHANGES`
-
-## Statistics
-
-- **Total Comments:** [N]
-- **Blocking Issues:** [N]
-- **Non-blocking Suggestions:** [N]
-- **Praise:** [N]
-
-## Prioritized Recommendations
-
-1. **(Blocking)** [Most critical change] (#N)
-2. **(Blocking)** [Second most critical] (#N)
-3. **(Non-blocking)** [Important but not blocking] (#N)
-...
-
----
-
-## Detailed Feedback
-
-### Blocking Issues
-
-[One entry per blocking issue, numbered sequentially using the per-comment template below]
-
-### Suggestions & Improvements
-
-[One entry per non-blocking suggestion, continuing the numbering]
-
-### Nitpicks & Polish
-
-[Trivial items, continuing the numbering]
-
-### Questions
-
-[Items needing author clarification, continuing the numbering]
-
-### Praise
-
-[Positive observations, continuing the numbering]
-
-## Additional Notes
-
-[Optional broader observations]
-```
-
-### Per-comment template
-
-Each feedback item in the detailed sections is numbered sequentially across all sections (a single counter that starts at 1 and increments through Blocking Issues, Suggestions, Nitpicks, Questions, and Praise). This makes it easy to reference specific items later (e.g. "item 4").
-
-```markdown
-**#N — <label> (<decorations>): [Concise title]**
-
-**Location:** `filename.ts:L##`
-
-**Original Code:**
-\`\`\`typescript
-// the code in question
-\`\`\`
-
-**Suggested Fix:**
-\`\`\`typescript
-// the proposed code
-\`\`\`
-
-**Rationale:**
-Why this matters and why the suggested change is better. Reference principles, patterns, or docs where it helps.
-```
-
-For lightweight comments (`nitpick:`, `praise:`, `typo:`), the rationale and code blocks can be condensed or omitted — match weight to substance.
-
-A complete worked example of a finished review is in `references/example-review.md`. Read it before writing your first review for this skill, especially to calibrate the tone and depth of `Rationale` sections.
-
-## Final checks before delivering
-
-Before surfacing the review to the user, verify:
-
-- The verdict matches the severity of the feedback (don't mark `APPROVE` if there are blocking issues).
-- Every blocking issue has a concrete suggested fix, not just a complaint.
-- At least one `praise:` is included if the code deserves it.
-- Statistics counts match the actual content.
-- Item numbers (`#1`, `#2`, …) are sequential across all sections with no gaps or duplicates.
-- Prioritized Recommendations cross-reference the correct item numbers.
-- File paths and line numbers in `Location:` fields are accurate.
diff --git a/skills/ts-code-reviewer/references/conventional-comments.md b/skills/ts-code-reviewer/references/conventional-comments.md
deleted file mode 100644
index c8d201a..0000000
--- a/skills/ts-code-reviewer/references/conventional-comments.md
+++ /dev/null
@@ -1,65 +0,0 @@
-# Conventional Comments Reference
-
-All feedback items in a code review use this format:
-
-```
-<label> [decorations]: <subject>
-
-[discussion]
-```
-
-The label classifies *what kind* of feedback it is. Decorations add metadata about urgency, domain, or scope. The subject is a one-line summary, and the discussion (which appears in the `Rationale` section of the review template) explains the reasoning.
-
-## Labels
-
-Pick the label that most accurately describes the comment. When in doubt between `issue:` and `question:`, prefer `question:` — it is more respectful when you aren't certain something is wrong.
-
-| Label         | Usage                                                                                |
-| ------------- | ------------------------------------------------------------------------------------ |
-| `praise:`     | Highlight something positive. Include at least one per review when the code earns it. |
-| `nitpick:`    | Trivial, preference-based suggestion. Always non-blocking.                           |
-| `suggestion:` | Propose a concrete improvement. Be explicit about *what* and *why*.                  |
-| `issue:`      | Highlight a specific problem. Pair with a suggested fix when possible.               |
-| `question:`   | Seek clarification when uncertain whether something is actually a problem.           |
-| `thought:`    | Share an idea sparked by the review. Non-blocking but potentially valuable.          |
-| `todo:`       | Small, trivial, necessary change.                                                    |
-| `chore:`      | Process-related task (docs, CI, formatting).                                         |
-| `note:`       | Non-blocking context the author should be aware of.                                  |
-| `typo:`       | Spelling or grammar mistake.                                                         |
-| `polish:`     | Nothing wrong, but could be immediately improved.                                    |
-
-## Decorations
-
-Decorations are optional and appear in parentheses after the label. Multiple decorations can be combined, comma-separated.
-
-| Decoration       | Meaning                              |
-| ---------------- | ------------------------------------ |
-| `(blocking)`     | Must be resolved before approval.    |
-| `(non-blocking)` | Should not prevent approval.         |
-| `(if-minor)`     | Resolve only if the fix is trivial.  |
-| `(security)`     | Security-related concern.            |
-| `(performance)`  | Performance-related concern.         |
-| `(testing)`      | Testing-related concern.             |
-| `(types)`        | TypeScript type-system concern.      |
-| `(ux)`           | User experience concern.             |
-
-## Combining labels and decorations
-
-A few real examples of well-formed comment headers (each prefixed with its sequential item number):
-
-- `**#1 — issue (blocking, security): Password comparison vulnerable to timing attacks**`
-- `**#2 — suggestion (non-blocking, types): Replace `any` with proper interface**`
-- `**#3 — nitpick (if-minor): Variable name could be more descriptive**`
-- `**#4 — question: Is the retry behavior here intentional?**`
-- `**#5 — praise: Excellent separation of concerns**`
-
-## Choosing severity
-
-A common mistake is over-blocking — marking too many things `(blocking)` dilutes the signal. Reserve blocking for:
-
-- Correctness bugs that will produce wrong behavior
-- Security vulnerabilities
-- Crashes, unhandled rejections, data loss risks
-- Major architectural problems that will be hard to fix later
-
-Style preferences, type-system improvements, refactor opportunities, and "I would have done it differently" feedback are virtually always non-blocking.
diff --git a/skills/ts-code-reviewer/references/example-review.md b/skills/ts-code-reviewer/references/example-review.md
deleted file mode 100644
index 2579963..0000000
--- a/skills/ts-code-reviewer/references/example-review.md
+++ /dev/null
@@ -1,168 +0,0 @@
-# Example Review
-
-This is a worked example of a finished review using the format defined in `SKILL.md`. Use it to calibrate tone, depth, and the level of detail to put into `Rationale` sections.
-
-The example reviews a hypothetical `UserService.ts`. The exact content is not important — pay attention to:
-
-- How the **summary** characterizes the code in 2–4 sentences without restating every comment
-- How **blocking issues** include both a concrete fix *and* a substantive rationale
-- How **suggestions** are phrased as improvements rather than corrections
-- How **praise** is specific (not "good code!") and points to a particular pattern or location
-
----
-
-# Code Review: UserService.ts
-
-## Summary
-
-This service handles user authentication and profile management. The core logic is sound and well-organized, with clean separation between authentication, profile, and persistence concerns. However, there is a critical security issue with password handling that must be addressed before merge, and several opportunities to strengthen type safety. Error handling is inconsistent and would benefit from a uniform approach.
-
-**Verdict:** `REQUEST_CHANGES`
-
-## Statistics
-
-- **Total Comments:** 6
-- **Blocking Issues:** 2
-- **Non-blocking Suggestions:** 2
-- **Praise:** 2
-
-## Prioritized Recommendations
-
-1. **(Blocking)** Fix password comparison to use constant-time comparison (#1)
-2. **(Blocking)** Add proper error handling for database operations (#2)
-3. **(Non-blocking)** Replace `any` types with proper interfaces (#3)
-4. **(Non-blocking)** Consider extracting validation logic into a dedicated module (#4)
-
----
-
-## Detailed Feedback
-
-### Blocking Issues
-
----
-
-**#1 — issue (blocking, security): Password comparison vulnerable to timing attacks**
-
-**Location:** `UserService.ts:L45`
-
-**Original Code:**
-```typescript
-async validatePassword(input: string, stored: string): Promise<boolean> {
-  return input === stored;
-}
-```
-
-**Suggested Fix:**
-```typescript
-import { timingSafeEqual } from 'crypto';
-
-async validatePassword(input: string, stored: string): Promise<boolean> {
-  const inputBuffer = Buffer.from(input);
-  const storedBuffer = Buffer.from(stored);
-
-  if (inputBuffer.length !== storedBuffer.length) {
-    return false;
-  }
-
-  return timingSafeEqual(inputBuffer, storedBuffer);
-}
-```
-
-**Rationale:**
-String comparison with `===` short-circuits at the first differing byte, which leaks information about how many leading characters matched. An attacker who can measure response times can determine the stored password one character at a time. `timingSafeEqual` from Node's crypto module performs constant-time comparison, eliminating this attack vector. This is table stakes for any authentication code, even when passwords are hashed — the hashes still need timing-safe comparison.
-
----
-
-**#2 — issue (blocking): Unhandled promise rejection and incorrect return type**
-
-**Location:** `UserService.ts:L28`
-
-**Original Code:**
-```typescript
-async getUser(id: string): Promise<User> {
-  const user = await this.db.query(`SELECT * FROM users WHERE id = $1`, [id]);
-  return user.rows[0];
-}
-```
-
-**Suggested Fix:**
-```typescript
-async getUser(id: string): Promise<User | null> {
-  try {
-    const result = await this.db.query(`SELECT * FROM users WHERE id = $1`, [id]);
-    return result.rows[0] ?? null;
-  } catch (error) {
-    this.logger.error('Failed to fetch user', { id, error });
-    throw new DatabaseError('Failed to fetch user', { cause: error });
-  }
-}
-```
-
-**Rationale:**
-Two problems here. First, database errors propagate raw to the caller, which both crashes any caller that doesn't `try/catch` and leaks implementation details (driver-specific error shapes, query fragments) up the stack. Wrapping in a domain `DatabaseError` gives callers a stable contract. Second, the return type promises `User` but actually returns `undefined` when no user is found — the `?? null` plus `User | null` return type makes the nullable case explicit and forces callers to handle it.
-
----
-
-### Suggestions & Improvements
-
----
-
-**#3 — suggestion (non-blocking, types): Replace `any` with a proper input interface**
-
-**Location:** `UserService.ts:L12`
-
-**Original Code:**
-```typescript
-async createUser(data: any): Promise<User> {
-```
-
-**Suggested Improvement:**
-```typescript
-interface CreateUserInput {
-  email: string;
-  password: string;
-  name?: string;
-}
-
-async createUser(data: CreateUserInput): Promise<User> {
-```
-
-**Rationale:**
-`any` opts out of the type system entirely, allowing invalid data to flow into the database layer where errors will surface late and be hard to trace. A dedicated input interface gives compile-time validation, IDE autocomplete for callers, and serves as living documentation of what the method expects. Consider pairing with a runtime validator (zod, valibot) if `data` originates from an HTTP boundary.
-
----
-
-**#4 — suggestion (non-blocking): Extract validation into a dedicated module**
-
-**Location:** `UserService.ts:L60–95`
-
-**Rationale:**
-The `validateRegistration` method has grown to ~35 lines of branching validation logic embedded in the service. As the rules evolve, this will be where bugs hide. Extracting to `validators/registration.ts` (or, better, a schema-based validator like zod) keeps the service focused on orchestration and makes the rules independently testable.
-
----
-
-### Praise
-
----
-
-**#5 — praise: Excellent separation of concerns**
-
-**Location:** `UserService.ts` (overall structure)
-
-The service is cleanly organized — each method has a single responsibility, dependencies are injected through the constructor rather than imported as singletons, and the boundary between domain logic and persistence is clear. This will be easy to test and easy to evolve.
-
----
-
-**#6 — praise: Clean async flow in registration**
-
-**Location:** `UserService.ts:L50–60`
-
-Using early returns for validation keeps the happy path unindented and easy to follow. The async/await usage avoids the nested `.then()` chains that often appear in code at this level of complexity.
-
----
-
-## Additional Notes
-
-Consider adding JSDoc to the public methods, especially documenting which errors can be thrown — this would pair well with the `DatabaseError` wrapping suggested above and give consumers a clear contract.
-
-For input validation, a runtime validator like `zod` or `valibot` would compose nicely with the TypeScript interfaces and eliminate the manual validation code suggested for extraction.
diff --git a/website/.vitepress/config.ts b/website/.vitepress/config.ts
index 40ad7c8..1ce7609 100644
--- a/website/.vitepress/config.ts
+++ b/website/.vitepress/config.ts
@@ -23,7 +23,6 @@ export default defineConfig({
                     { text: 'Idiomatic Go', link: '/idiomatic-go' },
                     { text: 'Publish VS Code Extension', link: '/publish-vscode-extension' },
                     { text: 'Skill Evals', link: '/skill-evals' },
-                    { text: 'TS Code Reviewer', link: '/ts-code-reviewer' },
                     { text: 'Write Like Me', link: '/write-like-me' }
                 ]
             }
diff --git a/website/index.md b/website/index.md
index 8bda4b5..0949a27 100644
--- a/website/index.md
+++ b/website/index.md
@@ -17,9 +17,9 @@ features:
   - title: Go
     details: Community idioms for API design, errors, concurrency and naming, plus doc comments that render on pkg.go.dev.
     link: /idiomatic-go
-  - title: TypeScript and VS Code
-    details: Senior-level code review for TypeScript projects, and publishing extensions to the Marketplace and Open VSX.
-    link: /ts-code-reviewer
+  - title: VS Code
+    details: Publishing extensions to the Marketplace and Open VSX.
+    link: /publish-vscode-extension
   - title: Your own voice
     details: Rewrite agent-written drafts so they read as you, from a style profile built from your own writing.
     link: /write-like-me
diff --git a/website/ts-code-reviewer.md b/website/ts-code-reviewer.md
deleted file mode 100644
index e056456..0000000
--- a/website/ts-code-reviewer.md
+++ /dev/null
@@ -1,15 +0,0 @@
-# TS Code Reviewer
-
-Perform a senior-level TypeScript and JavaScript code review and produce an actionable REVIEW.md report.
-
-Source: [skills/ts-code-reviewer](https://github.com/TypeFox/agent-skills/tree/main/skills/ts-code-reviewer)
-
-## Install
-
-```sh
-npx skills add TypeFox/agent-skills -s ts-code-reviewer
-```
-
-## Usage
-
-_This guide is still being written._