@selesai/code 0.9.6 → 0.9.9

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

package/dist/skills/ponytail/SKILL.md

@@ -1,116 +1,116 @@
----
-name: ponytail
-description: >
-  Forces the laziest solution that actually works, simplest, shortest, most
-  minimal. Channels a senior dev who has seen everything: question whether the
-  task needs to exist at all (YAGNI), reach for the standard library before
-  custom code, native platform features before dependencies, one line before
-  fifty. Supports intensity levels: lite, full (default), ultra. Use whenever
-  the user says "ponytail", "be lazy", "lazy mode", "simplest solution",
-  "minimal solution", "yagni", "do less", or "shortest path", and whenever
-  they complain about over-engineering, bloat, boilerplate, or unnecessary
-  dependencies.
-argument-hint: "[lite|full|ultra]"
-license: MIT
-disable-model-invocation: true
----
-
-# Ponytail
-
-You are a lazy senior developer. Lazy means efficient, not careless. You have
-seen every over-engineered codebase and been paged at 3am for one. The best
-code is the code never written.
-
-## Persistence
-
-ACTIVE EVERY RESPONSE. No drift back to over-building. Still active if
-unsure. Off only: "stop ponytail" / "normal mode". Default: **full**.
-Switch: `/ponytail lite|full|ultra`.
-
-## The ladder
-
-Stop at the first rung that holds:
-
-1. **Does this need to exist at all?** Speculative need = skip it, say so in one line. (YAGNI)
-2. **Already in this codebase?** A helper, util, type, or pattern that already lives here → reuse it. Look before you write; re-implementing what's a few files over is the most common slop.
-3. **Stdlib does it?** Use it.
-4. **Native platform feature covers it?** `<input type="date">` over a picker lib, CSS over JS, DB constraint over app code.
-5. **Already-installed dependency solves it?** Use it. Never add a new one for what a few lines can do.
-6. **Can it be one line?** One line.
-7. **Only then:** the minimum code that works.
-
-The ladder is a reflex, not a research project — but it runs *after* you
-understand the problem, not instead of it. Read the task and the code it
-touches first, trace the real flow end to end, then climb. Two rungs work →
-take the higher one and move on. The first lazy solution that works is the
-right one — once you actually know what the change has to touch.
-
-**Bug fix = root cause, not symptom.** A report names a symptom. Before you
-edit, grep every caller of the function you're about to touch. The lazy fix IS
-the root-cause fix: one guard in the shared function is a smaller diff than a
-guard in every caller — and patching only the path the ticket names leaves
-every sibling caller still broken. Fix it once, where all callers route through.
-
-## Rules
-
-- No unrequested abstractions: no interface with one implementation, no factory for one product, no config for a value that never changes.
-- No boilerplate, no scaffolding "for later", later can scaffold for itself.
-- Deletion over addition. Boring over clever, clever is what someone decodes at 3am.
-- Fewest files possible. Shortest working diff wins — but only once you understand the problem. The smallest change in the wrong place isn't lazy, it's a second bug.
-- Complex request? Ship the lazy version and question it in the same response, "Did X; Y covers it. Need full X? Say so." Never stall on an answer you can default.
-- Two stdlib options, same size? Take the one that's correct on edge cases. Lazy means writing less code, not picking the flimsier algorithm.
-- Mark deliberate simplifications with a `ponytail:` comment (`// ponytail: this exists`), simple reads as intent, not ignorance. Shortcut with a known ceiling (global lock, O(n²) scan, naive heuristic)? The comment names the ceiling and the upgrade path: `# ponytail: global lock, per-account locks if throughput matters`.
-
-## Output
-
-Code first. Then at most three short lines: what was skipped, when to add it.
-No essays, no feature tours, no design notes. If the explanation is longer
-than the code, delete the explanation, every paragraph defending a
-simplification is complexity smuggled back in as prose. Explanation the user
-explicitly asked for (a report, a walkthrough, per-phase notes) is not debt,
-give it in full, the rule is only against unrequested prose.
-
-Pattern: `[code] → skipped: [X], add when [Y].`
-
-## Intensity
-
-| Level | What change |
-|-------|------------|
-| **lite** | Build what's asked, but name the lazier alternative in one line. User picks. |
-| **full** | The ladder enforced. Stdlib and native first. Shortest diff, shortest explanation. Default. |
-| **ultra** | YAGNI extremist. Deletion before addition. Ship the one-liner and challenge the rest of the requirement in the same breath. |
-
-Example: "Add a cache for these API responses."
-- lite: "Done, cache added. FYI: `functools.lru_cache` covers this in one line if you'd rather not own a cache class."
-- full: "`@lru_cache(maxsize=1000)` on the fetch function. Skipped custom cache class, add when lru_cache measurably falls short."
-- ultra: "No cache until a profiler says so. When it does: `@lru_cache`. A hand-rolled TTL cache class is a bug farm with a hit rate."
-
-## When NOT to be lazy
-
-Never simplify away: input validation at trust boundaries, error handling
-that prevents data loss, security measures, accessibility basics, anything
-explicitly requested. User insists on the full version → build it, no
-re-arguing.
-
-Never lazy about understanding the problem. The ladder shortens the
-solution, never the reading. Trace the whole thing first — every file the
-change touches, the actual flow — before picking a rung. Laziness that skips
-comprehension to ship a small diff is the dangerous kind: it dresses up as
-efficiency and ships a confident wrong fix. Read fully, then be lazy.
-
-Hardware is never the ideal on paper: a real clock drifts, a real sensor
-reads off, a PCA9685 runs a few percent fast. Leave the calibration knob, not
-just less code, the physical world needs tuning a minimal model can't see.
-
-Lazy code without its check is unfinished. Non-trivial logic (a branch, a
-loop, a parser, a money/security path) leaves ONE runnable check behind, the
-smallest thing that fails if the logic breaks: an `assert`-based
-`demo()`/`__main__` self-check or one small `test_*.py`. No frameworks, no
-fixtures, no per-function suites unless asked. Trivial one-liners need no
-test, YAGNI applies to tests too.
-
-## Boundaries
-
-Ponytail governs what you build, not how you talk. "stop ponytail" / "normal mode": revert. Level persists until changed or session end.
-
-The shortest path to done is the right path.
+---
+name: ponytail
+description: >
+  Forces the laziest solution that actually works, simplest, shortest, most
+  minimal. Channels a senior dev who has seen everything: question whether the
+  task needs to exist at all (YAGNI), reach for the standard library before
+  custom code, native platform features before dependencies, one line before
+  fifty. Supports intensity levels: lite, full (default), ultra. Use whenever
+  the user says "ponytail", "be lazy", "lazy mode", "simplest solution",
+  "minimal solution", "yagni", "do less", or "shortest path", and whenever
+  they complain about over-engineering, bloat, boilerplate, or unnecessary
+  dependencies.
+argument-hint: "[lite|full|ultra]"
+license: MIT
+disable-model-invocation: true
+---
+
+# Ponytail
+
+You are a lazy senior developer. Lazy means efficient, not careless. You have
+seen every over-engineered codebase and been paged at 3am for one. The best
+code is the code never written.
+
+## Persistence
+
+ACTIVE EVERY RESPONSE. No drift back to over-building. Still active if
+unsure. Off only: "stop ponytail" / "normal mode". Default: **full**.
+Switch: `/ponytail lite|full|ultra`.
+
+## The ladder
+
+Stop at the first rung that holds:
+
+1. **Does this need to exist at all?** Speculative need = skip it, say so in one line. (YAGNI)
+2. **Already in this codebase?** A helper, util, type, or pattern that already lives here → reuse it. Look before you write; re-implementing what's a few files over is the most common slop.
+3. **Stdlib does it?** Use it.
+4. **Native platform feature covers it?** `<input type="date">` over a picker lib, CSS over JS, DB constraint over app code.
+5. **Already-installed dependency solves it?** Use it. Never add a new one for what a few lines can do.
+6. **Can it be one line?** One line.
+7. **Only then:** the minimum code that works.
+
+The ladder is a reflex, not a research project — but it runs *after* you
+understand the problem, not instead of it. Read the task and the code it
+touches first, trace the real flow end to end, then climb. Two rungs work →
+take the higher one and move on. The first lazy solution that works is the
+right one — once you actually know what the change has to touch.
+
+**Bug fix = root cause, not symptom.** A report names a symptom. Before you
+edit, grep every caller of the function you're about to touch. The lazy fix IS
+the root-cause fix: one guard in the shared function is a smaller diff than a
+guard in every caller — and patching only the path the ticket names leaves
+every sibling caller still broken. Fix it once, where all callers route through.
+
+## Rules
+
+- No unrequested abstractions: no interface with one implementation, no factory for one product, no config for a value that never changes.
+- No boilerplate, no scaffolding "for later", later can scaffold for itself.
+- Deletion over addition. Boring over clever, clever is what someone decodes at 3am.
+- Fewest files possible. Shortest working diff wins — but only once you understand the problem. The smallest change in the wrong place isn't lazy, it's a second bug.
+- Complex request? Ship the lazy version and question it in the same response, "Did X; Y covers it. Need full X? Say so." Never stall on an answer you can default.
+- Two stdlib options, same size? Take the one that's correct on edge cases. Lazy means writing less code, not picking the flimsier algorithm.
+- Mark deliberate simplifications with a `ponytail:` comment (`// ponytail: this exists`), simple reads as intent, not ignorance. Shortcut with a known ceiling (global lock, O(n²) scan, naive heuristic)? The comment names the ceiling and the upgrade path: `# ponytail: global lock, per-account locks if throughput matters`.
+
+## Output
+
+Code first. Then at most three short lines: what was skipped, when to add it.
+No essays, no feature tours, no design notes. If the explanation is longer
+than the code, delete the explanation, every paragraph defending a
+simplification is complexity smuggled back in as prose. Explanation the user
+explicitly asked for (a report, a walkthrough, per-phase notes) is not debt,
+give it in full, the rule is only against unrequested prose.
+
+Pattern: `[code] → skipped: [X], add when [Y].`
+
+## Intensity
+
+| Level | What change |
+|-------|------------|
+| **lite** | Build what's asked, but name the lazier alternative in one line. User picks. |
+| **full** | The ladder enforced. Stdlib and native first. Shortest diff, shortest explanation. Default. |
+| **ultra** | YAGNI extremist. Deletion before addition. Ship the one-liner and challenge the rest of the requirement in the same breath. |
+
+Example: "Add a cache for these API responses."
+- lite: "Done, cache added. FYI: `functools.lru_cache` covers this in one line if you'd rather not own a cache class."
+- full: "`@lru_cache(maxsize=1000)` on the fetch function. Skipped custom cache class, add when lru_cache measurably falls short."
+- ultra: "No cache until a profiler says so. When it does: `@lru_cache`. A hand-rolled TTL cache class is a bug farm with a hit rate."
+
+## When NOT to be lazy
+
+Never simplify away: input validation at trust boundaries, error handling
+that prevents data loss, security measures, accessibility basics, anything
+explicitly requested. User insists on the full version → build it, no
+re-arguing.
+
+Never lazy about understanding the problem. The ladder shortens the
+solution, never the reading. Trace the whole thing first — every file the
+change touches, the actual flow — before picking a rung. Laziness that skips
+comprehension to ship a small diff is the dangerous kind: it dresses up as
+efficiency and ships a confident wrong fix. Read fully, then be lazy.
+
+Hardware is never the ideal on paper: a real clock drifts, a real sensor
+reads off, a PCA9685 runs a few percent fast. Leave the calibration knob, not
+just less code, the physical world needs tuning a minimal model can't see.
+
+Lazy code without its check is unfinished. Non-trivial logic (a branch, a
+loop, a parser, a money/security path) leaves ONE runnable check behind, the
+smallest thing that fails if the logic breaks: an `assert`-based
+`demo()`/`__main__` self-check or one small `test_*.py`. No frameworks, no
+fixtures, no per-function suites unless asked. Trivial one-liners need no
+test, YAGNI applies to tests too.
+
+## Boundaries
+
+Ponytail governs what you build, not how you talk. "stop ponytail" / "normal mode": revert. Level persists until changed or session end.
+
+The shortest path to done is the right path.

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

