@stella-studio/ck 1.0.0

package/.claude/commands/docs/init.md

@@ -0,0 +1,38 @@
+---
+description: ⚡⚡⚡⚡ Analyze the codebase and create initial documentation
+---
+
+## Phase 1: Parallel Codebase Scouting
+
+1. Scan the codebase and calculate the number of files with LOC in each directory (skip credentials, cache or external modules directories, such as `.claude`, `.opencode`, `.git`, `tests`, `node_modules`, `__pycache__`, `secrets`, etc.)
+2. Target directories **that actually exist** - adapt to project structure, don't hardcode paths
+3. Activate `scout` skill to explore the code base and return detailed summary reports to the main agent
+4. Merge scout reports into context summary
+
+## Phase 2: Documentation Creation (docs-manager Agent)
+
+**CRITICAL:** You MUST spawn `docs-manager` agent via Task tool with merged reports. Do not wait for user input.
+
+Pass the gathered context to docs-manager agent to create initial documentation:
+- `README.md`: Update README with initial documentation (keep it under 300 lines)
+- `docs/project-overview-pdr.md`: Project overview and PDR (Product Development Requirements)
+- `docs/codebase-summary.md`: Codebase summary
+- `docs/code-standards.md`: Codebase structure and code standards
+- `docs/system-architecture.md`: System architecture
+- `docs/project-roadmap.md`: Project roadmap
+- `docs/deployment-guide.md` [optional]: Deployment guide
+- `docs/design-guidelines.md` [optional]: Design guidelines
+
+Use `docs/` directory as the source of truth for documentation.
+
+## Phase 3: Size Check (Post-Generation)
+
+After docs-manager completes:
+1. Run `wc -l docs/*.md 2>/dev/null | sort -rn` to check LOC
+2. Use `docs.maxLoc` from session context (default: 800)
+3. For files exceeding limit:
+   - Report which files exceed and by how much
+   - docs-manager should have already split proactively per Section 6 guidelines
+   - If still oversized, ask user: split now or accept as-is?
+
+**IMPORTANT**: **Do not** start implementing.

package/.claude/commands/docs/summarize.md

@@ -0,0 +1,22 @@
+---
+description: ⚡ Analyze the codebase and update documentation
+argument-hint: [focused-topics] [should-scan-codebase]
+---
+
+Activate `scout` skill to analyze the codebase and update `docs/codebase-summary.md` and respond with a summary report.
+
+## Arguments:
+$1: Focused topics (default: all)
+$2: Should scan codebase (`Boolean`, default: `false`)
+
+## Focused Topics:
+<focused_topics>$1</focused_topics>
+
+## Should Scan Codebase:
+<should_scan_codebase>$2</should_scan_codebase>
+
+## Important:
+- Use `docs/` directory as the source of truth for documentation.
+- Do not scan the entire codebase unless the user explicitly requests it.
+
+**IMPORTANT**: **Do not** start implementing.

package/.claude/commands/docs/update.md

