@stella-studio/ck 1.0.0

package/.claude/commands/plan/parallel.md

@@ -0,0 +1,145 @@
+---
+description: ⚡⚡⚡ Create detailed plan with parallel-executable phases
+argument-hint: [task]
+---
+
+Think strategically about parallelization.
+Activate `planning` skill.
+
+## Your mission
+<task>
+$ARGUMENTS
+</task>
+
+## Workflow
+1. Create a directory using naming pattern from `## Naming` section in injected context.
+   Make sure you pass the directory path to every subagent during the process.
+2. Follow strictly to the "Plan Creation & Organization" rules of `planning` skill.
+3. Use multiple `researcher` agents (max 2 agents) in parallel to research for this task:
+   Each agent research for a different aspect of the task and are allowed to perform max 5 tool calls.
+4. Analyze the codebase by reading `codebase-summary.md`, `code-standards.md`, `system-architecture.md` and `project-overview-pdr.md` file.
+   **ONLY PERFORM THIS FOLLOWING STEP IF `codebase-summary.md` is not available or older than 3 days**: Use `/scout <instructions>` slash command to search the codebase for files needed to complete the task.
+5. Main agent gathers all research and scout report filepaths, and pass them to `planner` subagent with the prompt to create a parallel-optimized implementation plan.
+6. Main agent receives the implementation plan from `planner` subagent, and ask user to review the plan
+
+## Post-Plan Validation (Optional)
+
+After plan creation, offer validation interview to confirm decisions before implementation.
+
+**Check `## Plan Context` → `Validation: mode=X, questions=MIN-MAX`:**
+
+| Mode | Behavior |
+|------|----------|
+| `prompt` | Ask user: "Validate this plan with a brief interview?" → Yes (Recommended) / No |
+| `auto` | Automatically execute `/plan:validate {plan-path}` |
+| `off` | Skip validation step entirely |
+
+**If mode is `prompt`:** Use `AskUserQuestion` tool with options above.
+**If user chooses validation or mode is `auto`:** Execute `/plan:validate {plan-path}` SlashCommand.
+
+## Special Requirements for Parallel Execution
+
+**CRITICAL:** The planner subagent must create phases that:
+1. **Can be executed independently** - Each phase should be self-contained with no runtime dependencies on other phases
+2. **Have clear boundaries** - No file overlap between phases (each file should only be modified in ONE phase)
+3. **Separate concerns logically** - Group by architectural layer, feature domain, or technology stack
+4. **Minimize coupling** - Phases should communicate through well-defined interfaces only
+5. **Include dependency matrix** - Clearly document which phases must run sequentially vs in parallel
+
+**Parallelization Strategy:**
+- Group frontend/backend/database work into separate phases when possible
+- Separate infrastructure setup from application logic
+- Isolate different feature domains (e.g., auth vs profile vs payments)
+- Split by file type/directory (e.g., components vs services vs models)
+- Create independent test phases per module
+
+**Phase Organization Example:**
+```
+Phase 01: Database Schema (can run independently)
+Phase 02: Backend API Layer (can run independently)
+Phase 03: Frontend Components (can run independently)
+Phase 04: Integration Tests (depends on 01, 02, 03)
+```
+
+## Output Requirements
+
+**Plan Directory Structure** (use `Plan dir:` from `## Naming` section)
+```
+{plan-dir}/
+├── research/
+│   ├── researcher-XX-report.md
+│   └── ...
+├── reports/
+│   ├── XX-report.md
+│   └── ...
+├── scout/
+│   ├── scout-XX-report.md
+│   └── ...
+├── plan.md
+├── phase-XX-phase-name-here.md
+└── ...
+```
+
+**Research Output Requirements**
+- Ensure every research markdown report remains concise (≤150 lines) while covering all requested topics and citations.
+
+**Plan File Specification**
+- Every `plan.md` MUST start with YAML frontmatter:
+  ```yaml
+  ---
+  title: "{Brief title}"
+  description: "{One sentence for card preview}"
+  status: pending
+  priority: P2
+  effort: {sum of phases, e.g., 4h}
+  branch: {current git branch}
+  tags: [relevant, tags]
+  created: {YYYY-MM-DD}
+  ---
+  ```
+- Save the overview access point at `{plan-dir}/plan.md`. Keep it generic, under 80 lines, and list each implementation phase with status, progress, parallelization group, and links to phase files.
+- For each phase, create `{plan-dir}/phase-XX-phase-name-here.md` containing the following sections in order:
+  - Context links (reference parent plan, dependencies, docs)
+  - **Parallelization Info** (which phases can run concurrently, which must wait)
+  - Overview (date, description, priority, implementation status, review status)
+  - Key Insights
+  - Requirements
+  - Architecture
+  - **Related code files** (MUST be exclusive to this phase - no overlap with other phases)
+  - **File Ownership** (explicit list of files this phase owns/modifies)
+  - Implementation Steps
+  - Todo list
+  - Success Criteria
+  - **Conflict Prevention** (how this phase avoids conflicts with parallel phases)
+  - Risk Assessment
+  - Security Considerations
+  - Next steps
+
+**Main plan.md must include:**
+- Dependency graph showing which phases can run in parallel
+- Execution strategy (e.g., "Phases 1-3 parallel, then Phase 4")
+- File ownership matrix (which phase owns which files)
+
+## Context Reminder (MANDATORY)
+
+**IMPORTANT:** After plan creation, you MUST remind the user with the **full absolute path**:
+
+> **Best Practice:** Run `/clear` before implementing to start with fresh context.
+> Then run:
+> ```
+> /cook --parallel {ABSOLUTE_PATH_TO_PLAN_DIR}/plan.md
+> ```
+> *(Replace with actual absolute path, e.g., `/home/user/project/plans/260203-1234-feature/plan.md`)*
+
+**Why `--parallel`?** Parallel-optimized plan pairs with parallel execution - multiple agents work on independent phases.
+**Why absolute path?** After `/clear`, the new session loses context. Worktree paths won't be discoverable without the full path.
+
+This reminder is **NON-NEGOTIABLE** - always output it after presenting the plan with the actual absolute path.
+
+## Important Notes
+**IMPORTANT:** Analyze the skills catalog and activate the skills that are needed for the task during the process.
+**IMPORTANT:** Ensure token efficiency while maintaining high quality.
+**IMPORTANT:** Sacrifice grammar for the sake of concision when writing reports.
+**IMPORTANT:** In reports, list any unresolved questions at the end, if any.
+**IMPORTANT:** Do not start implementing.
+**IMPORTANT:** Each phase MUST have exclusive file ownership - no file can be modified by multiple phases.

