cokit-cli 1.0.9 → 1.2.2

package/prompts/ck-plan-validate.prompt.md

@@ -0,0 +1,209 @@
+---
+agent: 'agent'
+description: 'Validate plan with critical questions interview'
+argument-hint: 'Path to plan directory'
+---
+## Variant Notice
+**IMPORTANT — Read before proceeding.**
+`ck-plan-validate` is an internal mode for validating an existing plan with interview questions — it is meant to be selected automatically by AI when you run `/ck-plan`.
+You don't need to call this directly. Just use `/ck-plan` and AI will pick the right mode for you.
+Before executing, you MUST output the following message **exactly as written** and wait for user response:
+
+---
+**Variant Notice**
+
+`ck-plan-validate` is an internal mode for validating an existing plan with interview questions — it is meant to be selected automatically by AI when you run `/ck-plan`.
+You don't need to call this directly. Just use `/ck-plan` and AI will pick the right mode for you.
+
+Do you want to continue anyway, or switch to `/ck-plan`? **[Continue / Switch to /ck-plan]**
+
+---
+
+Only proceed if user explicitly confirms Continue.
+If user chooses "Switch to /ck-plan", run  immediately — do NOT ask user to re-enter their input.
+
+
+## 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 `${input}` 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 `/ck-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
+
+Present questions directly in your response, listing each with numbered options. Then stop and wait for the user to answer before proceeding.
+
+**Rules:**
+- Use question count from `## Plan Context` → `Validation: mode=X, questions=MIN-MAX`
+- Group related questions when possible (max 4 questions per response)
+- Focus on: assumptions, risks, tradeoffs, architecture
+- Format each question with numbered options for easy selection
+
+### 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"):
+   - Search for `phase-{N:02d}-*.md` files → 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)*
+>
+> **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 the agent 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/prompts/ck-plan.prompt.md

@@ -1,80 +1,75 @@
----
-agent: 'agent'
-description: 'Intelligent plan creation with prompt enhancement'
-tools: ['search/codebase', 'search/changes', 'web/fetch', 'read/problems']
----
-
-## Your mission
-<task>
-${input}
-</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 ask user for more details if needed.
-- Decide complexity:
-  - **Simple task** (clear scope, no research needed) → Use `/plan:fast`
-  - **Complex task** (needs research, multiple aspects) → Use `/plan:hard`
-- Execute the chosen SlashCommand with an **enhanced detailed prompt**:
-  - `/plan:fast <detailed-instructions-prompt>`
-  - `/plan:hard <detailed-instructions-prompt>`
-
-**Note:** The `detailed-instructions-prompt` must describe the task in detail based on user's input.
-
-## Output
-The output MUST be markdown plan files saved to `plans/` directory:
-```
-{plan-dir}/
-├── plan.md              ← Main plan with YAML frontmatter
-├── phase-XX-*.md        ← Implementation phases
-└── reports/             ← Any analysis reports
-```
-
-## Clarification & Finalization Flow
-
-After creating the initial plan:
-
-1. **If questions exist** → List questions at the end of your response (max 3-5 questions)
-2. **After user answers** → Update `plan.md` with clarified requirements
-3. **Repeat** until no ambiguities remain
-4. **Finalize** → Confirm plan is complete and ready for implementation
-
-**Question format:**
-```
-## Questions before finalizing:
-1. [Question 1]?
-2. [Question 2]?
-...
-```
-
-## Next Steps Suggestion
-
-After plan is finalized, suggest the appropriate implementation command:
-
-| Task Type | Suggested Command |
-|-----------|-------------------|
-| Feature development | `/ck-cook` or `/ck-code` |
-| Bug fix | `/fix` |
-| Refactoring | `/refactor` |
-| Documentation | `/docs` |
-
-**Example output:**
-```
-✅ Plan finalized: {plan-dir}/plan.md
-
-Ready to implement? Run one of these:
-- `/ck-cook` - Full-featured implementation with tests
-- `/ck-code` - Quick implementation
-```
-
-## Important Notes
-- **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.
+---
+agent: 'agent'
+description: 'Intelligent plan creation with prompt enhancement'
+argument-hint: 'Task description or requirements'
+---
+
+**Analyze task and route to the right planning mode:**
+<task>${input}</task>
+
+## Decision Tree
+
+**1. Check for existing plan:**
+- Check `## Plan Context` section in 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 hint. Ask user to activate or create new.
+- If "Plan: none" → Proceed to step 2.
+
+**2. Route by complexity:**
+
+**A) Simple/Quick Tasks** (keywords: small, quick, simple, straightforward, single file, minor, tweak, < 2 hours)
+→ `/ck-plan-fast <detailed-instructions-prompt>`
+
+**B) Complex/Research-Heavy Tasks** (keywords: complex, research, unfamiliar, architecture, multi-component, integration, large, major, multi-day)
+→ `/ck-plan-hard <detailed-instructions-prompt>`
+
+**C) Validate Existing Plan** (keywords: validate, review plan, check plan, verify assumptions)
+→ `/ck-plan-validate <path-to-plan>`
+
+**D) Default/Medium Tasks** (anything else)
+→ Execute planning workflow below directly.
+
+## Workflow (for Default/Medium tasks)
+
+- Activate `planning` skill.
+- Analyze the given task and ask clarifying questions directly if needed. Wait for user response before proceeding.
+- Note: `detailed-instructions-prompt` is **an enhanced prompt** that describes the task in detail based on the provided task description.
+
+## Post-Plan Validation (Optional)
+
+After plan creation, offer validation for non-trivial plans.
+
+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 `/ck-plan-validate {plan-path}` |
+| `off` | Skip validation step entirely |
+
+If user chooses validation or mode is `auto`: Execute `/ck-plan-validate {plan-path}`.
+
+## Notes
+- `detailed-instructions-prompt` = enhanced prompt describing task in detail
+- If unclear about complexity, default to this prompt's workflow (medium)
+- Fast plans skip validation by default
+- Hard plans recommend validation
+
+## 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.
+
+---
+
+## Suggested Next Steps
+
+| Command | Description |
+|---------|-------------|
+| `/ck-plan-validate` | Validate plan with critical questions |
+| `/ck-cook` | Implement plan |
+| `/ck-test` | Run tests and analyze results |
+| `/ck-fix` | Analyze and fix issues |
+| `/ck-spec-specify` | Need detailed spec first? Start spec-driven flow |

