@selesai/code 0.9.10 → 0.9.11

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.

package/dist/skills/planger/SKILL.md

@@ -1,166 +1,166 @@
----
-name: planger
-description: Create decomposed planning for sub agent
-argument-hint: "How i provide a good plan for subagent"
-disable-model-invocation: true
----
-
-# Planning Skill
-
-## Goal
-
-Create implementation plans that can be executed by a small coding model with:
-
-- Limited context window
-- No project knowledge
-- No memory of previous conversation
-- Weak architectural understanding
-- No ability to infer missing steps
-
-Assume the executor only knows what is written in the plan.
-
-# Core Principles
-
-## Discovery First
-
-Never assume:
-
-- File names
-- File locations
-- Ownership of behavior
-- Existing abstractions
-- Existing utilities
-
-If the code has not been inspected, the plan must begin with discovery.
-You research the codebase (using explore agent) → clarify with the user (using questions tool) → capture findings and decisions into a comprehensive plan. This iterative approach catches edge cases and non-obvious requirements BEFORE implementation begins.
-
-## Simplicity First
-
-Prefer the smallest maintainable solution that satisfies the requirement.
-
-Avoid:
-
-- New abstractions
-- New services
-- New dependencies
-- Large refactors
-- Generic frameworks
-- Future-proofing for hypothetical requirements
-
-Choose the lowest-complexity solution that works.
-
-## Reuse Before Build
-
-Before creating anything new (use explorer agent):
-
-- Search for existing implementations
-- Search for existing utilities
-- Search for existing patterns
-- Search for existing tests
-
-Reuse existing code when reasonable.
-
-Do not duplicate behavior unless duplication is clearly preferable.
-
-## Scope Discipline
-
-Only modify code required for the task.
-
-Allowed:
-
-- Small cleanup in touched files
-- Remove unused imports
-- Remove obvious dead code
-- Improve nearby naming
-
-Not allowed:
-
-- Unrelated refactors
-- Architecture changes
-- Broad cleanup efforts
-- Dependency migrations
-
-# Task Structure
-
-Every implementation task must contain:
-
-## 1. Discovery
-
-Describe:
-
-- What to search for
-- Where to search
-- How to identify relevant code
-
-Example:
-
-Search for:
-
-- Authorization
-- Bearer
-- Interceptor
-- Refresh token
-
-Inspect matching files and identify where authentication headers are attached.
-
-## 2. Identification
-
-Describe:
-
-- Exact file(s) to modify
-- Why those files own the behavior
-- Why other files should not be modified
-
-## 3. Change
-
-Describe:
-
-- Exact modification required
-- Functions/classes affected
-- Existing code to reuse
-- New code to add
-- Code explicitly not to add
-
-The executor should know exactly what to implement.
-
-## 4. Verification
-
-Include:
-
-### Success Cases
-
-Expected working behavior.
-
-### Failure Cases
-
-Expected error behavior.
-
-### Regression Checks
-
-Existing behavior that must remain unchanged.
-
-# Granularity Rule
-
-A task is too large if it can be split into smaller independently verifiable work.
-
-Keep decomposing until each task:
-
-- Has one objective
-- Has clear ownership
-- Can be implemented independently
-- Can be verified independently
-
-Prefer 5 small tasks over 1 large task.
-
-# Final Review
-
-Before returning a plan verify:
-
-- Discovery exists
-- Ownership is justified
-- Solution is the simplest acceptable approach
-- Existing code is reused when possible
-- No unnecessary abstractions are introduced
-- Scope remains limited
-- Verification is included
-- Every step is executable without additional assumptions
+---
+name: planger
+description: Create decomposed planning for sub agent
+argument-hint: "How i provide a good plan for subagent"
+disable-model-invocation: true
+---
+
+# Planning Skill
+
+## Goal
+
+Create implementation plans that can be executed by a small coding model with:
+
+- Limited context window
+- No project knowledge
+- No memory of previous conversation
+- Weak architectural understanding
+- No ability to infer missing steps
+
+Assume the executor only knows what is written in the plan.
+
+# Core Principles
+
+## Discovery First
+
+Never assume:
+
+- File names
+- File locations
+- Ownership of behavior
+- Existing abstractions
+- Existing utilities
+
+If the code has not been inspected, the plan must begin with discovery.
+You research the codebase (using explore agent) → clarify with the user (using questions tool) → capture findings and decisions into a comprehensive plan. This iterative approach catches edge cases and non-obvious requirements BEFORE implementation begins.
+
+## Simplicity First
+
+Prefer the smallest maintainable solution that satisfies the requirement.
+
+Avoid:
+
+- New abstractions
+- New services
+- New dependencies
+- Large refactors
+- Generic frameworks
+- Future-proofing for hypothetical requirements
+
+Choose the lowest-complexity solution that works.
+
+## Reuse Before Build
+
+Before creating anything new (use explorer agent):
+
+- Search for existing implementations
+- Search for existing utilities
+- Search for existing patterns
+- Search for existing tests
+
+Reuse existing code when reasonable.
+
+Do not duplicate behavior unless duplication is clearly preferable.
+
+## Scope Discipline
+
+Only modify code required for the task.
+
+Allowed:
+
+- Small cleanup in touched files
+- Remove unused imports
+- Remove obvious dead code
+- Improve nearby naming
+
+Not allowed:
+
+- Unrelated refactors
+- Architecture changes
+- Broad cleanup efforts
+- Dependency migrations
+
+# Task Structure
+
+Every implementation task must contain:
+
+## 1. Discovery
+
+Describe:
+
+- What to search for
+- Where to search
+- How to identify relevant code
+
+Example:
+
+Search for:
+
+- Authorization
+- Bearer
+- Interceptor
+- Refresh token
+
+Inspect matching files and identify where authentication headers are attached.
+
+## 2. Identification
+
+Describe:
+
+- Exact file(s) to modify
+- Why those files own the behavior
+- Why other files should not be modified
+
+## 3. Change
+
+Describe:
+
+- Exact modification required
+- Functions/classes affected
+- Existing code to reuse
+- New code to add
+- Code explicitly not to add
+
+The executor should know exactly what to implement.
+
+## 4. Verification
+
+Include:
+
+### Success Cases
+
+Expected working behavior.
+
+### Failure Cases
+
+Expected error behavior.
+
+### Regression Checks
+
+Existing behavior that must remain unchanged.
+
+# Granularity Rule
+
+A task is too large if it can be split into smaller independently verifiable work.
+
+Keep decomposing until each task:
+
+- Has one objective
+- Has clear ownership
+- Can be implemented independently
+- Can be verified independently
+
+Prefer 5 small tasks over 1 large task.
+
+# Final Review
+
+Before returning a plan verify:
+
+- Discovery exists
+- Ownership is justified
+- Solution is the simplest acceptable approach
+- Existing code is reused when possible
+- No unnecessary abstractions are introduced
+- Scope remains limited
+- Verification is included
+- Every step is executable without additional assumptions