package/.claude/commands/plan/two.md

@@ -0,0 +1,61 @@
+---
+description: ⚡⚡⚡⚡ Research & create an implementation plan with 2 approaches
+argument-hint: [task]
+---
+
+Think harder.
+Activate `planning` skill.
+
+## Your mission
+Use the `planner` subagent to create 2 detailed implementation plans for this following task:
+<task>
+ $ARGUMENTS
+</task>
+
+## Workflow
+1. First: Create a directory using naming pattern from `## Naming` section in injected context.
+   Make sure you pass the directory path to every subagent during the process.
+2. Follow strictly to the "Plan Creation & Organization" rules of `planning` skill.
+3. Use multiple `researcher` agents in parallel to research for this task, each agent research for a different aspect of the task and perform max 5 researches (max 5 tool calls).
+4. Use `scout` agent to search the codebase for files needed to complete the task.
+5. Main agent gathers all research and scout report filepaths, and pass them to `planner` subagent with the detailed instructions prompt to create an implementation plan of this task.
+  **Output:** Provide at least 2 implementation approaches with clear trade-offs, and explain the pros and cons of each approach, and provide a recommended approach.
+1. Main agent receives the implementation plan from `planner` subagent, and ask user to review the plan
+
+## Plan File Specification
+- Every `plan.md` MUST start with YAML frontmatter:
+  ```yaml
+  ---
+  title: "{Brief title}"
+  description: "{One sentence for card preview}"
+  status: pending
+  priority: P2
+  effort: {sum of phases, e.g., 4h}
+  branch: {current git branch}
+  tags: [relevant, tags]
+  created: {YYYY-MM-DD}
+  ---
+  ```
+
+## Context Reminder (MANDATORY)
+
+**IMPORTANT:** After plan creation, you MUST remind the user with the **full absolute path**:
+
+> **Best Practice:** Run `/clear` before implementing to start with fresh context.
+> Then run:
+> ```
+> /cook {ABSOLUTE_PATH_TO_PLAN_DIR}/plan.md
+> ```
+> *(Replace with actual absolute path, e.g., `/home/user/project/plans/260203-1234-feature/plan.md`)*
+
+**Why no flag?** Multiple approaches need interactive review to choose the right one.
+**Why absolute path?** After `/clear`, the new session loses context. Worktree paths won't be discoverable without the full path.
+
+This reminder is **NON-NEGOTIABLE** - always output it after presenting the plan with the actual absolute path.
+
+## Important Notes
+**IMPORTANT:** Analyze the skills catalog and activate the skills that are needed for the task during the process.
+**IMPORTANT:** Sacrifice grammar for the sake of concision when writing reports.
+**IMPORTANT:** Ensure token efficiency while maintaining high quality.
+**IMPORTANT:** In reports, list any unresolved questions at the end, if any.
+**IMPORTANT**: **Do not** start implementing.

