cokit-cli 1.0.8 → 1.2.0

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

@@ -1,57 +0,0 @@
----
-agent: 'agent'
-description: 'Write journal entries and archive specific plans or all plans'
-tools: ['search/codebase', 'search/changes']
----
-
-## 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 `${input}` 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` 
-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  with `_type="journal-writer"`  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
-Ask if user wants to proceed with archiving these plans, select specific plans to archive or all completed plans only.
-Ask if user wants to delete permanently or move to the `.s/archive` directory.
-
-### Step 4: Archive the plans
-Start archiving the plans based on the user's choice:
-- Move the plans to the `.s/archive` directory.
-- Delete the plans permanently: `rm -rf .s/<plan-1> .s/<plan-2> ...`
-
-### Step 5: Ask if user wants to commit the changes
-Ask if user wants to commit the changes with these options:
-- Stage and commit the changes (Use `/git:cm` )
-- Commit and push the changes (Use `/git:cp` )
-- 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/templates/repo/.github/prompts/ck-plan-ci.prompt.md

@@ -1,35 +0,0 @@
----
-agent: 'agent'
-description: 'Analyze Github Actions logs and provide a plan to fix the issues'
-tools: ['search/codebase', 'search/changes', 'web/fetch', 'web/githubRepo', 'read/problems']
----
-
-
-
-## Github Actions URL
- ${input}
-
-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 Notes
-- **IMPORTANT:** Ask the user for confirmation before implementing.
-- **IMPORTANT:** Sacrifice grammar for the sake of concision when writing outputs.
-- **IMPORTANT:** **Do not** start implementing.

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

@@ -1,66 +0,0 @@
----
-agent: 'agent'
-description: 'Create a CRO plan for the given content'
-tools: ['search/codebase', 'search/changes', 'web/fetch', 'read/problems']
----
-
-You are an expert in conversion optimization. Analyze the content based on the given issues:
-<issues>${input}</issues>
-
-
-
-**IMPORTANT:** 
-**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, 
-- 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`).
  - 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/templates/repo/.github/prompts/ck-plan-parallel.prompt.md

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

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

@@ -1,117 +0,0 @@
----
-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-review-codebase.prompt.md

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

@@ -1,35 +0,0 @@
----
-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-skill-add.prompt.md

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

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

@@ -1,29 +0,0 @@
----
-agent: 'agent'
-description: 'Create a new agent skill'
-tools: ['search/codebase', 'search/changes', 'web/fetch', 'read/problems']
----
-
-Ultrathink.
-Use `skill-creator` skill.
-
-## 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, 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.