cokit-cli 1.0.4 → 1.0.6

package/templates/repo/.github/prompts/ck-plan-parallel.prompt.md

@@ -0,0 +1,159 @@
+---
+agent: 'agent'
+description: 'Create detailed plan with parallel-executable phases'
+tools: ['search/codebase', 'search/changes', 'web/fetch', 'read/problems']
+---
+
+Think strategically about parallelization.
+
+
+## Your mission
+<task>
+${input}
+</task>
+
+## Workflow
+1. Create a directory using naming pattern from `## Naming` section in injected context.
+   Make sure you pass the directory path to every  during the process.
+2. Follow strictly to the "Plan Creation & Organization" rules of `planning` skill.
+3. Use multiple `researcher` agents (max 2 agents)  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`, ``, `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  <instructions>`  to search the codebase for files needed to complete the task.
+5. 
+6. 
+
+**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 :validate {plan-path}` |
+| `off` | Skip validation step entirely |
+
+**If mode is `prompt`:** Ask user with options above.
+**If user chooses validation or mode is `auto`:** Execute :validate {plan-path}` SlashCommand.
+
+## Special Requirements for Parallel Execution
+
+**CRITICAL:** The planner  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 
+
+**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}.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 
+- Execution strategy (e.g., "Phases 1-3 parallel, then Phase 4")
+- File ownership matrix (which phase owns which files)
+
+## 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 parallel execution command:
+
+**Example output:**
+```
+✅ Plan finalized: {plan-dir}/plan.md
+
+Parallel execution strategy:
+- Phases 1-3: Can run in parallel
+- Phase 4: Depends on 1-3
+
+Ready to implement? Run:
+- `/cook:parallel` - Execute phases in parallel
+- `/cook` - Execute phases sequentially
+```
+
+## Important Notes
+- **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/templates/repo/.github/prompts/ck-plan-two.prompt.md

@@ -0,0 +1,78 @@
+---
+agent: 'agent'
+description: 'Research & create an implementation plan with 2 approaches'
+tools: ['search/codebase', 'search/changes', 'web/fetch', 'read/problems']
+---
+
+Think harder.
+
+
+## Your mission
+create 2 detailed implementation plans for this following task:
+<task>
+ ${input}
+</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  during the process.
+2. Follow strictly to the "Plan Creation & Organization" rules of `planning` skill.
+3. Use multiple `researcher` agents  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. search the codebase for files needed to complete the task.
+5. 
+  **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. 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}
+  ---
+  ```
+
+## Clarification & Finalization Flow
+
+After creating the initial plans:
+
+1. **If questions exist** → List questions at the end of your response (max 3-5 questions)
+2. **After user chooses approach** → Update selected `plan.md` with clarified requirements
+3. **Finalize** → Confirm plan is complete and ready for implementation
+
+**Question format:**
+```
+## Questions before finalizing:
+1. Which approach do you prefer? (A or B)
+2. [Other questions]?
+...
+```
+
+## Next Steps Suggestion
+
+After plan is finalized, suggest the appropriate implementation command:
+
+| Task Type | Suggested Command |
+|-----------|-------------------|
+| Feature development | `/cook` or `/code` |
+| Bug fix | `/fix` |
+| Refactoring | `/refactor` |
+| Documentation | `/docs` |
+
+**Example output:**
+```
+✅ Plan finalized: {plan-dir}/plan.md (Approach A selected)
+
+Ready to implement? Run one of these:
+- `/cook` - Full-featured implementation with tests
+- `/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.

package/templates/repo/.github/prompts/ck-plan-validate.prompt.md