package/.claude/commands/plan/validate.md

@@ -0,0 +1,188 @@
+---
+description: Validate plan with critical questions interview
+argument-hint: [plan-path]
+---
+
+## Your mission
+
+Interview the user with critical questions to validate assumptions, confirm decisions, and surface potential issues in an implementation plan before coding begins.
+
+## Plan Resolution
+
+1. If `$ARGUMENTS` provided → Use that path
+2. Else check `## Plan Context` section → Use active plan path
+3. If no plan found → Ask user to specify path or run `/plan:hard` first
+
+## Configuration (from injected context)
+
+Check `## Plan Context` section for validation settings:
+- `mode` - Controls auto/prompt/off behavior
+- `questions` - Range like `3-8` (min-max)
+
+These values are automatically injected from user config. Use them as constraints.
+
+## Workflow
+
+### Step 1: Read Plan Files
+
+Read the plan directory:
+- `plan.md` - Overview and phases list
+- `phase-*.md` - All phase files
+- Look for decision points, assumptions, risks, tradeoffs
+
+### Step 2: Extract Question Topics
+
+Scan plan content for:
+
+| Category | Keywords to detect |
+|----------|-------------------|
+| **Architecture** | "approach", "pattern", "design", "structure", "database", "API" |
+| **Assumptions** | "assume", "expect", "should", "will", "must", "default" |
+| **Tradeoffs** | "tradeoff", "vs", "alternative", "option", "choice", "either/or" |
+| **Risks** | "risk", "might", "could fail", "dependency", "blocker", "concern" |
+| **Scope** | "phase", "MVP", "future", "out of scope", "nice to have" |
+
+### Step 3: Generate Questions
+
+For each detected topic, formulate a concrete question:
+
+**Question format rules:**
+- Each question must have 2-4 concrete options
+- Mark recommended option with "(Recommended)" suffix
+- Include "Other" option is automatic - don't add it
+- Questions should surface implicit decisions
+
+**Example questions:**
+
+```
+Category: Architecture
+Question: "How should the validation results be persisted?"
+Options:
+1. Save to plan.md frontmatter (Recommended) - Updates existing plan
+2. Create validation-answers.md - Separate file for answers
+3. Don't persist - Ephemeral validation only
+```
+
+```
+Category: Assumptions
+Question: "The plan assumes API rate limiting is not needed. Is this correct?"
+Options:
+1. Yes, rate limiting not needed for MVP
+2. No, add basic rate limiting now (Recommended)
+3. Defer to Phase 2
+```
+
+### Step 4: Interview User
+
+Use `AskUserQuestion` tool to present questions.
+
+**Rules:**
+- Use question count from `## Plan Context` → `Validation: mode=X, questions=MIN-MAX`
+- Group related questions when possible (max 4 questions per tool call)
+- Focus on: assumptions, risks, tradeoffs, architecture
+
+### Step 5: Document Answers
+
+After collecting answers, update `plan.md` with a detailed validation log. If a `## Validation Log` section already exists (from previous sessions), **append** a new session block — never overwrite history.
+
+1. Add or append to `## Validation Log` section in `plan.md`:
+
+```markdown
+## Validation Log
+
+### Session 1 — {YYYY-MM-DD}
+**Trigger:** {what prompted this validation — initial plan creation, re-validation after scope change, etc.}
+**Questions asked:** {count}
+
+#### Questions & Answers
+
+1. **[{Category}]** {full question text}
+   - Options: {A} | {B} | {C}
+   - **Answer:** {user's choice}
+   - **Custom input:** {verbatim "Other" text if user selected Other, otherwise omit this line}
+   - **Rationale:** {why this decision matters for implementation}
+
+2. **[{Category}]** {full question text}
+   - Options: {A} | {B} | {C}
+   - **Answer:** {user's choice}
+   - **Custom input:** {verbatim text, omit if N/A}
+   - **Rationale:** {why this matters}
+
+#### Confirmed Decisions
+- {decision}: {choice} — {brief why}
+
+#### Action Items
+- [ ] {specific change needed based on answers}
+
+#### Impact on Phases
+- Phase {N}: {what needs updating and why}
+```
+
+**Recording rules:**
+- **Full question text**: Copy the exact question asked, not a summary
+- **All options**: List every option that was presented
+- **Verbatim custom input**: If user selected "Other" and typed custom text, record it exactly as entered — this often contains critical context
+- **Rationale**: Explain why the decision affects implementation (helps future agents understand intent)
+- **Session numbering**: Increment session number from last existing session. First validation = Session 1
+- **Trigger**: State what prompted this validation round (initial, re-validation, scope change, etc.)
+
+2. If answers require plan changes, document them in `#### Impact on Phases` section.
+
+### Step 6: Propagate Changes to Phases (Auto-Apply)
+
+**Auto-propagate** validation decisions to affected phase files.
+
+**Process:**
+1. Parse "Impact on Phases" section → If empty, skip and report "No phase changes required"
+2. For each phase reference (accepts "Phase 2", "phase-02", "P2"):
+   - Glob for `phase-{N:02d}-*.md` → If missing, warn and skip
+   - Locate target section (exact → fuzzy → fallback to Key Insights)
+   - Apply change + add marker: `<!-- Updated: Validation Session N - {change} -->`
+   - Skip if same-session marker already exists (prevent duplication)
+
+**Section mapping:**
+| Change Type | Target Section |
+|-------------|----------------|
+| Requirements | Requirements |
+| Architecture | Architecture |
+| Scope | Overview / Implementation Steps |
+| Risk | Risk Assessment |
+| Unknown | Key Insights (new subsection) |
+
+**Error handling:** Best-effort — log warnings for missing files/sections, continue with others, report all in Output.
+
+## Output
+
+After validation completes, provide summary:
+- Number of questions asked
+- Key decisions confirmed
+- **Phase propagation results:**
+  - ✅ Files updated (with section names)
+  - ⚠️ Warnings (skipped phases, fallback sections)
+  - ❌ Errors (if any write failures)
+- Any items flagged for plan revision
+- Recommendation: proceed to implementation or revise plan first
+
+## Next Steps (MANDATORY)
+
+**IMPORTANT:** After providing the validation summary, you MUST remind the user with the **full absolute path**:
+
+> **Best Practice:** Run `/clear` before implementing to start with fresh context.
+> Then run:
+> ```
+> /cook --auto {ABSOLUTE_PATH_TO_PLAN_DIR}/plan.md
+> ```
+> *(Replace with actual absolute path, e.g., `/home/user/project/plans/260203-1234-feature/plan.md`)*
+>
+> **Why `--auto`?** Plan was already validated - safe to skip review gates.
+> **Why absolute path?** After `/clear`, the new session loses context. Worktree paths won't be discoverable without the full path.
+>
+> Fresh context helps Claude focus solely on implementation without planning context pollution, improving plan adherence.
+
+This reminder is **NON-NEGOTIABLE** - always output it at the end of validation with the actual absolute path.
+
+## Important Notes
+
+**IMPORTANT:** Only ask questions about genuine decision points - don't manufacture artificial choices.
+**IMPORTANT:** If plan is simple with few decisions, it's okay to ask fewer than min questions.
+**IMPORTANT:** Prioritize questions that could change implementation significantly.

