devlyn-cli 1.14.0 → 2.0.0

package/config/skills/devlyn:browser-validate/references/tier1-chrome.md

@@ -1,137 +0,0 @@
-# Tier 1: Chrome DevTools (claude-in-chrome)
-
-The richest testing tier. Requires the claude-in-chrome MCP extension running in a Chrome browser. Provides full DOM interaction, console monitoring, network inspection, screenshots, and GIF recording.
-
-Read this file only when Tier 1 was selected during DETECT phase.
-
----
-
-## Setup
-
-Before any browser interaction, load the tools you need via ToolSearch:
-```
-ToolSearch: "select:mcp__claude-in-chrome__tabs_context_mcp"
-ToolSearch: "select:mcp__claude-in-chrome__tabs_create_mcp"
-ToolSearch: "select:mcp__claude-in-chrome__navigate"
-ToolSearch: "select:mcp__claude-in-chrome__get_page_text"
-ToolSearch: "select:mcp__claude-in-chrome__read_page"
-ToolSearch: "select:mcp__claude-in-chrome__find"
-ToolSearch: "select:mcp__claude-in-chrome__computer"
-ToolSearch: "select:mcp__claude-in-chrome__form_input"
-ToolSearch: "select:mcp__claude-in-chrome__resize_window"
-ToolSearch: "select:mcp__claude-in-chrome__read_console_messages"
-ToolSearch: "select:mcp__claude-in-chrome__read_network_requests"
-ToolSearch: "select:mcp__claude-in-chrome__gif_creator"
-ToolSearch: "select:mcp__claude-in-chrome__javascript_tool"
-```
-
-Then call `tabs_context_mcp` first to understand current browser state. Create a new tab for testing — never reuse existing user tabs.
-
-## Tool Mapping by Action
-
-### Navigate to a page
-```
-tabs_create_mcp → create new tab with URL http://localhost:{PORT}{route}
-  OR
-navigate → go to URL in existing tab
-```
-After navigating, wait 2-3 seconds for client-side rendering, then call `get_page_text` to verify content loaded.
-
-### Check if page rendered
-```
-get_page_text → extract visible text content
-```
-Read the text and judge: is this the actual application, or an error/fallback page? Browser error pages, framework error overlays, "Unable to connect" screens, and empty shells all have text — but they're not the app. If the page content doesn't look like what the application is supposed to show, it's a failure.
-
-### Read page structure
-```
-read_page → get DOM structure and layout info
-```
-Use this to understand component hierarchy before interacting.
-
-### Find interactive elements
-```
-find → locate buttons, links, inputs by text content or attributes
-```
-Returns element positions for clicking.
-
-### Click elements
-```
-computer → click at coordinates returned by find
-```
-After clicking, wait 1-2 seconds, then check console + network for errors.
-
-### Fill form fields
-```
-form_input → set values on input fields, selects, textareas
-```
-Identify fields with `find` first, then use `form_input` with the field selector.
-
-### Take screenshots
-```
-computer → screenshot action captures the visible viewport
-```
-Save screenshots into the topic-scoped directory that PHASE 1 set up (`.devlyn/screenshots/<topic-slug>/`), organized by phase:
-- Smoke: `<topic>/smoke/<route>.png` — e.g., `smoke/root.png`, `smoke/dashboard.png`
-- Feature: `<topic>/feature/<criterion>-step<N>.png` — e.g., `feature/create-project-step3.png`
-- Visual: `<topic>/visual/<viewport>-<route>.png` — e.g., `visual/mobile-dashboard.png`
-
-Since `computer → screenshot` writes to a default location, move/rename the captured file into the right subdirectory immediately after taking it, so evidence paths in the report match this scheme.
-
-### Resize viewport
-```
-resize_window → set width and height
-```
-Mobile: `resize_window(375, 812)`. Desktop: `resize_window(1280, 800)`.
-
-### Read console messages
-```
-read_console_messages → get all console output
-```
-Use `pattern` parameter to filter. Useful patterns:
-- `"error|Error|ERROR"` — catch errors
-- `"warn|Warning"` — catch warnings
-- Exclude known noise: React dev warnings (`"Warning: "` prefix), HMR messages (`"[vite]"`, `"[HMR]"`, `"[Fast Refresh]"`), favicon 404s
-
-### Read network requests
-```
-read_network_requests → get all HTTP requests with status codes
-```
-Flag: any request with status 4xx or 5xx (excluding `/favicon.ico`). Flag: any CORS error. Ignore: HMR websocket connections, source map requests (`.map`).
-
-### Record multi-step flows
-```
-gif_creator → record a sequence of actions as an animated GIF
-```
-Use for flow tests with 3+ steps. Capture extra frames before and after actions for smooth playback. Name meaningfully: `flow-user-registration.gif`.
-
-### Run custom assertions
-```
-javascript_tool → execute JS in the page context
-```
-Useful for checking specific DOM state that other tools can't easily verify:
-- `document.querySelectorAll('.error-message').length` — count error elements
-- `window.__NEXT_DATA__` — check Next.js hydration data
-- `document.title` — verify page title
-
-Avoid triggering alerts or confirms — they block the extension. Use `console.log` + `read_console_messages` instead.
-
-## Error Filtering
-
-Not every console message is a real problem. Apply these filters:
-
-**Ignore (dev noise)**:
-- `[HMR]`, `[vite]`, `[Fast Refresh]`, `[webpack-dev-server]`
-- `Warning: ReactDOM.render is no longer supported` (React 18 dev warning)
-- `Download the React DevTools`
-- `/favicon.ico` 404
-- Source map warnings
-
-**Flag as errors**:
-- `Uncaught` anything
-- `TypeError`, `ReferenceError`, `SyntaxError`
-- `Failed to fetch` (network errors)
-- `CORS` errors
-- `Hydration` mismatches
-- `ChunkLoadError` (code splitting failures)
-- Any `console.error` call from application code

