@su-record/vibe 2.16.4 → 3.1.0

package/skills/techdebt/templates/report.md

@@ -1,86 +0,0 @@
-# Technical Debt Report
-
-**Project**: {{PROJECT_NAME}}
-**Date**: {{DATE}}
-**Scanned Directory**: {{SCAN_DIR}}
-**Files Scanned**: {{FILE_COUNT}}
-
----
-
-## Summary
-
-| Priority | Count | Status |
-|----------|-------|--------|
-| P1 — Blocks Merge | {{P1_COUNT}} | {{P1_STATUS}} |
-| P2 — Fix Before PR | {{P2_COUNT}} | {{P2_STATUS}} |
-| P3 — Backlog | {{P3_COUNT}} | {{P3_STATUS}} |
-| **Total** | **{{TOTAL_COUNT}}** | |
-
----
-
-## P1 — Blocks Merge ({{P1_COUNT}} items)
-
-{{P1_ITEMS}}
-
-<!-- Example entry:
-- `src/services/auth.ts:42` — `any` type usage: parameter `payload` typed as `any`
--->
-
----
-
-## P2 — Fix Before PR ({{P2_COUNT}} items)
-
-### Console Statements ({{CONSOLE_COUNT}})
-
-{{CONSOLE_ITEMS}}
-
-### Unused Imports ({{UNUSED_IMPORT_COUNT}})
-
-{{UNUSED_IMPORT_ITEMS}}
-
-### Long Functions ({{LONG_FUNCTION_COUNT}})
-
-{{LONG_FUNCTION_ITEMS}}
-
-### Deep Nesting ({{DEEP_NESTING_COUNT}})
-
-{{DEEP_NESTING_ITEMS}}
-
----
-
-## P3 — Backlog ({{P3_COUNT}} items)
-
-### Magic Numbers ({{MAGIC_NUMBER_COUNT}})
-
-{{MAGIC_NUMBER_ITEMS}}
-
-### Commented-Out Code ({{COMMENTED_CODE_COUNT}})
-
-{{COMMENTED_CODE_ITEMS}}
-
----
-
-## Auto-fixable Items
-
-The following can be removed safely without review:
-
-{{AUTOFIXABLE_LIST}}
-
-> Run with user confirmation before applying auto-fixes.
-
----
-
-## Requires Manual Review
-
-The following require human judgment:
-
-{{MANUAL_REVIEW_LIST}}
-
----
-
-## Next Steps
-
-1. Fix all P1 items immediately
-2. Address P2 items before opening PR
-3. Create tracked tickets for P3 items
-4. Re-run scan after fixes: `node skills/techdebt/scripts/scan.js {{SCAN_DIR}}`

package/skills/typescript-advanced-types/SKILL.md

@@ -1,68 +0,0 @@
----
-name: typescript-advanced-types
-invocation: [auto]
-tier: core
-description: "TypeScript advanced type system master guide. Covers Generics, Conditional Types, Mapped Types, Template Literals, Utility Types. Activates for complex type logic, reusable type utilities, and compile-time type safety."
-sections:
-  - name: "Core Concepts"
-    triggers: [generic, generics, constraint, conditional, infer, mapped, utility, Pick, Omit, Partial, Required, Record, Exclude, Extract, readonly]
-  - name: "Advanced Patterns"
-    triggers: [template literal, branded, opaque, phantom, discriminated union, exhaustive, builder pattern, recursive type, variadic tuple]
-  - name: "Type Inference"
-    triggers: [inference, infer, type narrowing, type guard, satisfies, const assertion]
-  - name: "Best Practices"
-    triggers: [best practice, type safety, convention]
-  - name: "Type Testing"
-    triggers: [type test, type assertion, expectType, tsd]
-  - name: "Common Mistakes"
-    triggers: [mistake, pitfall, error, wrong]
-  - name: "Performance"
-    triggers: [performance, compile time, type complexity, depth limit]
----
-
-# TypeScript Advanced Types
-
-## Pre-check (K1)
-
-> Is this a VIBE-specific type safety issue? Standard TypeScript generics/conditionals/mapped types are well-known — read the code instead. This skill exists for VIBE's strict rules and non-obvious gotchas only.
-
-## VIBE Forbidden Patterns
-
-| Forbidden | Why | Use Instead |
-|-----------|-----|-------------|
-| `any` | Disables all type checking | `unknown` + type guard |
-| `as any` | Bypasses type system | Define proper interface |
-| `@ts-ignore` | Hides real errors | Fix the type issue at root |
-| Raw generic `T` without constraint | Too permissive | `T extends SomeInterface` |
-
-## `unknown` + Type Guard (VIBE's `any` Replacement)
-
-```typescript
-// Instead of: function process(data: any)
-function process(data: unknown): string {
-  if (typeof data === 'string') return data.toUpperCase();
-  if (isUser(data)) return data.name;
-  throw new Error('Unexpected data type');
-}
-
-function isUser(value: unknown): value is User {
-  return typeof value === 'object' && value !== null && 'name' in value;
-}
-```
-
-## Gotchas
-
-| Gotcha | Why Non-obvious | Fix |
-|--------|----------------|-----|
-| Distributive conditionals | `ToArray<string \| number>` → `string[] \| number[]`, not `(string \| number)[]` | Wrap in tuple: `[T] extends [U]` |
-| Recursive type depth | TS has ~50 level depth limit | Use tail-recursive patterns or simplify |
-| `satisfies` vs `as const` | `satisfies` validates + keeps literal types; `as` skips validation | Prefer `satisfies` |
-| Type assertions (`as X`) | Skips checking entirely | Use type guards instead |
-| `interface` vs `type` | `interface` gives better error messages for objects | Use `type` for unions/complex, `interface` for shapes |
-
-## Done Criteria (K4)
-
-- [ ] No `any`, `as any`, or `@ts-ignore` in code
-- [ ] All `unknown` usages have corresponding type guards
-- [ ] Complex types have `AssertEqual` type tests
-- [ ] Recursive types are bounded (no infinite depth)