@@ -0,0 +1,76 @@
+---
+description: ⚡⚡⚡ Analyze the codebase and update documentation
+---
+
+## Phase 1: Parallel Codebase Scouting
+
+1. Scan the codebase and calculate the number of files with LOC in each directory (skip credentials, cache or external modules directories, such as `.claude`, `.opencode`, `.git`, `tests`, `node_modules`, `__pycache__`, `secrets`, etc.)
+2. Target directories **that actually exist** - adapt to project structure, don't hardcode paths
+3. Activate `scout` skill to explore the code base and return detailed summary reports to the main agent
+4. Merge scout reports into context summary
+
+## Phase 1.5: Parallel Documentation Reading
+
+**You (main agent) must spawn readers** - subagents cannot spawn subagents.
+
+1. Count docs: `ls docs/*.md 2>/dev/null | wc -l`
+2. Get LOC: `wc -l docs/*.md 2>/dev/null | sort -rn`
+3. Strategy:
+   - 1-3 files: Skip parallel reading, docs-manager reads directly
+   - 4-6 files: Spawn 2-3 `Explore` agents
+   - 7+ files: Spawn 4-5 `Explore` agents (max 5)
+4. Distribute files by LOC (larger files get dedicated agent)
+5. Each agent prompt: "Read these docs, extract: purpose, key sections, areas needing update. Files: {list}"
+6. Merge results into context for docs-manager
+
+### Workload Distribution Example
+
+| Agent | Files | Est. LOC |
+|-------|-------|----------|
+| 1 | codebase-summary.md (800) | 800 |
+| 2 | system-architecture.md (400), code-standards.md (300) | 700 |
+| 3 | project-overview-pdr.md (500), project-roadmap.md (200) | 700 |
+
+## Phase 2: Documentation Update (docs-manager Agent)
+
+**CRITICAL:** You MUST spawn `docs-manager` agent via Task tool with merged reports and doc readings. Do not wait for user input.
+
+Pass the gathered context to docs-manager agent to update documentation:
+- `README.md`: Update README (keep it under 300 lines)
+- `docs/project-overview-pdr.md`: Update project overview and PDR (Product Development Requirements)
+- `docs/codebase-summary.md`: Update codebase summary
+- `docs/code-standards.md`: Update codebase structure and code standards
+- `docs/system-architecture.md`: Update system architecture
+- `docs/project-roadmap.md`: Update project roadmap
+- `docs/deployment-guide.md` [optional]: Update deployment guide
+- `docs/design-guidelines.md` [optional]: Update design guidelines
+
+## Additional requests
+<additional_requests>
+  $ARGUMENTS
+</additional_requests>
+
+## Phase 3: Size Check (Post-Update)
+
+After docs-manager completes:
+1. Run `wc -l docs/*.md 2>/dev/null | sort -rn` to check LOC
+2. Use `docs.maxLoc` from session context (default: 800)
+3. For files exceeding limit:
+   - Report which files exceed and by how much
+   - docs-manager should have already split proactively per Section 6 guidelines
+   - If still oversized, ask user: split now or accept as-is?
+
+## Phase 4: Documentation Validation (Post-Update)
+
+Run validation to detect potential hallucinations:
+1. Run: `node .claude/scripts/validate-docs.cjs docs/`
+2. Display validation report (warnings only, non-blocking)
+3. Checks performed:
+   - Code references: Verify `functionName()` and `ClassName` exist in codebase
+   - Internal links: Verify `[text](./path.md)` links point to existing files
+   - Config keys: Verify `ENV_VAR` mentioned in docs exist in `.env.example`
+
+## Important
+- Use `docs/` directory as the source of truth for documentation.
+
+**IMPORTANT**: **Do not** start implementing.

package/.claude/commands/journal.md

@@ -0,0 +1,7 @@
+---
+description: ⚡ Write some journal entries.
+---
+
+Use the `journal-writer` subagent to explore the memories and recent code changes, and write some journal entries.
+Journal entries should be concise and focused on the most important events, key changes, impacts, and decisions.
+Keep journal entries in the `./docs/journals/` directory.

package/.claude/commands/kanban.md

@@ -0,0 +1,99 @@
+---
+description: AI agent orchestration board (Coming Soon)
+arguments:
+  - name: dir
+    description: Plans directory (default: ./plans)
+    required: false
+---
+
+Plans dashboard with progress tracking and timeline visualization.
+
+## Usage
+
+- `/kanban` - View dashboard for ./plans directory
+- `/kanban plans/` - View dashboard for specific directory
+- `/kanban --stop` - Stop running server
+
+## Features
+
+- Plan cards with progress bars
+- Phase status breakdown (completed, in-progress, pending)
+- Timeline/Gantt visualization
+- Activity heatmap
+- Issue and branch links
+
+## Execution
+
+**IMPORTANT:** Run server as Claude Code background task using `run_in_background: true` with the Bash tool. This makes the server visible in `/tasks` and manageable via `KillShell`.
+
+The skill is located at `.claude/skills/plans-kanban/`.
+
+### Stop Server
+
+If `--stop` flag is provided:
+
+```bash
+node .claude/skills/plans-kanban/scripts/server.cjs --stop
+```
+
+### Start Server
+
+Otherwise, run the kanban server as CC background task with `--foreground` flag (keeps process alive for CC task management):
+
+```bash
+# Determine plans directory
+INPUT_DIR="{{dir}}"
+PLANS_DIR="${INPUT_DIR:-./plans}"
+
+# Start kanban dashboard
+node .claude/skills/plans-kanban/scripts/server.cjs \
+  --dir "$PLANS_DIR" \
+  --host 0.0.0.0 \
+  --open \
+  --foreground
+```
+
+**Critical:** When calling the Bash tool:
+- Set `run_in_background: true` to run as CC background task
+- Set `timeout: 300000` (5 minutes) to prevent premature termination
+- Parse JSON output and report URL to user
+
+Example Bash tool call:
+```json
+{
+  "command": "node .claude/skills/plans-kanban/scripts/server.cjs --dir \"./plans\" --host 0.0.0.0 --open --foreground",
+  "run_in_background": true,
+  "timeout": 300000,
+  "description": "Start kanban server in background"
+}
+```
+
+After starting, parse the JSON output (e.g., `{"success":true,"url":"http://localhost:3500/kanban?dir=...","networkUrl":"http://192.168.1.x:3500/kanban?dir=..."}`) and report:
+- Local URL for browser access
+- Network URL for remote device access (if available)
+- Inform user that server is now running as CC background task (visible in `/tasks`)
+
+**CRITICAL:** MUST display the FULL URL including path and query string. NEVER truncate to just `host:port`. The full URL is required for direct access.
+
+## Future Plans
+
+The `/kanban` command will evolve into **VibeKanban-inspired** AI agent orchestration:
+
+### Phase 1 (Current - MVP)
+- ✅ Task board with progress tracking
+- ✅ Visual representation of plans/tasks
+- ✅ Click to view plan details
+
+### Phase 2 (Worktree Integration)
+- Create tasks → spawn git worktrees
+- Assign agents to tasks
+- Track agent progress per worktree
+
+### Phase 3 (Full Orchestration)
+- Parallel agent execution monitoring
+- Code diff/review interface
+- PR creation workflow
+- Agent output streaming
+- Conflict detection
+
+Track progress: https://github.com/claudekit/claudekit-engineer/issues/189

