cokit-cli 1.2.0 → 1.2.3

package/templates/repo/.github/prompts/ck-spec-analyze.prompt.md

@@ -1,9 +1,6 @@
 ---
 agent: 'agent'
 description: 'Cross-artifact consistency and quality analysis across spec, plan, and tasks'
-scripts:
-  sh: spec-kit/scripts/bash/check-prerequisites.sh --json --require-tasks --include-tasks
-  ps: spec-kit/scripts/powershell/check-prerequisites.ps1 -Json -RequireTasks -IncludeTasks
 ---
 
 ## User Input
@@ -16,13 +13,13 @@ You **MUST** consider the user input before proceeding (if not empty).
 
 ## Goal
 
-Identify inconsistencies, duplications, ambiguities, and underspecified items across the three core artifacts (`spec.md`, `plan.md`, `tasks.md`) before implementation. This command MUST run only after `/ck.spec.tasks` has successfully produced a complete `tasks.md`.
+Identify inconsistencies, duplications, ambiguities, and underspecified items across the three core artifacts (`spec.md`, `plan.md`, `tasks.md`) before implementation. This command MUST run only after `/ck-spec-tasks` has successfully produced a complete `tasks.md`.
 
 ## Operating Constraints
 
 **STRICTLY READ-ONLY**: Do **not** modify any files. Output a structured analysis report. Offer an optional remediation plan (user must explicitly approve before any follow-up editing commands would be invoked manually).
 
-**Constitution Authority**: The project constitution (`constitution.md` at project root) is **non-negotiable** within this analysis scope. Constitution conflicts are automatically CRITICAL and require adjustment of the spec, plan, or tasks—not dilution, reinterpretation, or silent ignoring of the principle. If a principle itself needs to change, that must occur in a separate, explicit constitution update outside `/ck.spec.analyze`.
+**Constitution Authority**: The project constitution (`constitution.md` at project root) is **non-negotiable** within this analysis scope. Constitution conflicts are automatically CRITICAL and require adjustment of the spec, plan, or tasks—not dilution, reinterpretation, or silent ignoring of the principle. If a principle itself needs to change, that must occur in a separate, explicit constitution update outside `/ck-spec-analyze`.
 
 ## Execution Steps
 
@@ -161,9 +158,9 @@ Output a Markdown report (no file writes) with the following structure:
 
 At end of report, output a concise Next Actions block:
 
-- If CRITICAL issues exist: Recommend resolving before `/ck.spec.implement`
+- If CRITICAL issues exist: Recommend resolving before `/ck-spec-implement`
 - If only LOW/MEDIUM: User may proceed, but provide improvement suggestions
-- Provide explicit command suggestions: e.g., "Run /ck.spec.specify with refinement", "Run /ck.spec.plan to adjust architecture", "Manually edit tasks.md to add coverage for 'performance-metrics'"
+- Provide explicit command suggestions: e.g., "Run /ck-spec-specify with refinement", "Run /ck-spec-plan to adjust architecture", "Manually edit tasks.md to add coverage for 'performance-metrics'"
 
 ### 8. Offer Remediation
 
@@ -196,8 +193,9 @@ Ask the user: "Would you like me to suggest concrete remediation edits for the t
 
 | Command | Description | When to Use |
 |---------|-------------|-------------|
-| `/ck.spec.implement` | Start implementation | Analysis passed, no critical issues |
-| `/ck.spec.clarify` | Clarify requirements | Analysis found ambiguities in spec |
-| `/ck.spec.tasks` | Regenerate tasks | Task coverage gaps identified |
+| `/ck-spec-implement` | Start implementation | Analysis passed, no critical issues |
+| `/ck-spec-clarify` | Clarify requirements | Analysis found ambiguities in spec |
+| `/ck-spec-tasks` | Regenerate tasks | Task coverage gaps identified |
+| `/ck-fix` | Fix issues found in analysis | Code-level bugs identified |
 
-**Workflow:** `/ck.spec.analyze` → fix issues → `/ck.spec.implement`
+**Workflow:** `/ck-spec-analyze` → fix issues → `/ck-spec-implement`

package/templates/repo/.github/prompts/ck-spec-checklist.prompt.md

@@ -1,9 +1,6 @@
 ---
 agent: 'agent'
 description: 'Generate a custom checklist for the current feature based on user requirements'
-scripts:
-  sh: spec-kit/scripts/bash/check-prerequisites.sh --json
-  ps: spec-kit/scripts/powershell/check-prerequisites.ps1 -Json
 ---
 
 ## Checklist Purpose: "Unit Tests for English"
@@ -97,7 +94,7 @@ You **MUST** consider the user input before proceeding (if not empty).
      - Format: `[domain].md`
      - If file exists, append to existing file
    - Number items sequentially starting from CHK001
