@bastani/atomic 0.6.8 → 0.7.0-2

package/.agents/skills/impeccable/reference/typeset.md

@@ -1,124 +0,0 @@
-Assess and improve typography that feels generic, inconsistent, or poorly structured — turning default-looking text into intentional, well-crafted type.
-
----
-
-## Register
-
-Brand: run the font selection procedure in [brand.md](brand.md). Pairing follows the brand's lane (display serif + sans body for editorial/luxury, one committed sans for tech, etc.). Fluid `clamp()` scale, ≥1.25 ratio between steps.
-
-Product: system fonts and familiar sans stacks are legitimate here. One well-tuned family typically carries the whole UI. Fixed `rem` scale, 1.125–1.2 ratio between more closely-spaced steps.
-
----
-
-## Assess Current Typography
-
-Analyze what's weak or generic about the current type:
-
-1. **Font choices**:
-   - Are we using invisible defaults? (Inter, Roboto, Arial, Open Sans, system defaults)
-   - Does the font match the brand personality? (A playful brand shouldn't use a corporate typeface)
-   - Are there too many font families? (More than 2-3 is almost always a mess)
-
-2. **Hierarchy**:
-   - Can you tell headings from body from captions at a glance?
-   - Are font sizes too close together? (14px, 15px, 16px = muddy hierarchy)
-   - Are weight contrasts strong enough? (Medium vs Regular is barely visible)
-
-3. **Sizing & scale**:
-   - Is there a consistent type scale, or are sizes arbitrary?
-   - Does body text meet minimum readability? (16px+)
-   - Is the sizing strategy appropriate for the context? (Fixed `rem` scales for app UIs; fluid `clamp()` for marketing/content page headings)
-
-4. **Readability**:
-   - Are line lengths comfortable? (45-75 characters ideal)
-   - Is line-height appropriate for the font and context?
-   - Is there enough contrast between text and background?
-
-5. **Consistency**:
-   - Are the same elements styled the same way throughout?
-   - Are font weights used consistently? (Not bold in one section, semibold in another for the same role)
-   - Is letter-spacing intentional or default everywhere?
-
-**CRITICAL**: The goal isn't to make text "fancier" — it's to make it clearer, more readable, and more intentional. Good typography is invisible; bad typography is distracting.
-
-## Plan Typography Improvements
-
-Consult the [typography reference](typography.md) for detailed guidance on scales, pairing, and loading strategies.
-
-Create a systematic plan:
-
-- **Font selection**: Do fonts need replacing? What fits the brand/context?
-- **Type scale**: Establish a modular scale (e.g., 1.25 ratio) with clear hierarchy
-- **Weight strategy**: Which weights serve which roles? (Regular for body, Semibold for labels, Bold for headings — or whatever fits)
-- **Spacing**: Line-heights, letter-spacing, and margins between typographic elements
-
-## Improve Typography Systematically
-
-### Font Selection
-
-If fonts need replacing:
-- Choose fonts that reflect the brand personality
-- Pair with genuine contrast (serif + sans, geometric + humanist) — or use a single family in multiple weights
-- Ensure web font loading doesn't cause layout shift (`font-display: swap`, metric-matched fallbacks)
-
-### Establish Hierarchy
-
-Build a clear type scale:
-- **5 sizes cover most needs**: caption, secondary, body, subheading, heading
-- **Use a consistent ratio** between levels (1.25, 1.333, or 1.5)
-- **Combine dimensions**: Size + weight + color + space for strong hierarchy — don't rely on size alone
-- **App UIs**: Use a fixed `rem`-based type scale, optionally adjusted at 1-2 breakpoints. Fluid sizing undermines the spatial predictability that dense, container-based layouts need
-- **Marketing / content pages**: Use fluid sizing via `clamp(min, preferred, max)` for headings and display text. Keep body text fixed
-
-### Fix Readability
-
-- Set `max-width` on text containers using `ch` units (`max-width: 65ch`)
-- Adjust line-height per context: tighter for headings (1.1-1.2), looser for body (1.5-1.7)
-- Increase line-height slightly for light-on-dark text
-- Ensure body text is at least 16px / 1rem
-
-### Refine Details
-
-- Use `tabular-nums` for data tables and numbers that should align
-- Apply proper `letter-spacing`: slightly open for small caps and uppercase, default or tight for large display text
-- Use semantic token names (`--text-body`, `--text-heading`), not value names (`--font-16`)
-- Set `font-kerning: normal` and consider OpenType features where appropriate
-
-### Weight Consistency
-
-- Define clear roles for each weight and stick to them
-- Don't use more than 3-4 weights (Regular, Medium, Semibold, Bold is plenty)
-- Load only the weights you actually use (each weight adds to page load)
-
-**NEVER**:
-- Use more than 2-3 font families
-- Pick sizes arbitrarily — commit to a scale
-- Set body text below 16px
-- Use decorative/display fonts for body text
-- Disable browser zoom (`user-scalable=no`)
-- Use `px` for font sizes — use `rem` to respect user settings
-- Default to Inter/Roboto/Open Sans when personality matters
-- Pair fonts that are similar but not identical (two geometric sans-serifs)
-
-## Verify Typography Improvements
-
-- **Hierarchy**: Can you identify heading vs body vs caption instantly?
-- **Readability**: Is body text comfortable to read in long passages?
-- **Consistency**: Are same-role elements styled identically throughout?
-- **Personality**: Does the typography reflect the brand?
-- **Performance**: Are web fonts loading efficiently without layout shift?
-- **Accessibility**: Does text meet WCAG contrast ratios? Is it zoomable to 200%?
-
-Remember: Typography is the foundation of interface design — it carries the majority of information. Getting it right is the highest-leverage improvement you can make.
-
-## Live-mode signature params
-
-Each variant MUST declare a `scale` param controlling the hierarchy ratio. Express all font sizes in the variant's scoped CSS through `calc(var(--p-scale, 1) * <base>)` or, better, scale the type ramp via `clamp(min, calc(var(--p-scale, 1) * Npx), max)`. Users slide from subdued to commanding.
-
-```json
-{"id":"scale","kind":"range","min":0.85,"max":1.3,"step":0.05,"default":1,"label":"Scale"}
-```
-
-Where the variant riffs on a specific pairing, expose the pairing choice as a `steps` param (e.g. "serif display + sans body" vs. "mono display + sans body" vs. "all-sans"). Each branch routes through `:scope[data-p-pairing="X"]` selectors in scoped CSS.
-
-See `reference/live.md` for the full params contract.

package/.agents/skills/impeccable/reference/typography.md

@@ -1,159 +0,0 @@
-# Typography
-
-## Classic Typography Principles
-
-### Vertical Rhythm
-
-Your line-height should be the base unit for ALL vertical spacing. If body text has `line-height: 1.5` on `16px` type (= 24px), spacing values should be multiples of 24px. This creates subconscious harmony—text and space share a mathematical foundation.
-
-### Modular Scale & Hierarchy
-
-The common mistake: too many font sizes that are too close together (14px, 15px, 16px, 18px...). This creates muddy hierarchy.
-
-**Use fewer sizes with more contrast.** A 5-size system covers most needs:
-
-| Role | Typical Ratio | Use Case |
-|------|---------------|----------|
-| xs | 0.75rem | Captions, legal |
-| sm | 0.875rem | Secondary UI, metadata |
-| base | 1rem | Body text |
-| lg | 1.25-1.5rem | Subheadings, lead text |
-| xl+ | 2-4rem | Headlines, hero text |
-
-Popular ratios: 1.25 (major third), 1.333 (perfect fourth), 1.5 (perfect fifth). Pick one and commit.
-
-### Readability & Measure
-
-Use `ch` units for character-based measure (`max-width: 65ch`). Line-height scales inversely with line length—narrow columns need tighter leading, wide columns need more.
-
-**Non-obvious**: Light text on dark backgrounds needs compensation on three axes, not just one. Bump line-height by 0.05–0.1, add a touch of letter-spacing (0.01–0.02em), and optionally step the body weight up one notch (regular → medium). The perceived weight drops across all three; fix all three.
-
-**Paragraph rhythm**: Pick either space between paragraphs OR first-line indentation. Never both. Digital usually wants space; editorial/long-form can justify indent-only.
-
-## Font Selection & Pairing
-
-The tactical selection procedure and the reflex-reject list live in [reference/brand.md](brand.md) under **Font selection procedure** and **Reflex-reject list** (loaded for brand-register tasks). The rest of this section covers the adjacent knowledge: anti-reflex corrections, system font use, and pairing rules.
-
-### Anti-reflexes worth defending against
-
-- A technical/utilitarian brief does NOT need a serif "for warmth." Most tech tools should look like tech tools.
-- An editorial/premium brief does NOT need the same expressive serif everyone is using right now. Premium can be Swiss-modern, can be neo-grotesque, can be a literal monospace, can be a quiet humanist sans.
-- A children's product does NOT need a rounded display font. Kids' books use real type.
-- A "modern" brief does NOT need a geometric sans. The most modern thing you can do is not use the font everyone else is using.
-
-**System fonts are underrated**: `-apple-system, BlinkMacSystemFont, "Segoe UI", system-ui` looks native, loads instantly, and is highly readable. Consider this for apps where performance > personality.
-
-### Pairing Principles
-
-**The non-obvious truth**: You often don't need a second font. One well-chosen font family in multiple weights creates cleaner hierarchy than two competing typefaces. Only add a second font when you need genuine contrast (e.g., display headlines + body serif).
-
-When pairing, contrast on multiple axes:
-- Serif + Sans (structure contrast)
-- Geometric + Humanist (personality contrast)
-- Condensed display + Wide body (proportion contrast)
-
-**Never pair fonts that are similar but not identical** (e.g., two geometric sans-serifs). They create visual tension without clear hierarchy.
-
-### Web Font Loading
-
-The layout shift problem: fonts load late, text reflows, and users see content jump. Here's the fix:
-
-```css
-/* 1. Use font-display: swap for visibility */
-@font-face {
-  font-family: 'CustomFont';
-  src: url('font.woff2') format('woff2');
-  font-display: swap;
-}
-
-/* 2. Match fallback metrics to minimize shift */
-@font-face {
-  font-family: 'CustomFont-Fallback';
-  src: local('Arial');
-  size-adjust: 105%;        /* Scale to match x-height */
-  ascent-override: 90%;     /* Match ascender height */
-  descent-override: 20%;    /* Match descender depth */
-  line-gap-override: 10%;   /* Match line spacing */
-}
-
-body {
-  font-family: 'CustomFont', 'CustomFont-Fallback', sans-serif;
-}
-```
-
-Tools like [Fontaine](https://github.com/unjs/fontaine) calculate these overrides automatically.
-
-**`swap` vs `optional`**: `swap` shows fallback text immediately and FOUT-swaps when the web font arrives. `optional` uses the fallback if the web font misses a small load budget (~100ms) and avoids the shift entirely. Pick `optional` when zero layout shift matters more than seeing the branded font on slow networks.
-
-**Preload the critical weight only**: typically the regular-weight body font used above the fold. Preloading every weight costs more bandwidth than it saves.
-
-**Variable fonts for 3+ weights or styles**: a single variable font file is usually smaller than three static weight files, gives fractional weight control, and pairs well with `font-optical-sizing: auto`. For 1–2 weights, static is fine.
-
-## Modern Web Typography
-
-### Fluid Type
-
-Fluid typography via `clamp(min, preferred, max)` scales text smoothly with the viewport. The middle value (e.g., `5vw + 1rem`) controls scaling rate—higher vw = faster scaling. Add a rem offset so it doesn't collapse to 0 on small screens.
-
-**Use fluid type for**: Headings and display text on marketing/content pages where text dominates the layout and needs to breathe across viewport sizes.
-
-**Use fixed `rem` scales for**: App UIs, dashboards, and data-dense interfaces. No major app design system (Material, Polaris, Primer, Carbon) uses fluid type in product UI — fixed scales with optional breakpoint adjustments give the spatial predictability that container-based layouts need. Body text should also be fixed even on marketing pages, since the size difference across viewports is too small to warrant it.
-
-**Bound your clamp()**: keep `max-size ≤ ~2.5 × min-size`. Wider ratios break the browser's zoom and reflow behaviour and make large viewports feel like the page is shouting.
-
-**Scale container width and font-size together** so effective character measure stays in the 45–75ch band at every viewport. A heading that widens faster than its container drifts out of the comfortable measure at the top end.
-
-### OpenType Features
-
-Most developers don't know these exist. Use them for polish:
-
-```css
-/* Tabular numbers for data alignment */
-.data-table { font-variant-numeric: tabular-nums; }
-
-/* Proper fractions */
-.recipe-amount { font-variant-numeric: diagonal-fractions; }
-
-/* Small caps for abbreviations */
-abbr { font-variant-caps: all-small-caps; }
-
-/* Disable ligatures in code */
-code { font-variant-ligatures: none; }
-
-/* Enable kerning (usually on by default, but be explicit) */
-body { font-kerning: normal; }
-```
-
-Check what features your font supports at [Wakamai Fondue](https://wakamaifondue.com/).
-
-### Rendering polish
-
-```css
-/* Even out heading line lengths (browser picks better break points) */
-h1, h2, h3 { text-wrap: balance; }
-
-/* Reduce orphans and ragged endings in long prose */
-article p { text-wrap: pretty; }
-
-/* Variable fonts: pick the right optical-size master automatically */
-body { font-optical-sizing: auto; }
-```
-
-**ALL-CAPS tracking**: capitals sit too close at default spacing. Add 5–12% letter-spacing (`letter-spacing: 0.05em` to `0.12em`) to short all-caps labels, eyebrows, and small headings. Real small caps (via `font-variant-caps`) need the same treatment, slightly gentler.
-
-## Typography System Architecture
-
-Name tokens semantically (`--text-body`, `--text-heading`), not by value (`--font-size-16`). Include font stacks, size scale, weights, line-heights, and letter-spacing in your token system.
-
-## Accessibility Considerations
-
-Beyond contrast ratios (which are well-documented), consider:
-
-- **Never disable zoom**: `user-scalable=no` breaks accessibility. If your layout breaks at 200% zoom, fix the layout.
-- **Use rem/em for font sizes**: This respects user browser settings. Never `px` for body text.
-- **Minimum 16px body text**: Smaller than this strains eyes and fails WCAG on mobile.
-- **Adequate touch targets**: Text links need padding or line-height that creates 44px+ tap targets.
-
----
-
-**Avoid**: More than 2-3 font families per project. Skipping fallback font definitions. Ignoring font loading performance (FOUT/FOIT). Using decorative fonts for body text.

package/.agents/skills/impeccable/reference/ux-writing.md

@@ -1,107 +0,0 @@
-# UX Writing
-
-## The Button Label Problem
-
-**Never use "OK", "Submit", or "Yes/No".** These are lazy and ambiguous. Use specific verb + object patterns:
-
-| Bad | Good | Why |
-|-----|------|-----|
-| OK | Save changes | Says what will happen |
-| Submit | Create account | Outcome-focused |
-| Yes | Delete message | Confirms the action |
-| Cancel | Keep editing | Clarifies what "cancel" means |
-| Click here | Download PDF | Describes the destination |
-
-**For destructive actions**, name the destruction:
-- "Delete" not "Remove" (delete is permanent, remove implies recoverable)
-- "Delete 5 items" not "Delete selected" (show the count)
-
-## Error Messages: The Formula
-
-Every error message should answer: (1) What happened? (2) Why? (3) How to fix it? Example: "Email address isn't valid. Please include an @ symbol." not "Invalid input".
-
-### Error Message Templates
-
-| Situation | Template |
-|-----------|----------|
-| **Format error** | "[Field] needs to be [format]. Example: [example]" |
-| **Missing required** | "Please enter [what's missing]" |
-| **Permission denied** | "You don't have access to [thing]. [What to do instead]" |
-| **Network error** | "We couldn't reach [thing]. Check your connection and [action]." |
-| **Server error** | "Something went wrong on our end. We're looking into it. [Alternative action]" |
-
-### Don't Blame the User
-
-Reframe errors: "Please enter a date in MM/DD/YYYY format" not "You entered an invalid date".
-
-## Empty States Are Opportunities
-
-Empty states are onboarding moments: (1) Acknowledge briefly, (2) Explain the value of filling it, (3) Provide a clear action. "No projects yet. Create your first one to get started." not just "No items".
-
-## Voice vs Tone
-
-**Voice** is your brand's personality—consistent everywhere.
-**Tone** adapts to the moment.
-
-| Moment | Tone Shift |
-|--------|------------|
-| Success | Celebratory, brief: "Done! Your changes are live." |
-| Error | Empathetic, helpful: "That didn't work. Here's what to try..." |
-| Loading | Reassuring: "Saving your work..." |
-| Destructive confirm | Serious, clear: "Delete this project? This can't be undone." |
-
-**Never use humor for errors.** Users are already frustrated. Be helpful, not cute.
-
-## Writing for Accessibility
-
-**Link text** must have standalone meaning—"View pricing plans" not "Click here". **Alt text** describes information, not the image—"Revenue increased 40% in Q4" not "Chart". Use `alt=""` for decorative images. **Icon buttons** need `aria-label` for screen reader context.
-
-## Writing for Translation
-
-### Plan for Expansion
-
-German text is ~30% longer than English. Allocate space:
-
-| Language | Expansion |
-|----------|-----------|
-| German | +30% |
-| French | +20% |
-| Finnish | +30-40% |
-| Chinese | -30% (fewer chars, but same width) |
-
-### Translation-Friendly Patterns
-
-Keep numbers separate ("New messages: 3" not "You have 3 new messages"). Use full sentences as single strings (word order varies by language). Avoid abbreviations ("5 minutes ago" not "5 mins ago"). Give translators context about where strings appear.
-
-## Consistency: The Terminology Problem
-
-Pick one term and stick with it:
-
-| Inconsistent | Consistent |
-|--------------|------------|
-| Delete / Remove / Trash | Delete |
-| Settings / Preferences / Options | Settings |
-| Sign in / Log in / Enter | Sign in |
-| Create / Add / New | Create |
-
-Build a terminology glossary and enforce it. Variety creates confusion.
-
-## Avoid Redundant Copy
-
-If the heading explains it, the intro is redundant. If the button is clear, don't explain it again. Say it once, say it well.
-
-## Loading States
-
-Be specific: "Saving your draft..." not "Loading...". For long waits, set expectations ("This usually takes 30 seconds") or show progress.
-
-## Confirmation Dialogs: Use Sparingly
-
-Most confirmation dialogs are design failures—consider undo instead. When you must confirm: name the action, explain consequences, use specific button labels ("Delete project" / "Keep project", not "Yes" / "No").
-
-## Form Instructions
-
-Show format with placeholders, not instructions. For non-obvious fields, explain why you're asking.
-
----
-
-**Avoid**: Jargon without explanation. Blaming users ("You made an error" → "This field is required"). Vague errors ("Something went wrong"). Varying terminology for variety. Humor for errors.

package/.agents/skills/impeccable/scripts/cleanup-deprecated.mjs

@@ -1,284 +0,0 @@
-#!/usr/bin/env node
-/**
- * Cleans up deprecated Impeccable skill files, symlinks, and
- * skills-lock.json entries left over from previous versions.
- *
- * Safe to run repeatedly -- it is a no-op when nothing needs cleaning.
- *
- * Usage (from the project root):
- *   node {{scripts_path}}/cleanup-deprecated.mjs
- *
- * What it does:
- *   1. Finds every harness-specific skills directory (.claude/skills,
- *      .cursor/skills, .agents/skills, etc.).
- *   2. For each deprecated skill name (with and without i- prefix),
- *      checks if the directory exists and its SKILL.md mentions
- *      "impeccable" (to avoid deleting unrelated user skills).
- *   3. Deletes confirmed matches (files, directories, or symlinks).
- *   4. Removes the corresponding entries from skills-lock.json.
- */
-
-import { existsSync, readFileSync, writeFileSync, rmSync, readdirSync, statSync, lstatSync, unlinkSync } from 'node:fs';
-import { join, resolve } from 'node:path';
-
-// Skills that were renamed, merged, or folded in v2.0, v2.1, and v3.0.
-const DEPRECATED_NAMES = [
-  // v2.0 renames
-  'frontend-design',    // renamed to impeccable
-  'teach-impeccable',   // folded into /impeccable teach
-  // v2.1 merges
-  'arrange',            // renamed to layout
-  'normalize',          // merged into polish
-  'onboard',            // merged into harden
-  'extract',            // merged into /impeccable extract
-  // v3.0 consolidation: all standalone skills -> /impeccable sub-commands
-  'adapt',
-  'animate',
-  'audit',
-  'bolder',
-  'clarify',
-  'colorize',
-  'critique',
-  'delight',
-  'distill',
-  'harden',
-  'layout',
-  'optimize',
-  'overdrive',
-  'polish',
-  'quieter',
-  'shape',
-  'typeset',
-];
-
-// All known harness directories that may contain a skills/ subfolder.
-const HARNESS_DIRS = [
-  '.claude', '.cursor', '.gemini', '.codex', '.agents',
-  '.trae', '.trae-cn', '.pi', '.opencode', '.kiro', '.rovodev',
-];
-
-// Per-skill fingerprints for SKILL.md bodies that never mentioned
-// "impeccable" in their v2.x source. Used as a last-resort match
-// when no skills-lock.json exists and the word heuristic fails.
-// The strings are lifted verbatim from the v2.x frontmatter
-// descriptions, so collisions with hand-written user skills are
-// vanishingly unlikely.
-const SKILL_FINGERPRINTS = {
-  harden: 'Make interfaces production-ready: error handling, empty states',
-  optimize: 'Diagnoses and fixes UI performance across loading speed',
-};
-
-/**
- * Walk up from startDir until we find a directory that looks like a
- * project root (has package.json, .git, or skills-lock.json).
- */
-export function findProjectRoot(startDir = process.cwd()) {
-  let dir = resolve(startDir);
-  const { root } = { root: '/' };
-  while (dir !== root) {
-    if (
-      existsSync(join(dir, 'package.json')) ||
-      existsSync(join(dir, '.git')) ||
-      existsSync(join(dir, 'skills-lock.json'))
-    ) {
-      return dir;
-    }
-    const parent = resolve(dir, '..');
-    if (parent === dir) break;
-    dir = parent;
-  }
-  return resolve(startDir);
-}
-
-/**
- * Load skills-lock.json from the project root, or null if missing/unreadable.
- */
-export function loadLock(projectRoot) {
-  const lockPath = join(projectRoot, 'skills-lock.json');
-  if (!existsSync(lockPath)) return null;
-  try {
-    return JSON.parse(readFileSync(lockPath, 'utf-8'));
-  } catch {
-    return null;
-  }
-}
-
-/**
- * Check whether a skill directory belongs to Impeccable. Three layered
- * signals, in order of reliability:
- *   1. Lock source equals "pbakaus/impeccable" (authoritative).
- *   2. SKILL.md body contains the word "impeccable".
- *   3. SKILL.md body contains a per-skill fingerprint (for harden and
- *      optimize, whose v2.x SKILL.md never mentioned the pack name).
- */
-export function isImpeccableSkill(skillDir, { skillName, lock } = {}) {
-  // 1. Authoritative: the lock file claims this skill is ours.
-  if (skillName && lock?.skills?.[skillName]?.source === 'pbakaus/impeccable') {
-    return true;
-  }
-  const skillMd = join(skillDir, 'SKILL.md');
-  if (!existsSync(skillMd)) return false;
-  let content;
-  try {
-    content = readFileSync(skillMd, 'utf-8');
-  } catch {
-    return false;
-  }
-  // 2. Word-level content heuristic.
-  if (/impeccable/i.test(content)) return true;
-  // 3. Per-skill fingerprint for old skills that never mentioned the pack.
-  //    Strip the i- prefix so both `harden` and `i-harden` resolve to the
-  //    same fingerprint entry.
-  const unprefixed = skillName?.startsWith('i-') ? skillName.slice(2) : skillName;
-  const fingerprint = unprefixed && SKILL_FINGERPRINTS[unprefixed];
-  if (fingerprint && content.includes(fingerprint)) return true;
-  return false;
-}
-
-/**
- * Build the full list of names to check: each deprecated name, plus
- * its i-prefixed variant.
- */
-export function buildTargetNames() {
-  const names = [];
-  for (const name of DEPRECATED_NAMES) {
-    names.push(name);
-    names.push(`i-${name}`);
-  }
-  return names;
-}
-
-/**
- * Find every skills directory across all harness dirs in the project.
- * Returns absolute paths that exist on disk.
- */
-export function findSkillsDirs(projectRoot) {
-  const dirs = [];
-  for (const harness of HARNESS_DIRS) {
-    const candidate = join(projectRoot, harness, 'skills');
-    if (existsSync(candidate)) {
-      dirs.push(candidate);
-    }
-  }
-  return dirs;
-}
-
-/**
- * Remove deprecated skill directories/symlinks from all harness dirs.
- * Reads skills-lock.json so the authoritative "source" field can
- * drive deletion even when SKILL.md never mentions impeccable.
- * Returns an array of paths that were deleted.
- */
-export function removeDeprecatedSkills(projectRoot, lock) {
-  if (lock === undefined) lock = loadLock(projectRoot);
-  const targets = buildTargetNames();
-  const skillsDirs = findSkillsDirs(projectRoot);
-  const deleted = [];
-
-  for (const skillsDir of skillsDirs) {
-    for (const name of targets) {
-      const skillPath = join(skillsDir, name);
-
-      // Use lstat to detect symlinks (existsSync follows symlinks and
-      // returns false for dangling ones).
-      let stat;
-      try {
-        stat = lstatSync(skillPath);
-      } catch {
-        continue; // does not exist at all
-      }
-
-      if (stat.isSymbolicLink()) {
-        // Symlink: check the target if it's alive, otherwise treat
-        // dangling symlinks to deprecated names as safe to remove.
-        const targetAlive = existsSync(skillPath);
-        const isMatch = targetAlive
-          ? isImpeccableSkill(skillPath, { skillName: name, lock })
-          : true;
-        if (isMatch) {
-          unlinkSync(skillPath);
-          deleted.push(skillPath);
-        }
-        continue;
-      }
-
-      // Regular directory -- verify it belongs to impeccable
-      if (isImpeccableSkill(skillPath, { skillName: name, lock })) {
-        rmSync(skillPath, { recursive: true, force: true });
-        deleted.push(skillPath);
-      }
-    }
-  }
-
-  return deleted;
-}
-
-/**
- * Remove deprecated entries from skills-lock.json.
- * Only removes entries whose source is "pbakaus/impeccable".
- * Returns the list of removed skill names.
- */
-export function cleanSkillsLock(projectRoot) {
-  const lockPath = join(projectRoot, 'skills-lock.json');
-  if (!existsSync(lockPath)) return [];
-
-  let lock;
-  try {
-    lock = JSON.parse(readFileSync(lockPath, 'utf-8'));
-  } catch {
-    return [];
-  }
-
-  if (!lock.skills || typeof lock.skills !== 'object') return [];
-
-  const targets = buildTargetNames();
-  const removed = [];
-
-  for (const name of targets) {
-    const entry = lock.skills[name];
-    if (!entry) continue;
-    // Only remove if it belongs to impeccable
-    if (entry.source === 'pbakaus/impeccable') {
-      delete lock.skills[name];
-      removed.push(name);
-    }
-  }
-
-  if (removed.length > 0) {
-    writeFileSync(lockPath, JSON.stringify(lock, null, 2) + '\n', 'utf-8');
-  }
-
-  return removed;
-}
-
-/**
- * Run the full cleanup. Returns a summary object.
- *
- * Order matters: read the lock and delete directories first, then
- * strip lock entries. Otherwise the authoritative signal is gone by
- * the time directory deletion runs.
- */
-export function cleanup(projectRoot) {
-  const root = projectRoot || findProjectRoot();
-  const lock = loadLock(root);
-  const deletedPaths = removeDeprecatedSkills(root, lock);
-  const removedLockEntries = cleanSkillsLock(root);
-  return { deletedPaths, removedLockEntries, projectRoot: root };
-}
-
-// CLI entry point
-if (process.argv[1] && resolve(process.argv[1]) === resolve(new URL(import.meta.url).pathname)) {
-  const result = cleanup();
-  if (result.deletedPaths.length === 0 && result.removedLockEntries.length === 0) {
-    console.log('No deprecated Impeccable skills found. Nothing to clean up.');
-  } else {
-    if (result.deletedPaths.length > 0) {
-      console.log(`Removed ${result.deletedPaths.length} deprecated skill(s):`);
-      for (const p of result.deletedPaths) console.log(`  - ${p}`);
-    }
-    if (result.removedLockEntries.length > 0) {
-      console.log(`Cleaned ${result.removedLockEntries.length} entry/entries from skills-lock.json:`);
-      for (const name of result.removedLockEntries) console.log(`  - ${name}`);
-    }
-  }
-}