@@ -0,0 +1,117 @@
+---
+agent: 'agent'
+description: 'Validate plan with critical questions interview'
+tools: ['search/codebase', 'search/changes', 'read/problems']
+---
+
+## 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 :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 to user.
+
+**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 the plan:
+
+1. Add `## Validation Summary` section to `plan.md`:
+```markdown
+## Validation Summary
+
+**Validated:** {date}
+**Questions asked:** {count}
+
+### Confirmed Decisions
+- {decision 1}: {user choice}
+- {decision 2}: {user choice}
+
+### Action Items
+- [ ] {any changes needed based on answers}
+```
+
+2. If answers require plan changes, note them but **do not modify phase files** - just document what needs updating.
+
+## Output
+
+After validation completes, provide summary:
+- Number of questions asked
+- Key decisions confirmed
+- Any items flagged for plan revision
+- Recommendation: proceed to implementation or revise plan first
+
+## 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/templates/repo/.github/prompts/ck-plan.prompt.md

@@ -1,24 +1,80 @@
 ---
-mode: agent
-description: Create implementation plans before coding
+agent: 'agent'
+description: 'Intelligent plan creation with prompt enhancement'
+tools: ['search/codebase', 'search/changes', 'web/fetch', 'read/problems']
 ---
 
-# Plan - Implementation Planning
+## Your mission
+<task>
+${input}
+</task>
 
-You are a technical planner. Help create a clear plan before implementation.
+## Pre-Creation Check (Active vs Suggested Plan Detection)
 
-## Approach
+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.
 
-1. **Understand requirements** - What needs to be built?
-2. **Explore codebase** - What exists? What patterns to follow?
-3. **Design solution** - How will it work?
-4. **Break down tasks** - What are the steps?
-5. **Identify risks** - What could go wrong?
+## 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>`
 
-## Output Format
+**Note:** The `detailed-instructions-prompt` must describe the task in detail based on user's input.
 
-Create a markdown plan with:
-- Overview
-- Tasks (numbered, specific)
-- Dependencies
-- Risks/considerations
+## 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 | `/cook` or `/code` |
+| Bug fix | `/fix` |
+| Refactoring | `/refactor` |
+| Documentation | `/docs` |
+
+**Example output:**
+```
+✅ Plan finalized: {plan-dir}/plan.md
+
+Ready to implement? Run one of these:
+- `/cook` - Full-featured implementation with tests
+- `/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.

package/templates/repo/.github/prompts/ck-preview.prompt.md

@@ -0,0 +1,65 @@
+---
+agent: 'agent'
+description: 'Path to file or directory to preview'
+tools: ['search/codebase', 'read/terminalLastCommand']
+---
+
+Universal viewer using `markdown-novel-viewer` skill - pass ANY path and see it rendered nicely.
+
+## Usage
+
+- `/preview <file.md>` - View markdown file in novel-reader UI
+- `/preview <directory/>` - Browse directory contents
+- `/preview --stop` - Stop running server
+
+## Examples
+
+```bash
+/preview plans/my-plan.md     # View markdown file
+/preview plans/                    # Browse plans directory
+/preview docs/                     # Browse docs directory
+/preview any/path/to/file.md      # View any markdown file
+/preview any/path/                 # Browse any directory
+```
+
+## Execution
+
+**IMPORTANT:**  This makes the server visible in `/tasks` and manageable via `KillShell`.
+
+Check if this script is located in the current workspace or in  directory:
+- If in current workspace: `$SKILL_DIR_PATH` = 
+- If in home directory: `$SKILL_DIR_PATH` = 
+
+### Stop Server
+
+If `--stop` flag is provided:
+
+```bash
+node $SKILL_DIR_PATH/scripts/server.cjs --stop
+```
+
+### Start Server
+
+Otherwise, run the `markdown-novel-viewer` server as CC background task with `--foreground` flag (keeps process alive for CC task management):
+
+```bash
+# Determine if path is file or directory
+INPUT_PATH="${path}"
+if [[ -d "$INPUT_PATH" ]]; then
+  # Directory mode - browse
+  node $SKILL_DIR_PATH/scripts/server.cjs \
+    --dir "$INPUT_PATH" \
+    --host 0.0.0.0 \
+    --open \
+    --foreground
+else
+  # File mode - view markdown
+  node $SKILL_DIR_PATH/scripts/server.cjs \
+    --file "$INPUT_PATH" \
+    --host 0.0.0.0 \
+    --open \
+    --foreground
+fi
+```
+
+**Critical:** 

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