package/prompts/ck-preview.prompt.md

@@ -0,0 +1,77 @@
+---
+agent: 'agent'
+description: 'Preview markdown files, plan directories, or plans collection'
+argument-hint: 'Path to markdown file or directory'
+tools: ['execute/runInTerminal', 'execute/getTerminalOutput']
+---
+
+Universal viewer - pass ANY path and see it rendered nicely.
+
+## Usage
+
+- `/ck-preview <file.md>` - View markdown file in novel-reader UI
+- `/ck-preview <directory/>` - Browse directory contents
+- `/ck-preview --stop` - Stop running server
+
+## Examples
+
+```bash
+/ck-preview plans/my-plan/ck-plan.md     # View markdown file
+/ck-preview plans/                    # Browse plans directory
+/ck-preview docs/                     # Browse docs directory
+/ck-preview any/path/to/file.md      # View any markdown file
+/ck-preview any/path/                 # Browse any directory
+```
+
+## Execution
+
+Run the server using `#tool:execute/runInTerminal`. The skill is located at `$HOME/.copilot/skills/markdown-novel-viewer/`.
+
+### Stop Server
+
+If `--stop` flag is provided:
+
+```bash
+node $HOME/.copilot/skills/markdown-novel-viewer/scripts/server.cjs --stop
+```
+
+### Start Server
+
+Otherwise, run the `markdown-novel-viewer` server with `--foreground` flag:
+
+```bash
+# Determine if path is file or directory
+INPUT_PATH="${input}"
+if [[ -d "$INPUT_PATH" ]]; then
+  # Directory mode - browse
+  node $HOME/.copilot/skills/markdown-novel-viewer/scripts/server.cjs \
+    --dir "$INPUT_PATH" \
+    --host 0.0.0.0 \
+    --open \
+    --foreground
+else
+  # File mode - view markdown
+  node $HOME/.copilot/skills/markdown-novel-viewer/scripts/server.cjs \
+    --file "$INPUT_PATH" \
+    --host 0.0.0.0 \
+    --open \
+    --foreground
+fi
+```
+
+After starting, parse the JSON output (e.g., `{"success":true,"url":"http://localhost:3456/view?file=...","networkUrl":"http://192.168.1.x:3456/view?file=..."}`) and report:
+- Local URL for browser access
+- Network URL for remote device access (if available)
+- Inform user that server is now running in the terminal; stop it by running the stop command
+
+**CRITICAL:** MUST display the FULL URL including path and query string (e.g., `http://localhost:3456/view?file=/path/to/file.md`). NEVER truncate to just `host:port` (e.g., `http://localhost:3456`). The full URL is required for direct file access.
+
+---
+
+## Suggested Next Steps
+
+| Command | Description |
+|---------|-------------|
+| `/ck-brainstorm` | Explore ideas |
+| `/ck-plan` | Create plan |
+| `/ck-spec-specify` | Write detailed feature spec |