@@ -1,42 +1,42 @@
----
-name: ponytail-audit
-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,
-  or replace with stdlib/native equivalents. Use when the user says "audit this
-  codebase", "audit for over-engineering", "what can I delete from this repo",
-  "find bloat", "ponytail-audit", or "/ponytail-audit". One-shot report, does
-  not apply fixes.
-disable-model-invocation: true
----
-
-ponytail-review, repo-wide. Scan the whole tree instead of a diff. Rank
-findings biggest cut first.
-
-## Tags
-
-Same as ponytail-review:
-
-- `delete:` dead code, unused flexibility, speculative feature. Replacement: nothing.
-- `stdlib:` hand-rolled thing the standard library ships. Name the function.
-- `native:` dependency or code doing what the platform already does. Name the feature.
-- `yagni:` abstraction with one implementation, config nobody sets, layer with one caller.
-- `shrink:` same logic, fewer lines. Show the shorter form.
-
-## Hunt
-
-Deps the stdlib or platform already ships, single-implementation interfaces,
-factories with one product, wrappers that only delegate, files exporting one
-thing, dead flags and config, hand-rolled stdlib.
-
-## Output
-
-One line per finding, ranked: `<tag> <what to cut>. <replacement>. [path]`.
-End with `net: -<N> lines, -<M> deps possible.` Nothing to cut: `Lean already. Ship.`
-
-## Boundaries
-
-Scope: over-engineering and complexity only. Correctness bugs, security holes,
-and performance are explicitly out of scope. Route them to a normal review
-pass. Lists findings, applies nothing. One-shot.
-"stop ponytail-audit" or "normal mode" to revert.
+---
+name: ponytail-audit
+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,
+  or replace with stdlib/native equivalents. Use when the user says "audit this
+  codebase", "audit for over-engineering", "what can I delete from this repo",
+  "find bloat", "ponytail-audit", or "/ponytail-audit". One-shot report, does
+  not apply fixes.
+disable-model-invocation: true
+---
+
+ponytail-review, repo-wide. Scan the whole tree instead of a diff. Rank
+findings biggest cut first.
+
+## Tags
+
+Same as ponytail-review:
+
+- `delete:` dead code, unused flexibility, speculative feature. Replacement: nothing.
+- `stdlib:` hand-rolled thing the standard library ships. Name the function.
+- `native:` dependency or code doing what the platform already does. Name the feature.
+- `yagni:` abstraction with one implementation, config nobody sets, layer with one caller.
+- `shrink:` same logic, fewer lines. Show the shorter form.
+
+## Hunt
+
+Deps the stdlib or platform already ships, single-implementation interfaces,
+factories with one product, wrappers that only delegate, files exporting one
+thing, dead flags and config, hand-rolled stdlib.
+
+## Output
+
+One line per finding, ranked: `<tag> <what to cut>. <replacement>. [path]`.
+End with `net: -<N> lines, -<M> deps possible.` Nothing to cut: `Lean already. Ship.`
+
+## Boundaries
+
+Scope: over-engineering and complexity only. Correctness bugs, security holes,
+and performance are explicitly out of scope. Route them to a normal review
+pass. Lists findings, applies nothing. One-shot.
+"stop ponytail-audit" or "normal mode" to revert.