-   - Each `/ck.spec.checklist` run creates a NEW file (never overwrites existing checklists)
+   - Each `/ck-spec-checklist` run creates a NEW file (never overwrites existing checklists)
 
    **CORE PRINCIPLE - Test the Requirements, Not the Implementation**:
    Every checklist item MUST evaluate the REQUIREMENTS THEMSELVES for:
@@ -215,7 +212,7 @@ You **MUST** consider the user input before proceeding (if not empty).
    - Actor/timing
    - Any explicit user-specified must-have items incorporated
 
-**Important**: Each `/ck.spec.checklist` command invocation creates a checklist file using short, descriptive names unless file already exists. This allows:
+**Important**: Each `/ck-spec-checklist` command invocation creates a checklist file using short, descriptive names unless file already exists. This allows:
 
 - Multiple checklists of different types (e.g., `ux.md`, `test.md`, `security.md`)
 - Simple, memorable filenames that indicate checklist purpose
@@ -303,8 +300,9 @@ Sample items:
 
 | Command | Description | When to Use |
 |---------|-------------|-------------|
-| `/ck.spec.clarify` | Clarify requirements | Checklist revealed gaps in spec |
-| `/ck.spec.plan` | Generate implementation plan | Checklist passed, spec is solid |
-| `/ck.spec.implement` | Start implementation | Plan exists, checklist validated |
+| `/ck-spec-clarify` | Clarify requirements | Checklist revealed gaps in spec |
+| `/ck-spec-plan` | Generate implementation plan | Checklist passed, spec is solid |
+| `/ck-spec-implement` | Start implementation | Plan exists, checklist validated |
+| `/ck-test` | Run tests to validate | Checklist passed, verify with tests |
 
-**Usage:** Run `/ck.spec.checklist [domain]` for focused validation (e.g., security, ux, api)
+**Usage:** Run `/ck-spec-checklist [domain]` for focused validation (e.g., security, ux, api)

package/templates/repo/.github/prompts/ck-spec-clarify.prompt.md

@@ -1,13 +1,6 @@
 ---
 agent: 'agent'
 description: 'Identify underspecified areas and ask targeted clarification questions'
-handoffs:
-  - label: Build Technical Plan
-    agent: ck.spec.plan
-    prompt: Create a plan for the spec. I am building with...
-scripts:
-  sh: spec-kit/scripts/bash/check-prerequisites.sh --json --paths-only
-  ps: spec-kit/scripts/powershell/check-prerequisites.ps1 -Json -PathsOnly
 ---
 
 ## User Input
@@ -22,7 +15,7 @@ You **MUST** consider the user input before proceeding (if not empty).
 
 Goal: Detect and reduce ambiguity or missing decision points in the active feature specification and record the clarifications directly in the spec file.
 
-Note: This clarification workflow is expected to run (and be completed) BEFORE invoking `/ck.spec.plan`. If the user explicitly states they are skipping clarification (e.g., exploratory spike), you may proceed, but must warn that downstream rework risk increases.
+Note: This clarification workflow is expected to run (and be completed) BEFORE invoking `/ck-spec-plan`. If the user explicitly states they are skipping clarification (e.g., exploratory spike), you may proceed, but must warn that downstream rework risk increases.
 
 Execution steps:
 
@@ -30,7 +23,7 @@ Execution steps:
    - `FEATURE_DIR`
    - `FEATURE_SPEC`
    - (Optionally capture `IMPL_PLAN`, `TASKS` for future chained flows.)
-   - If JSON parsing fails, abort and instruct user to re-run `/ck.spec.specify` or verify feature branch environment.
+   - If JSON parsing fails, abort and instruct user to re-run `/ck-spec-specify` or verify feature branch environment.
    - For single quotes in args like "I'm Groot", use escape syntax: e.g 'I'\''m Groot' (or double-quote if possible: "I'm Groot").
 
 2. Load the current spec file. Perform a structured ambiguity & coverage scan using this taxonomy. For each category, mark status: Clear / Partial / Missing. Produce an internal coverage map used for prioritization (do not output raw map unless no questions will be asked).
@@ -169,13 +162,13 @@ Execution steps:
    - Path to updated spec.
    - Sections touched (list names).
    - Coverage summary table listing each taxonomy category with Status: Resolved (was Partial/Missing and addressed), Deferred (exceeds question quota or better suited for planning), Clear (already sufficient), Outstanding (still Partial/Missing but low impact).
-   - If any Outstanding or Deferred remain, recommend whether to proceed to `/ck.spec.plan` or run `/ck.spec.clarify` again later post-plan.
+   - If any Outstanding or Deferred remain, recommend whether to proceed to `/ck-spec-plan` or run `/ck-spec-clarify` again later post-plan.
    - Suggested next command.
 
 Behavior rules:
 
 - If no meaningful ambiguities found (or all potential questions would be low-impact), respond: "No critical ambiguities detected worth formal clarification." and suggest proceeding.
