@selesai/code 0.10.1 → 0.10.2

package/dist/skills/improve-codebase/REFERENCE.md

@@ -1,78 +1,78 @@
-# Reference
-
-## Dependency Categories
-
-When assessing a candidate for deepening, classify its dependencies:
-
-### 1. In-process
-
-Pure computation, in-memory state, no I/O. Always deepenable — just merge the modules and test directly.
-
-### 2. Local-substitutable
-
-Dependencies that have local test stand-ins (e.g., PGLite for Postgres, in-memory filesystem). Deepenable if the test substitute exists. The deepened module is tested with the local stand-in running in the test suite.
-
-### 3. Remote but owned (Ports & Adapters)
-
-Your own services across a network boundary (microservices, internal APIs). Define a port (interface) at the module boundary. The deep module owns the logic; the transport is injected. Tests use an in-memory adapter. Production uses the real HTTP/gRPC/queue adapter.
-
-Recommendation shape: "Define a shared interface (port), implement an HTTP adapter for production and an in-memory adapter for testing, so the logic can be tested as one deep module even though it's deployed across a network boundary."
-
-### 4. True external (Mock)
-
-Third-party services (Stripe, Twilio, etc.) you don't control. Mock at the boundary. The deepened module takes the external dependency as an injected port, and tests provide a mock implementation.
-
-## Testing Strategy
-
-The core principle: **replace, don't layer.**
-
-- Old unit tests on shallow modules are waste once boundary tests exist — delete them
-- Write new tests at the deepened module's interface boundary
-- Tests assert on observable outcomes through the public interface, not internal state
-- Tests should survive internal refactors — they describe behavior, not implementation
-
-## Issue Template
-
-<issue-template>
-
-## Problem
-
-Describe the architectural friction:
-
-- Which modules are shallow and tightly coupled
-- What integration risk exists in the seams between them
-- Why this makes the codebase harder to navigate and maintain
-
-## Proposed Interface
-
-The chosen interface design:
-
-- Interface signature (types, methods, params)
-- Usage example showing how callers use it
-- What complexity it hides internally
-
-## Dependency Strategy
-
-Which category applies and how dependencies are handled:
-
-- **In-process**: merged directly
-- **Local-substitutable**: tested with [specific stand-in]
-- **Ports & adapters**: port definition, production adapter, test adapter
-- **Mock**: mock boundary for external services
-
-## Testing Strategy
-
-- **New boundary tests to write**: describe the behaviors to verify at the interface
-- **Old tests to delete**: list the shallow module tests that become redundant
-- **Test environment needs**: any local stand-ins or adapters required
-
-## Implementation Recommendations
-
-Durable architectural guidance that is NOT coupled to current file paths:
-
-- What the module should own (responsibilities)
-- What it should hide (implementation details)
-- What it should expose (the interface contract)
-- How callers should migrate to the new interface
-
-</issue-template>
+# Reference
+
+## Dependency Categories
+
+When assessing a candidate for deepening, classify its dependencies:
+
+### 1. In-process
+
+Pure computation, in-memory state, no I/O. Always deepenable — just merge the modules and test directly.
+
+### 2. Local-substitutable
+
+Dependencies that have local test stand-ins (e.g., PGLite for Postgres, in-memory filesystem). Deepenable if the test substitute exists. The deepened module is tested with the local stand-in running in the test suite.
+
+### 3. Remote but owned (Ports & Adapters)
+
+Your own services across a network boundary (microservices, internal APIs). Define a port (interface) at the module boundary. The deep module owns the logic; the transport is injected. Tests use an in-memory adapter. Production uses the real HTTP/gRPC/queue adapter.
+
+Recommendation shape: "Define a shared interface (port), implement an HTTP adapter for production and an in-memory adapter for testing, so the logic can be tested as one deep module even though it's deployed across a network boundary."
+
+### 4. True external (Mock)
+
+Third-party services (Stripe, Twilio, etc.) you don't control. Mock at the boundary. The deepened module takes the external dependency as an injected port, and tests provide a mock implementation.
+
+## Testing Strategy
+
+The core principle: **replace, don't layer.**
+
+- Old unit tests on shallow modules are waste once boundary tests exist — delete them
+- Write new tests at the deepened module's interface boundary
+- Tests assert on observable outcomes through the public interface, not internal state
+- Tests should survive internal refactors — they describe behavior, not implementation
+
+## Issue Template
+
+<issue-template>
+
+## Problem
+
+Describe the architectural friction:
+
+- Which modules are shallow and tightly coupled
+- What integration risk exists in the seams between them
+- Why this makes the codebase harder to navigate and maintain
+
+## Proposed Interface
+
+The chosen interface design:
+
+- Interface signature (types, methods, params)
+- Usage example showing how callers use it
+- What complexity it hides internally
+
+## Dependency Strategy
+
+Which category applies and how dependencies are handled:
+
+- **In-process**: merged directly
+- **Local-substitutable**: tested with [specific stand-in]
+- **Ports & adapters**: port definition, production adapter, test adapter
+- **Mock**: mock boundary for external services
+
+## Testing Strategy
+
+- **New boundary tests to write**: describe the behaviors to verify at the interface
+- **Old tests to delete**: list the shallow module tests that become redundant
+- **Test environment needs**: any local stand-ins or adapters required
+
+## Implementation Recommendations
+
+Durable architectural guidance that is NOT coupled to current file paths:
+
+- What the module should own (responsibilities)
+- What it should hide (implementation details)
+- What it should expose (the interface contract)
+- How callers should migrate to the new interface
+
+</issue-template>

package/dist/skills/improve-codebase/SKILL.md

@@ -1,5 +1,6 @@
 ---
 name: improve-codebase