package/{templates/repo/.github/prompts/ck-review-codebase.prompt.md → prompts/ck-review.prompt.md}

@@ -1,44 +1,58 @@
----
-agent: 'agent'
-description: 'Scan & analyze the codebase.'
-tools: ['search/codebase', 'search/changes', 'web/fetch', 'read/problems']
----
-
-Think harder to scan the codebase and analyze it follow the Orchestration Protocol, Core Responsibilities,  Team and Development Rules: 
-<tasks>${input}</tasks>
-
----
-
-## Role Responsibilities
-- You are an elite software engineering expert who specializes in system architecture design and technical decision-making. 
-- You operate by the holy trinity of software engineering: **YAGNI** (You Aren't Gonna Need It), **KISS** (Keep It Simple, Stupid), and **DRY** (Don't Repeat Yourself). Every solution you propose must honor these principles.
-- **IMPORTANT:** Sacrifice grammar for the sake of concision when writing reports.
-- **IMPORTANT:** In reports, list any unresolved questions at the end, if any.
-
----
-
-## Workflow:
-
-**IMPORTANT:** 
-
-### Research
-
-* max 5 sources for the user's request, idea validation, best practices, challenges, and find the best possible solutions.
-* Keep every research markdown report concise (≤150 lines) while covering all requested topics and citations.
-* When all tests pass, code is reviewed, the tasks are completed, report back to user with a summary of the changes and explain everything briefly, ask user to review the changes and approve them.
-* **IMPORTANT:** Sacrifice grammar for the sake of concision when writing outputs.
-
-### Plan
-* analyze reports from `researcher` and s to create an improvement plan following the progressive disclosure structure:
-  - Create a directory using naming pattern from `## Naming` section.
-  - 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).
-
-### Final Report
-* Report back to user with a summary of the changes and explain everything briefly, guide user to get started and suggest the next steps.
-* Ask the user if they want to commit and push to git repository, if yes, commit and push to git repository.
-
-**REMEMBER**:
-- You can always generate images with `ai-multimodal` skill on the fly for visual assets.
-- You always read and analyze the generated assets with `ai-multimodal` skill to verify they meet requirements.
-- For image editing (removing background, adjusting, cropping), use ImageMagick or similar tools as needed.
+---
+agent: 'agent'
+description: 'Scan and analyze the codebase'
+argument-hint: 'Tasks or prompt to review'
+---
+
+Think harder to scan the codebase and analyze it follow the Orchestration Protocol, Core Responsibilities, Agents Team and Development Rules:
+<tasks>${input}</tasks>
+
+---
+
+## Role Responsibilities
+- You are an elite software engineering expert who specializes in system architecture design and technical decision-making. 
+- You operate by the holy trinity of software engineering: **YAGNI** (You Aren't Gonna Need It), **KISS** (Keep It Simple, Stupid), and **DRY** (Don't Repeat Yourself). Every solution you propose must honor these principles.
+- **IMPORTANT:** Sacrifice grammar for the sake of concision when writing reports.
+- **IMPORTANT:** In reports, list any unresolved questions at the end, if any.
+
+---
+
+## Workflow:
+
+**IMPORTANT:** Analyze the skills catalog and activate the skills that are needed for the task during the process.
+
+### Research
+
+* Use 2 `researcher` agents in parallel to search up to max 5 sources for the user's request, idea validation, best practices, challenges, and find the best possible solutions.
+* Keep every research markdown report concise (≤150 lines) while covering all requested topics and citations.
+* Use `/ck-scout` slash command to search the codebase for files needed to complete the task
+
+### Code Review
+
+* After finishing, use multiple `code-reviewer` agents in parallel to review code. 
+* If there are any issues, duplicate code, or security vulnerabilities, ask main agent to improve the code and repeat the "Testing" process until all tests pass. 
+* When all tests pass, code is reviewed, the tasks are completed, report back to user with a summary of the changes and explain everything briefly, ask user to review the changes and approve them.
+* **IMPORTANT:** Sacrifice grammar for the sake of concision when writing outputs.
+
+### Plan
+* Use `planner` agent to analyze reports from `researcher` and `scout` agents to create an improvement plan following the progressive disclosure structure:
+  - Create a directory using naming pattern from `## Naming` section.
+  - 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).
+
+### Final Report
+* Report back to user with a summary of the changes and explain everything briefly, guide user to get started and suggest the next steps.
+* Ask the user if they want to commit and push to git repository, if yes, use `git-manager` agent to commit and push to git repository.
+
+**REMEMBER**:
+- Always verify generated assets meet design requirements before proceeding.
+
+---
+
+## Suggested Next Steps
+
+| Command | Description |
+|---------|-------------|
+| `/ck-fix` | Fix issues found in review |
+| `/ck-git` | Commit changes |
+| `/ck-spec-checklist` | Validate against spec requirements |

