@selesai/code 0.9.6 → 0.9.9

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,179 +1,179 @@
----
-name: improve-codebase
-description: improve codebase quality
-disable-model-invocation: true
----
-
-# Improve Codebase Architecture
-
-Explore a codebase (or provided context) like an AI would. Surface architectural friction, identify deepening opportunities, and propose refactors as GitHub issue RFCs.
-
-The input is already provided inline. Do NOT describe or restate it — use it directly.
-
----
-
-## Core Principle
-
-A **deep module** (John Ousterhout, "A Philosophy of Software Design") has a small interface hiding a large implementation.
-
-Your goal:
-- Reduce cognitive load
-- Collapse shallow abstractions
-- Move complexity behind stable boundaries
-- Improve testability at module boundaries
-
----
-
-## Process
-
-### 1. Explore the context
-
-Call the subagent tool with `{ agent: "explorer", task: "..." }` (do not pass a model) when possible.
-
-If the context is partial:
-- Infer surrounding architecture cautiously
-- Focus on local friction signals
-- Avoid blocking on missing information
-
-Explore organically. Do NOT follow rigid heuristics.
-
-Look for friction:
-
-- Does understanding one concept require jumping across multiple files or layers?
-- Are modules shallow (interface ≈ implementation complexity)?
-- Are “pure functions” extracted for testability, but orchestration is fragile?
-- Are modules tightly coupled through shared types or call sequences?
-- Are there hidden integration risks between layers?
-- What is hard or impossible to test from the outside?
-
-The friction you encounter IS the signal.
-
-### 2. Identify candidate(s) and frame the problem
-
-Analyze the context and identify deepening opportunities.
-
-If the input clearly implies a specific target (file, module, diff, or instruction):
-- Select the most relevant candidate automatically
-- Do NOT present multiple options
-- Proceed directly to framing the problem space below
-
-If the input is ambiguous or spans multiple concerns:
-- Present a numbered list of candidates
-
-Each candidate must include:
-
-- **Cluster**  
-  Modules / files / concepts involved
-
-- **Why they're coupled**  
-  Shared types, execution flow, ownership of a concept
-
-- **Dependency category**  
-  Classify using `REFERENCE.md`:
-  - In-process
-  - Local-substitutable
-  - Ports & adapters
-  - True external
-
-- **Test impact**  
-  - Which tests become obsolete
-  - What boundary tests would replace them
-
-Then ask:
-"Which of these would you like to explore?"
-Wait for user input before continuing.
-
----
-
-### Problem framing (execute immediately if a candidate is selected or inferred)
-
-Explain the selected candidate clearly:
-
-- Constraints a new interface must satisfy
-- Dependencies it must handle
-- What complexity needs to be hidden
-
-Include a small illustrative code sketch to make constraints concrete.  
-This is NOT a proposal.
-
-After writing this, immediately proceed to Step 5: Design multiple interfaces.
-
-### 5. Design multiple interfaces
-
-Spawn 3+ sub-agents in parallel using the subagent tool (`tasks: [...]`).
-
-Each sub-agent gets:
-- A focused technical brief derived from the provided context
-- Clear coupling + dependency context
-- A distinct design constraint
-
-Required variants:
-
-- Agent 1: Minimize interface (1–3 entry points max)
-- Agent 2: Maximize flexibility / extensibility
-- Agent 3: Optimize for the most common caller
-- Agent 4 (if relevant): Ports & adapters oriented design
-- ...
-
----
-
-### Each sub-agent must output:
-
-1. Interface signature (types, methods, params)
-2. Usage example
-3. Hidden complexity (what gets absorbed internally)
-4. Dependency strategy (per `REFERENCE.md`)
-5. Trade-offs
-
----
-
-### Synthesis
-
-After all designs:
-
-- Compare approaches in prose
-- Highlight meaningful differences (not superficial ones)
-- Identify where each design wins/fails
-
-Then give a strong recommendation:
-- Pick the best design OR
-- Propose a hybrid
-
-Be opinionated.
-
----
-
-### 6. User picks an interface (or accepts recommendation)
-
----
-
-### 7. Create Branch
-
-Create a new branch for implementation.
-
-Branch name should reflect the domain concept being deepened.
-
-Examples:
-- deepen-payment-orchestration
-- deepen-map-rendering-pipeline
-
----
-
-## Behavior Rules
-
-- Do NOT restate or summarize the provided input
-- Do NOT overfit to file structure — think in conceptual modules
-- Do NOT suggest incremental refactors — prefer boundary redefinition
-- Do NOT preserve bad abstractions — collapse aggressively
-- Prefer fewer, deeper modules over many shallow ones
-- Tests must move to the boundary, not remain internal
-
----
-
-## Handling Incomplete Context
-
-- Make reasonable assumptions
-- State them explicitly
-- Continue without blocking
-
+---
+name: improve-codebase
+description: improve codebase quality
+disable-model-invocation: true
+---
+
+# Improve Codebase Architecture
+
+Explore a codebase (or provided context) like an AI would. Surface architectural friction, identify deepening opportunities, and propose refactors as GitHub issue RFCs.
+
+The input is already provided inline. Do NOT describe or restate it — use it directly.
+
+---
+
+## Core Principle
+
+A **deep module** (John Ousterhout, "A Philosophy of Software Design") has a small interface hiding a large implementation.
+
+Your goal:
+- Reduce cognitive load
+- Collapse shallow abstractions
+- Move complexity behind stable boundaries
+- Improve testability at module boundaries
+
+---
+
+## Process
+
+### 1. Explore the context
+
+Call the subagent tool with `{ agent: "explorer", task: "..." }` (do not pass a model) when possible.
+
+If the context is partial:
+- Infer surrounding architecture cautiously
+- Focus on local friction signals
+- Avoid blocking on missing information
+
+Explore organically. Do NOT follow rigid heuristics.
+
+Look for friction:
+
+- Does understanding one concept require jumping across multiple files or layers?
+- Are modules shallow (interface ≈ implementation complexity)?
+- Are “pure functions” extracted for testability, but orchestration is fragile?
+- Are modules tightly coupled through shared types or call sequences?
+- Are there hidden integration risks between layers?
+- What is hard or impossible to test from the outside?
+
+The friction you encounter IS the signal.
+
+### 2. Identify candidate(s) and frame the problem
+
+Analyze the context and identify deepening opportunities.
+
+If the input clearly implies a specific target (file, module, diff, or instruction):
+- Select the most relevant candidate automatically
+- Do NOT present multiple options
+- Proceed directly to framing the problem space below
+
+If the input is ambiguous or spans multiple concerns:
+- Present a numbered list of candidates
+
+Each candidate must include:
+
+- **Cluster**  
+  Modules / files / concepts involved
+
+- **Why they're coupled**  
+  Shared types, execution flow, ownership of a concept
+
+- **Dependency category**  
+  Classify using `REFERENCE.md`:
+  - In-process
+  - Local-substitutable
+  - Ports & adapters
+  - True external
+
+- **Test impact**  
+  - Which tests become obsolete
+  - What boundary tests would replace them
+
+Then ask:
+"Which of these would you like to explore?"
+Wait for user input before continuing.
+
+---
+
+### Problem framing (execute immediately if a candidate is selected or inferred)
+
+Explain the selected candidate clearly:
+
+- Constraints a new interface must satisfy
+- Dependencies it must handle
+- What complexity needs to be hidden
+
+Include a small illustrative code sketch to make constraints concrete.  
+This is NOT a proposal.
+
+After writing this, immediately proceed to Step 5: Design multiple interfaces.
+
+### 5. Design multiple interfaces
+
+Spawn 3+ sub-agents in parallel using the subagent tool (`tasks: [...]`).
+
+Each sub-agent gets:
+- A focused technical brief derived from the provided context
+- Clear coupling + dependency context
+- A distinct design constraint
+
+Required variants:
+
+- Agent 1: Minimize interface (1–3 entry points max)
+- Agent 2: Maximize flexibility / extensibility
+- Agent 3: Optimize for the most common caller
+- Agent 4 (if relevant): Ports & adapters oriented design
+- ...
+
+---
+
+### Each sub-agent must output:
+
+1. Interface signature (types, methods, params)
+2. Usage example
+3. Hidden complexity (what gets absorbed internally)
+4. Dependency strategy (per `REFERENCE.md`)
+5. Trade-offs
+
+---
+
+### Synthesis
+
+After all designs:
+
+- Compare approaches in prose
+- Highlight meaningful differences (not superficial ones)
+- Identify where each design wins/fails
+
+Then give a strong recommendation:
+- Pick the best design OR
+- Propose a hybrid
+
+Be opinionated.
+
+---
+
+### 6. User picks an interface (or accepts recommendation)
+
+---
+
+### 7. Create Branch
+
+Create a new branch for implementation.
+
+Branch name should reflect the domain concept being deepened.
+
+Examples:
+- deepen-payment-orchestration
+- deepen-map-rendering-pipeline
+
+---
+
+## Behavior Rules
+
+- Do NOT restate or summarize the provided input
+- Do NOT overfit to file structure — think in conceptual modules
+- Do NOT suggest incremental refactors — prefer boundary redefinition
+- Do NOT preserve bad abstractions — collapse aggressively
+- Prefer fewer, deeper modules over many shallow ones
+- Tests must move to the boundary, not remain internal
+
+---
+
+## Handling Incomplete Context
+
+- Make reasonable assumptions
+- State them explicitly
+- Continue without blocking
+
 Do NOT ask for more information unless absolutely necessary.