@selesai/code 0.13.15 → 0.13.18

package/dist/skills/implanger/SKILL.md

@@ -1,70 +0,0 @@
----
-name: implanger
-category: planning
-description: Execute the Planger's style planning
-argument-hint: "For Subagent to be able to understand Planger and can execute it perfectly"
-disable-model-invocation: true
----
-
-## Goal
-
-Implement the requested change with the smallest correct modification.
-
-## Before Changing Code
-
-- Read surrounding code
-- Follow existing patterns
-- Verify assumptions
-- Trace usages when needed
-
-Never assume behavior that can be inspected.
-
-## Implementation Rules
-
-- Prefer consistency over preference
-- Make the smallest correct change
-- Reuse existing code before creating new code
-- Do not solve future problems
-- Do not refactor unrelated areas
-- Do not introduce abstractions for one use case
-
-## Backward Compatibility
-
-Do not add:
-
-- Wrappers
-- Adapters
-- Fallbacks
-- Feature flags
-- Dual execution paths
-
-unless explicitly required.
-
-When replacing behavior:
-
-1. Find usages
-2. Update usages
-3. Remove obsolete code
-
-Prefer one source of truth.
-
-## Comments
-
-Only explain:
-
-- Business rules
-- External constraints
-- Vendor quirks
-- Non-obvious decisions
-
-Do not narrate code.
-
-## Validation
-
-Before completion verify:
-
-- Requirement satisfied
-- Scope remained limited
-- Existing patterns followed
-- No unnecessary complexity added
-- No dead code remains

package/dist/skills/output/SKILL.md

@@ -1,49 +0,0 @@
----
-name: output
-description: Overrides default LLM truncation behavior. Enforces complete code generation, bans placeholder patterns, and handles token-limit splits cleanly. Apply to any task requiring exhaustive, unabridged output.
----
-
-# Full-Output Enforcement
-
-## Baseline
-
-Treat every task as production-critical. A partial output is a broken output. Do not optimize for brevity — optimize for completeness. If the user asks for a full file, deliver the full file. If the user asks for 5 components, deliver 5 components. No exceptions.
-
-## Banned Output Patterns
-
-The following patterns are hard failures. Never produce them:
-
-**In code blocks:** `// ...`, `// rest of code`, `// implement here`, `// TODO`, `/* ... */`, `// similar to above`, `// continue pattern`, `// add more as needed`, bare `...` standing in for omitted code
-
-**In prose:** "Let me know if you want me to continue", "I can provide more details if needed", "for brevity", "the rest follows the same pattern", "similarly for the remaining", "and so on" (when replacing actual content), "I'll leave that as an exercise"
-
-**Structural shortcuts:** Outputting a skeleton when the request was for a full implementation. Showing the first and last section while skipping the middle. Replacing repeated logic with one example and a description. Describing what code should do instead of writing it.
-
-## Execution Process
-
-1. **Scope** — Read the full request. Count how many distinct deliverables are expected (files, functions, sections, answers). Lock that number.
-2. **Build** — Generate every deliverable completely. No partial drafts, no "you can extend this later."
-3. **Cross-check** — Before output, re-read the original request. Compare your deliverable count against the scope count. If anything is missing, add it before responding.
-
-## Handling Long Outputs
-
-When a response approaches the token limit:
-
-- Do not compress remaining sections to squeeze them in.
-- Do not skip ahead to a conclusion.
-- Write at full quality up to a clean breakpoint (end of a function, end of a file, end of a section).
-- End with:
-
-```
-[PAUSED — X of Y complete. Send "continue" to resume from: next section name]
-```
-
-On "continue", pick up exactly where you stopped. No recap, no repetition.
-
-## Quick Check
-
-Before finalizing any response, verify:
-- No banned patterns from the list above appear anywhere in the output
-- Every item the user requested is present and finished
-- Code blocks contain actual runnable code, not descriptions of what code would do
-- Nothing was shortened to save space

package/dist/skills/planger/SKILL.md

@@ -1,167 +0,0 @@
----
-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
----
-
-# 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 scout 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/workflow/SKILL.md