package/config/skills/devlyn:browser-validate/references/tier2-playwright.md

@@ -1,195 +0,0 @@
-# Tier 2: Playwright (Headless Browser)
-
-Solid middle-ground tier. No browser extension needed — works in CI, SSH, Docker, and headless environments. Provides DOM interaction, console monitoring, screenshots, and network inspection. No GIF recording.
-
-Read this file only when Tier 2 was selected during DETECT phase.
-
----
-
-## Two Modes
-
-Playwright Tier 2 has two sub-modes depending on what's available. The skill auto-detects which to use.
-
-### Mode A: Playwright MCP (preferred)
-
-If `mcp__playwright__*` tools are available (installed via `npx devlyn-cli` → select "playwright" MCP), use them directly. This gives interactive browser control similar to Tier 1:
-
-- `mcp__playwright__browser_navigate` — navigate to URL
-- `mcp__playwright__browser_screenshot` — capture screenshot
-- `mcp__playwright__browser_click` — click elements
-- `mcp__playwright__browser_type` — type into inputs
-- `mcp__playwright__browser_console` — read console messages
-- `mcp__playwright__browser_network` — read network requests
-- `mcp__playwright__browser_resize` — resize viewport
-
-When Playwright MCP is available, follow the same interaction pattern as Tier 1 (navigate → check → interact → screenshot) but using `mcp__playwright__*` tools instead of `mcp__claude-in-chrome__*`.
-
-Load tools via ToolSearch before use: `ToolSearch: "select:mcp__playwright__browser_navigate"` etc.
-
-### Mode B: Script Generation (fallback)
-
-If Playwright MCP is not installed but `npx playwright` CLI is available, generate and execute test scripts. This is the approach documented below.
-
-## Setup (Mode B only)
-
-Playwright runs via `npx` with auto-download. No global install needed. If browsers aren't installed yet:
-```bash
-npx playwright install chromium 2>/dev/null
-```
-This downloads only Chromium (~130MB), not all browsers. It's a one-time cost.
-
-## Approach (Mode B)
-
-Generate a temporary test script from the test steps, run it with Playwright's JSON reporter, then parse the results. This avoids needing a persistent test infrastructure — the script is created, executed, and cleaned up.
-
-## Script Generation
-
-For each phase (smoke, flow, visual), generate a test script at `.devlyn/browser-test.spec.ts`.
-
-### Smoke Test Script Template
-
-```typescript
-import { test, expect } from '@playwright/test';
-
-const PORT = {PORT};
-const ROUTES = {ROUTES_JSON_ARRAY};
-
-test.describe('Smoke Tests', () => {
-  for (const route of ROUTES) {
-    test(`smoke: ${route}`, async ({ page }) => {
-      const errors: string[] = [];
-      const failedRequests: string[] = [];
-
-      page.on('console', msg => {
-        if (msg.type() === 'error') errors.push(msg.text());
-      });
-
-      page.on('response', response => {
-        if (response.status() >= 400 && !response.url().includes('favicon')) {
-          failedRequests.push(`${response.status()} ${response.url()}`);
-        }
-      });
-
-      // If goto throws (connection refused), the test fails — that's correct behavior
-      await page.goto(`http://localhost:${PORT}${route}`, { waitUntil: 'networkidle', timeout: 15000 });
-
-      // Verify this is the actual application, not an error page.
-      // When a server is down or a route is broken, the browser shows an error page
-      // that still has text content — "Unable to connect", "This site can't be reached", etc.
-      // A naive length check would pass on these. The title is the best signal:
-      // browser error pages have titles like "Problem loading page" or the URL itself,
-      // while real apps have meaningful titles set by the application.
-      const title = await page.title();
-      const bodyText = await page.textContent('body') || '';
-
-      // Page must have substantive content
-      expect(bodyText.trim().length, 'Page body is empty').toBeGreaterThan(0);
-
-      // Fail if the page navigation itself failed (Playwright sets title to the URL on error)
-      const pageUrl = page.url();
-      expect(title, 'Page shows a browser error — server may be down').not.toBe(pageUrl);
-
-      await page.screenshot({ path: `${SCREENSHOT_DIR}/smoke/${route.replace(/^\//, '').replace(/\//g, '-') || 'root'}.png`, fullPage: true });
-      // SCREENSHOT_DIR is the topic-scoped dir set up in PHASE 1 of SKILL.md
-      // (e.g., .devlyn/screenshots/add-login-page). Inject it at test-generation
-      // time so every test writes into the same per-run folder.
-
-      if (errors.length > 0) {
-        test.info().annotations.push({ type: 'console_errors', description: errors.join(' | ') });
-      }
-      if (failedRequests.length > 0) {
-        test.info().annotations.push({ type: 'network_failures', description: failedRequests.join(' | ') });
-      }
-
-      expect(errors.filter(e => !e.includes('[HMR]') && !e.includes('favicon'))).toHaveLength(0);
-      expect(failedRequests).toHaveLength(0);
-    });
-  }
-});
-```
-
-### Flow Test Script Template
-
-For each flow test step from done-criteria, generate a test block:
-
-```typescript
-test('flow: [criterion description]', async ({ page }) => {
-  // Navigate
-  await page.goto(`http://localhost:${PORT}{start_route}`);
-
-  // Find and interact
-  await page.click('[text or selector]');
-  await page.fill('[selector]', '[value]');
-  await page.click('[submit selector]');
-
-  // Verify
-  await expect(page.locator('[verification selector]')).toBeVisible();
-
-  // Screenshot
-  await page.screenshot({ path: `${SCREENSHOT_DIR}/feature/[criterion-slug]-step[N].png` });
-});
-```
-
-### Visual Test Script Template
-
-```typescript
-test.describe('Visual - Mobile', () => {
-  test.use({ viewport: { width: 375, height: 812 } });
-  for (const route of ROUTES) {
-    test(`visual-mobile: ${route}`, async ({ page }) => {
-      await page.goto(`http://localhost:${PORT}${route}`, { waitUntil: 'networkidle' });
-      await page.screenshot({ path: `${SCREENSHOT_DIR}/visual/mobile-${route.replace(/^\//, '').replace(/\//g, '-') || 'root'}.png`, fullPage: true });
-    });
-  }
-});
-
-test.describe('Visual - Desktop', () => {
-  test.use({ viewport: { width: 1280, height: 800 } });
-  for (const route of ROUTES) {
-    test(`visual-desktop: ${route}`, async ({ page }) => {
-      await page.goto(`http://localhost:${PORT}${route}`, { waitUntil: 'networkidle' });
-      await page.screenshot({ path: `${SCREENSHOT_DIR}/visual/desktop-${route.replace(/^\//, '').replace(/\//g, '-') || 'root'}.png`, fullPage: true });
-    });
-  }
-});
-```
-
-## Execution
-
-```bash
-mkdir -p "$SCREENSHOT_DIR"/{smoke,feature,visual}
-npx playwright test .devlyn/browser-test.spec.ts \
-  --reporter=json \
-  --output=.devlyn/playwright-results \
-  2>&1 | tee .devlyn/playwright-output.json
-```
-
-## Parsing Results
-
-Read `.devlyn/playwright-output.json`. The JSON structure contains:
-- `suites[].specs[].tests[].results[].status` — `"passed"`, `"failed"`, `"timedOut"`
-- `suites[].specs[].tests[].results[].errors` — error messages with stack traces
-- `suites[].specs[].tests[].annotations` — custom annotations (console_errors, network_failures)
-
-Map these to BROWSER-RESULTS.md findings:
-- `failed` → route fails smoke, include error message
-- Annotations with `console_errors` → list in Runtime Errors section
-- Annotations with `network_failures` → list in Failed Network Requests section
-
-## Cleanup
-
-After parsing results:
-```bash
-rm -f .devlyn/browser-test.spec.ts
-rm -rf .devlyn/playwright-results
-rm -f .devlyn/playwright-output.json
-```
-
-Keep `$SCREENSHOT_DIR` (`.devlyn/screenshots/<topic-slug>/`) — those are evidence referenced by the report. Don't touch other topics' directories.
-
-## Limitations vs Tier 1
-
-- No GIF recording (can't capture multi-step flow animations)
-- No live DOM exploration (tests are scripted, not interactive)
-- Screenshots are full-page captures, not viewport-specific (use `fullPage: true`)
-- Console filtering is code-based (less flexible than chrome MCP pattern matching)

package/config/skills/devlyn:browser-validate/references/tier3-curl.md

@@ -1,57 +0,0 @@
-# Tier 3: HTTP Smoke (curl)
-
-Bare-minimum fallback. No browser, no JavaScript execution, no interaction testing. This tier confirms the dev server responds and pages return valid HTML. It catches "app doesn't start" and "page returns 500" but nothing subtler.
-
-Read this file only when Tier 3 was selected during DETECT phase.
-
----
-
-## What You Can Test
-
-- Server responds on the expected port
-- Pages return HTTP 200
-- HTML contains a `<body>` with content (not an empty shell)
-- No server-side error indicators in the HTML
-
-## What You Cannot Test
-
-- Client-side rendering (SPA content won't appear in curl output)
-- JavaScript errors or console output
-- Network requests made by the client
-- Interactive elements (forms, buttons, navigation)
-- Visual layout or responsive behavior
-- Screenshots
-
-## Smoke Test
-
-For each affected route:
-
-```bash
-# Check HTTP status
-STATUS=$(curl -s -o /dev/null -w "%{http_code}" http://localhost:{PORT}{route} --max-time 10)
-
-# Get HTML content
-HTML=$(curl -s http://localhost:{PORT}{route} --max-time 10)
-```
-
-### Pass Criteria
-
-A route passes if:
-1. curl succeeds (doesn't error out with connection refused or timeout)
-2. `STATUS` is `200` (or `301`, `302`, `304`) — not `000`, not `5xx`
-3. HTML contains `<body` tag
-3. HTML body has more than 100 characters of text content (not just empty divs)
-4. HTML does not contain server error indicators: `Internal Server Error`, `500`, `ECONNREFUSED`, `Cannot GET`, `404`
-
-### Parsing HTML Content
-
-Since curl returns raw HTML (no JS execution), for SPAs the body may only contain a root `<div id="root"></div>` or `<div id="__next"></div>`. This is normal and counts as a PASS for Tier 3 — note it as "SPA shell detected, client-side rendering not verifiable at this tier."
-
-For SSR frameworks (Next.js with server components, Nuxt, Astro), the HTML should contain actual rendered content.
-
-## Report Adjustments
-
-When writing BROWSER-RESULTS.md from Tier 3:
-- Set confidence level to LOW
-- Leave Console Errors, Network Failures, Flow Tests, and Visual Check sections as "N/A — Tier 3 (HTTP only)"
-- Note the limitation: "Tier 3 testing provides HTTP-level validation only. Client-side behavior, JavaScript errors, and visual rendering were not tested. For comprehensive browser validation, install the claude-in-chrome extension (Tier 1) or Playwright (Tier 2)."

package/config/skills/devlyn:clean/SKILL.md

@@ -1,285 +0,0 @@
----
-description: Detect and remove dead code, unused dependencies, complexity hotspots, and tech debt. Keeps your codebase lean and maintainable.
-allowed-tools: Read, Write, Edit, Glob, Grep, Bash(ls:*), Bash(test:*), Bash(git log:*), Bash(git blame:*), Bash(wc:*), Bash(npm:*), Bash(npx:*), Bash(pnpm:*), Bash(yarn:*), Bash(cargo:*), Bash(pip:*), Bash(go:*), Bash(node -e:*), Bash(python -c:*)
-argument-hint: [focus area, or empty for full scan]
----
-
-<role>
-You are a Codebase Health Engineer. Your job is to find and safely remove dead weight from a codebase — unused code, stale dependencies, orphan files, complexity hotspots, and test gaps. You care about maintainability as much as functionality.
-
-Your operating principle: every line of code is a liability. Code that serves no purpose increases build times, confuses contributors, and hides real bugs. Remove it with confidence, preserve it with evidence.
-</role>
-
-<user_input>
-$ARGUMENTS
-</user_input>
-
-<escalation>
-If the cleanup reveals deeply intertwined architectural debt — circular dependencies, god objects woven into multiple systems, or patterns that can't be safely removed without redesigning interfaces — escalate to `/devlyn:team-resolve` with your findings so a multi-perspective team can plan the refactor.
-</escalation>
-
-<process>
-
-## Phase 1: CODEBASE UNDERSTANDING
-
-Before analyzing anything, understand the project's shape.
-
-1. Read project metadata in parallel:
-   - package.json / Cargo.toml / pyproject.toml / go.mod (whatever applies)
-   - README.md, CLAUDE.md
-   - Linter and build configs (tsconfig.json, .eslintrc, biome.json, etc.)
-
-2. Scan the project structure:
-   - List top-level directories
-   - Identify the tech stack, framework, entry points
-   - Check for monorepo structure (workspaces, packages/)
-
-3. Check recent git activity:
-   - `git log --oneline -20` for recent changes
-   - Identify actively maintained vs. stale areas
-
-## Phase 2: ANALYSIS
-
-Run these 5 analysis categories. Use parallel tool calls — each category is independent.
-
-### Category 1: Dead Code Detection
-
-Find code that is never executed or referenced.
-
-**What to scan:**
-- Exported functions/classes never imported elsewhere
-- Files with zero inbound imports (orphan files)
-- Unused variables and parameters (beyond what linters catch)
-- Feature flags or config branches that are permanently off
-- Commented-out code blocks (more than 3 lines)
-- Dead routes: route definitions pointing to removed handlers
-- Unused CSS classes or styled components (in UI projects)
-
-**How to verify:**
-- Use Grep to search for import/require/usage of each suspect
-- Check if "unused" code is actually used dynamically (string interpolation, dynamic imports, reflection)
-- Verify test files before flagging — test helpers may appear unused but are needed
-
-### Category 2: Dependency Hygiene
-
-Find dependency bloat and version issues.
-
-**What to scan:**
-- Installed packages never imported in source code
-- Duplicate packages serving the same purpose (e.g., both lodash and underscore)
-- devDependencies used in production code (or vice versa)
-- Pinned versions with known security issues (if lockfile available)
-- Dependencies that could be replaced by built-in language features
-
-**How to verify:**
-- Search all source files for each dependency's import/require
-- Check indirect usage (peer dependencies, plugins, config references)
-- Verify build tool plugins (webpack, vite, etc.) that may reference deps implicitly
-
-### Category 3: Test Health
-
-Find gaps, obsolete tests, and tests that don't actually test anything.
-
-**What to scan:**
-- Test files for components/modules that no longer exist
-- Tests with no assertions (empty test bodies, missing expect/assert)
-- Skipped tests (`.skip`, `xit`, `xdescribe`, `@pytest.mark.skip`) without explanation
-- Snapshot tests with stale snapshots
-- Test coverage gaps: source files with zero corresponding test files
-
-**How to verify:**
-- Cross-reference test file names with source file names
-- Read test bodies to check for meaningful assertions
-- Check if skipped tests reference issues that are now resolved
-
-### Category 4: Complexity Hotspots
-
-Find code that's disproportionately hard to maintain.
-
-**What to scan:**
-- Functions longer than 50 lines
-- Files longer than 500 lines
-- Nesting deeper than 4 levels
-- Functions with more than 5 parameters
-- God objects/files that accumulate unrelated responsibilities
-- Circular dependencies between modules
-
-**How to measure:**
-- `wc -l` on suspect files
-- Read and count nesting levels
-- Trace import chains for circularity
-
-### Category 5: Code Hygiene
-
-Find patterns that degrade codebase quality over time.
-
-**What to scan:**
-- Console.log/print statements in production code (not in designated logger)
-- TODO/FIXME/HACK comments older than 90 days (check with git blame)
-- Hardcoded values that should be constants or config (magic numbers, URLs, keys)
-- Inconsistent naming patterns (camelCase mixed with snake_case)
-- Duplicate code blocks (3+ lines repeated in 2+ places)
-- Empty catch blocks or swallowed errors
-- Type `any` overuse (TypeScript projects)
-
-## Phase 3: PRIORITIZE
-
-Score each finding:
-
-```
-| Priority | Criteria | Action |
-|----------|----------|--------|
-| P0 — Remove now | Zero risk, clearly dead (orphan file, unused export with no dynamic usage) | Auto-fix |
-| P1 — Remove with care | Likely dead but verify (unused dep, stale test) | Fix after user confirms |
-| P2 — Refactor | Alive but unhealthy (complexity, duplication, hygiene) | Plan the refactor |
-| P3 — Flag | Ambiguous — might be used in ways not visible in code | Report to user |
-```
-
-## Phase 4: PRESENT PLAN
-
-Present findings to the user for approval before making changes.
-
-```
-## Codebase Health Report
-
-### Summary
-- Scanned: {N} files across {M} directories
-- Found: {X} issues ({P0} auto-fixable, {P1} to confirm, {P2} to refactor, {P3} flagged)
-
-### P0 — Safe to Remove (auto-fix)
-- `src/utils/oldHelper.ts` — Orphan file, zero imports anywhere
-- `package.json` — Remove `left-pad` (never imported)
-
-### P1 — Remove with Confirmation
-- `src/components/LegacyWidget.tsx` — No imports found, but has a default export (could be dynamic import)
-- `tests/api.old.test.ts` — Tests removed API endpoints
-
-### P2 — Refactor Candidates
-- `src/services/userService.ts` (287 lines) — Split into auth, profile, preferences
-- `src/utils/helpers.ts:45-98` — Duplicated in `src/lib/shared.ts:12-65`
-
-### P3 — Flagged for Review
-- `src/config/featureFlags.ts` — Contains 3 flags set to `false` since [date]
-
-### Estimated Impact
-- Lines removed: ~{N}
-- Dependencies removed: {N}
-- Files deleted: {N}
-- Complexity reduced: {description}
-
-Approve this plan to proceed? (You can exclude specific items.)
-```
-
-Wait for explicit user approval. If the user excludes items, respect that.
-
-## Phase 5: APPLY FIXES
-
-Execute the approved changes in this order:
-
-1. **Delete orphan files** — safest, no cascading effects
-2. **Remove dead exports/functions** — verify no dynamic usage first
-3. **Remove unused dependencies** — update package.json/lockfile
-4. **Delete stale tests** — clean up test suite
-5. **Apply hygiene fixes** — remove console.logs, resolve TODOs, clean comments
-6. **Refactor complexity** — only if user approved P2 items
-
-For each change:
-- Use Edit for targeted removals (prefer over full rewrites)
-- Run linter after changes to catch cascade issues
-- If removing a dependency, verify the project still builds
-
-## Phase 6: VERIFY & REPORT
-
-After all changes:
-
-1. Run the linter — fix any new issues introduced
-2. Run the test suite — everything should still pass
-3. If anything breaks, revert that specific change and report it
-
-Present the final summary:
-
-```
-## Cleanup Complete
-
-### Changes Applied
-- **Removed**: {N} dead files, {N} unused functions, {N} stale deps
-- **Cleaned**: {N} console.logs, {N} resolved TODOs, {N} commented blocks
-- **Refactored**: {N} complexity hotspots (if applicable)
-
-### Verification
-- Lint: [PASS / FAIL with details]
-- Tests: [PASS / FAIL with details]
-- Build: [PASS / FAIL if applicable]
-
-### Lines of Code
-- Before: {N}
-- After: {N}
-- Removed: {N} ({percentage}%)
-
-### Deferred Items
-- {items the user excluded or that couldn't be safely removed}
-
-### Recommendations
-- {Any follow-up actions needed}
-- Schedule: run `/devlyn:clean` periodically to prevent debt accumulation
-```
-
-</process>
-
-<focus_area>
-
-## Handling Focus Area Arguments
-
-If the user provides a focus area (e.g., `/devlyn:clean dependencies` or `/devlyn:clean tests`):
-
-1. Still run Phase 1 (codebase understanding) at reduced depth
-2. In Phase 2, only run the relevant analysis category:
-   - `dead code` or `unused` → Category 1
-   - `dependencies` or `deps` → Category 2
-   - `tests` or `test health` → Category 3
-   - `complexity` or `hotspots` → Category 4
-   - `hygiene` or `lint` → Category 5
-3. Present a focused plan and execute
-
-This enables quick, targeted cleanups without a full scan.
-
-</focus_area>
-
-<safety_rules>
-
-## What to Preserve
-
-Be careful not to remove:
-- Dynamically imported modules (`import()`, `require()` with variables)
-- Reflection-based usage (decorators, dependency injection, ORM entities)
-- CLI entry points referenced in package.json `bin` field
-- Config files referenced by tools (webpack, babel, jest, etc.)
-- Build artifacts referenced in CI/CD pipelines
-- Public API surface used by consumers of the package
-- Test utilities imported by test files in other packages (monorepo)
-
-When in doubt, classify as P3 (flagged) rather than P0 (auto-remove).
-
-</safety_rules>
-
-<examples>
-
-### Example 1: Small project cleanup
-
-Input: `/devlyn:clean`
-
-Finds: 2 orphan files, 3 unused deps, 8 console.logs, 1 stale test.
-
-Plan is small (P0 + P1 items), presents and executes after approval:
-```
-Removed 2 orphan files, 3 dependencies, 8 console.logs, 1 stale test.
-Tests pass. 340 lines removed.
-```
-
-### Example 2: Focused dependency cleanup
-
-Input: `/devlyn:clean deps`
-
-Scans only dependency hygiene. Finds `moment` (replaced by `dayjs` already in use), `lodash` (only `_.get` used — replaceable with optional chaining). Presents targeted plan.
-
-</examples>