@kinqs/brainrouter-mcp-server 0.3.4

package/skills/api/testing-skill/SKILL.md

@@ -0,0 +1,100 @@
+---
+name: testing-skill
+description: Mocking strategies, assertion standards, integration testing, and test coverage rules. Use when writing tests for new features, bug fixes, API endpoints, or core library integrations.
+hints: |
+  - Write tests alongside or immediately after implementing code to verify behavioral paths.
+  - Mock all external dependencies (e.g. databases, Redis caches, email services, third-party APIs).
+  - Verify security barriers, including authentication blocks, permission levels, and validation errors.
+  - Enforce strict response schema checks using object matching or JSON schema snapshots.
+  - Target 100% path coverage for error handling branches and catch blocks.
+---
+
+# Testing Skill
+
+## Overview
+
+This skill ensures that every codebase feature is robust, regression-free, secure, and easily verifiable. All new features and endpoints must incorporate corresponding unit or integration tests that validate both standard success operations and failure boundaries.
+
+## Workflow
+
+- **[TEST-001] Security Shield Verification**
+  - Integration tests must verify the entire request-handling ingress pipeline:
+    - Confirm `401 Unauthorized` responses when requests are unauthenticated.
+    - Confirm `403 Forbidden` responses when requests lack required roles.
+    - Confirm `429 Too Many Requests` when rate limits are exceeded (using mocks to accelerate testing).
+    - Confirm `400 Bad Request` when structural input validation (e.g., Zod, Joi) fails.
+
+- **[TEST-002] Mandatory Mocking**
+  - Never run unit or integration tests against a live production database or external system.
+  - Mock all database querying layers (such as `readQuery`, `writeQuery`, or ORM functions) using mock injection systems.
+  - Mock all external integrations, including Cloud storage, email transmitters, and Redis cache clusters.
+
+- **[TEST-003] Response Schema Consistency**
+  - Ensure API responses precisely match active specifications using `expect.objectContaining` or json-schema snapshot comparisons.
+
+- **[TEST-004] Error Case Coverage**
+  - Exercise failure branches. Tests must cover `catch` blocks, invalid formats, entity-not-found exceptions, and rate limit occurrences.
+
+## Implementation Pattern (Vitest + Supertest)
+
+```typescript
+import request from 'supertest';
+import { vi, describe, it, expect } from 'vitest';
+import app from '../../app';
+import { query } from '../../database/connection';
+
+vi.mock('../../database/connection');
+
+describe('POST /api/v1/resource', () => {
+  it('should reject unauthenticated requests [TEST-001]', async () => {
+    const response = await request(app).post('/api/v1/resource').send({});
+    expect(response.status).toBe(401);
+  });
+
+  it('should validate input using Zod [TEST-001]', async () => {
+    const response = await request(app)
+      .post('/api/v1/resource')
+      .set('Authorization', 'Bearer valid_token')
+      .send({ invalid: 'data' });
+    expect(response.status).toBe(400);
+    expect(response.body.error.code).toBe('VALIDATION_ERROR');
+  });
+});
+```
+
+---
+
+## When to Use
+
+- Implementing new backend routes, controllers, or service logic.
+- Resolving bugs, where a regression-preventing test should be added.
+- Modifying critical authentication, security, or routing middlewares.
+- Restructuring core data-fetching models or database connectors.
+
+**When NOT to use:**
+- Updating documentation files (`README.md`, `walkthrough.md`) or configuration comments.
+- Working on local scratch files, design assets, or styling-only UI adjustments.
+
+## Common Rationalizations
+
+| Rationalization | Reality |
+|---|---|
+| "The feature is too simple to test." | Simple features aggregate. Without automated test verification, basic structural regressions occur when global layouts or database models change. |
+| "Writing mocks is too slow and tedious." | Live database connections in tests cause flaky, slow, and environment-dependent builds. Mocks guarantee stable, ultra-fast test execution. |
+| "I'll add test coverage in a subsequent PR." | Post-hoc testing rarely happens due to shifting priorities. Features without automated proof of success are considered incomplete. |
+
+## Red Flags
+
+- Tests that require a live, external internet connection or local database instance to pass.
+- Bypassing input validation or authorization middleware checks in integration tests.
+- High test coverage metrics that only assert success paths while completely skipping failure scenarios.
+- Suppressing uncaught exceptions or console errors inside active test suites.
+
+## Verification
+
+After completing the test suite implementation, verify:
+- [ ] Automated test suite runs synchronously and passes without flakiness or timeout warnings.
+- [ ] Security boundaries (401 Unauthorized, 400 Bad Request) are explicitly tested.
+- [ ] Database interfaces and external API calls are verified as 100% mocked.
+- [ ] Response structures match specifications precisely.
+- [ ] Test coverage reports are generated and confirm error path traversal.