-- If spec file missing, instruct user to run `/ck.spec.specify` first (do not create a new spec here).
+- If spec file missing, instruct user to run `/ck-spec-specify` first (do not create a new spec here).
 - Never exceed 5 total asked questions (clarification retries for a single question do not count as new questions).
 - Avoid speculative tech stack questions unless the absence blocks functional clarity.
 - Respect user early termination signals ("stop", "done", "proceed").
@@ -190,8 +183,8 @@ Context for prioritization: {ARGS}
 
 | Command | Description | When to Use |
 |---------|-------------|-------------|
-| `/ck.spec.plan` | Generate implementation plan | All clarifications resolved, spec is complete |
-| `/ck.spec.checklist` | Generate validation checklist | Need domain-specific requirements validation |
-| `/ck.spec.specify` | Update/rewrite spec | Major scope changes or new feature |
+| `/ck-spec-plan` | Generate implementation plan | All clarifications resolved, spec is complete |
+| `/ck-spec-checklist` | Generate validation checklist | Need domain-specific requirements validation |
+| `/ck-spec-specify` | Update/rewrite spec | Major scope changes or new feature |
 
-**Workflow:** `/ck.spec.specify` → `/ck.spec.clarify` → `/ck.spec.plan` → `/ck.spec.tasks` → `/ck.spec.implement`
+**Workflow:** `/ck-spec-specify` → `/ck-spec-clarify` → `/ck-spec-plan` → `/ck-spec-tasks` → `/ck-spec-implement`

package/templates/repo/.github/prompts/ck-spec-constitution.prompt.md

@@ -1,12 +1,6 @@
 ---
 agent: 'agent'
 description: 'Create or update the project constitution from principle inputs'
-handoffs:
-  - label: Build Specification
-    agent: ck.spec.specify
-    prompt: >-
-      Implement the feature specification based on the updated constitution. I
-      want to build...
 ---
 
 ## User Input
@@ -47,7 +41,7 @@ Follow this execution flow:
    - Read `spec-kit/templates/plan-template.md` and ensure any "Constitution Check" or rules align with updated principles.
    - Read `spec-kit/templates/spec-template.md` for scope/requirements alignment—update if constitution adds/removes mandatory sections or constraints.
    - Read `spec-kit/templates/tasks-template.md` and ensure task categorization reflects new or removed principle-driven task types (e.g., observability, versioning, testing discipline).
-   - Read each command file in `spec-kit/templates/commands/*.md` (including this one) to verify no outdated references (agent-specific names like CLAUDE only) remain when generic guidance is required.
+   - Read each command file in `spec-kit/templates/commands/*.md` (including this one) to verify no outdated references (agent-specific names only) remain when generic guidance is required.
    - Read any runtime guidance docs (e.g., `README.md`, `docs/quickstart.md`, or agent-specific guidance files if present). Update references to principles changed.
 
 5. Produce a Sync Impact Report (prepend as an HTML comment at top of the constitution file after update):
@@ -90,8 +84,9 @@ The template at `spec-kit/memory/constitution.md` should NOT be modified; always
 
 | Command | Description | When to Use |
 |---------|-------------|-------------|
-| `/ck.spec.specify` | Create feature spec | Constitution ready, start defining features |
-| `/ck.spec.plan` | Generate implementation plan | Update existing plan with new principles |
-| `/ck.spec.analyze` | Validate consistency | Check if existing artifacts align with constitution |
+| `/ck-spec-specify` | Create feature spec | Constitution ready, start defining features |
+| `/ck-spec-plan` | Generate implementation plan | Update existing plan with new principles |
+| `/ck-spec-analyze` | Validate consistency | Check if existing artifacts align with constitution |
+| `/ck-brainstorm` | Brainstorm project ideas | Early stage, exploring project direction |
 
-**Usage:** Run `/ck.spec.constitution` at project start to establish non-negotiable principles
+**Usage:** Run `/ck-spec-constitution` at project start to establish non-negotiable principles

package/templates/repo/.github/prompts/ck-spec-implement.prompt.md

@@ -1,9 +1,6 @@
 ---
 agent: 'agent'
 description: 'Execute the implementation plan by processing all tasks in tasks.md'
-scripts:
-  sh: spec-kit/scripts/bash/check-prerequisites.sh --json --require-tasks --include-tasks
-  ps: spec-kit/scripts/powershell/check-prerequisites.ps1 -Json -RequireTasks -IncludeTasks
 ---
 
 ## User Input