@@ -1,95 +0,0 @@
----
-name: workflow
-category: orchestration
-description: Delegate user work to Selesai subagents. When invoked, decompose the request into subtasks, choose the right child agent for each subtask, and coordinate them with workflowScript. Use when the user asks to use a workflow, asks to orchestrate or delegate a task, or invokes the workflow skill.
----
-
-# Workflow via subagents
-
-This is a parent-only orchestration policy over `pi-subagents`. When this skill is invoked, the parent's job is to delegate the user's request to subagents, not to perform the implementation itself. Read `../pi-subagents/SKILL.md` and the matching references before launching children. Use `workflowScript` for every coordinated launch. Do not inject or follow this skill inside child subagents.
-
-## Delegation policy
-
-- The parent owns classification, scope, decisions, synthesis, and final acceptance.
-- Whenever the workflow skill is active, solve the user's request by delegating subtasks to subagents. The parent is a coordinator and reviewer, not the primary implementer.
-- Decompose every non-trivial request into narrow subtasks before launch. Read-only subtasks (scout, research, plan, review, validation) are also delegated; do not keep them in the parent just because they are cheap.
-- Keep **one writer per checkout/worktree**. Parallelize only read-only subtasks; a single mutation-capable worker should own writes per lane.
-- Give each child a narrow role-specific task, source seam, constraints, acceptance evidence, and expected output. Never send clone prompts.
-
-## Choosing subagents
-
-Read `../pi-subagents/SKILL.md` and its references to pick builtin/custom agents. Common mapping:
-
-| Subtask | Agent |
-| --- | --- |
-| Codebase recon / find seams | `scout` |
-| External/uncertain research | `researcher` |
-| Scoped implementation | `worker` or `delegate` |
-| Independent review | `reviewer` |
-| Material architecture/product tradeoffs | `oracle` or Council Mode |
-
-For material architecture/product tradeoffs, resolve them first with an `oracle` or Council Mode before implementation.
-
-## Coordinating with workflowScript
-
-Use `workflowScript` with top-level `await`, `runs.run` for ordered stages, and `runs.all` for independent fanout. Keep async work background by default.
-
-### Single bounded task
-
-```js
-const worker = await runs.run("implement", {
-  agent: "worker",
-  task: "Implement the requested change. Return changed files, checks run, residual risks, and decisions needing approval."
-});
-return worker.outputReference;
-```
-
-### Uncertain task
-
-```js
-const scout = await runs.run("scout", {
-  agent: "scout",
-  task: "Find the code seams, existing helpers, and constraints involved. Do not edit."
-});
-const worker = await runs.run("implement", {
-  agent: "worker",
-  reads: [scout.outputReference],
-  task: "Implement the requested change from the scout findings. Return changed files, checks run, residual risks, decisions needing approval."
-});
-const reviews = await runs.all([
-  { key: "correctness", agent: "reviewer", reads: [scout.outputReference, worker.outputReference], task: "Inspect the current diff for correctness and regressions. Do not edit." },
-  { key: "simplicity", agent: "reviewer", reads: [scout.outputReference, worker.outputReference], task: "Inspect the current diff for unnecessary complexity. Do not edit." }
-]);
-return { worker: worker.outputReference, reviews: reviews.map((result) => result.outputReference) };
-```
-
-### Parallel independent subtasks
-
-Parallelize read-only discovery, research, and review with `runs.all`. If independent mutation subtasks need parallel execution, read the multi-lane guidance in `pi-subagents`, give each worker a managed `worktree: true`, and plan an explicit integration step. Otherwise serialize workers.
-
-```js
-const findings = await runs.all([
-  { key: "subtask-a-scout", agent: "scout", task: "Investigate subtask A. Do not edit." },
-  { key: "subtask-b-scout", agent: "scout", task: "Investigate subtask B. Do not edit." }
-]);
-const worker = await runs.run("implement", {
-  agent: "worker",
-  reads: findings.map((result) => result.outputReference),
-  task: "Implement the independent subtasks sequentially in this checkout, with focused checks."
-});
-return worker.outputReference;
-```
-
-## Review and fix
-
-The parent synthesizes review findings and sends one scoped fix worker. Do not launch an unbounded fix loop. Classify findings:
-
-- **blocking/actionable in approved scope** → synthesize and send one fix worker;
-- **optional, speculative, or scope-expanding** → defer or ask the user;
-- **decision needed** → stop and escalate to the user.
-
-Re-review only after a material fix. Default cap: two review rounds; use three only for risky work.
-
-## Final acceptance
-
-The parent inspects the final diff and validation evidence before reporting completion. Treat child completion, tests, and receipts as evidence—not authority to make product, architecture, merge, or release decisions.

package/docs/workflows.md

@@ -1,18 +0,0 @@
-# Adaptive implementation workflow
-
-Selesai uses the built-in [`workflow`](../src/skills/workflow/SKILL.md) skill for implementation orchestration. It is guidance for the parent agent, built on `pi-subagents`' `workflowScript` runtime; it is not a separate extension, slash-command system, or durable workflow engine.
-
-Invoke it inline with `$workflow`, or ask Selesai to orchestrate the implementation.
-
-## Policy
-
-The parent first inspects the task and chooses the smallest flow that can safely finish it:
-
-- localized changes stay local or use one worker and focused validation;
-- uncertain code or external dependencies add scoped discovery/research;
-- architecture or product tradeoffs are settled before implementation, with an oracle or Council Mode only when warranted;
-- substantial work uses one writer, independent read-only review/validation, a scoped fix worker for accepted findings, and another review only after material changes.
-
-Reviewers inspect the shared checkout's actual diff. Sibling transcripts are not shared automatically, so the parent passes a concise synthesis to a later fix worker. Handoffs are optional and reserved for cross-session continuity, milestone boundaries, or durable records.
-
-`pi-subagents` missions and receipts provide recovery evidence for delegated work. They do not turn a static flow into the source of truth or replace parent acceptance.