cokit-cli 1.0.4 → 1.0.5

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

@@ -0,0 +1,89 @@
+---
+agent: 'agent'
+description: 'Research, analyze, and create an implementation plan'
+tools: ['search/codebase', 'search/changes', 'web/fetch', 'read/problems']
+---
+
+Think harder.
+
+
+## Your mission
+<task>
+${input}
+</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  {plan-dir}`
+   If reusing: Use the active plan path from Plan 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`:** Use `AskUserQuestion` tool with options above.
+**If user chooses validation or mode is `auto`:** Execute :validate {plan-path}` SlashCommand.
+
+## 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 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:** 
+**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.

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

@@ -0,0 +1,126 @@
+---
+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`:** Use `AskUserQuestion` tool 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)
+
+## Important Notes
+**IMPORTANT:** 
+**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,43 @@
+---
+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}
+  ---
+  ```
+
+## Important Notes
+**IMPORTANT:** 
+**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,118 @@
+---
+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
+
+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 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,29 @@
----
-mode: agent
-description: Create implementation plans before coding
----
-
-# Plan - Implementation Planning
-
-You are a technical planner. Help create a clear plan before implementation.
-
-## Approach
-
-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?
-
-## Output Format
-
-Create a markdown plan with:
-- Overview
-- Tasks (numbered, specific)
-- Dependencies
-- Risks/considerations
- Note: `detailed-instructions-prompt` is **an enhanced prompt** that describes the task in detail based on the provided task description.
+---
+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 use `AskUserQuestion` tool to ask for more details if needed.
+- Decide to use :fast` or :hard` SlashCommands based on the complexity.
+- Execute SlashCommand: :fast <detailed-instructions-prompt>` or :hard <detailed-instructions-prompt>`
+
+## Important Notes
+**IMPORTANT:** 
+**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` and `claude-code` skills.
+
+## 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, use `AskUserQuestion` tool 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 Claude Code to use the tools, packages, plugins or APIs to achieve the tasks.
+- Each skill teaches Claude how to perform a specific development task, not what a tool does.
+- Claude Code can activate multiple skills automatically to achieve the user's request.

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

@@ -0,0 +1,29 @@
+---
+agent: 'agent'
+description: 'Create a new agent skill'
+tools: ['search/codebase', 'search/changes', 'web/fetch', 'read/problems']
+---
+
+Ultrathink.
+Use `skill-creator` and `claude-code` skills.
+
+## Your mission
+Create a new skill in  directory.
+
+## Requirements
+<user-prompt>${input}</user-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, use `AskUserQuestion` tool 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 Claude Code to use the tools, packages, plugins or APIs to achieve the tasks.
+- Each skill teaches Claude how to perform a specific development task, not what a tool does.
+- Claude Code can activate multiple skills automatically to achieve the user's request.