self-evolve-framework 1.1.0 → 1.2.0

package/template/skills/setup-matt-pocock-skills/issue-tracker-gitlab.md

@@ -1,23 +0,0 @@
-# Issue tracker: GitLab
-
-Issues and PRDs for this repo live as GitLab issues. Use the [`glab`](https://gitlab.com/gitlab-org/cli) CLI for all operations.
-
-## Conventions
-
-- **Create an issue**: `glab issue create --title "..." --description "..."`. Use a heredoc for multi-line descriptions. Pass `--description -` to open an editor.
-- **Read an issue**: `glab issue view <number> --comments`. Use `-F json` for machine-readable output.
-- **List issues**: `glab issue list -F json` with appropriate `--label` filters.
-- **Comment on an issue**: `glab issue note <number> --message "..."`. GitLab calls comments "notes".
-- **Apply / remove labels**: `glab issue update <number> --label "..."` / `--unlabel "..."`. Multiple labels can be comma-separated or by repeating the flag.
-- **Close**: `glab issue close <number>`. `glab issue close` does not accept a closing comment, so post the explanation first with `glab issue note <number> --message "..."`, then close.
-- **Merge requests**: GitLab calls PRs "merge requests". Use `glab mr create`, `glab mr view`, `glab mr note`, etc. — the same shape as `gh pr ...` with `mr` in place of `pr` and `note`/`--message` in place of `comment`/`--body`.
-
-Infer the repo from `git remote -v` — `glab` does this automatically when run inside a clone.
-
-## When a skill says "publish to the issue tracker"
-
-Create a GitLab issue.
-
-## When a skill says "fetch the relevant ticket"
-
-Run `glab issue view <number> --comments`.

package/template/skills/setup-matt-pocock-skills/issue-tracker-local.md

@@ -1,19 +0,0 @@
-# Issue tracker: Local Markdown
-
-Issues and PRDs for this repo live as markdown files in `.scratch/`.
-
-## Conventions
-
-- One feature per directory: `.scratch/<feature-slug>/`
-- The PRD is `.scratch/<feature-slug>/PRD.md`
-- Implementation issues are `.scratch/<feature-slug>/issues/<NN>-<slug>.md`, numbered from `01`
-- Triage state is recorded as a `Status:` line near the top of each issue file (see `triage-labels.md` for the role strings)
-- Comments and conversation history append to the bottom of the file under a `## Comments` heading
-
-## When a skill says "publish to the issue tracker"
-
-Create a new file under `.scratch/<feature-slug>/` (creating the directory if needed).
-
-## When a skill says "fetch the relevant ticket"
-
-Read the file at the referenced path. The user will normally pass the path or the issue number directly.

package/template/skills/setup-matt-pocock-skills/triage-labels.md

@@ -1,15 +0,0 @@
-# Triage Labels
-
-The skills speak in terms of five canonical triage roles. This file maps those roles to the actual label strings used in this repo's issue tracker.
-
-| Label in mattpocock/skills | Label in our tracker | Meaning                                  |
-| -------------------------- | -------------------- | ---------------------------------------- |
-| `needs-triage`             | `needs-triage`       | Maintainer needs to evaluate this issue  |
-| `needs-info`               | `needs-info`         | Waiting on reporter for more information |
-| `ready-for-agent`          | `ready-for-agent`    | Fully specified, ready for an AFK agent  |
-| `ready-for-human`          | `ready-for-human`    | Requires human implementation            |
-| `wontfix`                  | `wontfix`            | Will not be actioned                     |
-
-When a skill mentions a role (e.g. "apply the AFK-ready triage label"), use the corresponding label string from this table.
-
-Edit the right-hand column to match whatever vocabulary you actually use.

package/template/skills/setup-pre-commit/SKILL.md

@@ -1,91 +0,0 @@
----
-name: setup-pre-commit
-description: Set up Husky pre-commit hooks with lint-staged (Prettier), type checking, and tests in the current repo. Use when user wants to add pre-commit hooks, set up Husky, configure lint-staged, or add commit-time formatting/typechecking/testing.
----
-
-# Setup Pre-Commit Hooks
-
-## What This Sets Up
-
-- **Husky** pre-commit hook
-- **lint-staged** running Prettier on all staged files
-- **Prettier** config (if missing)
-- **typecheck** and **test** scripts in the pre-commit hook
-
-## Steps
-
-### 1. Detect package manager
-
-Check for `package-lock.json` (npm), `pnpm-lock.yaml` (pnpm), `yarn.lock` (yarn), `bun.lockb` (bun). Use whichever is present. Default to npm if unclear.
-
-### 2. Install dependencies
-
-Install as devDependencies:
-
-```
-husky lint-staged prettier
-```
-
-### 3. Initialize Husky
-
-```bash
-npx husky init
-```
-
-This creates `.husky/` dir and adds `prepare: "husky"` to package.json.
-
-### 4. Create `.husky/pre-commit`
-
-Write this file (no shebang needed for Husky v9+):
-
-```
-npx lint-staged
-npm run typecheck
-npm run test
-```
-
-**Adapt**: Replace `npm` with detected package manager. If repo has no `typecheck` or `test` script in package.json, omit those lines and tell the user.
-
-### 5. Create `.lintstagedrc`
-
-```json
-{
-  "*": "prettier --ignore-unknown --write"
-}
-```
-
-### 6. Create `.prettierrc` (if missing)
-
-Only create if no Prettier config exists. Use these defaults:
-
-```json
-{
-  "useTabs": false,
-  "tabWidth": 2,
-  "printWidth": 80,
-  "singleQuote": false,
-  "trailingComma": "es5",
-  "semi": true,
-  "arrowParens": "always"
-}
-```
-
-### 7. Verify
-
-- [ ] `.husky/pre-commit` exists and is executable
-- [ ] `.lintstagedrc` exists
-- [ ] `prepare` script in package.json is `"husky"`
-- [ ] `prettier` config exists
-- [ ] Run `npx lint-staged` to verify it works
-
-### 8. Commit
-
-Stage all changed/created files and commit with message: `Add pre-commit hooks (husky + lint-staged + prettier)`
-
-This will run through the new pre-commit hooks — a good smoke test that everything works.
-
-## Notes
-
-- Husky v9+ doesn't need shebangs in hook files
-- `prettier --ignore-unknown` skips files Prettier can't parse (images, etc.)
-- The pre-commit runs lint-staged first (fast, staged-only), then full typecheck and tests

package/template/skills/svelte-warnings-fix/SKILL.md

@@ -1,94 +0,0 @@
----
-name: fix:svelte-warnings
-description: Read vite-plugin-svelte diagnostics from the IDE and automatically fix detected issues (a11y, unused CSS, deprecated syntax). Use when the user mentions vite-plugin-svelte warnings, Svelte a11y errors, unused CSS selectors, Svelte build warnings, or asks to fix Svelte component issues from vite build output.
----
-
-# Svelte Warnings Fix
-
-## Quick start
-
-```svelte
-<!-- ✅ 正确修复：加 ARIA 属性 -->
-<div role="dialog" aria-modal="true" tabindex="-1" onclick={handler}>
-
-<!-- ✅ 不可避免时用 svelte-ignore -->
-<!-- svelte-ignore a11y_no_static_element_interactions -->
-<div onclick={(e) => e.stopPropagation()}>
-```
-
-## Diagnostics collection (dual channel)
-
-1. **Fast path** — `read_lints(paths="d:/code/sheetflow/src")` 读 IDE 实时诊断（~0s）
-2. **Fallback** — 如果 read_lints 未捕获到，运行 `npm run build 2>&1` 取构建输出
-
-Diagnostics 按类型分类：
-- **A11y** — `a11y_no_static_element_interactions`, `a11y_interactive_supports_focus`, `a11y_click_events_have_key_events` 等
-- **Unused CSS** — `Unused CSS selector "..."`
-- **Deprecated syntax** — Svelte 5 迁移提示
-- **Type errors** — TS 编译失败
-
-## Fix order & verification
-
-批量处理同类问题，而非逐条 rebuild：
-
-```
-Collect all A11y warnings → fix all → rebuild once to verify
-Collect all unused CSS   → fix all → rebuild once to verify
-Collect all type errors  → fix all → rebuild once to verify
-```
-
-每类修复后只用一次 `npm run build` 验证，而非每条警告 rebuild 一次。
-
-## Fix rules by category
-
-### 1. A11y issues
-
-参照表决定修复方式：
-
-| 警告 | 正确修复 | svelte-ignore 条件 |
-|------|---------|-------------------|
-| `a11y_no_static_element_interactions` | 加 `role` 属性 | 当元素仅用于 stopPropagation 包装时 |
-| `a11y_interactive_supports_focus` | 加 `tabindex="-1"` 或 `tabindex="0"` | 元素不可聚焦（纯装饰） |
-| `a11y_click_events_have_key_events` | 加 `onkeydown` 处理器 | 当 click 仅用于非交互场景时 |
-| `a11y_no_noninteractive_element_interactions` | 替换为非交互元素或加 role | 很少需要 ignore |
-
-Svelte 5 的 `svelte-ignore` 注释格式：
-
-```svelte
-<!-- svelte-ignore a11y_no_static_element_interactions -->
-<div onclick={handler}>
-```
-
-> **原则**：优先正确修复（加 role/tabindex/aria-label），仅在确实不可避免时用 `svelte-ignore`。
-
-### 2. Unused CSS
-
-- 如果选择器在 template/JS 中确实未引用 → **删除该选择器或整个 `<style>` 块**
-- 如果只在运行时由 JS 动态添加 → 用 `:global(.selector) { }` 包裹
-
-### 3. Deprecated syntax
-
-严格遵循项目 Svelte 5 编码规范（工作区规则）：
-
-| 旧语法（Svelte 4） | 新语法（Svelte 5） |
-|---|---|
-| `export let name` | `let { name } = $props()` |
-| `$: double = count * 2` | `let double = $derived(count * 2)` |
-| `$: { effect }` | `$effect(() => { effect })` |
-| `on:click` handler | `onclick` prop |
-
-### 4. Type errors
-
-与 `rust-auto-fix` 技能协作：Svelte 模板中的 TS 类型错误由本技能修复，.ts 文件中的由 `rust-auto-fix` 处理。
-
-## Final report
-
-```
-## Svelte warnings resolved
-
-Total warnings fixed: X
-
-Changes made:
-- file.svelte: fixed a11y (added role="dialog" tabindex="-1")
-- file.svelte: removed unused CSS selector ".config-field label"
-```

package/template/skills/tauri-nsis-installer-icon/SKILL.md

@@ -1,92 +0,0 @@
----
-name: tauri-nsis-installer-icon
-description: Configure Tauri 2 NSIS installer icon. This skill should be used when modifying the Windows NSIS installer to use a custom icon instead of the Tauri default.
----
-
-# Tauri NSIS Installer Icon Configuration
-
-## Purpose
-
-Tauri 2 separates app icon from installer icon. The `bundle.icon` configures the executable icon; the NSIS installer uses its own icon defined in `bundle.windows.nsis.installerIcon`. Without this configuration, NSIS defaults to a generic icon.
-
-## Procedure
-
-### 1. Ask user about language
-
-Ask whether the installer should show Chinese UI. If yes, set `displayLanguageSelector` to false (auto-detect) or leave unset (default auto-detect based on system locale). NSIS ships built-in Chinese language files so no extra files are needed.
-
-### 2. Ask user about headerImage
-
-Ask whether to replace the default header image in the installer wizard.
-
-| Field | Format | Size | Location |
-|-------|--------|------|----------|
-| `headerImage` | BMP (Windows bitmap) | 150 x 57 px | Any path under `src-tauri/`, e.g. `icons/installer-header.bmp` |
-
-If the user provides a PNG, convert it to BMP before placing in the project. The image sits at the top of each installer page.
-
-### 3. Ask user about sidebarImage
-
-Ask whether to replace the default sidebar/banner image on the Welcome and Finish pages.
-
-| Field | Format | Size | Location |
-|-------|--------|------|----------|
-| `sidebarImage` | BMP (Windows bitmap) | 164 x 314 px | Any path under `src-tauri/`, e.g. `icons/installer-sidebar.bmp` |
-
-If the user provides a PNG, convert it to BMP before placing in the project.
-
-### 4. Ask user about install mode
-
-Ask `installMode`: "currentUser" (per-user, no admin required) is the default. Use "both" to allow the user to choose per-user or per-machine during installation.
-
-### 5. Ensure icon file exists
-
-Place a valid `.ico` file in `src-tauri/icons/`. The ICO should contain multiple sizes (e.g., 32x32, 256x256). Verify with:
-
-```bash
-node -e "const fs=require('fs');const b=fs.readFileSync('src-tauri/icons/icon.ico').subarray(0,6);console.log(b[0]===0&&b[1]===0&&b[2]===1&&b[3]===0?'Valid ICO':'Unknown')"
-```
-
-### 6. Add NSIS config to `src-tauri/tauri.conf.json`
-
-```json
-{
-  "bundle": {
-    "icon": ["icons/icon.ico", "icons/32x32.png", "icons/128x128.png", "icons/128x128@2x.png"],
-    "windows": {
-      "nsis": {
-        "installerIcon": "icons/icon.ico",
-        "headerImage": "icons/installer-header.bmp",
-        "sidebarImage": "icons/installer-sidebar.bmp",
-        "installMode": "currentUser"
-      }
-    }
-  }
-}
-```
-
-Remove `headerImage` / `sidebarImage` lines if the user chose not to customize them. Remove `installMode` if the default "currentUser" is acceptable.
-
-### 7. Rebuild
-
-```bash
-tauri build
-```
-
-The NSIS script is generated at `src-tauri/target/.../release/nsis/x64/installer.nsi`. Verify the generated script contains:
-- `!define INSTALLERICON "icons/icon.ico"` and `!define MUI_ICON "icons/icon.ico"`
-- `!define HEADERIMAGE "icons/installer-header.bmp"` (if configured)
-- `!define SIDEBARIMAGE "icons/installer-sidebar.bmp"` (if configured)
-- `!define INSTALLMODE "currentUser"`
-
-## Schema Reference
-
-See `references/tauri-nsis-schema.md` for the full `bundle.windows.nsis` schema.
-
-## Common Pitfalls
-
-- `bundle.icon` does NOT affect the NSIS installer — a separate `installerIcon` field is required.
-- The `.ico` file must be a valid ICO file (not a renamed PNG).
-- Paths are relative to `src-tauri/`, not the project root.
-- The NSIS script is auto-generated during `tauri build`; editing `installer.nsi` directly is overwritten on rebuild.
-- `headerImage` and `sidebarImage` must be BMP format; PNG will cause build failure. Convert via ImageMagick: `magick convert input.png bmp:output.bmp`.

package/template/skills/tauri-nsis-installer-icon/references/tauri-nsis-schema.md

@@ -1,71 +0,0 @@
-# Tauri 2 `bundle.windows.nsis` Schema
-
-Extracted from Tauri 2 official config schema. Paths are relative to `src-tauri/`.
-
-## Full Bundle Windows Config
-
-```json
-{
-  "bundle": {
-    "windows": {
-      "digestAlgorithm": "sha256",
-      "certificateThumbprint": null,
-      "timestampUrl": null,
-      "tsp": false,
-      "webviewInstallMode": {
-        "type": "downloadBootstrapper"
-      },
-      "nsis": {
-        "installerIcon": "icons/icon.ico",
-        "installMode": "currentUser",
-        "languages": null,
-        "template": null,
-        "displayLanguageSelector": false,
-        "startMenuFolder": null,
-        "headerImage": null,
-        "sidebarImage": null,
-        "customHeight": null,
-        "customWidth": null
-      }
-    }
-  }
-}
-```
-
-## NSIS Fields Detail
-
-| Field | Type | Default | Description |
-|-------|------|---------|-------------|
-| `installerIcon` | string (path) | — | ICO file for the NSIS installer |
-| `installMode` | `"currentUser"` or `"both"` | `"currentUser"` | Install scope: per-user (no admin) or user-selectable |
-| `displayLanguageSelector` | boolean | false | Show language selector in installer |
-| `languages` | string[] | null | Custom NSIS language files |
-| `template` | string (path) | null | Custom NSIS template file |
-| `startMenuFolder` | string | null | Start menu folder name |
-| `headerImage` | string (path) | null | BMP for installer header (150 x 57 px) |
-| `sidebarImage` | string (path) | null | BMP for installer sidebar (164 x 314 px) |
-| `customHeight` | number | null | Custom installer window height |
-| `customWidth` | number | null | Custom installer window width |
-
-## Image Format Requirements
-
-| Image | Format | Dimensions | Location in Installer |
-|-------|--------|-----------|----------------------|
-| `installerIcon` | ICO | Multi-resolution | Taskbar / title bar |
-| `headerImage` | BMP | 150 x 57 px | Top of each installer page |
-| `sidebarImage` | BMP | 164 x 314 px | Welcome / Finish page left panel |
-
-### BMP Conversion (if user provides PNG)
-
-```bash
-# ImageMagick
-magick convert input.png -resize 150x57 bmp:src-tauri/icons/installer-header.bmp
-magick convert input.png -resize 164x314 bmp:src-tauri/icons/installer-sidebar.bmp
-```
-
-## ICO Requirements
-
-- Must be a valid `.ico` file (not a renamed `.png`)
-- Recommended: include 32x32, 256x256 sizes
-- 85 KB+ typically indicates a well-formed multi-resolution ICO
-- Verify header: first 4 bytes `00 00 01 00` (reserved + type=ico + count=1)

package/template/skills/tb/SKILL.md

@@ -1,62 +0,0 @@
----
-name: sync-docs
-description: |
-  Synchronize project documentation files (README.md, AGENTS.md, CLAUDE.md, CONTEXT.md, RULES.md) 
-  to ensure consistency. This skill should be used when the user asks to "同步项目文档",
-  "update project constraints", "sync-docs", or when project structure or conventions change.
----
-
-# Sync Project Documentation (sync-docs)
-
-Keep README.md, AGENTS.md, CLAUDE.md, CONTEXT.md, and RULES.md consistent with each other and with the current codebase state.
-
-## Purpose
-
-These files serve different but overlapping roles:
-
-| File | Role | Audience |
-|------|------|----------|
-| README.md | Project overview & quick start | New developers |
-| AGENTS.md | AI agent project guidance & build commands | AI assistants & developers |
-| CLAUDE.md | AI agent constraints & rules | AI assistants |
-| CONTEXT.md | Architecture decisions & history | Developers & AI |
-| RULES.md | Detailed coding rules & conventions | All developers & AI |
-
-When the project evolves (new modules, refactoring, new conventions), all may need updating.
-
-## Process
-
-### Step 1: Read all five files
-
-Read README.md, AGENTS.md, CLAUDE.md, CONTEXT.md, and RULES.md.
-
-### Step 2: Read the codebase for changes
-
-Check for discrepancies:
-- New modules in `src-tauri/src/` not listed in README project structure
-- New pages in `src/pages/` not listed in README
-- Build commands or dependencies that changed in package.json/Cargo.toml
-- New architectural decisions since last CONTEXT.md update
-- New rules or conventions since last CLAUDE.md / RULES.md update
-
-### Step 3: Identify inconsistencies
-
-Compare across files:
-- Module lists should match across README and CLAUDE
-- AGENTS.md build commands and known issues should match README.md and CONTEXT.md
-- RULES.md should be the authoritative source for coding rules referenced by CLAUDE.md
-- Architecture decisions in CONTEXT should reflect current state
-- Version number should be consistent everywhere
-
-### Step 4: Update files
-
-Apply minimal targeted edits using `replace_in_file`. Priority order:
-1. README.md — project structure and commands
-2. AGENTS.md — project guidance, build commands, known issues
-3. CLAUDE.md — module structure and rules summary
-4. RULES.md — detailed coding rules and conventions
-5. CONTEXT.md — ADR records and known issues
-
-### Step 5: Commit
-
-`docs: sync README/AGENTS/CLAUDE/CONTEXT/RULES after project changes`

package/template/skills/tdd/SKILL.md

@@ -1,109 +0,0 @@
----
-name: tdd
-description: Test-driven development with red-green-refactor loop. Use when user wants to build features or fix bugs using TDD, mentions "red-green-refactor", wants integration tests, or asks for test-first development.
----
-
-# Test-Driven Development
-
-## Philosophy
-
-**Core principle**: Tests should verify behavior through public interfaces, not implementation details. Code can change entirely; tests shouldn't.
-
-**Good tests** are integration-style: they exercise real code paths through public APIs. They describe _what_ the system does, not _how_ it does it. A good test reads like a specification - "user can checkout with valid cart" tells you exactly what capability exists. These tests survive refactors because they don't care about internal structure.
-
-**Bad tests** are coupled to implementation. They mock internal collaborators, test private methods, or verify through external means (like querying a database directly instead of using the interface). The warning sign: your test breaks when you refactor, but behavior hasn't changed. If you rename an internal function and tests fail, those tests were testing implementation, not behavior.
-
-See [tests.md](tests.md) for examples and [mocking.md](mocking.md) for mocking guidelines.
-
-## Anti-Pattern: Horizontal Slices
-
-**DO NOT write all tests first, then all implementation.** This is "horizontal slicing" - treating RED as "write all tests" and GREEN as "write all code."
-
-This produces **crap tests**:
-
-- Tests written in bulk test _imagined_ behavior, not _actual_ behavior
-- You end up testing the _shape_ of things (data structures, function signatures) rather than user-facing behavior
-- Tests become insensitive to real changes - they pass when behavior breaks, fail when behavior is fine
-- You outrun your headlights, committing to test structure before understanding the implementation
-
-**Correct approach**: Vertical slices via tracer bullets. One test → one implementation → repeat. Each test responds to what you learned from the previous cycle. Because you just wrote the code, you know exactly what behavior matters and how to verify it.
-
-```
-WRONG (horizontal):
-  RED:   test1, test2, test3, test4, test5
-  GREEN: impl1, impl2, impl3, impl4, impl5
-
-RIGHT (vertical):
-  RED→GREEN: test1→impl1
-  RED→GREEN: test2→impl2
-  RED→GREEN: test3→impl3
-  ...
-```
-
-## Workflow
-
-### 1. Planning
-
-When exploring the codebase, use the project's domain glossary so that test names and interface vocabulary match the project's language, and respect ADRs in the area you're touching.
-
-Before writing any code:
-
-- [ ] Confirm with user what interface changes are needed
-- [ ] Confirm with user which behaviors to test (prioritize)
-- [ ] Identify opportunities for [deep modules](deep-modules.md) (small interface, deep implementation)
-- [ ] Design interfaces for [testability](interface-design.md)
-- [ ] List the behaviors to test (not implementation steps)
-- [ ] Get user approval on the plan
-
-Ask: "What should the public interface look like? Which behaviors are most important to test?"
-
-**You can't test everything.** Confirm with the user exactly which behaviors matter most. Focus testing effort on critical paths and complex logic, not every possible edge case.
-
-### 2. Tracer Bullet
-
-Write ONE test that confirms ONE thing about the system:
-
-```
-RED:   Write test for first behavior → test fails
-GREEN: Write minimal code to pass → test passes
-```
-
-This is your tracer bullet - proves the path works end-to-end.
-
-### 3. Incremental Loop
-
-For each remaining behavior:
-
-```
-RED:   Write next test → fails
-GREEN: Minimal code to pass → passes
-```
-
-Rules:
-
-- One test at a time
-- Only enough code to pass current test
-- Don't anticipate future tests
-- Keep tests focused on observable behavior
-
-### 4. Refactor
-
-After all tests pass, look for [refactor candidates](refactoring.md):
-
-- [ ] Extract duplication
-- [ ] Deepen modules (move complexity behind simple interfaces)
-- [ ] Apply SOLID principles where natural
-- [ ] Consider what new code reveals about existing code
-- [ ] Run tests after each refactor step
-
-**Never refactor while RED.** Get to GREEN first.
-
-## Checklist Per Cycle
-
-```
-[ ] Test describes behavior, not implementation
-[ ] Test uses public interface only
-[ ] Test would survive internal refactor
-[ ] Code is minimal for this test
-[ ] No speculative features added
-```

package/template/skills/tdd/deep-modules.md

@@ -1,33 +0,0 @@
-# Deep Modules
-
-From "A Philosophy of Software Design":
-
-**Deep module** = small interface + lots of implementation
-
-```
-┌─────────────────────┐
-│   Small Interface   │  ← Few methods, simple params
-├─────────────────────┤
-│                     │
-│                     │
-│  Deep Implementation│  ← Complex logic hidden
-│                     │
-│                     │
-└─────────────────────┘
-```
-
-**Shallow module** = large interface + little implementation (avoid)
-
-```
-┌─────────────────────────────────┐
-│       Large Interface           │  ← Many methods, complex params
-├─────────────────────────────────┤
-│  Thin Implementation            │  ← Just passes through
-└─────────────────────────────────┘
-```
-
-When designing interfaces, ask:
-
-- Can I reduce the number of methods?
-- Can I simplify the parameters?
-- Can I hide more complexity inside?

package/template/skills/tdd/interface-design.md

@@ -1,31 +0,0 @@
-# Interface Design for Testability
-
-Good interfaces make testing natural:
-
-1. **Accept dependencies, don't create them**
-
-   ```typescript
-   // Testable
-   function processOrder(order, paymentGateway) {}
-
-   // Hard to test
-   function processOrder(order) {
-     const gateway = new StripeGateway();
-   }
-   ```
-
-2. **Return results, don't produce side effects**
-
-   ```typescript
-   // Testable
-   function calculateDiscount(cart): Discount {}
-
-   // Hard to test
-   function applyDiscount(cart): void {
-     cart.total -= discount;
-   }
-   ```
-
-3. **Small surface area**
-   - Fewer methods = fewer tests needed
-   - Fewer params = simpler test setup