package/skills/typescript-advanced-types/rubrics/type-patterns.md

@@ -1,109 +0,0 @@
-# Advanced TypeScript Type Patterns
-
-## Discriminated Unions
-
-Use a literal `kind`/`type` field to let TypeScript narrow exhaustively.
-
-```typescript
-type Result<T> =
-  | { kind: 'ok'; value: T }
-  | { kind: 'err'; error: string };
-
-function handle<T>(r: Result<T>): T {
-  if (r.kind === 'ok') return r.value;   // narrowed: r.value exists
-  throw new Error(r.error);              // narrowed: r.error exists
-}
-```
-
-**Exhaustive check pattern** — compile-time guard against missing branches:
-
-```typescript
-function assertNever(x: never): never {
-  throw new Error(`Unhandled case: ${JSON.stringify(x)}`);
-}
-// In switch default: case: return assertNever(action);
-```
-
-## Template Literal Types
-
-Compose string types at the type level.
-
-```typescript
-type EventName = 'click' | 'focus' | 'blur';
-type Handler = `on${Capitalize<EventName>}`;
-// → 'onClick' | 'onFocus' | 'onBlur'
-
-type RouteParam<T extends string> =
-  T extends `${infer _Start}:${infer Param}/${infer Rest}`
-    ? Param | RouteParam<Rest>
-    : T extends `${infer _Start}:${infer Param}`
-    ? Param
-    : never;
-// RouteParam<'/user/:id/post/:postId'> → 'id' | 'postId'
-```
-
-**Gotcha**: Template literals distribute over unions — one type per combination.
-
-## Conditional Types
-
-Branch the type system on type relationships.
-
-```typescript
-type NonNullable<T> = T extends null | undefined ? never : T;
-type Awaited<T> = T extends Promise<infer U> ? Awaited<U> : T;
-```
-
-**Distributive gotcha** — to prevent distribution, wrap in a tuple:
-
-```typescript
-type IsArray<T> = T extends unknown[] ? true : false;
-// IsArray<string | number[]> → boolean (distributed!)
-
-type IsArrayExact<T> = [T] extends [unknown[]] ? true : false;
-// IsArrayExact<string | number[]> → false (no distribution)
-```
-
-## Mapped Types
-
-Transform every property in a type.
-
-```typescript
-type Readonly<T> = { readonly [K in keyof T]: T[K] };
-type Optional<T> = { [K in keyof T]?: T[K] };
-
-// Key remapping with 'as'
-type Getters<T> = {
-  [K in keyof T as `get${Capitalize<string & K>}`]: () => T[K];
-};
-// Getters<{ name: string }> → { getName: () => string }
-```
-
-## Branded / Opaque Types
-
-Prevent mixing semantically different strings/numbers.
-
-```typescript
-type UserId = string & { readonly _brand: 'UserId' };
-type PostId = string & { readonly _brand: 'PostId' };
-
-function toUserId(id: string): UserId {
-  return id as UserId;  // only one cast, at the boundary
-}
-// toUserId('abc') satisfies UserId ✅
-// 'raw-string' satisfies UserId    ✗ (compile error)
-```
-
-## `satisfies` vs `as const`
-
-```typescript
-const config = {
-  port: 3000,
-  host: 'localhost',
-} satisfies Record<string, string | number>;
-// satisfies: validates shape AND keeps literal types (port: 3000, not number)
-
-const colors = ['red', 'green', 'blue'] as const;
-// as const: freezes to readonly tuple of literals
-```
-
-Use `satisfies` when you need both **validation** and **literal type preservation**.