package/.claude/commands/plan/archive.md

@@ -0,0 +1,57 @@
+---
+description: Write journal entries and archive specific plans or all plans
+argument-hint: [path-to-plan] (default: all plans)
+---
+
+## Your mission
+Read and analyze the plans, then write journal entries and archive specific plans or all plans in the `plans` directory.
+
+## Plan Resolution
+1. If `$ARGUMENTS` provided → Use that path
+2. Else read all plans in the `plans` directory
+
+## Workflow
+
+### Step 1: Read Plan Files
+
+Read the plan directory:
+- `plan.md` - Overview and phases list
+- `phase-*.md` - 20 first lines of each phase file to understand the progress and status
+
+### Step 2: Summarize the plans and document them with `/journal` slash command
+Use `AskUserQuestion` tool to ask if user wants to document journal entries or not.
+Skip this step if user selects "No".
+If user selects "Yes":
+- Analyze the information in previous steps.
+- Use Task tool with `subagent_type="journal-writer"` in parallel to document all plans.
+- Journal entries should be concise and focused on the most important events, key changes, impacts, and decisions.
+- Keep journal entries in the `./docs/journals/` directory.
+
+### Step 3: Ask user to confirm the action before archiving these plans
+Use `AskUserQuestion` tool to ask if user wants to proceed with archiving these plans, select specific plans to archive or all completed plans only.
+Use `AskUserQuestion` tool to ask if user wants to delete permanently or move to the `./plans/archive` directory.
+
+### Step 4: Archive the plans
+Start archiving the plans based on the user's choice:
+- Move the plans to the `./plans/archive` directory.
+- Delete the plans permanently: `rm -rf ./plans/<plan-1> ./plans/<plan-2> ...`
+
+### Step 5: Ask if user wants to commit the changes
+Use `AskUserQuestion` tool to ask if user wants to commit the changes with these options:
+- Stage and commit the changes (Use `/git:cm` slash command)
+- Commit and push the changes (Use `/git:cp` slash command)
+- Nah, I'll do it later
+
+## Output
+After archiving the plans, provide summary:
+- Number of plans archived 
+- Number of plans deleted permanently
+- Table of plans that are archived or deleted (title, status, created date, LOC)
+- Table of journal entries that are created (title, status, created date, LOC)
+
+## Important Notes
+
+**IMPORTANT:** Only ask questions about genuine decision points - don't manufacture artificial choices.
+**IMPORTANT:** Sacrifice grammar for the sake of concision when writing outputs.
+**IMPORTANT:** In the last summary report, list any unresolved questions at the end, if any.
+**IMPORTANT:** Ensure token efficiency while maintaining high quality.

package/.claude/commands/plan/ci.md

