@selesai/code 0.13.11 → 0.13.13

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/improve-codebase/REFERENCE.md

@@ -1,78 +0,0 @@
-# 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,180 +0,0 @@
----
-name: improve-codebase
-category: planning
-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: "scout", 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/industrial-brutalist-ui/SKILL.md

@@ -1,94 +0,0 @@
----
-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
----
-
-# SKILL: Industrial Brutalism & Tactical Telemetry UI
-
-## 1. Skill Meta
-**Name:** Industrial Brutalism & Tactical Telemetry Interface Engineering
-**Description:** Advanced proficiency in architecting web interfaces that synthesize mid-century Swiss Typographic design, industrial manufacturing manuals, and retro-futuristic aerospace/military terminal interfaces. This discipline requires absolute mastery over rigid modular grids, extreme typographic scale contrast, purely utilitarian color palettes, and the programmatic simulation of analog degradation (halftones, CRT scanlines, bitmap dithering). The objective is to construct digital environments that project raw functionality, mechanical precision, and high data density, deliberately discarding conventional consumer UI patterns.
-
-## 2. Visual Archetypes
-The design system operates by merging two distinct but highly compatible visual paradigms. **Pick ONE per project and commit to it. Do not alternate or mix both modes within the same interface.**
-
-### 2.1 Swiss Industrial Print
-Derived from 1960s corporate identity systems and heavy machinery blueprints.
-*   **Characteristics:** High-contrast light modes (newsprint/off-white substrates). Reliance on monolithic, heavy sans-serif typography. Unforgiving structural grids outlined by visible dividing lines. Aggressive, asymmetric use of negative space punctuated by oversized, viewport-bleeding numerals or letterforms. Heavy use of primary red as an alert/accent color.
-
-### 2.2 Tactical Telemetry & CRT Terminal
-Derived from classified military databases, legacy mainframes, and aerospace Heads-Up Displays (HUDs).
-*   **Characteristics:** Dark mode exclusivity. High-density tabular data presentation. Absolute dominance of monospaced typography. Integration of technical framing devices (ASCII brackets, crosshairs). Application of simulated hardware limitations (phosphor glow, scanlines, low bit-depth rendering).
-
-## 3. Typographic Architecture
-Typography is the primary structural and decorative infrastructure. Imagery is secondary. The system demands extreme variance in scale, weight, and spacing.
-
-### 3.1 Macro-Typography (Structural Headers)
-*   **Classification:** Neo-Grotesque / Heavy Sans-Serif.
-*   **Optimal Web Fonts:** Neue Haas Grotesk (Black), Inter (Extra Bold/Black), Archivo Black, Roboto Flex (Heavy), Monument Extended.
-*   **Implementation Parameters:**
-    *   **Scale:** Deployed at massive scales using fluid typography (e.g., `clamp(4rem, 10vw, 15rem)`).
-    *   **Tracking (Letter-spacing):** Extremely tight, often negative (`-0.03em` to `-0.06em`), forcing glyphs to form solid architectural blocks.
-    *   **Leading (Line-height):** Highly compressed (`0.85` to `0.95`).
-    *   **Casing:** Exclusively uppercase for structural impact.
-
-### 3.2 Micro-Typography (Data & Telemetry)
-*   **Classification:** Monospace / Technical Sans.
-*   **Optimal Web Fonts:** JetBrains Mono, IBM Plex Mono, Space Mono, VT323, Courier Prime.
-*   **Implementation Parameters:**
-    *   **Scale:** Fixed and small (`10px` to `14px` / `0.7rem` to `0.875rem`).
-    *   **Tracking:** Generous (`0.05em` to `0.1em`) to simulate mechanical typewriter spacing or terminal matrices.
-    *   **Leading:** Standard to tight (`1.2` to `1.4`).
-    *   **Casing:** Exclusively uppercase. Used for all metadata, navigation, unit IDs, and coordinates.
-
-### 3.3 Textural Contrast (Artistic Disruption)
-*   **Classification:** High-Contrast Serif.
-*   **Optimal Web Fonts:** Playfair Display, EB Garamond, Times New Roman.
-*   **Implementation Parameters:** Used exceedingly sparingly. Must be subjected to heavy post-processing (halftone filters, 1-bit dithering) to degrade vector perfection and create textural juxtaposition against the clean sans-serifs.
-
-## 4. Color System
-The color architecture is uncompromising. Gradients, soft drop shadows, and modern translucency are strictly prohibited. Colors simulate physical media or primitive emissive displays.
-
-**CRITICAL: Choose ONE substrate palette per project and use it consistently. Never mix light and dark substrates within the same interface.**
-
-### If Swiss Industrial Print (Light):
-*   **Background:** `#F4F4F0` or `#EAE8E3` (Matte, unbleached documentation paper).
-*   **Foreground:** `#050505` to `#111111` (Carbon Ink).
-*   **Accent:** `#E61919` or `#FF2A2A` (Aviation/Hazard Red). This is the ONLY accent color. Used for strike-throughs, thick structural dividing lines, or vital data highlights.
-
-### If Tactical Telemetry (Dark):
-*   **Background:** `#0A0A0A` or `#121212` (Deactivated CRT. Avoid pure `#000000`).
-*   **Foreground:** `#EAEAEA` (White phosphor). This is the primary text color.
-*   **Accent:** `#E61919` or `#FF2A2A` (Aviation/Hazard Red). Same red, same rules.
-*   **Terminal Green (`#4AF626`):** Optional. Use ONLY for a single specific UI element (e.g., one status indicator or one data readout) — never as a general text color. If it doesn't serve a clear purpose, omit it entirely.
-
-## 5. Layout and Spatial Engineering
-The layout must appear mathematically engineered. It rejects conventional web padding in favor of visible compartmentalization.
-
-*   **The Blueprint Grid:** Strict adherence to CSS Grid architectures. Elements do not float; they are anchored precisely to grid tracks and intersections.
-*   **Visible Compartmentalization:** Extensive utilization of solid borders (`1px` or `2px solid`) to delineate distinct zones of information. Horizontal rules (`<hr>`) frequently span the entire container width to segregate operational units.
-*   **Bimodal Density:** Layouts oscillate between extreme data density (tightly packed monospace metadata clustered together) and vast expanses of calculated negative space framing macro-typography.
-*   **Geometry:** Absolute rejection of `border-radius`. All corners must be exactly 90 degrees to enforce mechanical rigidity.
-
-## 6. UI Components and Symbology
-Standard web UI conventions are replaced with utilitarian, industrial graphic elements.
-
-*   **Syntax Decoration:** Utilization of ASCII characters to frame data points.
-    *   *Framing:* `[ DELIVERY SYSTEMS ]`, `< RE-IND >`
-    *   *Directional:* `>>>`, `///`, `\\\\`
-*   **Industrial Markers:** Prominent integration of registration (`®`), copyright (`©`), and trademark (`™`) symbols functioning as structural geometric elements rather than legal text.
-*   **Technical Assets:** Integration of crosshairs (`+`) at grid intersections, repeating vertical lines (barcodes), thick horizontal warning stripes, and randomized string data (e.g., `REV 2.6`, `UNIT / D-01`) to simulate active mechanical processes.
-
-## 7. Textural and Post-Processing Effects
-To prevent the design from appearing purely digital, simulated analog degradation is engineered into the frontend via CSS and SVG filters.
-
-*   **Halftone and 1-Bit Dithering:** Transforming continuous-tone images or large serif typography into dot-matrix patterns. Achieved via pre-processing or CSS `mix-blend-mode: multiply` overlays combined with SVG radial dot patterns.
-*   **CRT Scanlines:** For terminal interfaces, applying a `repeating-linear-gradient` to the background to simulate horizontal electron beam sweeps (e.g., `repeating-linear-gradient(0deg, transparent, transparent 2px, rgba(0,0,0,0.1) 2px, rgba(0,0,0,0.1) 4px)`).
-*   **Mechanical Noise:** A global, low-opacity SVG static/noise filter applied to the DOM root to introduce a unified physical grain across both dark and light modes.
-
-## 8. Web Engineering Directives
-1.  **Grid Determinism:** Utilize `display: grid; gap: 1px;` with contrasting parent/child background colors to generate mathematically perfect, razor-thin dividing lines without complex border declarations.
-2.  **Semantic Rigidity:** Construct the DOM using precise semantic tags (`<data>`, `<samp>`, `<kbd>`, `<output>`, `<dl>`) to accurately reflect the technical nature of the telemetry.
-3.  **Typography Clamping:** Implement CSS `clamp()` functions exclusively for macro-typography to ensure massive text scales aggressively while maintaining structural integrity across viewports.

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