package/skills/codebase/code-review-and-quality/SKILL.md

@@ -0,0 +1,228 @@
+---
+name: code-review-and-quality
+description: Conducts multi-axis code review across correctness, readability, architecture, security, and performance. Use before merging any change. Use when reviewing code written by yourself, another agent, or a human. Use when running an agentic review-fix loop until tests pass and the PR is clean.
+hints: |
+  - Review tests first — they reveal intent before you read the implementation.
+  - Evaluate across all five axes: correctness, readability, architecture, security, performance.
+  - PRs over ~300 lines should be split before review — accuracy degrades on large diffs.
+  - In the review-fix loop: fix only issues that are real and relevant — never over-fix.
+  - Approve when the change improves overall code health, even if it isn't perfect.
+memory_hints: |
+  - Capture recurring review failures the user encounters (e.g. always missing error handling, recurring N+1 patterns).
+  - Note if user consistently skips specific review axes (e.g. tends to skip security review).
+  - Extract project-specific quality standards the user has set (e.g. "all PRs must be under 200 lines").
+  - Remember when user requests review on AI-generated code — note what types of issues are found.
+---
+
+# Code Review and Quality
+
+## Overview
+
+Multi-dimensional code review with quality gates. Every change gets reviewed before merge — no exceptions. Review covers five axes: correctness, readability, architecture, security, and performance.
+
+**The approval standard:** Approve a change when it definitely improves overall code health, even if it isn't perfect. Perfect code doesn't exist — the goal is continuous improvement. Don't block a change because it isn't exactly how you would have written it. If it improves the codebase and follows the project's conventions, approve it.
+
+## When to Use
+
+- Before merging any PR or change
+- After completing a feature implementation
+- When another agent or model produced code you need to evaluate
+- When refactoring existing code
+- After any bug fix (review both the fix and the regression test)
+
+## Workflow
+
+Read the diff and task context first, review tests before implementation details, evaluate the five quality axes, list concrete findings with severity and file references, then verify fixes with the relevant build and test commands.
+
+## The Five-Axis Review
+
+Every review evaluates code across these dimensions:
+
+### 1. Correctness
+
+Does the code do what it claims to do?
+
+- Does it match the spec or task requirements?
+- Are edge cases handled (null, empty, boundary values)?
+- Are error paths handled (not just the happy path)?
+- Does it pass all tests? Are the tests actually testing the right things?
+- Are there off-by-one errors, race conditions, or state inconsistencies?
+
+### 2. Readability & Simplicity
+
+Can another engineer (or agent) understand this code without the author explaining it?
+
+- Are names descriptive and consistent with project conventions? (No `temp`, `data`, `result` without context)
+- Is the control flow straightforward (avoid nested ternaries, deep callbacks)?
+- Is the code organized logically (related code grouped, clear module boundaries)?
+- Are there any "clever" tricks that should be simplified?
+- **Could this be done in fewer lines?** (1000 lines where 100 suffice is a failure)
+- **Are abstractions earning their complexity?** (Don't generalize until the third use case)
+- Would comments help clarify non-obvious intent? (But don't comment obvious code.)
+- Are there dead code artifacts: no-op variables (`_unused`), backwards-compat shims, or `// removed` comments?
+
+### 3. Architecture
+
+Does the change fit the system's design?
+
+- Does it follow existing patterns or introduce a new one? If new, is it justified?
+- Does it maintain clean module boundaries?
+- Is there code duplication that should be shared?
+- Are dependencies flowing in the right direction (no circular dependencies)?
+- Is the abstraction level appropriate (not over-engineered, not too coupled)?
+
+### 4. Security
+
+For detailed security guidance, see `security-and-hardening`. Does the change introduce vulnerabilities?
+
+- Is user input validated and sanitized?
+- Are secrets kept out of code, logs, and version control?
+- Is authentication/authorization checked where needed?
+- Are SQL queries parameterized (no string concatenation)?
+- Are outputs encoded to prevent XSS?
+- Are dependencies from trusted sources with no known vulnerabilities?
+- Is data from external sources (APIs, logs, user content, config files) treated as untrusted?
+- Are external data flows validated at system boundaries before use in logic or rendering?
+
+### 5. Performance
+
+For detailed profiling and optimization, see `performance-optimization`. Does the change introduce performance problems?
+
+- Any N+1 query patterns?
+- Any unbounded loops or unconstrained data fetching?
+- Any synchronous operations that should be async?
+- Any unnecessary re-renders in UI components?
+- Any missing pagination on list endpoints?
+- Any large objects created in hot paths?
+
+## Change Sizing
+
+Small, focused changes are easier to review, faster to merge, and safer to deploy. Target these sizes:
+
+```
+~100 lines changed   → Good. Reviewable in one sitting.
+~300 lines changed   → Acceptable if it's a single logical change.
+~1000 lines changed  → Too large. Split it.
+```
+
+**What counts as "one change":** A single self-contained modification that addresses one thing, includes related tests, and keeps the system functional after submission. One part of a feature — not the whole feature.
+
+## Change Descriptions
+
+Every change needs a description that stands alone in version control history.
+
+**First line:** Short, imperative, standalone. "Delete the FizzBuzz RPC" not "Deleting the FizzBuzz RPC."
+**Body:** What is changing and why. Include context, decisions, and reasoning not visible in the code itself.
+
+## Agentic Review-Fix Loop (Grep Loop)
+
+This is an auto-research-style loop for code review, specifically useful when a PR is small and you want an agent to repeatedly fix review feedback until tests pass and the PR is merge-ready.
+
+1. Create a small PR.
+2. Let a review tool, AI reviewer, or human inspect it.
+3. Feed the review back to the coding agent.
+4. Agent fixes the feedback.
+5. Review again.
+6. Repeat until the PR is clean and tests pass.
+
+### Review-Fix Prompt
+
+```md
+Run a review-fix loop for this PR.
+
+Inputs:
+- Current branch: <branch-name>
+- Review feedback: <paste feedback or point to reviewer output>
+- Required end state: tests pass, reviewer issues resolved, no unrelated rewrites.
+
+Rules:
+1. Read the PR diff first.
+2. Read the review feedback.
+3. Fix only issues that are real and relevant to this PR.
+4. Add or update tests for each bug fix when possible.
+5. Run the relevant tests/typechecks.
+6. Commit/push the fix if this workflow is allowed to push.
+7. Stop only when the PR is clean or when blocked by a decision that needs a human.
+```
+
+### Pre-Flight Check
+
+Before starting the loop, ask: "Is this PR too large for a reliable review loop? If yes, suggest how to split it." If the answer is yes, split the PR first.
+
+### Human Guardrails & Pitfalls
+
+- **Thousands of lines in one PR:** The reviewer and coding agent both lose accuracy. Split it.
+- **No tests:** The loop needs objective checks, not just vibes.
+- **Blindly accepting every comment:** Some comments are wrong or irrelevant.
+- **Over-fixing:** Agents can rewrite unrelated code. Fix only what was reviewed.
+- **False security:** A clean review is not proof the product is valuable; it only means this diff looks clean.
+
+## The Review Checklist
+
+```markdown
+## Review: [PR/Change title]
+
+### Context
+- [ ] I understand what this change does and why
+
+### Correctness
+- [ ] Change matches spec/task requirements
+- [ ] Edge cases handled
+- [ ] Error paths handled
+- [ ] Tests cover the change adequately
+
+### Readability
+- [ ] Names are clear and consistent
+- [ ] Logic is straightforward
+- [ ] No unnecessary complexity
+
+### Architecture
+- [ ] Follows existing patterns
+- [ ] No unnecessary coupling or dependencies
+- [ ] Appropriate abstraction level
+
+### Security
+- [ ] No secrets in code
+- [ ] Input validated at boundaries
+- [ ] No injection vulnerabilities
+- [ ] Auth checks in place
+- [ ] External data sources treated as untrusted
+
+### Performance
+- [ ] No N+1 patterns
+- [ ] No unbounded operations
+- [ ] Pagination on list endpoints
+
+### Verification
+- [ ] Tests pass
+- [ ] Build succeeds
+- [ ] Manual verification done (if applicable)
+
+### Verdict
+- [ ] **Approve** — Ready to merge
+- [ ] **Request changes** — Issues must be addressed
+```
+
+## Common Rationalizations
+
+| Rationalization | Reality |
+|---|---|
+| "It works, that's good enough" | Working code that's unreadable, insecure, or architecturally wrong creates debt that compounds. |
+| "I wrote it, so I know it's correct" | Authors are blind to their own assumptions. Every change benefits from another set of eyes. |
+| "We'll clean it up later" | Later never comes. The review is the quality gate — use it. |
+| "AI-generated code is probably fine" | AI code needs more scrutiny, not less. It's confident and plausible, even when wrong. |
+
+## Red Flags
+
+- PRs merged without any review.
+- "LGTM" without evidence of actual review.
+- Security-sensitive changes without security-focused review.
+- Large PRs that are "too big to review properly" (split them).
+- Review comments without severity labels.
+
+## Verification
+
+After completing the skill, confirm:
+- [ ] All Critical issues are identified and addressed.
+- [ ] The review follows the five-axis framework.
+- [ ] The output follows the standard checklist template.

package/skills/codebase/code-simplification/SKILL.md

@@ -0,0 +1,352 @@
+---
+name: code-simplification
+description: Simplifies code for clarity. Use when refactoring code for clarity without changing behavior. Use when code works but is harder to read, maintain, or extend than it should be. Use when reviewing code that has accumulated unnecessary complexity.
+hints:
+  - Separate refactoring/simplification from feature implementation; never mix the two in a single PR.
+  - Apply Chesterton's Fence: understand why the original code was written before simplifying it.
+  - Prioritize comprehension speed and readability over clever tricks or extreme line count reduction.
+  - Verify every simplification step immediately by running the unit test suite or the build system.
+  - Review openSrc/ or existing patterns for idiomatic simplification examples in the target language.
+---
+
+# Code Simplification
+
+> Inspired by the [Claude Code Simplifier plugin](https://github.com/anthropics/claude-plugins-official/blob/main/plugins/code-simplifier/agents/code-simplifier.md). Adapted here as a model-agnostic, process-driven skill for any AI coding agent.
+
+## Overview
+
+Simplify code by reducing complexity while preserving exact behavior. The goal is not fewer lines — it's code that is easier to read, understand, modify, and debug. Every simplification must pass a simple test: "Would a new team member understand this faster than the original?"
+
+## When to Use
+
+- After a feature is working and tests pass, but the implementation feels heavier than it needs to be
+- During code review when readability or complexity issues are flagged
+- When you encounter deeply nested logic, long functions, or unclear names
+- When refactoring code written under time pressure
+- When consolidating related logic scattered across files
+- After merging changes that introduced duplication or inconsistency
+
+**When NOT to use:**
+
+- Code is already clean and readable — don't simplify for the sake of it
+- You don't understand what the code does yet — comprehend before you simplify
+- The code is performance-critical and the "simpler" version would be measurably slower
+- You're about to rewrite the module entirely — simplifying throwaway code wastes effort
+
+## The Five Principles
+
+### 1. Preserve Behavior Exactly
+
+Don't change what the code does — only how it expresses it. All inputs, outputs, side effects, error behavior, and edge cases must remain identical. If you're not sure a simplification preserves behavior, don't make it.
+
+```
+ASK BEFORE EVERY CHANGE:
+→ Does this produce the same output for every input?
+→ Does this maintain the same error behavior?
+→ Does this preserve the same side effects and ordering?
+→ Do all existing tests still pass without modification?
+```
+
+### 2. Follow Project Conventions
+
+Simplification means making code more consistent with the codebase, not imposing external preferences. Before simplifying:
+
+```
+1. Read CLAUDE.md / project conventions
+2. Study how neighboring code handles similar patterns
+3. Match the project's style for:
+   - Import ordering and module system
+   - Function declaration style
+   - Naming conventions
+   - Error handling patterns
+   - Type annotation depth
+```
+
+Simplification that breaks project consistency is not simplification — it's churn.
+
+### 3. Prefer Clarity Over Cleverness
+
+Explicit code is better than compact code when the compact version requires a mental pause to parse.
+
+```typescript
+// UNCLEAR: Dense ternary chain
+const label = isNew ? 'New' : isUpdated ? 'Updated' : isArchived ? 'Archived' : 'Active';
+
+// CLEAR: Readable mapping
+function getStatusLabel(item: Item): string {
+  if (item.isNew) return 'New';
+  if (item.isUpdated) return 'Updated';
+  if (item.isArchived) return 'Archived';
+  return 'Active';
+}
+```
+
+```typescript
+// UNCLEAR: Chained reduces with inline logic
+const result = items.reduce((acc, item) => ({
+  ...acc,
+  [item.id]: { ...acc[item.id], count: (acc[item.id]?.count ?? 0) + 1 }
+}), {});
+
+// CLEAR: Named intermediate step
+const countById = new Map<string, number>();
+for (const item of items) {
+  countById.set(item.id, (countById.get(item.id) ?? 0) + 1);
+}
+```
+
+### 4. Maintain Balance
+
+Simplification has a failure mode: over-simplification. Watch for these traps:
+
+- **Inlining too aggressively** — removing a helper that gave a concept a name makes the call site harder to read
+- **Combining unrelated logic** — two simple functions merged into one complex function is not simpler
+- **Removing "unnecessary" abstraction** — some abstractions exist for extensibility or testability, not complexity
+- **Optimizing for line count** — fewer lines is not the goal; easier comprehension is
+
+### 5. Scope to What Changed
+
+Default to simplifying recently modified code. Avoid drive-by refactors of unrelated code unless explicitly asked to broaden scope. Unscoped simplification creates noise in diffs and risks unintended regressions.
+
+## The Simplification Process
+
+### Step 1: Understand Before Touching (Chesterton's Fence)
+
+Before changing or removing anything, understand why it exists. This is Chesterton's Fence: if you see a fence across a road and don't understand why it's there, don't tear it down. First understand the reason, then decide if the reason still applies.
+
+```
+BEFORE SIMPLIFYING, ANSWER:
+- What is this code's responsibility?
+- What calls it? What does it call?
+- What are the edge cases and error paths?
+- Are there tests that define the expected behavior?
+- Why might it have been written this way? (Performance? Platform constraint? Historical reason?)
+- Check git blame: what was the original context for this code?
+```
+
+If you can't answer these, you're not ready to simplify. Read more context first.
+
+### Step 2: Identify Simplification Opportunities
+
+Scan for these patterns — each one is a concrete signal, not a vague smell:
+
+**Structural complexity:**
+
+| Pattern | Signal | Simplification |
+|---------|--------|----------------|
+| Deep nesting (3+ levels) | Hard to follow control flow | Extract conditions into guard clauses or helper functions |
+| Long functions (50+ lines) | Multiple responsibilities | Split into focused functions with descriptive names |
+| Nested ternaries | Requires mental stack to parse | Replace with if/else chains, switch, or lookup objects |
+| Boolean parameter flags | `doThing(true, false, true)` | Replace with options objects or separate functions |
+| Repeated conditionals | Same `if` check in multiple places | Extract to a well-named predicate function |
+
+**Naming and readability:**
+
+| Pattern | Signal | Simplification |
+|---------|--------|----------------|
+| Generic names | `data`, `result`, `temp`, `val`, `item` | Rename to describe the content: `userProfile`, `validationErrors` |
+| Abbreviated names | `usr`, `cfg`, `btn`, `evt` | Use full words unless the abbreviation is universal (`id`, `url`, `api`) |
+| Misleading names | Function named `get` that also mutates state | Rename to reflect actual behavior |
+| Comments explaining "what" | `// increment counter` above `count++` | Delete the comment — the code is clear enough |
+| Comments explaining "why" | `// Retry because the API is flaky under load` | Keep these — they carry intent the code can't express |
+
+**Redundancy:**
+
+| Pattern | Signal | Simplification |
+|---------|--------|----------------|
+| Duplicated logic | Same 5+ lines in multiple places | Extract to a shared function |
+| Dead code | Unreachable branches, unused variables, commented-out blocks | Remove (after confirming it's truly dead) |
+| Unnecessary abstractions | Wrapper that adds no value | Inline the wrapper, call the underlying function directly |
+| Over-engineered patterns | Factory-for-a-factory, strategy-with-one-strategy | Replace with the simple direct approach |
+| Redundant type assertions | Casting to a type that's already inferred | Remove the assertion |
+
+### Step 3: Apply Changes Incrementally
+
+Make one simplification at a time. Run tests after each change. **Submit refactoring changes separately from feature or bug fix changes.** A PR that refactors and adds a feature is two PRs — split them.
+
+```
+FOR EACH SIMPLIFICATION:
+1. Make the change
+2. Run the test suite
+3. If tests pass → commit (or continue to next simplification)
+4. If tests fail → revert and reconsider
+```
+
+Avoid batching multiple simplifications into a single untested change. If something breaks, you need to know which simplification caused it.
+
+**The Rule of 500:** If a refactoring would touch more than 500 lines, invest in automation (codemods, sed scripts, AST transforms) rather than making the changes by hand. Manual edits at that scale are error-prone and exhausting to review.
+
+### Step 4: Verify the Result
+
+After all simplifications, step back and evaluate the whole:
+
+```
+COMPARE BEFORE AND AFTER:
+- Is the simplified version genuinely easier to understand?
+- Did you introduce any new patterns inconsistent with the codebase?
+- Is the diff clean and reviewable?
+- Would a teammate approve this change?
+```
+
+If the "simplified" version is harder to understand or review, revert. Not every simplification attempt succeeds.
+
+## Language-Specific Guidance
+
+### TypeScript / JavaScript
+
+```typescript
+// SIMPLIFY: Unnecessary async wrapper
+// Before
+async function getUser(id: string): Promise<User> {
+  return await userService.findById(id);
+}
+// After
+function getUser(id: string): Promise<User> {
+  return userService.findById(id);
+}
+
+// SIMPLIFY: Verbose conditional assignment
+// Before
+let displayName: string;
+if (user.nickname) {
+  displayName = user.nickname;
+} else {
+  displayName = user.fullName;
+}
+// After
+const displayName = user.nickname || user.fullName;
+
+// SIMPLIFY: Manual array building
+// Before
+const activeUsers: User[] = [];
+for (const user of users) {
+  if (user.isActive) {
+    activeUsers.push(user);
+  }
+}
+// After
+const activeUsers = users.filter((user) => user.isActive);
+
+// SIMPLIFY: Redundant boolean return
+// Before
+function isValid(input: string): boolean {
+  if (input.length > 0 && input.length < 100) {
+    return true;
+  }
+  return false;
+}
+// After
+function isValid(input: string): boolean {
+  return input.length > 0 && input.length < 100;
+}
+```
+
+### Python
+
+```python
+# SIMPLIFY: Verbose dictionary building
+# Before
+result = {}
+for item in items:
+    result[item.id] = item.name
+# After
+result = {item.id: item.name for item in items}
+
+# SIMPLIFY: Nested conditionals with early return
+# Before
+def process(data):
+    if data is not None:
+        if data.is_valid():
+            if data.has_permission():
+                return do_work(data)
+            else:
+                raise PermissionError("No permission")
+        else:
+            raise ValueError("Invalid data")
+    else:
+        raise TypeError("Data is None")
+# After
+def process(data):
+    if data is None:
+        raise TypeError("Data is None")
+    if not data.is_valid():
+        raise ValueError("Invalid data")
+    if not data.has_permission():
+        raise PermissionError("No permission")
+    return do_work(data)
+```
+
+### React / JSX
+
+```tsx
+// SIMPLIFY: Verbose conditional rendering
+// Before
+function UserBadge({ user }: Props) {
+  if (user.isAdmin) {
+    return <Badge variant="admin">Admin</Badge>;
+  } else {
+    return <Badge variant="default">User</Badge>;
+  }
+}
+// After
+function UserBadge({ user }: Props) {
+  const variant = user.isAdmin ? 'admin' : 'default';
+  const label = user.isAdmin ? 'Admin' : 'User';
+  return <Badge variant={variant}>{label}</Badge>;
+}
+
+// SIMPLIFY: Prop drilling through intermediate components
+// Before — consider whether context or composition solves this better.
+// This is a judgment call — flag it, don't auto-refactor.
+```
+
+## Common Rationalizations
+
+| Rationalization | Reality |
+|---|---|
+| "It's working, no need to touch it" | Working code that's hard to read will be hard to fix when it breaks. Simplifying now saves time on every future change. |
+| "Fewer lines is always simpler" | A 1-line nested ternary is not simpler than a 5-line if/else. Simplicity is about comprehension speed, not line count. |
+| "I'll just quickly simplify this unrelated code too" | Unscoped simplification creates noisy diffs and risks regressions in code you didn't intend to change. Stay focused. |
+| "The types make it self-documenting" | Types document structure, not intent. A well-named function explains *why* better than a type signature explains *what*. |
+| "This abstraction might be useful later" | Don't preserve speculative abstractions. If it's not used now, it's complexity without value. Remove it and re-add when needed. |
+| "The original author must have had a reason" | Maybe. Check git blame — apply Chesterton's Fence. But accumulated complexity often has no reason; it's just the residue of iteration under pressure. |
+| "I'll refactor while adding this feature" | Separate refactoring from feature work. Mixed changes are harder to review, revert, and understand in history. |
+
+## Red Flags
+
+- Simplification that requires modifying tests to pass (you likely changed behavior)
+- "Simplified" code that is longer and harder to follow than the original
+- Renaming things to match your preferences rather than project conventions
+- Removing error handling because "it makes the code cleaner"
+- Simplifying code you don't fully understand
+- Batching many simplifications into one large, hard-to-review commit
+- Refactoring code outside the scope of the current task without being asked
+
+## Required Checks
+
+After completing a simplification pass:
+
+- [ ] All existing tests pass without modification
+- [ ] Build succeeds with no new warnings
+- [ ] Linter/formatter passes (no style regressions)
+- [ ] Each simplification is a reviewable, incremental change
+- [ ] The diff is clean — no unrelated changes mixed in
+- [ ] Simplified code follows project conventions (checked against CLAUDE.md or equivalent)
+- [ ] No error handling was removed or weakened
+- [ ] No dead code was left behind (unused imports, unreachable branches)
+- [ ] A teammate or review agent would approve the change as a net improvement
+
+## Workflow
+
+1. **Locate Complex Code:** Identify code with high cyclomatic complexity, deep nesting, vague naming, or redundant logic.
+2. **Apply Chesterton's Fence:** Read git history or docstrings to understand why the current complexity exists before modifying it.
+3. **Refactor Incrementally:** Break down refactoring into micro-steps (e.g. invert if-statements to return early, extract sub-functions, rename variables).
+4. **Compile and Test:** Run compile and test suites after each micro-step to ensure behavior is fully preserved.
+5. **Review and Polish:** Compare readability before/after; ensure naming and formatting align with project style.
+
+## Verification
+
+After executing this skill, confirm:
+- [ ] All unit tests pass successfully without modifying test code.
+- [ ] Readability has measurably improved (verified by visual inspection).
+- [ ] No behavioral side-effects or functional regressions were introduced.