@@ -0,0 +1,33 @@
+---
+description: Analyze Github Actions logs and provide a plan to fix the issues
+argument-hint: [github-actions-url]
+---
+
+Activate `planning` skill.
+
+## Github Actions URL
+ $ARGUMENTS
+
+Use the `planner` subagent to read the github actions logs, analyze and find the root causes of the issues, then provide a detailed plan for implementing the fixes.
+
+**Plan File Specification:**
+- Every `plan.md` MUST start with YAML frontmatter:
+  ```yaml
+  ---
+  title: "{Brief title}"
+  description: "{One sentence for card preview}"
+  status: pending
+  priority: P1
+  effort: {estimated fix time}
+  branch: {current git branch}
+  tags: [ci, bugfix]
+  created: {YYYY-MM-DD}
+  ---
+  ```
+
+**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.
+
+**IMPORTANT:** Ask the user for confirmation before implementing.
+**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 outputs.

package/.claude/commands/plan/cro.md

@@ -0,0 +1,69 @@
+---
+description: Create a CRO plan for the given content
+argument-hint: [issues]
+---
+
+You are an expert in conversion optimization. Analyze the content based on the given issues:
+<issues>$ARGUMENTS</issues>
+
+Activate `planning` skill.
+
+**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 outputs.
+
+## Conversion Optimization Framework
+
+1. Headline 4-U Formula: **Useful, Unique, Urgent, Ultra-specific** (80% won't read past this)
+2. Above-Fold Value Proposition: Customer problem focus, no company story, zero scroll required
+3. CTA First-Person Psychology: "Get MY Guide" vs "Get YOUR Guide" (90% more clicks)
+4. 5-Field Form Maximum: Every field kills conversions, progressive profiling for the rest
+5. Message Match Precision: Ad copy, landing page headline, broken promises = bounce
+6. Social Proof Near CTAs: Testimonials with faces/names, results, placed at decision points
+7. Cognitive Bias Stack: Loss aversion (fear), social proof (FOMO), anchoring (pricing)
+8. PAS Copy Framework: Problem > Agitate > Solve, emotion before logic
+9. Genuine Urgency Only: Real deadlines, actual limits, fake timers destroy trust forever
+10. Price Anchoring Display: Show expensive option first, make real price feel like relief
+11. Trust Signal Clustering: Security badges, guarantees, policies all visible together
+12. Visual Hierarchy F-Pattern: Eyes scan F-shape, put conversions in the path
+13. Lead Magnet Hierarchy: Templates > Checklists > Guides (instant > delayed gratification)
+14. Objection Preemption: Address top 3 concerns before they think them, FAQ near CTA
+15. Mobile Thumb Zone: CTAs where thumbs naturally rest, not stretching required
+16. One-Variable Testing: Change one thing, measure impact, compound wins over time
+17. Post-Conversion Momentum: Thank you page sells next step while excitement peaks
+18. Cart Recovery Sequence: Email in 1 hour, retarget in 4 hours, incentive at 24 hours
+19. Reading Level Grade 6: Smart people prefer simple, 11-word sentences, short paragraphs
+20. TOFU/MOFU/BOFU Logic: Awareness content ≠ decision content, match intent precisely
+21. White Space = Focus: Empty space makes CTAs impossible to miss, crowded = confused
+22. Benefit-First Language: Features tell, benefits sell, transformations compel
+23. Micro-Commitment Ladder: Small yes leads to big yes, start with email only
+24. Performance Tracking Stack: Heatmaps show problems, recordings show why, events show what
+25. Weekly Optimization Ritual: Review metrics Monday, test Tuesday, iterate or scale
+
+## Workflow
+
+- If the user provides a screenshots or videos, use `ai-multimodal` skill to describe as detailed as possible the issue, make sure fullstack-developer can fully understand the issue easily based on the description.
+- If the user provides a URL, use `web_fetch` tool to fetch the content of the URL and analyze the current issues.
+- You can use screenshot capture tools along with `ai-multimodal` skill to capture screenshots of the exact parent container and analyze the current issues with the appropriate Gemini analysis skills (`ai-multimodal`, `gemini-video-understanding`, or `gemini-document-processing`).
+- Use `/scout:ext` (preferred) or `/scout` (fallback) slash command to search the codebase for files needed to complete the task
+- Use `planner` agent to create a comprehensive CRO plan following the progressive disclosure structure:
+  - Create a directory using naming pattern from `## Naming` section.
+  - 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: [cro, conversion]
+    created: {YYYY-MM-DD}
+    ---
+    ```
+  - Save the overview access point at `plan.md`, keep it generic, under 80 lines, and list each phase with status/progress and links.
+  - For each phase, add `phase-XX-phase-name.md` files containing sections (Context links, Overview with date/priority/statuses, Key Insights, Requirements, Architecture, Related code files, Implementation Steps, Todo list, Success Criteria, Risk Assessment, Security Considerations, Next steps).
+  - Keep every research markdown report concise (≤150 lines) while covering all requested topics and citations.
+- Do not start implementing the CRO plan yet, wait for the user to approve the plan first.
+
+**IMPORTANT:** Sacrifice grammar for the sake of concision when writing reports.
+**IMPORTANT:** In reports, list any unresolved questions at the end, if any.

package/.claude/commands/plan/fast.md

@@ -0,0 +1,82 @@
+---
+description: ⚡⚡ No research. Only analyze and create an implementation plan
+argument-hint: [task]
+---
+
+Think.
+Activate `planning` skill.
+
+## Your mission
+<task>
+$ARGUMENTS
+</task>
+
+## Pre-Creation Check (Active vs Suggested Plan)
+
+Check the `## Plan Context` section in the injected context:
+- If "Plan:" shows a path → Active plan exists. Ask user: "Continue with this? [Y/n]"
+- If "Suggested:" shows a path → Branch-matched hint only. Ask if they want to activate or create new.
+- If "Plan: none" → Create new plan using naming from `## Naming` section.
+
+## Workflow
+Use `planner` subagent to:
+1. If creating new: Create directory using `Plan dir:` from `## Naming` section, then run `node .claude/scripts/set-active-plan.cjs {plan-dir}`
+   If reusing: Use the active plan path from Plan 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. Analyze the codebase by reading `codebase-summary.md`, `code-standards.md`, `system-architecture.md` and `project-overview-pdr.md` file.
+4. Gathers all information and create an implementation plan of this task.
+5. Ask user to review the plan.
+
+## 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 --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`?** Fast planning pairs with fast execution - skips review gates.
+**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.
+
+## Output Requirements
+
+**Plan Directory Structure** (use `Plan dir:` from `## Naming` section)
+```
+{plan-dir}/
+├── reports/
+│   ├── XX-report.md
+│   └── ...
+├── plan.md
+├── phase-XX-phase-name-here.md
+└── ...
+```
+
+**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 and progress plus 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), Overview (date, description, priority, implementation status, review status), Key Insights, Requirements, Architecture, Related code files, Implementation Steps, Todo list, Success Criteria, Risk Assessment, Security Considerations, Next steps.
+
+## Important Notes
+- **IMPORTANT:** Ensure token consumption efficiency while maintaining high quality.
+- **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:** In reports, list any unresolved questions at the end, if any.
+- **IMPORTANT**: **Do not** start implementing.