@@ -98,8 +95,8 @@ You **MUST** consider the user input before proceeding (if not empty).
    **Tool-Specific Patterns**:
    - **Docker**: `node_modules/`, `.git/`, `Dockerfile*`, `.dockerignore`, `*.log*`, `.env*`, `coverage/`
    - **ESLint**: `node_modules/`, `dist/`, `build/`, `coverage/`, `*.min.js`
-   - **Prettier**: `node_modules/`, `dist/`, `build/`, `coverage/`, `package-lock.json`, `yarn.lock`, `pnpm-lock.yaml`
-   - **Terraform**: `.terraform/`, `*.tfstate*`, `*.tfvars`, `.terraform.lock.hcl`
+   - **Prettier**: `node_modules/`, `dist/`, `build/`, `coverage/`, `package-lock.json`, `yarn.lock`, `pnpm-lock-yaml`
+   - **Terraform**: `.terraform/`, `*.tfstate*`, `*.tfvars`, `.terraform.lock-hcl`
    - **Kubernetes/k8s**: `*.secret.yaml`, `secrets/`, `.kube/`, `kubeconfig*`, `*.key`, `*.crt`
 
 5. Parse task structure and extract:
@@ -144,7 +141,7 @@ You **MUST** consider the user input before proceeding (if not empty).
 
 **Notes**:
 - This command supports both single-file (tasks.md only) and hybrid structure (tasks.md + tasks/phase-*.md)
-- If tasks are incomplete or missing, suggest running `/ck.spec.tasks` first to regenerate the task list
+- If tasks are incomplete or missing, suggest running `/ck-spec-tasks` first to regenerate the task list
 - Hybrid structure enables parallel work: multiple agents can work on different phase files simultaneously
 
 ---
@@ -153,8 +150,8 @@ You **MUST** consider the user input before proceeding (if not empty).
 
 | Command | Description | When to Use |
 |---------|-------------|-------------|
-| `/ck.test` | Run tests and analyze | Validate implementation against requirements |
-| `/ck.review` | Code review | Implementation complete, ready for QA |
-| `/ck.fix` | Fix issues | Tests failed or bugs discovered |
+| `/ck-test` | Run tests and analyze | Validate implementation against requirements |
+| `/ck-review` | Code review | Implementation complete, ready for QA |
+| `/ck-fix` | Fix issues | Tests failed or bugs discovered |
 
-**Workflow:** `/ck.spec.implement` → `/ck.test` → `/ck.review` → `/ck.git`
+**Workflow:** `/ck-spec-implement` → `/ck-test` → `/ck-review` → `/ck-git`

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

@@ -1,20 +1,6 @@
 ---
 agent: 'agent'
 description: 'Execute implementation planning workflow to generate design artifacts'
-handoffs:
-  - label: Create Tasks
-    agent: ck.spec.tasks
-    prompt: Break the plan into tasks
-    send: true
-  - label: Create Checklist
-    agent: ck.spec.checklist
-    prompt: Create a checklist for the following domain...
-scripts:
-  sh: spec-kit/scripts/bash/setup-plan.sh --json
-  ps: spec-kit/scripts/powershell/setup-plan.ps1 -Json
-agent_scripts:
-  sh: spec-kit/scripts/bash/update-agent-context.sh __AGENT__
-  ps: spec-kit/scripts/powershell/update-agent-context.ps1 -AgentType __AGENT__
 ---
 
 ## User Input
@@ -101,8 +87,9 @@ You **MUST** consider the user input before proceeding (if not empty).
 
 | Command | Description | When to Use |
 |---------|-------------|-------------|
-| `/ck.spec.tasks` | Generate executable tasks | Plan complete with data-model.md, contracts/ ready |
-| `/ck.spec.checklist` | Generate validation checklist | Need domain-specific QA before implementation |
-| `/ck.spec.analyze` | Cross-artifact analysis | After tasks generated, check consistency |
+| `/ck-spec-tasks` | Generate executable tasks | Plan complete with data-model.md, contracts/ ready |
+| `/ck-spec-checklist` | Generate validation checklist | Need domain-specific QA before implementation |
+| `/ck-spec-analyze` | Cross-artifact analysis | After tasks generated, check consistency |
+| `/ck-cook` | Quick flow — implement plan directly | Plan is simple, skip spec-tasks |
 
-**Workflow:** `/ck.spec.specify` → `/ck.spec.clarify` → `/ck.spec.plan` → `/ck.spec.tasks` → `/ck.spec.implement`
+**Workflow:** `/ck-spec-specify` → `/ck-spec-clarify` → `/ck-spec-plan` → `/ck-spec-tasks` → `/ck-spec-implement`

package/templates/repo/.github/prompts/ck-spec-specify.prompt.md

@@ -1,17 +1,6 @@
 ---
 agent: 'agent'
 description: 'Create or update the feature specification from a natural language description'