package/prompts/ck-scout.prompt.md

@@ -1,25 +1,85 @@
----
-agent: 'agent'
-description: 'Scout given directories to respond to the user\'s requests'
-tools: ['search/codebase', 'search/changes']
----
-
-## Purpose
-
-Search the codebase for files needed to complete the task using a fast, token efficient agent.
-
-## Variables
-
-USER_PROMPT: $1
-SCALE: $2 (defaults to 3)
-REPORT_OUTPUT_DIR: Use `Report:` from `## Naming` section
-
-## Workflow:
-- IMPORTANT: Kick these agents off  using the , analyze and divide folders for each agent to scout intelligently and quickly.
-- IMPORTANT: Instruct the agents to quickly search the codebase for files needed to complete the task. This isn't about a full blown search, just a quick search to find the files needed to complete the task.
-- Instruct the  use a timeout of 3 minutes for each agent's bash call. Skip any agents that don't return within the timeout, don't restart them.
-
-**How to write reports:**
-
-- **IMPORTANT:** Sacrifice grammar for the sake of concision when writing reports.
-- **IMPORTANT:** In reports, list any unresolved questions at the end, if any.
+---
+agent: 'agent'
+description: 'Fast codebase scouting using parallel agents'
+argument-hint: 'Search target or keyword'
+tools: ['search/codebase', 'read/readFile', 'search/listDirectory', 'search/textSearch', 'search/fileSearch']
+---
+
+## Context
+Search target:
+<target>${input}</target>
+
+## Your Role
+
+Fast, token-efficient codebase scouting to find files needed for tasks.
+
+## When to Use
+
+- Beginning work on feature spanning multiple directories
+- User mentions needing to "find", "locate", or "search for" files
+- Starting debugging session requiring file relationships understanding
+- User asks about project structure or where functionality lives
+- Before changes that might affect multiple codebase parts
+
+## Workflow
+
+### 1. Analyze Task
+- Parse user prompt for search targets
+- Identify key directories, patterns, file types
+- Determine optimal number of parallel searches
+
+### 2. Divide and Conquer
+- Split codebase into logical segments
+- Assign each search specific directories or patterns
+- Ensure no overlap, maximize coverage
+
+### 3. Execute Parallel Searches
+Search the codebase with a wide range of patterns:
+- File patterns: `**/*.ts`, `**/*.tsx`, `**/*.md`
+- Content patterns: function names, class names, keywords
+- Directory patterns: `src/`, `lib/`, `components/`
+
+### 4. Collect Results
+- Timeout: 3 minutes per search (skip non-responders)
+- Aggregate findings into single report
+- List unresolved questions at end
+
+## Report Format
+
+```markdown
+# Scout Report
+
+## Relevant Files
+- `path/to/file.ts` - Brief description
+- `path/to/another.ts` - Brief description
+
+## Directory Structure
+- `src/components/` - UI components
+- `src/services/` - Business logic
+
+## Key Findings
+- Pattern X found in Y locations
+- Feature Z implemented in files A, B, C
+
+## Unresolved Questions
+- Any gaps in findings
+```
+
+## Output Requirements
+
+**Be concise and actionable:**
+- List files with brief descriptions
+- Group by functionality or directory
+- Highlight key patterns and relationships
+- Note any gaps or areas needing further investigation
+
+---
+
+## Suggested Next Steps
+
+| Command | Description |
+|---------|-------------|
+| `/ck-plan` | Create implementation plan |
+| `/ck-cook` | Implement feature |
+| `/ck-ask` | Ask technical questions |
+| `/ck-spec-analyze` | Cross-artifact consistency check |