coctostan

Execute an approved PALS plan. Runs tasks sequentially, verifies each step, handles checkpoints, and records results for reconciliation.

Manage PALS module configuration and integrations. View, enable, and disable modules and integrations via pals.json.

Explore and articulate vision before planning. Facilitates discussion about the next milestone or phase scope, then creates a context handoff file.

Quick fix with three modes: standard (compressed loop), fast-forward (zero overhead), and hotfix (execute first, document after). For ad-hoc fixes outside the main phase loop.

Show available PALS commands and usage guide. Explains how Pi /paul-* commands relate to canonical /skill:paul-* skills.

Initialize PALS in a project. Creates .paul/ directory with STATE.md, PROJECT.md, PRD.md, ROADMAP.md, and configures modules. Supports greenfield and brownfield projects.

Manage PALS milestones. Creates new milestones with phase structure, or completes the current milestone. Detects intent from project state.

Create a handoff file for session breaks. Captures current state, in-progress work, decisions, and next actions so a future session can resume cleanly.

You MUST use this before any creative work - creating features, building components, adding functionality, or modifying behavior. Explores user intent, requirements and design before implementation.

Use when executing implementation plans with independent tasks in the current session

Use when encountering any bug, test failure, or unexpected behavior, before proposing fixes

Use when implementing any feature or bugfix, before writing implementation code

Use when about to claim work is complete, fixed, or passing, before committing or creating PRs - requires running verification commands and confirming output before making any success claims; evidence before assertions always

Use when you have a spec or requirements for a multi-step task, before touching code

Use when completing tasks, implementing major features, or before merging to verify work meets requirements

Use when facing 2+ independent tasks that can be worked on without shared state or sequential dependencies

Use when creating new skills, editing existing skills, or verifying skills work before deployment

Use when implementation is complete, all tests pass, and you need to decide how to integrate the work - guides completion of development work by presenting structured options for merge, PR, or cleanup

Use when starting feature work that needs isolation from current workspace or before executing implementation plans - creates isolated git worktrees with smart directory selection and safety verification

Use when receiving code review feedback, before implementing suggestions, especially if feedback seems unclear or technically questionable - requires technical rigor and verification, not performative agreement or blind implementation

Use when completing tasks, implementing major features, or before merging to verify work meets requirements

Use when facing 2+ independent tasks that can be worked on without shared state or sequential dependencies

Use when executing implementation plans with independent tasks in the current session

Use when encountering any bug, test failure, or unexpected behavior, before proposing fixes

Explore design options before committing to an approach

Break work into tasks, dispatch specialized agents, review iteratively

Write failing tests before implementation code — RED, GREEN, REFACTOR

Create structured implementation plans with machine-parseable task blocks

Write acceptance tests before unit tests to ensure you're building the right thing