@@ -1,87 +0,0 @@
----
-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
----
-
-# Protocol: Premium Utilitarian Minimalism UI Architect
-
-## 1. Protocol Overview
-Name: Premium Utilitarian Minimalism & Editorial UI
-Description: An advanced frontend engineering directive for generating highly refined, ultra-minimalist, "document-style" web interfaces analogous to top-tier workspace platforms. This protocol strictly enforces a high-contrast warm monochrome palette, bespoke typographic hierarchies, meticulous structural macro-whitespace, bento-grid layouts, and an ultra-flat component architecture with deliberate muted pastel accents. It actively rejects standard generic SaaS design trends.
-
-## 2. Absolute Negative Constraints (Banned Elements)
-The AI must strictly avoid the following generic web development defaults:
-- DO NOT use the "Inter", "Roboto", or "Open Sans" typefaces.
-- DO NOT use generic, thin-line icon libraries like "Lucide", "Feather", or standard "Heroicons".
-- DO NOT use Tailwind's default heavy drop shadows (e.g., `shadow-md`, `shadow-lg`, `shadow-xl`). Shadows must be practically non-existent or heavily customized to be ultra-diffuse and low opacity (< 0.05).
-- DO NOT use primary colored backgrounds for large elements or sections (e.g., no bright blue, green, or red hero sections).
-- DO NOT use gradients, neon colors, or 3D glassmorphism (beyond subtle navbar blurs).
-- DO NOT use `rounded-full` (pill shapes) for large containers, cards, or primary buttons.
-- DO NOT use emojis anywhere in code, markup, text content, headings, or alt text. Replace with proper icons or clean SVG primitives.
-- DO NOT use generic placeholder names like "John Doe", "Acme Corp", or "Lorem Ipsum". Use realistic, contextual content.
-- DO NOT use AI copywriting clichés: "Elevate", "Seamless", "Unleash", "Next-Gen", "Game-changer", "Delve". Write plain, specific language.
-
-## 3. Typographic Architecture
-The interface must rely on extreme typographic contrast and premium font selection to establish an editorial feel.
-- Primary Sans-Serif (Body, UI, Buttons): Use clean, geometric, or system-native fonts with character. Target: `font-family: 'SF Pro Display', 'Geist Sans', 'Helvetica Neue', 'Switzer', sans-serif`.
-- Editorial Serif (Hero Headings & Quotes): Target: `font-family: 'Lyon Text', 'Newsreader', 'Playfair Display', 'Instrument Serif', serif`. Apply tight tracking (`letter-spacing: -0.02em` to `-0.04em`) and tight line-height (`1.1`).
-- Monospace (Code, Keystrokes, Meta-data): Target: `font-family: 'Geist Mono', 'SF Mono', 'JetBrains Mono', monospace`.
-- Text Colors: Body text must never be absolute black (`#000000`). Use off-black/charcoal (`#111111` or `#2F3437`) with a generous `line-height` of `1.6` for legibility. Secondary text should be muted gray (`#787774`).
-
-## 4. Color Palette (Warm Monochrome + Spot Pastels)
-Color is a scarce resource, utilized only for semantic meaning or subtle accents.
-- Canvas / Background: Pure White `#FFFFFF` or Warm Bone/Off-White `#F7F6F3` / `#FBFBFA`.
-- Primary Surface (Cards): `#FFFFFF` or `#F9F9F8`.
-- Structural Borders / Dividers: Ultra-light gray `#EAEAEA` or `rgba(0,0,0,0.06)`.
-- Accent Colors: Exclusively use highly desaturated, washed-out pastels for tags, inline code backgrounds, or subtle icon backgrounds.
-  - Pale Red: `#FDEBEC` (Text: `#9F2F2D`)
-  - Pale Blue: `#E1F3FE` (Text: `#1F6C9F`)
-  - Pale Green: `#EDF3EC` (Text: `#346538`)
-  - Pale Yellow: `#FBF3DB` (Text: `#956400`)
-
-## 5. Component Specifications
-- Bento Box Feature Grids:
-  - Utilize asymmetrical CSS Grid layouts.
-  - Cards must have exactly `border: 1px solid #EAEAEA`.
-  - Border-radius must be crisp: `8px` or `12px` maximum.
-  - Internal padding must be generous (e.g., `24px` to `40px`).
-- Primary Call-To-Action (Buttons):
-  - Solid background `#111111`, text `#FFFFFF`. 
-  - Slight border-radius (`4px` to `6px`). No box-shadow. 
-  - Hover state should be a subtle color shift to `#333333` or a micro-scale `transform: scale(0.98)`.
-- Tags & Status Badges:
-  - Pill-shaped (`border-radius: 9999px`), very small typography (`text-xs`), uppercase with wide tracking (`letter-spacing: 0.05em`).
-  - Background must use the defined Muted Pastels.
-- Accordions (FAQ):
-  - Strip all container boxes. Separate items only with a `border-bottom: 1px solid #EAEAEA`.
-  - Use a clean, sharp `+` and `-` icon for the toggle state.
-- Keystroke Micro-UIs:
-  - Render shortcuts as physical keys using `<kbd>` tags: `border: 1px solid #EAEAEA`, `border-radius: 4px`, `background: #F7F6F3`, using the Monospace font.
-- Faux-OS Window Chrome:
-  - When mocking up software, wrap it in a minimalist container with a white top bar containing three small, light gray circles (replicating macOS window controls).
-
-## 6. Iconography & Imagery Directives
-- System Icons: Use "Phosphor Icons (Bold or Fill weights)" or "Radix UI Icons" for a technical, slightly thicker-stroke aesthetic. Standardize stroke width across all icons.
-- Illustrations: Monochromatic, rough continuous-line ink sketches on a white background, featuring a single offset geometric shape filled with a muted pastel color.
-- Photography: Use high-quality, desaturated images with a warm tone. Apply subtle overlays (`opacity: 0.04` warm grain) to blend photos into the monochrome palette. Never use oversaturated stock photos. Use reliable placeholders like `https://picsum.photos/seed/{context}/1200/800` when real assets are unavailable.
-- Hero & Section Backgrounds: Sections should not feel empty and flat. Use subtle full-width background imagery at very low opacity, soft radial light spots (`radial-gradient` with warm tones at `opacity: 0.03`), or minimal geometric line patterns to add depth without breaking the clean aesthetic.
-
-## 7. Subtle Motion & Micro-Animations
-Motion should feel invisible — present but never distracting. The goal is quiet sophistication, not spectacle.
-- Scroll Entry: Elements fade in gently as they enter the viewport. Use `translateY(12px)` + `opacity: 0` resolving over `600ms` with `cubic-bezier(0.16, 1, 0.3, 1)`. Use `IntersectionObserver`, never `window.addEventListener('scroll')`.
-- Hover States: Cards lift with an ultra-subtle shadow shift (`box-shadow` transitioning from `0 0 0` to `0 2px 8px rgba(0,0,0,0.04)` over `200ms`). Buttons respond with `scale(0.98)` on `:active`.
-- Staggered Reveals: Lists and grid items enter with a cascade delay (`animation-delay: calc(var(--index) * 80ms)`). Never mount everything at once.
-- Background Ambient Motion: Optional. A single, very slow-moving radial gradient blob (`animation-duration: 20s+`, `opacity: 0.02-0.04`) drifting behind hero sections. Must be applied to a `position: fixed; pointer-events: none` layer. Never on scrolling containers.
-- Performance: Animate exclusively via `transform` and `opacity`. No layout-triggering properties (`top`, `left`, `width`, `height`). Use `will-change: transform` sparingly and only on actively animating elements.
-
-## 8. Execution Protocol
-When tasked with writing frontend code (HTML, React, Tailwind, Vue) or designing a layout:
-1. Establish the macro-whitespace first. Use massive vertical padding between sections (e.g., `py-24` or `py-32` in Tailwind).
-2. Constrain the main typography content width to `max-w-4xl` or `max-w-5xl`.
-3. Apply the custom typographic hierarchy and monochromatic color variables immediately.
-4. Ensure every card, divider, and border adheres strictly to the `1px solid #EAEAEA` rule.
-5. Add scroll-entry animations to all major content blocks.
-6. Ensure sections have visual depth through imagery, ambient gradients, or subtle textures — no empty flat backgrounds.
-7. Provide code that reflects this high-end, uncluttered, editorial aesthetic natively without requiring manual adjustments.

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