@@ -0,0 +1,44 @@
+---
+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.

package/templates/repo/.github/prompts/ck-scout-ext.prompt.md

@@ -0,0 +1,35 @@
+---
+agent: 'agent'
+description: 'Use external agentic tools to scout given directories'
+tools: ['search/codebase', 'search/changes', 'read/terminalLastCommand']
+---
+
+## Purpose
+
+Utilize external agentic tools to scout given directories or explore the codebase for files needed to complete the task using a fast, token efficient agent.
+
+## Variables
+
+USER_PROMPT: $1
+SCALE: $2 (defaults to 3)
+RELEVANT_FILE_OUTPUT_DIR: Use `Report:` from `## Naming` section
+
+## Workflow:
+- 5-flash-preview-09-2025` (if count <= 3)
+  - `opencode run "[prompt]" --model opencode/grok-code` (if count > 3 and count < 6)
+  - if count >= 6, spawn s to search the codebase 
+
+**Why use external agentic tools?**
+- External agentic tools are faster and more efficient when using LLMs with large context windows (1M+ tokens).
+
+**How to prompt the agents:**
+- If `gemini` or `opencode` is not available, ask the user if they want to install it:
+  - If **yes**, install it (if there are permission issues, instruct the user to install it manually, including authentication steps)
+  - If **no**, use the default s.
+- IMPORTANT: Kick these agents off  using the , analyze and divide folders for each agent to scout intelligently and quickly.
+- IMPORTANT: These agents are calling OTHER agentic coding tools to search the codebase. DO NOT call any search tools yourself.
+- IMPORTANT: That means )
+- 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.
+- **IMPORTANT:** Sacrifice grammar for the sake of concision when writing reports.
+- **IMPORTANT:** In reports, list any unresolved questions at the end, if any.

package/templates/repo/.github/prompts/ck-scout.prompt.md

@@ -0,0 +1,25 @@
+---
+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.

package/templates/repo/.github/prompts/ck-skill-add.prompt.md

@@ -0,0 +1,36 @@
+---
+agent: 'agent'
+description: 'Add new reference files or scripts to a skill'
+tools: ['search/codebase', 'search/changes', 'web/fetch', 'read/problems']
+---
+
+Think harder.
+Use `skill-creator` skill.
+
+## Arguments
+$1: skill name (required, default: "")
+$2: reference or script prompt (required, default: "")
+If $1 or $2 is not provided, ask the user to provide it.
+
+## Your mission
+Add new reference files or scripts to a skill at  directory.
+
+## Requirements
+<reference-or-script-prompt>
+$2
+</reference-or-script-prompt>
+
+## Rules of Skill Creation:
+Base on the requirements:
+- Always keep in mind that `SKILL.md` and reference files should be token consumption efficient, so that **progressive disclosure** can be leveraged at best.
+- `SKILL.md` is always short and concise, straight to the point, treat it as a quick reference guide.
+- If you're given nothing, ask for clarifications and  to research about the topic.
+- If you're given an URL, it's documentation page, explore every internal link and .
+- If you receive a lot of URLs, use multiple s to explore them , .
+- If you receive a lot of files, use multiple s to explore them , .
+- If you're given a Github URL, use [](https://repomix.com/guide/usage) command to summarize ([install it](https://repomix.com/guide/installation) if needed) and spawn multiple s to explore it , .
+
+**IMPORTANT:**
+- Skills are not documentation, they are practical instructions for GitHub Copilot to use the tools, packages, plugins or APIs to achieve the tasks.
+- Each skill teaches GitHub Copilot how to perform a specific development task, not what a tool does.
+- GitHub Copilot can activate multiple skills automatically to achieve the user's request.