package/.claude/commands/plan.md

@@ -0,0 +1,30 @@
+---
+description: ⚡⚡⚡ Intelligent plan creation with prompt enhancement
+argument-hint: [task]
+---
+
+## Your mission
+<task>
+$ARGUMENTS
+</task>
+
+## Pre-Creation Check (Active vs Suggested Plan Detection)
+
+Check the `## Plan Context` section in the injected context:
+- If "Plan:" shows a path → Active plan exists. Ask user: "Active plan found: {path}. Continue with this? [Y/n]"
+- If "Suggested:" shows a path → Branch-matched plan hint only. Ask user if they want to activate it or create new.
+- If "Plan: none" → Proceed to create new plan using naming pattern from `## Naming` section.
+
+## Workflow
+- Analyze the given task and use `AskUserQuestion` tool to ask for more details if needed.
+- Decide to use `/plan:fast` or `/plan:hard` SlashCommands based on the complexity.
+- Execute SlashCommand: `/plan:fast <detailed-instructions-prompt>` or `/plan:hard <detailed-instructions-prompt>`
+- Activate `planning` skill.
+- Note: `detailed-instructions-prompt` is **an enhanced prompt** that describes the task in detail based on the provided task description.
+
+## Important Notes
+**IMPORTANT:** Analyze the skills catalog and activate the skills that are needed for the task during the process.
+**IMPORTANT:** Sacrifice grammar for the sake of concision when writing reports.
+**IMPORTANT:** Ensure token efficiency while maintaining high quality.
+**IMPORTANT:** In reports, list any unresolved questions at the end, if any.
+**IMPORTANT**: **Do not** start implementing.