+category: planning
 description: improve codebase quality
 disable-model-invocation: true
 ---

package/dist/skills/industrial-brutalist-ui/SKILL.md

@@ -1,5 +1,6 @@
 ---
 name: industrial-brutalist-ui
+category: design
 description: Raw mechanical interfaces fusing Swiss typographic print with military terminal aesthetics. Rigid grids, extreme type scale contrast, utilitarian color, analog degradation effects. For data-heavy dashboards, portfolios, or editorial sites that need to feel like declassified blueprints.
 license: MIT
 ---

package/dist/skills/minimalist-ui/SKILL.md

@@ -1,5 +1,6 @@
 ---
 name: minimalist-ui
+category: design
 description: Clean editorial-style interfaces. Warm monochrome palette, typographic contrast, flat bento grids, muted pastels. No gradients, no heavy shadows.
 license: MIT
 ---

package/dist/skills/pi-subagents/SKILL.md

@@ -1,5 +1,6 @@
 ---
 name: pi-subagents
+category: orchestration
 description: |
   Delegate work to builtin or custom subagents with single-agent, parallel,
   scripted-chaining, async, forked-context, and coordinated workflows. Use

package/dist/skills/planger/SKILL.md

@@ -1,5 +1,6 @@
 ---
 name: planger
+category: planning
 description: Create decomposed planning for sub agent
 argument-hint: "How i provide a good plan for subagent"
 disable-model-invocation: true

package/dist/skills/ponytail/SKILL.md

@@ -1,5 +1,6 @@
 ---
 name: ponytail
+category: simplicity
 description: >
   Forces the laziest solution that actually works, simplest, shortest, most
   minimal. Channels a senior dev who has seen everything: question whether the

package/dist/skills/ponytail-audit/SKILL.md

@@ -1,5 +1,6 @@
 ---
 name: ponytail-audit
+category: simplicity
 description: >
   Whole-repo audit for over-engineering. Like ponytail-review, but scans the
   entire codebase instead of a diff: a ranked list of what to delete, simplify,

package/dist/skills/ponytail-debt/SKILL.md

@@ -1,5 +1,6 @@
 ---
 name: ponytail-debt
+category: simplicity
 description: >
   Harvest every `ponytail:` comment in the codebase into a debt ledger, so the
   deliberate shortcuts and deferrals ponytail leaves behind get tracked instead

package/dist/skills/ponytail-gain/SKILL.md

@@ -1,5 +1,6 @@
 ---
 name: ponytail-gain
+category: simplicity
 description: >
   Show ponytail's measured impact as a compact scoreboard: less code, less
   cost, more speed, from the benchmark medians. One-shot display, not a

package/dist/skills/ponytail-help/SKILL.md

@@ -1,5 +1,6 @@
 ---
 name: ponytail-help
+category: simplicity
 description: >
   Quick-reference card for all ponytail modes, skills, and commands.
   One-shot display, not a persistent mode. Trigger: /ponytail-help,

package/dist/skills/ponytail-review/SKILL.md

@@ -1,5 +1,6 @@
 ---
 name: ponytail-review
+category: simplicity
 description: >
   Code review focused exclusively on over-engineering. Finds what to delete:
   reinvented standard library, unneeded dependencies, speculative abstractions,

package/dist/skills/redesign-existing-projects/SKILL.md

@@ -1,5 +1,6 @@
 ---
 name: redesign-existing-projects
+category: design
 description: Upgrades existing websites and apps to premium quality. Audits current design, identifies generic AI patterns, and applies high-end design standards without breaking functionality. Works with any CSS framework or vanilla CSS.
 license: MIT
 ---

package/dist/skills/selesai-handoff/SKILL.md

@@ -1,5 +1,6 @@
 ---
 name: selesai-handoff
+category: handoff
 description: Hand the current conversation off to a fresh background agent that picks up the work immediately.
 argument-hint: "What will the next session be used for?"
 disable-model-invocation: true

package/dist/skills/stitch-design-taste/SKILL.md

@@ -1,5 +1,6 @@
 ---
 name: stitch-design-taste
+category: design
 description: Semantic Design System Skill for Google Stitch. Generates agent-friendly DESIGN.md files that enforce premium, anti-generic UI standards — strict typography, calibrated color, asymmetric layouts, perpetual micro-motion, and hardware-accelerated performance.
 license: MIT
 ---

package/dist/skills/unlazy/SKILL.md

@@ -1,5 +1,6 @@
 ---
 name: unlazy
+category: discipline
 description: Enforces completion discipline for substantial autonomous work by writing acceptance gates before execution, decomposing work with the Depth Tree, running approved checks, and re-verifying evidence before reporting. Use when Codex faces a long or multi-part task, work that has returned half-done, an exhaustive audit or build, parallel leaves or pipelines, or explicit triggers such as /unlazy, $unlazy, "tree N", "gates", and "do not stop until it is done".
 ---
 

package/dist/skills/web-design-guidelines/SKILL.md

@@ -1,5 +1,6 @@
 ---
 name: web-design-guidelines
+category: design
 description: Review UI code for Web Interface Guidelines compliance. Use when asked to "review my UI", "check accessibility", "audit design", "review UX", or "check my site against best practices".
 license: MIT
 metadata:

package/dist/skills/workflow/SKILL.md

@@ -1,5 +1,6 @@
 ---
 name: workflow
+category: orchestration
 description: Adaptively orchestrate non-trivial implementation work with Selesai subagents. Use when the user asks to use a workflow, orchestrate a task, run an implementation/review/fix loop, or coordinate architecture, workers, and reviewers. Choose only the necessary stages; do not use static slash-command flows.
 ---