cokit-cli 1.2.6 → 1.3.0

package/skills/mcp-management/SKILL.md

@@ -1,6 +1,7 @@
 ---
 name: mcp-management
 description: Manage MCP servers - discover, analyze, execute tools/prompts/resources. Use for MCP integrations, intelligent tool selection, multi-server management, context-efficient capability discovery.
+argument-hint: "[task or server-name]"
 ---
 
 # MCP Management
@@ -15,7 +16,7 @@ MCP is an open protocol enabling AI agents to connect to external tools and data
 - Progressive disclosure of MCP capabilities (load only what's needed)
 - Intelligent tool/prompt/resource selection based on task requirements
 - Multi-server management from single config file
-- Context-efficient: agents handle MCP discovery and execution
+- Context-efficient: subagents handle MCP discovery and execution
 - Persistent tool catalog: automatically saves discovered tools to JSON for fast reference
 
 ## When to Use This Skill
@@ -25,17 +26,17 @@ Use this skill when:
 2. **Task-Based Tool Selection**: Analyzing which MCP tools are relevant for a specific task
 3. **Executing MCP Tools**: Calling MCP tools programmatically with proper parameter handling
 4. **MCP Integration**: Building or debugging MCP client implementations
-5. **Context Management**: Avoiding context pollution by delegating MCP operations to agents
+5. **Context Management**: Avoiding context pollution by delegating MCP operations to subagents
 
 ## Core Capabilities
 
 ### 1. Configuration Management
 
-MCP servers configured in `$HOME/.copilot/.mcp.json`.
+MCP servers configured in `.vscode/mcp.json`.
 
 **Gemini CLI Integration** (recommended): Create symlink to `.gemini/settings.json`:
 ```bash
-mkdir -p .gemini && ln -sf $HOME/.copilot/.mcp.json .gemini/settings.json
+mkdir -p .gemini && ln -sf .vscode/mcp.json .gemini/settings.json
 ```
 
 See [references/configuration.md](references/configuration.md) and [references/gemini-cli-integration.md](references/gemini-cli-integration.md).
@@ -80,7 +81,7 @@ echo "Take a screenshot of https://example.com" | gemini -y -m <gemini.model>
 npx tsx scripts/cli.ts call-tool memory create_entities '{"entities":[...]}'
 ```
 
-**Fallback: mcp-manager Agent**
+**Fallback: mcp-manager Subagent**
 
 See [references/gemini-cli-integration.md](references/gemini-cli-integration.md) for complete examples.
 
@@ -104,16 +105,16 @@ echo "Take a screenshot of https://example.com. Return JSON only per GEMINI.md i
 
 **Benefits**:
 - Automatic tool discovery
-- Structured JSON responses (parseable by the agent)
+- Structured JSON responses (parseable by AI)
 - GEMINI.md auto-loaded for consistent formatting
-- Faster than agent orchestration
+- Faster than subagent orchestration
 - No natural language ambiguity
 
 See [references/gemini-cli-integration.md](references/gemini-cli-integration.md) for complete guide.
 
-### Pattern 2: Agent-Based Execution (Fallback)
+### Pattern 2: Subagent-Based Execution (Fallback)
 
-Use `mcp-manager` agent when Gemini CLI unavailable. Agent discovers tools, selects relevant ones, executes tasks, reports back.
+Use `mcp-manager` agent when Gemini CLI unavailable. Subagent discovers tools, selects relevant ones, executes tasks, reports back.
 
 **Benefit**: Main context stays clean, only relevant tool definitions loaded when needed.
 
@@ -130,7 +131,7 @@ Coordinate tools across multiple servers. Each tool knows its source server for
 ### scripts/mcp-client.ts
 
 Core MCP client manager class. Handles:
-- Config loading from `$HOME/.copilot/.mcp.json`
+- Config loading from `.vscode/mcp.json`
 - Connecting to multiple MCP servers
 - Listing tools/prompts/resources across all servers
 - Executing tools with proper error handling
@@ -151,7 +152,7 @@ Command-line interface for MCP operations. Commands:
 **Method 1: Gemini CLI** (recommended)
 ```bash
 npm install -g gemini-cli
-mkdir -p .gemini && ln -sf $HOME/.copilot/.mcp.json .gemini/settings.json
+mkdir -p .gemini && ln -sf .vscode/mcp.json .gemini/settings.json
 # IMPORTANT: Use stdin piping, NOT -p flag (deprecated, skips MCP init)
 # GEMINI.md auto-loads to enforce JSON responses
 echo "Take a screenshot of https://example.com. Return JSON only per GEMINI.md instructions." | gemini -y -m <gemini.model>
@@ -161,12 +162,12 @@ Returns structured JSON: `{"server":"puppeteer","tool":"screenshot","success":tr
 
 **Method 2: Scripts**
 ```bash
-cd $HOME/.copilot/skills/mcp-management/scripts && npm install
+cd skills/mcp-management/scripts && npm install
 npx tsx cli.ts list-tools  # Saves to assets/tools.json
 npx tsx cli.ts call-tool memory create_entities '{"entities":[...]}'
 ```
 
-**Method 3: mcp-manager Agent**
+**Method 3: mcp-manager Subagent**
 
 See [references/gemini-cli-integration.md](references/gemini-cli-integration.md) for complete guide.
 
@@ -193,7 +194,7 @@ See [references/mcp-protocol.md](references/mcp-protocol.md) for:
    - Use when: Need specific tool/server control
    - Execute: `npx tsx scripts/cli.ts call-tool <server> <tool> <args>`
 
-3. **mcp-manager Agent** (Fallback): Context-efficient delegation
+3. **mcp-manager Subagent** (Fallback): Context-efficient delegation
    - Use when: Gemini unavailable or failed
    - Keeps main context clean
 
@@ -206,4 +207,4 @@ The `mcp-manager` agent uses this skill to:
 - Discover MCP capabilities without loading into main context
 - Report results back to main agent
 
-This keeps main agent context clean and enables efficient MCP integration.
+This keeps main agent context clean and enables efficient MCP integration.

package/skills/mcp-management/references/configuration.md

@@ -2,7 +2,7 @@
 
 ## Configuration File Structure
 
-MCP servers are configured in `$HOME/.copilot/.mcp.json`:
+MCP servers are configured in `.vscode/mcp.json`:
 
 ```json
 {
@@ -101,9 +101,9 @@ Reference env vars with `${VAR_NAME}` syntax:
 Scripts check for config in this order:
 
 1. `process.env` (runtime environment)
-2. `$HOME/.copilot/skills/mcp-management/.env`
-3. `$HOME/.copilot/skills/.env`
-4. `$HOME/.copilot/.env`
+2. `skills/mcp-management/.env`
+3. `skills/.env`
+4. `.env`
 
 ## Validation
 

package/skills/mcp-management/references/gemini-cli-integration.md

@@ -2,7 +2,7 @@
 
 ## Model Configuration
 
-Read model from `$HOME/.copilot/.ck.json`: `gemini.model` (default: `gemini-3.0-flash`)
+Read model from `.ck.json`: `gemini.model` (default: `gemini-3-flash-preview`)
 
 ## ⚠️ CRITICAL: Use Stdin Piping, NOT -p Flag
 
@@ -12,7 +12,7 @@ The `-p` flag is **deprecated** and skips MCP server initialization, causing too
 # ❌ WRONG - Deprecated -p flag skips MCP connections!
 gemini -y -m <gemini.model> -p "Take a screenshot"
 # Also wrong: Using --model instead of -m
-gemini -y -p "Take a screenshot" --model gemini-3.0-flash
+gemini -y -p "Take a screenshot" --model gemini-3-flash-preview
 
 # ✅ CORRECT - This initializes MCP servers
 echo "Take a screenshot" | gemini -y -m <gemini.model>
@@ -39,17 +39,17 @@ gemini --version
 
 ### Symlink Setup
 
-Gemini CLI reads MCP servers from `.gemini/settings.json`. Create a symlink to `$HOME/.copilot/.mcp.json`:
+Gemini CLI reads MCP servers from `.gemini/settings.json`. Create a symlink to `.vscode/mcp.json`:
 
 ```bash
 # Create .gemini directory
 mkdir -p .gemini
 
 # Create symlink (Unix/Linux/macOS)
-ln -sf $HOME/.copilot/.mcp.json .gemini/settings.json
+ln -sf .vscode/mcp.json .gemini/settings.json
 
 # Create symlink (Windows - requires admin or developer mode)
-mklink .gemini\settings.json .copilot\.mcp.json
+mklink .gemini\settings.json .vscode/mcp.json
 ```
 
 ### Security
@@ -74,8 +74,8 @@ echo "<prompt>" | gemini [flags]
 
 - `-y`: Skip confirmation prompts (auto-approve tool execution)
 - `-m <model>`: Model selection
-  - `gemini-3.0-flash` (fast, recommended for MCP)
-  - `gemini-3.0-flash` (balanced)
+  - `gemini-3-flash-preview` (fast, recommended for MCP)
+  - `gemini-3-pro-preview` (balanced)
   - `gemini-pro` (high quality)
 
 ### Examples
@@ -97,7 +97,7 @@ echo "Search for latest Next.js 15 features and summarize the top 3" | gemini -y
 
 **Multi-Tool Orchestration**:
 ```bash
-echo "Search for AI documentation, take a screenshot of the homepage, and save both to memory" | gemini -y -m <gemini.model>
+echo "Search for API documentation, take a screenshot of the homepage, and save both to memory" | gemini -y -m <gemini.model>
 ```
 
 **Browser Automation**:
@@ -107,7 +107,7 @@ echo "Navigate to https://example.com, click the signup button, and take a scree
 
 ## How It Works
 
-1. **Configuration Loading**: Reads `.gemini/settings.json` (symlinked to `$HOME/.copilot/.mcp.json`)
+1. **Configuration Loading**: Reads `.gemini/settings.json` (symlinked to `.vscode/mcp.json`)
 2. **Server Connection**: Connects to all configured MCP servers
 3. **Tool Discovery**: Lists all available tools from servers
 4. **Prompt Analysis**: Gemini model analyzes the prompt
@@ -119,7 +119,7 @@ echo "Navigate to https://example.com, click the signup button, and take a scree
 
 ### Trusted Servers (Skip Confirmations)
 
-Edit `$HOME/.copilot/.mcp.json`:
+Edit `.vscode/mcp.json`:
 
 ```json
 {
@@ -194,7 +194,7 @@ ls -la .gemini/settings.json
 dir .gemini\settings.json
 ```
 
-Should show symlink pointing to `$HOME/.copilot/.mcp.json`.
+Should show symlink pointing to `.vscode/mcp.json`.
 
 ### Debug Mode
 
@@ -212,7 +212,7 @@ Shows detailed MCP communication logs.
 | Direct Scripts | ⭐⭐ | ⭐⭐⭐ | ⭐⭐⭐ | Specific tools |
 | mcp-manager | ⭐ | ⭐⭐ | ⭐⭐⭐ | Fallback |
 
-**Recommendation**: Use Gemini CLI as primary method, fallback to scripts/agent when unavailable.
+**Recommendation**: Use Gemini CLI as primary method, fallback to scripts/subagent when unavailable.
 
 ## Resources
 

package/skills/mcp-management/scripts/.env.example

@@ -1,7 +1,7 @@
 # MCP Management Scripts Environment Variables
 
-# Path to MCP configuration file (optional, defaults to .copilot/.mcp.json)
-MCP_CONFIG_PATH=.copilot/.mcp.json
+# Path to MCP configuration file (optional, defaults to .vscode/mcp.json)
+MCP_CONFIG_PATH=.vscode/mcp.json
 
 # Logging level (optional, defaults to info)
 LOG_LEVEL=info

package/skills/mcp-management/scripts/dist/mcp-client.js

@@ -10,7 +10,7 @@ export class MCPClientManager {
     config = null;
     clients = new Map();
     transports = new Map();
-    async loadConfig(configPath = '$HOME/.copilot/.mcp.json') {
+    async loadConfig(configPath = '.vscode/mcp.json') {
         const fullPath = resolve(process.cwd(), configPath);
         const content = await readFile(fullPath, 'utf-8');
         const config = JSON.parse(content);

package/skills/mcp-management/scripts/mcp-client.ts

@@ -46,7 +46,7 @@ export class MCPClientManager {
   private clients: Map<string, Client> = new Map();
   private transports: Map<string, StdioClientTransport> = new Map();
 
-  async loadConfig(configPath: string = '$HOME/.copilot/.mcp.json'): Promise<MCPConfig> {
+  async loadConfig(configPath: string = '.vscode/mcp.json'): Promise<MCPConfig> {
     const fullPath = resolve(process.cwd(), configPath);
     const content = await readFile(fullPath, 'utf-8');
     const config = JSON.parse(content) as MCPConfig;

package/skills/mermaidjs-v11/SKILL.md

@@ -1,6 +1,7 @@
 ---
 name: mermaidjs-v11
 description: Create diagrams with Mermaid.js v11 syntax. Use for flowcharts, sequence diagrams, class diagrams, ER diagrams, Gantt charts, state diagrams, architecture diagrams, timelines, user journeys.
+argument-hint: "[diagram-type or description]"
 ---
 
 # Mermaid.js v11

package/skills/planning/SKILL.md

@@ -1,46 +1,86 @@
 ---
-name: planning
-description: Plan implementations, design architectures, create technical roadmaps with detailed phases. Use for feature planning, system design, solution architecture, implementation strategy, phase documentation.
+name: plan
+description: "Plan implementations, design architectures, create technical roadmaps with detailed phases. Use for feature planning, system design, solution architecture, implementation strategy, phase documentation."
+argument-hint: "[task] OR [archive|red-team|validate]"
+license: MIT
 ---
 
 # Planning
 
 Create detailed technical implementation plans through research, codebase analysis, solution design, and comprehensive documentation.
 
+**IMPORTANT:** Before you start, scan unfinished plans in the current project at `./plans/` directory, read the `plan.md`, if there are relevant plans with your upcoming plan, update them as well. If you're unsure or need more clarifications, use ask the user.
+
+### Cross-Plan Dependency Detection
+
+During the pre-creation scan, detect and mark blocking relationships between plans:
+
+1. **Scan** — Read `plan.md` frontmatter of each unfinished plan (status != `completed`/`cancelled`)
+2. **Compare scope** — Check overlapping files, shared dependencies, same feature area
+3. **Classify relationship:**
+   - New plan needs output of existing plan → new plan `blockedBy: [existing-plan-dir]`
+   - New plan changes something existing plan depends on → existing plan `blockedBy: [new-plan-dir]`, new plan `blocks: [existing-plan-dir]`
+   - Mutual dependency → both plans reference each other in `blockedBy`/`blocks`
+4. **Bidirectional update** — When relationship detected, update BOTH `plan.md` files' frontmatter
+5. **Ambiguous?** → Use asking the user with header "Plan Dependency", present detected overlap, ask user to confirm relationship type (blocks/blockedBy/none)
+
+**Frontmatter fields** (relative plan dir paths):
+```yaml
+blockedBy: [260301-1200-auth-system]     # This plan waits on these plans
+blocks: [260228-0900-user-dashboard]     # This plan blocks these plans
+```
+
+**Status interaction:** A plan with `blockedBy` entries where ANY blocker is not `completed` → plan status should note `blocked` in its overview. When all blockers complete, the blocked plan becomes unblocked automatically on next scan.
+
+## Default (No Arguments)
+
+If invoked with a task description, proceed with planning workflow. If invoked WITHOUT arguments or with unclear intent, use asking the user to present available operations:
+
+| Operation | Description |
+|-----------|-------------|
+| `(default)` | Create implementation plan for a task |
+| `archive` | Write journal entry & archive plans |
+| `red-team` | Adversarial plan review |
+| `validate` | Critical questions interview |
+
+Present as options by asking the user with header "Planning Operation", question "What would you like to do?".
+
 ## Workflow Modes
 
-Default: `--auto` — analyze the task and auto-pick the most appropriate mode.
+Default: `--auto` (analyze task complexity and auto-pick mode).
 
-| Flag | Research | Red Team | Validation | Cook Flag |
-|------|----------|----------|------------|-----------|
-| `--auto` | Auto | Auto | Auto | auto |
-| `--fast` | Skip | Skip | Skip | fast |
-| `--hard` | Full | Yes | Yes | hard |
-| `--parallel` | Parallel | Yes | Yes | parallel |
-| `--two` | Full | Yes | Yes | two |
+| Flag | Mode | Research | Red Team | Validation | Cook Flag |
+|------|------|----------|----------|------------|-----------|
+| `--auto` | Auto-detect | Follows mode | Follows mode | Follows mode | Follows mode |
+| `--fast` | Fast | Skip | Skip | Skip | `--auto` |
+| `--hard` | Hard | 2 researchers | Yes | Optional | (none) |
+| `--parallel` | Parallel | 2 researchers | Yes | Optional | `--parallel` |
+| `--two` | Two approaches | 2+ researchers | After selection | After selection | (none) |
 
-Add `--no-tasks` to any mode to skip todo checklist hydration after the plan is written.
+Add `--no-tasks` to skip task hydration in any mode.
 
-See `references/workflow-modes.md` for detailed mode behavior.
+Load: `references/workflow-modes.md` for auto-detection logic, per-mode workflows, context reminders.
 
 ## When to Use
 
-Use this skill when:
 - Planning new feature implementations
 - Architecting system designs
 - Evaluating technical approaches
 - Creating implementation roadmaps
 - Breaking down complex requirements
-- Assessing technical trade-offs
 
 ## Core Responsibilities & Rules
 
 Always honoring **YAGNI**, **KISS**, and **DRY** principles.
 **Be honest, be brutal, straight to the point, and be concise.**
 
+### 0. Scope Challenge
+Load: `references/scope-challenge.md`
+**Skip if:** `--fast` mode or trivial task (single file fix, <20 word description)
+
 ### 1. Research & Analysis
 Load: `references/research-phase.md`
-**Skip if:** Provided with researcher reports
+**Skip if:** Fast mode or provided with researcher reports
 
 ### 2. Codebase Understanding
 Load: `references/codebase-understanding.md`
@@ -55,109 +95,100 @@ Load: `references/plan-organization.md`
 ### 5. Task Breakdown & Output Standards
 Load: `references/output-standards.md`
 
+## Process Flow (Authoritative)
+
+```mermaid
+flowchart TD
+    A[Pre-Creation Check] --> B[Cross-Plan Scan]
+    B --> C[Scope Challenge]
+    C --> D[Mode Detection]
+    D -->|fast| E[Skip Research]
+    D -->|hard/parallel/two| F[Spawn Researchers]
+    E --> G[Codebase Analysis]
+    F --> G
+    G --> H[Write Plan via Planner]
+    H --> I{Red Team?}
+    I -->|Yes| J[Red Team Review]
+    I -->|No| K{Validate?}
+    J --> K
+    K -->|Yes| L[Validation Interview]
+    K -->|No| M[Hydrate Tasks]
+    L --> M
+    M --> N[Output Cook Command]
+    N --> O[Journal]
+```
+
+**This diagram is the authoritative workflow.** Prose sections below provide detail for each node.
+
 ## Workflow Process
 
-1. **Pre-Creation Check** → Check `## Plan Context` from hook injection; follow Active Plan State rules below.
-2. **Mode Detection** → Use explicit flag if provided; otherwise auto-detect based on task complexity.
-3. **Research Phase** → Spawn parallel researcher agents to investigate approaches (skip in `--fast` mode).
-4. **Codebase Analysis** → Read docs in `./docs`; activate `/ck-scout` if file relationships are unclear.
-5. **Plan Documentation** → Write comprehensive plan via `planner` agent using the directory structure below.
-6. **Red Team Review** → Spawn adversarial reviewers to challenge assumptions (`--hard`, `--parallel`, `--two` modes only). See `references/workflow-modes.md`.
-7. **Post-Plan Validation** → Use `/ck-plan-validate` to verify completeness and coherence (`--hard`, `--parallel`, `--two` modes only).
-8. **Hydrate Tasks** → Create a todo checklist from plan phases with dependency annotations (default on; skip with `--no-tasks` or fewer than 3 phases).
-9. **Context Reminder** → Output the cook command with the absolute plan path (MANDATORY): `Use plan at: {absolute-plan-dir-path}`
+1. **Pre-Creation Check** → Check Plan Context for active/suggested/none
+1b. **Cross-Plan Scan** → Scan unfinished plans, detect `blockedBy`/`blocks` relationships, update both plans
+1c. **Scope Challenge** → Run Step 0 scope questions, select mode (see `references/scope-challenge.md`)
+    **Skip if:** `--fast` mode or trivial task
+2. **Mode Detection** → Auto-detect or use explicit flag (see `workflow-modes.md`)
+3. **Research Phase** → Spawn researchers (skip in fast mode)
+4. **Codebase Analysis** → Read docs, scout if needed
+5. **Plan Documentation** → Write comprehensive plan via planner subagent
+6. **Red Team Review** → Run `/ck-plan red-team {plan-path}` (hard/parallel/two modes)
+7. **Post-Plan Validation** → Run `/ck-plan validate {plan-path}` (hard/parallel/two modes)
+8. **Hydrate Tasks** → Create Tasks from phases (default on, `--no-tasks` to skip)
+9. **Context Reminder** → Output cook command with absolute path (MANDATORY)
+10. **Journal** → Run `/ck-journal` to write a concise technical journal entry upon completion
 
 ## Output Requirements
+**IMPORTANT:** Invoke "/ck-project-organization" skill to organize the outputs.
 
 - DO NOT implement code - only create plans
 - Respond with plan file path and summary
 - Ensure self-contained plans with necessary context
 - Include code snippets/pseudocode when clarifying
-- Provide multiple options with trade-offs when appropriate
-- Fully respect the `./docs/development-rules.md` file.
+- Fully respect the `./docs/development-rules.md` file
 
 ## Task Management
 
-Plan files are persistent on disk. Todo checklists are session-scoped. Hydration bridges the gap by converting plan phases into trackable checklist items at plan-creation time.
+Plan files = persistent. Tasks = session-scoped. Hydration bridges the gap.
 
-- **Default:** Auto-hydrate after plan is written (create checklist with one item per phase).
-- **Skip with:** `--no-tasks` flag or when plan has fewer than 3 phases (3-Task Rule).
-- **Checklist format:** Include phase name, dependencies, and owning agent hint per item.
+**Default:** Auto-hydrate tasks after plan files are written. Skip with `--no-tasks`.
+**3-Task Rule:** <3 phases → skip task creation.
+**Fallback:** Task tools (`TaskCreate`/`TaskUpdate`/`TaskGet`/`TaskList`) are CLI-only — unavailable in VSCode extension. If they error, use `TodoWrite` for tracking. Plan files remain the source of truth; hydration is an optimization, not a requirement.
 
-See `references/task-management.md` for checklist schema and dependency notation.
+Load: `references/task-management.md` for hydration pattern, TaskCreate patterns, cook handoff protocol.
 
-### Important
-DO NOT create plans or reports in USER directory.
-ALWAYS create plans or reports in CURRENT WORKING PROJECT DIRECTORY.
-
-**Plan Directory Structure**
-IN CURRENT WORKING PROJECT DIRECTORY:
-```
-plans/
-└── {date}-plan-name/
-    ├── research/
-    │   ├── researcher-XX-report.md
-    │   └── ...
-    ├── reports/
-    │   ├── XX-report.md
-    │   └── ...
-    ├── scout/
-    │   ├── scout-XX-report.md
-    │   └── ...
-    ├── plan.md
-    ├── phase-XX-phase-name-here.md
-    └── ...
-```
+### Hydration Workflow
+1. Write plan.md + phase files (persistent layer)
+2. TaskCreate per phase with `addBlockedBy` chain (skip if Task tools unavailable)
+3. TaskCreate for critical/high-risk steps within phases (skip if Task tools unavailable)
+4. Metadata: phase, priority, effort, planDir, phaseFile
+5. Cook picks up via TaskList (same session) or re-hydrates (new session)
 
 ## Active Plan State
 
-Prevents version proliferation by tracking current working plan via session state.
-
-### Active vs Suggested Plans
-
-Check the `## Plan Context` section injected by hooks:
-- **"Plan: {path}"** = Active plan, explicitly set via `set-active-plan.cjs` — use this path for all reports
-- **"Suggested: {path}"** = Branch-matched hint only — do NOT auto-use
-- **"Plan: none"** = No active plan
+Check `## Plan Context` injected by hooks:
+- **"Plan: {path}"** → Active plan. Ask "Continue? [Y/n]"
+- **"Suggested: {path}"** → Branch hint only. Ask if activate or create new.
+- **"Plan: none"** → Create new using `Plan dir:` from `## Naming`
 
-### Rules
-
-1. **If "Plan:" shows a path**: Ask "Continue with existing plan? [Y/n]"
-2. **If "Suggested:" shows a path**: Inform user, ask if they want to activate or create new
-3. **If "Plan: none"**: Create new plan using naming from `## Naming` section
-4. **Update on create**: Run `node $HOME/.copilot/scripts/set-active-plan.cjs {plan-dir}`
-
-### Report Output Location
-
-All agents writing reports MUST:
-1. Check `## Naming` section injected by hooks for the computed naming pattern
-2. Active plans use plan-specific reports path
-3. Suggested plans use default reports path (not plan folder)
+Reports: Active plans → plan-specific path. Suggested → default path.
 
 ### Important
-DO NOT create plans or reports in USER directory.
-ALWAYS create plans or reports in CURRENT WORKING PROJECT DIRECTORY.
+**DO NOT** create plans or reports in USER directory.
+**MUST** create plans or reports in **THE CURRENT WORKING PROJECT DIRECTORY**.
 
-**Important:** Suggested plans do NOT get plan-specific reports — this prevents pollution of old plan folders.
+## Subcommands
+
+| Subcommand | Reference | Purpose |
+|------------|-----------|---------|
+| `/ck-plan archive` | `references/archive-workflow.md` | Archive plans + write journal entries |
+| `/ck-plan red-team` | `references/red-team-workflow.md` | Adversarial plan review with hostile reviewers |
+| `/ck-plan validate` | `references/validate-workflow.md` | Validate plan with critical questions interview |
 
 ## Quality Standards
 
-- Be thorough and specific
-- Consider long-term maintainability
+- Thorough and specific, consider long-term maintainability
 - Research thoroughly when uncertain
 - Address security and performance concerns
-- Make plans detailed enough for junior developers
+- Detailed enough for junior developers
 - Validate against existing codebase patterns
 
 **Remember:** Plan quality determines implementation success. Be comprehensive and consider all solution aspects.
-
-## References
-
-Load as needed:
-- `references/workflow-modes.md` - Mode behavior details and flag descriptions
-- `references/task-management.md` - Checklist schema, dependency notation, hydration rules
-- `references/research-phase.md` - Research phase execution
-- `references/codebase-understanding.md` - Codebase analysis steps
-- `references/solution-design.md` - Solution design process
-- `references/plan-organization.md` - Plan file structure and organization
-- `references/output-standards.md` - Task breakdown and output format standards

package/skills/planning/references/archive-workflow.md

@@ -0,0 +1,53 @@
+# Archive Workflow
+
+## 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 `$ARGUMENTS` 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 `/ck-journal` skill invocation
+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 Task tool with `subagent_type="journal-writer"` in parallel 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 `./plans/archive` directory.
+
+### Step 4: Archive the plans
+Start archiving the plans based on the user's choice:
+- Move the plans to the `./plans/archive` directory.
+- Delete the plans permanently: `rm -rf ./plans/<plan-1> ./plans/<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 `/ck-git` for commit flow)
+- Commit and push the changes (Use `/ck-git` for push flow)
+- 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
+- Only ask questions about genuine decision points
+- Sacrifice grammar for concision
+- List any unresolved questions at the end
+- Ensure token efficiency while maintaining high quality

package/skills/planning/references/codebase-understanding.md

@@ -5,7 +5,7 @@
 ## Core Activities
 
 ### Parallel Scout Agents
-- Use `/scout:ext` (preferred) or `/scout` (fallback) slash command to search the codebase for files needed to complete the task
+- Use `/ck-scout ext` (preferred) or `/ck-scout` (fallback) skill invocation to search the codebase for files needed to complete the task
 - Each scout locates files needed for specific task aspects
 - Wait for all scout agents to report back before analysis
 - Efficient for finding relevant code across large codebases