-handoffs:
-  - label: Build Technical Plan
-    agent: ck.spec.plan
-    prompt: Create a plan for the spec. I am building with...
-  - label: Clarify Spec Requirements
-    agent: ck.spec.clarify
-    prompt: Clarify specification requirements
-    send: true
-scripts:
-  sh: 'spec-kit/scripts/bash/create-new-feature.sh --json "{ARGS}"'
-  ps: 'spec-kit/scripts/powershell/create-new-feature.ps1 -Json "{ARGS}"'
 ---
 
 ## User Input
@@ -24,7 +13,7 @@ You **MUST** consider the user input before proceeding (if not empty).
 
 ## Outline
 
-The text the user typed after `/ck.spec.specify` in the triggering message **is** the feature description. Assume you always have it available in this conversation even if `{ARGS}` appears literally below. Do not ask the user to repeat it unless they provided an empty command.
+The text the user typed after `/ck-spec-specify` in the triggering message **is** the feature description. Assume you always have it available in this conversation even if `{ARGS}` appears literally below. Do not ask the user to repeat it unless they provided an empty command.
 
 Given that feature description, do this:
 
@@ -138,7 +127,7 @@ Given that feature description, do this:
       
       ## Notes
       
-      - Items marked incomplete require spec updates before `/ck.spec.clarify` or `/ck.spec.plan`
+      - Items marked incomplete require spec updates before `/ck-spec-clarify` or `/ck-spec-plan`
       ```
 
    b. **Run Validation Check**: Review the spec against each checklist item:
@@ -192,7 +181,7 @@ Given that feature description, do this:
 
    d. **Update Checklist**: After each validation iteration, update the checklist file with current pass/fail status
 
-7. Report completion with branch name, spec file path, checklist results, and readiness for the next phase (`/ck.spec.clarify` or `/ck.spec.plan`).
+7. Report completion with branch name, spec file path, checklist results, and readiness for the next phase (`/ck-spec-clarify` or `/ck-spec-plan`).
 
 **NOTE:** The script creates and checks out the new branch and initializes the spec file before writing.
 
@@ -265,6 +254,7 @@ Success criteria must be:
 
 | Command | Description | When to Use |
 |---------|-------------|-------------|
-| `/ck.spec.clarify` | Ask clarification questions | Spec has [NEEDS CLARIFICATION] markers or vague requirements |
-| `/ck.spec.plan` | Generate implementation plan | Spec is complete and ready for technical planning |
-| `/ck.spec.constitution` | Create project principles | Need to establish non-negotiable rules before planning |
+| `/ck-spec-clarify` | Ask clarification questions | Spec has [NEEDS CLARIFICATION] markers or vague requirements |
+| `/ck-spec-plan` | Generate implementation plan | Spec is complete and ready for technical planning |
+| `/ck-spec-constitution` | Create project principles | Need to establish non-negotiable rules before planning |
+| `/ck-brainstorm` | Brainstorm ideas first | Not sure what to build yet |

package/templates/repo/.github/prompts/ck-spec-tasks.prompt.md

@@ -1,18 +1,6 @@
 ---
 agent: 'agent'
 description: 'Generate actionable, dependency-ordered tasks.md from design artifacts'
-handoffs:
-  - label: Analyze For Consistency
-    agent: ck.spec.analyze
-    prompt: Run a project analysis for consistency
-    send: true
-  - label: Implement Project
-    agent: ck.spec.implement
-    prompt: Start the implementation in phases
-    send: true
-scripts:
-  sh: spec-kit/scripts/bash/check-prerequisites.sh --json
-  ps: spec-kit/scripts/powershell/check-prerequisites.ps1 -Json
 ---
 
 ## User Input
@@ -186,8 +174,8 @@ Every task MUST strictly follow this format:
 
 | Command | Description | When to Use |
 |---------|-------------|-------------|
-| `/ck.spec.analyze` | Cross-artifact consistency check | Before implementation, validate spec/plan/tasks alignment |
-| `/ck.spec.implement` | Execute implementation | All tasks validated, ready to code |
-| `/ck.spec.taskstoissues` | Create GitHub issues | Track tasks in GitHub project board |
+| `/ck-spec-analyze` | Cross-artifact consistency check | Before implementation, validate spec/plan/tasks alignment |
+| `/ck-spec-implement` | Execute implementation | All tasks validated, ready to code |
+| `/ck-cook` | Quick flow — implement without full spec | Simple tasks that don't need spec-implement |
 
-**Workflow:** `/ck.spec.specify` → `/ck.spec.clarify` → `/ck.spec.plan` → `/ck.spec.tasks` → `/ck.spec.implement`
+**Workflow:** `/ck-spec-specify` → `/ck-spec-clarify` → `/ck-spec-plan` → `/ck-spec-tasks` → `/ck-spec-implement`

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

@@ -4,7 +4,7 @@ description: 'Run tests locally and analyze the summary report'
 tools: ['execute/runInTerminal', 'execute/getTerminalOutput', 'execute/runTests', 'execute/testFailure', 'read/problems']
 ---
 
-Use the `tester` subagent to run tests locally and analyze the summary report.
+Use the `tester` agent to run tests locally and analyze the summary report.
 
 **IMPORTANT**: **Do not** start implementing.
 **IMPORTANT:** Analyze the skills catalog and activate the skills that are needed for the task during the process.
@@ -15,5 +15,7 @@ Use the `tester` subagent to run tests locally and analyze the summary report.
 
 | Command | Description |
 |---------|-------------|
-| `/ck.fix` | Analyze and fix issues |
-| `/ck.review` | Scan and analyze codebase |
+| `/ck-fix` | Analyze and fix issues |
+| `/ck-review` | Scan and analyze codebase |
+| `/ck-git` | Commit changes |
+| `/ck-spec-checklist` | Validate against spec requirements |

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

@@ -15,5 +15,7 @@ Analyze the overall impact and quality of the changes.
 
 | Command | Description |
 |---------|-------------|
-| `/ck.brainstorm` | Explore ideas |
-| `/ck.plan` | Create plan |
+| `/ck-brainstorm` | Explore ideas |
+| `/ck-plan` | Create plan |
+| `/ck-cook` | Implement feature |
+| `/ck-spec-specify` | Write detailed feature spec |

package/templates/repo/.github/skills/INSTALLATION.md

@@ -1,6 +1,6 @@
 # Skills Installation Guide
 
-This guide explains how to install dependencies for Claude Code skills.
+This guide explains how to install dependencies for skills.
 
 ## Overview
 
@@ -203,7 +203,7 @@ Skills respect environment variable loading priority:
 1. **process.env** (highest priority - runtime environment)
 2. **`$HOME/.copilot/skills/{skill-name}/.env`** (skill-specific config)
 3. **`$HOME/.copilot/skills/.env`** (shared skills config)
-4. **`$HOME/.copilot/.env`** (global Claude config)
+4. **`$HOME/.copilot/.env`** (global config)
 
 Example `.env` files are provided where needed (e.g., `devops/.env.example`).
 
@@ -308,4 +308,4 @@ If dependencies fail to install or scripts don't work:
 2. Verify system tools are installed and in PATH
 3. Check environment variables are set correctly
 4. Review skill's `SKILL.md` for additional setup instructions
-5. Open an issue: https://github.com/anthropics/claude-code/issues
+5. Open an issue on the project repository

package/templates/repo/.github/skills/README.md

@@ -1,17 +1,11 @@
 # Skills
-Skills are folders of instructions, scripts, and resources that Claude loads dynamically to improve performance on specialized tasks. Skills teach Claude how to complete specific tasks in a repeatable way, whether that's creating documents with your company's brand guidelines, analyzing data using your organization's specific workflows, or automating personal tasks.
-
-For more information, check out:
-- [What are skills?](https://support.claude.com/en/articles/12512176-what-are-skills)
-- [Using skills in Claude](https://support.claude.com/en/articles/12512180-using-skills-in-claude)
-- [How to create custom skills](https://support.claude.com/en/articles/12512198-creating-custom-skills)
-- [Equipping agents for the real world with Agent Skills](https://anthropic.com/engineering/equipping-agents-for-the-real-world-with-agent-skills)
+Skills are folders of instructions, scripts, and resources that the AI agent loads dynamically to improve performance on specialized tasks. Skills teach the AI agent how to complete specific tasks in a repeatable way, whether that's creating documents with your company's brand guidelines, analyzing data using your organization's specific workflows, or automating personal tasks.
 
 # About This Repository
 
-This repository contains example skills that demonstrate what's possible with Claude's skills system. These examples range from creative applications (art, music, design) to technical tasks (testing web apps, MCP server generation) to enterprise workflows (communications, branding, etc.).
+This repository contains example skills that demonstrate what's possible with the skills system. These examples range from creative applications (art, music, design) to technical tasks (testing web apps, MCP server generation) to enterprise workflows (communications, branding, etc.).
 
-Each skill is self-contained in its own directory with a `SKILL.md` file containing the instructions and metadata that Claude uses. Browse through these examples to get inspiration for your own skills or to understand different patterns and approaches.
+Each skill is self-contained in its own directory with a `SKILL.md` file containing the instructions and metadata that the AI agent uses. Browse through these examples to get inspiration for your own skills or to understand different patterns and approaches.
 
 The example skills in this repo are open source (Apache 2.0).
 
@@ -19,7 +13,7 @@ The example skills in this repo are open source (Apache 2.0).
 
 ## Disclaimer
 
-**These skills are provided for demonstration and educational purposes only.** While some of these capabilities may be available in Claude, the implementations and behaviors you receive from Claude may differ from what is shown in these examples. These examples are meant to illustrate patterns and possibilities. Always test skills thoroughly in your own environment before relying on them for critical tasks.
+**These skills are provided for demonstration and educational purposes only.** The implementations and behaviors you receive may differ from what is shown in these examples. These examples are meant to illustrate patterns and possibilities. Always test skills thoroughly in your own environment before relying on them for critical tasks.
 
 # Installation
 
@@ -69,34 +63,18 @@ This repository includes a diverse collection of example skills demonstrating di
 - **slack-gif-creator** - Create animated GIFs optimized for Slack's size constraints
 
 ## Development & Technical
-- **artifacts-builder** - Build complex claude.ai HTML artifacts using React, Tailwind CSS, and shadcn/ui components
+- **artifacts-builder** - Build complex HTML artifacts using React, Tailwind CSS, and shadcn/ui components
 - **mcp-server** - Guide for creating high-quality MCP servers to integrate external APIs and services
 - **webapp-testing** - Test local web applications using Playwright for UI verification and debugging
 
 ## Enterprise & Communication
-- **brand-guidelines** - Apply Anthropic's official brand colors and typography to artifacts
+- **brand-guidelines** - Apply brand colors and typography to artifacts
 - **internal-comms** - Write internal communications like status reports, newsletters, and FAQs
 - **theme-factory** - Style artifacts with 10 pre-set professional themes or generate custom themes on-the-fly
 
-# Try in Claude Code, Claude.ai, and the API
-
-## Claude Code
-You can register this repository as a Claude Code Plugin marketplace by running the following command in Claude Code:
-```
-/plugin marketplace add anthropics/skills
-```
-
-After installing the plugin, you can use the skill by just mentioning it. For instance, you can ask Claude Code to do something like: "use the pdf skill to extract the form fields from path/to/some-file.pdf"
-
-## Claude.ai
-
-These example skills are all already available to paid plans in Claude.ai. 
-
-To use any skill from this repository or upload custom skills, follow the instructions in [Using skills in Claude](https://support.claude.com/en/articles/12512180-using-skills-in-claude#h_a4222fa77b).
-
-## Claude API
+# Using Skills
 
-You can use Anthropic's pre-built skills, and upload custom skills, via the Claude API. See the [Skills API Quickstart](https://docs.claude.com/en/api/skills-guide#creating-a-skill) for more.
+You can use skills by mentioning them in conversation. For instance, you can ask the AI agent to do something like: "use the pdf skill to extract the form fields from path/to/some-file.pdf"
 
 # Creating a Basic Skill
 
@@ -110,7 +88,7 @@ description: A clear description of what this skill does and when to use it
 
 # My Skill Name
 
-[Add your instructions here that Claude will follow when this skill is active]
+[Add your instructions here that the AI agent will follow when this skill is active]
 
 ## Examples
 - Example usage 1
@@ -125,10 +103,10 @@ The frontmatter requires only two fields:
 - `name` - A unique identifier for your skill (lowercase, hyphens for spaces)
 - `description` - A complete description of what the skill does and when to use it
 
-The markdown content below contains the instructions, examples, and guidelines that Claude will follow. For more details, see [How to create custom skills](https://support.claude.com/en/articles/12512198-creating-custom-skills).
+The markdown content below contains the instructions, examples, and guidelines that the AI agent will follow.
 
 # Partner Skills
 
-Skills are a great way to teach Claude how to get better at using specific pieces of software. As we see awesome example skills from partners, we may highlight some of them here:
+Skills are a great way to teach the AI agent how to get better at using specific pieces of software. Here are some partner skills:
 
-- **Notion** - [Notion Skills for Claude](https://www.notion.so/notiondevs/Notion-Skills-for-Claude-28da4445d27180c7af1df7d8615723d0)
+- **Notion** - [Notion Skills](https://www.notion.so/notiondevs/Notion-Skills-28da4445d27180c7af1df7d8615723d0)

package/templates/repo/.github/skills/agent-browser/SKILL.md

@@ -1,7 +1,6 @@
 ---
 name: agent-browser
 description: AI-optimized browser automation CLI with context-efficient snapshots. Use for long autonomous sessions, self-verifying workflows, video recording, and cloud browser testing (Browserbase).
-license: Apache-2.0
 ---
 
 # agent-browser Skill

package/templates/repo/.github/skills/agent_skills_spec.md

@@ -27,7 +27,7 @@ The YAML frontmatter has 2 required properties:
     - Restricted to lowercase Unicode alphanumeric + hyphen
     - Must match the name of the directory containing the SKILL.md
 - `description` 
-    - Description of what the skill does and when Claude should use it
+    - Description of what the skill does and when the agent should use it
 
 There are 3 optional properties:
 
@@ -36,7 +36,7 @@ There are 3 optional properties:
     - We recommend keeping it short (either the name of a license or the name of a bundled license file)
 - `allowed-tools` 
     - A list of tools that are pre-approved to run
-    - Currently only supported in Claude Code
+    - Currently only supported in AI coding agents
 - `metadata`
     - A map from string keys to string values
     - Clients can use this to store additional properties not defined by the Agent Skills Spec

package/templates/repo/.github/skills/backend-development/SKILL.md

@@ -1,8 +1,6 @@
 ---
 name: backend-development
 description: Build backends with Node.js, Python, Go, C#/.NET (NestJS, FastAPI, Django, ASP.NET Core). Use for REST/GraphQL/gRPC APIs, auth (OAuth, JWT), databases, microservices, security (OWASP), Docker/K8s.
-license: MIT
-version: 1.0.0
 ---
 
 # Backend Development Skill

package/templates/repo/.github/skills/brainstorm/SKILL.md

@@ -1,8 +1,6 @@
 ---
 name: brainstorm
 description: Brainstorm solutions with trade-off analysis and brutal honesty. Use for ideation, architecture decisions, technical debates, feature exploration, feasibility assessment, design discussions.
-license: MIT
-version: 2.0.0
 ---
 
 # Brainstorming Skill
@@ -24,11 +22,11 @@ You operate by the holy trinity of software engineering: **YAGNI** (You Aren't G
 - Performance optimization and bottleneck identification
 
 ## Your Approach
-1. **Question Everything**: Use `AskUserQuestion` tool to ask probing questions to fully understand the user's request, constraints, and true objectives. Don't assume - clarify until you're 100% certain.
-2. **Brutal Honesty**: Use `AskUserQuestion` tool to provide frank, unfiltered feedback about ideas. If something is unrealistic, over-engineered, or likely to cause problems, say so directly. Your job is to prevent costly mistakes.
+1. **Question Everything**: Ask probing questions directly in your response to fully understand the user's request, constraints, and true objectives. Then stop and wait for user to answer. Don't assume - clarify until you're 100% certain.
+2. **Brutal Honesty**: Provide frank, unfiltered feedback about ideas directly in your response. If something is unrealistic, over-engineered, or likely to cause problems, say so directly. Your job is to prevent costly mistakes.
 3. **Explore Alternatives**: Always consider multiple approaches. Present 2-3 viable solutions with clear pros/cons, explaining why one might be superior.
-4. **Challenge Assumptions**: Use `AskUserQuestion` tool to question the user's initial approach. Often the best solution is different from what was originally envisioned.
-5. **Consider All Stakeholders**: Use `AskUserQuestion` tool to evaluate impact on end users, developers, operations team, and business objectives.
+4. **Challenge Assumptions**: Question the user's initial approach directly in your response. Often the best solution is different from what was originally envisioned. Wait for user input.
+5. **Consider All Stakeholders**: Ask the user about impact on end users, developers, operations team, and business objectives. Wait for response.
 
 ## Collaboration Tools
 - Consult the `planner` agent to research industry best practices and find proven solutions
@@ -41,13 +39,13 @@ You operate by the holy trinity of software engineering: **YAGNI** (You Aren't G
 
 ## Your Process
 1. **Scout Phase**: Use `scout` skill to discover relevant files and code patterns, read relevant docs in `<project-dir>/docs` directory, to understand the current state of the project
-2. **Discovery Phase**: Use `AskUserQuestion` tool to ask clarifying questions about requirements, constraints, timeline, and success criteria
+2. **Discovery Phase**: Ask clarifying questions about requirements, constraints, timeline, and success criteria directly in your response. Wait for user answers.
 3. **Research Phase**: Gather information from other agents and external sources
 4. **Analysis Phase**: Evaluate multiple approaches using your expertise and principles
-5. **Debate Phase**: Use `AskUserQuestion` tool to Present options, challenge user preferences, and work toward the optimal solution
+5. **Debate Phase**: Present options directly, challenge user preferences, and work toward the optimal solution. Wait for user input.
 6. **Consensus Phase**: Ensure alignment on the chosen approach and document decisions
 7. **Documentation Phase**: Create a comprehensive markdown summary report with the final agreed solution
-8. **Finalize Phase**: Use `AskUserQuestion` tool to ask if user wants to create a detailed implementation plan.
+8. **Finalize Phase**: Ask the user if they want to create a detailed implementation plan. Wait for response.
    - If `Yes`: Run `/plan` command with the brainstorm summary context as the argument to ensure plan continuity.
      **CRITICAL:** The invoked plan command will create `plan.md` with YAML frontmatter including `status: pending`.
    - If `No`: End the session.