@@ -1,50 +0,0 @@
----
-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
-  for advisory review, implementation handoffs, and multi-step tasks where a
-  single agent should stay in control while other agents contribute context,
-  planning, or execution.
----
-
-# Pi Subagents
-
-This skill is for the main parent orchestrator only. Do not inject or follow it inside spawned child subagents. The parent session owns delegation, orchestration, review fanout, and final fix-worker launches. Ordinary children should not run their own subagent workflows; the explicit exception is a delegated fanout child whose resolved builtin `tools` includes `subagent`, and that child may use `subagent` only for the fanout work the parent assigned.
-
-Use this skill when the parent orchestrator needs one specialized child or composed orchestration. Use `workflowScript` for all execution, including one isolated child. Chaining is still supported, but it is code-driven: use `await runs.run(...)` for sequential steps, `runs.all([...])` for parallel fanout, and ordinary JavaScript for branching, retries, gate monitors, and aggregation. Keep workflow helpers portable: use plain helper functions or explicit Promise chains, not nested `async function` helpers, async arrows, or async methods. Do not use legacy top-level `chain` / `tasks` inputs or durable `.chain.md` execution. Scripted workflows normally start asynchronously unless config sets `asyncByDefault:false`; set `async:true` explicitly when async behavior matters. Pass `async:false` only when the parent must block until completion. Async mode still shows progress. Do not use `async:false` for final reviews, backlog gates, run-to-completion convenience, or because no other work is available.
-
-Package-installed agents appear in `subagent({ action: "list" })` with builtin, user, and project agents. If `surf-cli` is installed as a Pi package, the Surf browser extension is loaded, and Chrome is logged into a ChatGPT Pro account, Surf can expose `gpt-pro`: a read-only async advisor that reaches ChatGPT web through Surf Oracle. Check it with `subagent({ action: "get", agent: "gpt-pro" })` and run it with `subagent({ agent: "gpt-pro", task: "Review this plan and identify release risks." })`.
-
-## How to use this router
-
-Read the matching reference file before acting. Paths are relative to this `SKILL.md`; resolve them against `skills/pi-subagents/` and load them with the read tool.
-
-| Task | Read |
-| --- | --- |
-| Decide whether to delegate, choose agents, compare tool versus slash commands, apply prompt techniques, or understand builtin roles | `references/prompting-and-roles.md` |
-| Use council mode, convene several advisors, debate a decision, cross-examine recommendations, critique or improve a plan with multiple model perspectives, or run `/council` | `../council-mode/SKILL.md` |
-| Run one-child, scripted, async, scheduled, mission-backed, forked, watchdog, oracle, or intercom-coordinated workflows | `references/execution-controls.md` |
-| Coordinate several independent tasks, worktrees, repositories, or writer lanes | `references/multi-lane-orchestration.md` |
-| List/create/update/delete/eject/disable agents, inspect legacy chain records, edit agent files, use prompt-template integration, or expose extension RPC | `references/management-authoring-rpc.md` |
-| Check safety constraints, best practices, standard workflows, or error handling | `references/constraints-and-recipes.md` |
-
-For broad or uncertain requests, read more than one reference. For complex work, start with `references/prompting-and-roles.md` and `references/execution-controls.md`, then consult `references/constraints-and-recipes.md` before launching or reviewing child work.
-
-## Always-on constraints
-
-- Keep the parent as orchestrator and final decision-maker.
-- Before multiple mutation-capable lanes, record a lane board and each lane's isolation path.
-- For plan, design, or architecture advice that asks for council mode, asks to convene several advisors, compare model perspectives, debate a decision, cross-examine recommendations, or critique and improve a plan, read `../council-mode/SKILL.md` and use Council Mode instead of ad hoc parallel oracle calls.
-- For plan, design, or architecture advice that asks to consult, discuss with, or come to agreement with one `oracle`, use a short same-session consultation loop: read the first result, resume once with a targeted challenge when material tradeoffs remain, then synthesize the parent decision. Keep explicit one-shot, trivial, and fully settled consultations one-shot.
-- Use one writer per cwd/worktree unless isolated worktrees are intentional.
-- For cross-codebase work, record the target repo, explicit `cwd`, authority boundary, and expected output before launch. Do not assume the parent session cwd is the child repo.
-- For parallel fanout, compare child prompts before launch. Do not send clone prompts with only issue numbers, titles, or broad file globs swapped; each child needs a lane-specific task, source seam, prior evidence, and decision that remains distinct without the item number. Launch that fanout as one async `workflowScript` with stable keys and aggregate output unless there is truly only one child.
-- Prefer fresh-context review/validation fanout, then synthesize and apply fixes in the parent.
-- Use async/background by default. Final reviews, gate checks, oracle checks, and backlog lanes stay async. Use `async:false` only when the parent must block until completion. Do not poll just to wait. For adaptive gates, branch in `workflowScript`.
-- For Pi extension repos whose canonical checkout is under `~/.selesai/agent/extensions`, never create lane worktrees as sibling directories there. Pi auto-loads `~/.selesai/agent/extensions/*/index.ts`, so sibling worktrees can register duplicate tools. Put lanes under `~/.selesai/agent/worktrees`, another worktree base outside auto-discovery, or a temporary clone. If a lane must run the modified extension itself, use an isolated Pi config home with `SELESAI_CODING_AGENT_DIR=<lane-config> pi --no-extensions -e <lane>/index.ts`. Use full containers only when path and config isolation are insufficient.
-- Preserve capability ceilings, including child tool restrictions and session-scoped allowed-agent restrictions.
-- Escalate unresolved product, architecture, authority, release, merge, or safety decisions upward instead of letting a child decide silently.
-- Treat receipts, CI, review bots, and external-run records as evidence, not authority to merge, close, comment, publish, or release.
-- As a conservative orchestration policy, do not pass `turnBudget`, a hard `toolBudget`, or a tight `usageBudget` to mutation-capable workers. The default tool budget blocks read/search tools rather than mutation tools, and reported usage has no reservation model. If a worker is interrupted after a tool call starts, checkpoint after the current tool returns with changed files, build/test state, and commit or PR state.