package/skills/yagni-ladder/SKILL.md

@@ -1,90 +0,0 @@
----
-name: yagni-ladder
-user-invocable: false
-invocation: [auto]
-tier: core
-description: "YAGNI Ladder — block writing code before checking 5 cheaper rungs. Sibling of rob-pike: rob-pike blocks premature optimization, this blocks premature code. Auto-activates when about to write non-trivial implementation code."
-triggers: [add feature, implement, create a class, write a, build a, helper, utility, wrapper, abstraction, manager, handler, service for]
-priority: 90
----
-
-# The YAGNI Ladder
-
-`rob-pike` blocks premature *optimization*. This blocks premature *code*.
-
-The agent's default failure mode is writing too much: a 50-line class for a
-one-line job, a wrapper around something the stdlib already does, a config
-system for a value that never changes. Catch it **before** generation, not in
-review — once the code exists, deleting it costs more tokens than never writing
-it.
-
-## The Ladder
-
-Before writing implementation code, climb these rungs **in order** and stop at
-the **first** one that satisfies the need:
-
-1. **Is it needed at all?** — Does the requirement actually ask for this, or am
-   I inventing it? If speculative ("might need it later"), stop. Don't build it.
-2. **Is it in the stdlib?** — Language standard library / built-ins. (`crypto`,
-   `Intl`, `Array.prototype`, `pathlib`, …)
-3. **Is it a native platform feature?** — The runtime/platform already does it.
-   (`<input type="date">`, CSS `:has()`, HTTP caching headers, DB constraints.)
-4. **Does an already-installed dependency do it?** — Check `package.json` /
-   lockfile first. Don't add a dependency for what an existing one covers.
-5. **Can it be one line?** — A single expression / call, no new file, no class.
-6. **Only now: write the minimal code** — and no more than rungs 1–5 left undone.
-
-**Tie-break rule:** if two rungs both apply, take the **higher** rung (lower
-number). Native feature beats a one-liner; stdlib beats a dependency.
-
-## Anti-Patterns to Block
-
-| Impulse | Rung that catches it | Response |
-|---|---|---|
-| "I'll write a date-picker component" | 3 (native) | `<input type="date">`. One line. |
-| "Add a `StringUtils.isEmpty()` helper" | 2 (stdlib) | `!s` / `not s`. The language already does this. |
-| "Let me build a retry wrapper class" | 4 (installed dep) | Does an HTTP/util lib in the lockfile already retry? |
-| "I'll add a config system for this value" | 1 (needed?) | It's one constant that never changes. A `const` is the config. |
-| "A `CacheManager` class with TTL + eviction" | 1 / 5 | Is concurrency real yet? A `Map` + one `setTimeout` may be the whole job. |
-| "Generic `DataProcessor(strategy, validator…)`" | 1 (needed?) | One concrete function. Generalize when a *second* caller exists. |
-| "190-line animated dashboard" | 1 (needed?) | Did the task ask for animation, or just the number? Ship the 13 lines. |
-
-## When Writing The Code IS Justified
-
-Proceed to rung 6 only when ALL are true:
-
-- Rungs 1–5 genuinely don't cover it (you checked the lockfile, not guessed).
-- The requirement explicitly asks for it — not "might need."
-- You write the **minimum** that satisfies the requirement, nothing for "later."
-
-## Two Hard Rules That Override Simplicity
-
-Simplification pressure must never erode these:
-
-1. **Never skip security or trust-boundary work.** Input validation, auth
-   checks, escaping, permission boundaries — these are *requirements*, not
-   optional complexity. "One line" is no excuse to drop a validation.
-2. **Leave a comment + upgrade path on deliberate simplifications.** When you
-   pick the simple option knowing a bigger one might be needed later, say so in
-   the code so the next reader sees it was a *choice*, not an oversight:
-
-   ```ts
-   // Global lock is enough at current throughput.
-   // Switch to per-account locking if write contention shows up.
-   const lock = new Mutex();
-   ```
-
-## Relationship to Other Skills
-
-- **`rob-pike`** — same shape, optimization axis. Climb both ladders: don't
-  optimize without measuring, don't write code without climbing the rungs.
-- **`simplicity-reviewer`** (review agent) — the *sufficiency net* after the
-  fact. This skill is the *generation gate* before the fact. If this skill did
-  its job, simplicity-reviewer finds nothing to delete.
-
-## Questions to Ask Before Writing
-
-1. "Does the stdlib or platform already do this?"
-2. "Is there a dependency already installed that covers it?"
-3. "Can this be one line instead of one file?"
-4. "Am I building for a requirement that exists, or one I imagined?"