package/.claude/commands/plan/hard.md

@@ -0,0 +1,108 @@
+---
+description: ⚡⚡⚡ Research, analyze, and create an implementation plan
+argument-hint: [task]
+---
+
+Think harder.
+Activate `planning` skill.
+
+## Your mission
+<task>
+$ARGUMENTS
+</task>
+
+## Pre-Creation Check (Active vs Suggested Plan)
+
+Check the `## Plan Context` section in the injected context:
+- If "Plan:" shows a path → Active plan exists. Ask user: "Continue with this? [Y/n]"
+- If "Suggested:" shows a path → Branch-matched hint only. Ask if they want to activate or create new.
+- If "Plan: none" → Create new plan using naming from `## Naming` section.
+
+## Workflow
+1. If creating new: Create directory using `Plan dir:` from `## Naming` section, then run `node .claude/scripts/set-active-plan.cjs {plan-dir}`
+   If reusing: Use the active plan path from Plan 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 an implementation plan of this task.
+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.
+
+## Context Reminder (MANDATORY)
+
+**IMPORTANT:** If user skips validation (chooses "No" or mode is `off`), you MUST remind them 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?** Thorough planning without validation needs interactive review gates.
+**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** when validation is skipped - always output with the actual absolute path.
+
+## 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 and progress plus 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), Overview (date, description, priority, implementation status, review status), Key Insights, Requirements, Architecture, Related code files, Implementation Steps, Todo list, Success Criteria, Risk Assessment, Security Considerations, Next steps.
+
+## 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.