thanh-kit 2.5.3 → 2.5.4

package/templates/command-archive/kanban.md

@@ -1,99 +0,0 @@
----
-description: 'AI agent orchestration board (Coming Soon)'
-arguments:
-  - name: dir
-    description: 'Plans directory (default: ./plans)'
-    required: false
----
-
-Plans dashboard with progress tracking and timeline visualization.
-
-## Usage
-
-- `/kanban` - View dashboard for ./plans directory
-- `/kanban plans/` - View dashboard for specific directory
-- `/kanban --stop` - Stop running server
-
-## Features
-
-- Plan cards with progress bars
-- Phase status breakdown (completed, in-progress, pending)
-- Timeline/Gantt visualization
-- Activity heatmap
-- Issue and branch links
-
-## Execution
-
-**IMPORTANT:** Run server as Claude Code background task using `run_in_background: true` with the Bash tool. This makes the server visible in `/tasks` and manageable via `KillShell`.
-
-The skill is located at `.claude/skills/plans-kanban/`.
-
-### Stop Server
-
-If `--stop` flag is provided:
-
-```bash
-node .claude/skills/plans-kanban/scripts/server.cjs --stop
-```
-
-### Start Server
-
-Otherwise, run the kanban server as CC background task with `--foreground` flag (keeps process alive for CC task management):
-
-```bash
-# Determine plans directory
-INPUT_DIR="{{dir}}"
-PLANS_DIR="${INPUT_DIR:-./plans}"
-
-# Start kanban dashboard
-node .claude/skills/plans-kanban/scripts/server.cjs \
-  --dir "$PLANS_DIR" \
-  --host 0.0.0.0 \
-  --open \
-  --foreground
-```
-
-**Critical:** When calling the Bash tool:
-- Set `run_in_background: true` to run as CC background task
-- Set `timeout: 300000` (5 minutes) to prevent premature termination
-- Parse JSON output and report URL to user
-
-Example Bash tool call:
-```json
-{
-  "command": "node .claude/skills/plans-kanban/scripts/server.cjs --dir \"./plans\" --host 0.0.0.0 --open --foreground",
-  "run_in_background": true,
-  "timeout": 300000,
-  "description": "Start kanban server in background"
-}
-```
-
-After starting, parse the JSON output (e.g., `{"success":true,"url":"http://localhost:3500/kanban?dir=...","networkUrl":"http://192.168.1.x:3500/kanban?dir=..."}`) and report:
-- Local URL for browser access
-- Network URL for remote device access (if available)
-- Inform user that server is now running as CC background task (visible in `/tasks`)
-
-**CRITICAL:** MUST display the FULL URL including path and query string. NEVER truncate to just `host:port`. The full URL is required for direct access.
-
-## Future Plans
-
-The `/kanban` command will evolve into **VibeKanban-inspired** AI agent orchestration:
-
-### Phase 1 (Current - MVP)
-- ✅ Task board with progress tracking
-- ✅ Visual representation of plans/tasks
-- ✅ Click to view plan details
-
-### Phase 2 (Worktree Integration)
-- Create tasks → spawn git worktrees
-- Assign agents to tasks
-- Track agent progress per worktree
-
-### Phase 3 (Full Orchestration)
-- Parallel agent execution monitoring
-- Code diff/review interface
-- PR creation workflow
-- Agent output streaming
-- Conflict detection
-
-Track progress: https://github.com/claudekit/claudekit-engineer/issues/189

package/templates/command-archive/plan/archive.md

@@ -1,57 +0,0 @@
----
-description: Write journal entries and archive specific plans or all plans
-argument-hint: [path-to-plan] (default: all plans)
----
-
-## 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 `/journal` slash command
-Use `AskUserQuestion` tool to 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
-Use `AskUserQuestion` tool to ask if user wants to proceed with archiving these plans, select specific plans to archive or all completed plans only.
-Use `AskUserQuestion` tool to 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
-Use `AskUserQuestion` tool to ask if user wants to commit the changes with these options:
-- Stage and commit the changes (Use `/git cm` slash command)
-- Commit and push the changes (Use `/git cp` slash command)
-- 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/command-archive/plan/red-team.md

@@ -1,200 +0,0 @@
----
-description: Adversarial plan review — spawn hostile reviewers to find flaws, security holes, false assumptions, failure modes
-argument-hint: [plan-path]
----
-
-## Your Mission
-
-Adversarially review an implementation plan by spawning parallel reviewer subagents that try to tear it apart. Each reviewer adopts a different hostile lens. You then adjudicate findings, and the user decides which to apply.
-
-**Mindset:** Like hiring someone who hates the implementer to destroy their work.
-
-## Plan Resolution
-
-1. If `$ARGUMENTS` 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 `/plan` first
-
-## Workflow
-
-### Step 1: Read Plan Files
-
-Read the plan directory:
-- `plan.md` — Overview, phases, dependencies
-- `phase-*.md` — All phase files (full content)
-- Note: architecture decisions, assumptions, scope, risks, implementation steps
-
-Collect all plan file paths for reviewers to read directly.
-
-### Step 2: Scale Reviewer Count
-
-Scale reviewers based on plan complexity:
-
-| Phase Count | Reviewers | Lenses Selected |
-|-------------|-----------|-----------------|
-| 1-2 phases | 2 | Security Adversary + Assumption Destroyer |
-| 3-5 phases | 3 | + Failure Mode Analyst |
-| 6+ phases | 4 | + Scope & Complexity Critic (all lenses) |
-
-### Step 3: Define Adversarial Lenses
-
-Available lenses (select per Step 2):
-
-| Reviewer | Lens | Focus |
-|----------|------|-------|
-| **Security Adversary** | Attacker mindset | Auth bypass, injection, data exposure, privilege escalation, supply chain, OWASP top 10 |
-| **Failure Mode Analyst** | Murphy's Law | Race conditions, data loss, cascading failures, recovery gaps, deployment risks, rollback holes |
-| **Assumption Destroyer** | Skeptic | Unstated dependencies, false "will work" claims, missing error paths, scale assumptions, integration assumptions |
-| **Scope & Complexity Critic** | YAGNI enforcer | Over-engineering, premature abstraction, unnecessary complexity, missing MVP cuts, scope creep, gold plating |
-
-### Step 4: Spawn Reviewers
-
-Launch reviewers simultaneously via Task tool with `subagent_type: "code-reviewer"`.
-
-**Each reviewer prompt MUST include:**
-1. This override: `"IGNORE your default code-review instructions. You are reviewing a PLAN DOCUMENT, not code. There is no code to lint, build, or test. Focus exclusively on plan quality."`
-2. Their specific adversarial lens and persona
-3. The plan file paths so they can read original files directly
-4. These instructions:
-
-```
-You are a hostile reviewer. Your job is to DESTROY this plan.
-Adopt the {LENS_NAME} perspective. Find every flaw you can.
-
-Rules:
-- Be specific: cite exact phase/section where the flaw lives
-- Be concrete: describe the failure scenario, not just "could be a problem"
-- Rate severity: Critical (blocks success) | High (significant risk) | Medium (notable concern)
-- Skip trivial observations (style, naming, formatting) — not worth reporting.
-- No praise. No "overall looks good". Only findings.
-- 5-10 findings per reviewer. Quality over quantity.
-
-Output format per finding:
-## Finding {N}: {title}
-- **Severity:** Critical | High | Medium
-- **Location:** Phase {X}, section "{name}"
-- **Flaw:** {what's wrong}
-- **Failure scenario:** {concrete description of how this fails}
-- **Evidence:** {quote from plan or missing element}
-- **Suggested fix:** {brief recommendation}
-```
-
-### Step 5: Collect, Deduplicate & Cap
-
-After all reviewers complete:
-1. Collect all findings
-2. Deduplicate overlapping findings (merge if same root issue)
-3. Sort by severity: Critical → High → Medium
-4. **Cap at 15 findings:** Keep all Critical, top High by specificity, note dropped Medium count
-
-### Step 6: Adjudicate
-
-For each finding, the main agent evaluates and proposes a disposition:
-
-| Disposition | Meaning |
-|-------------|---------|
-| **Accept** | Valid flaw — plan should be updated |
-| **Reject** | False positive, acceptable risk, or already handled |
-
-**Adjudication format:**
-
-```markdown
-## Red Team Findings
-
-### Finding 1: {title} — {SEVERITY}
-**Reviewer:** {lens name}
-**Location:** {phase/section}
-**Flaw:** {description}
-**Failure scenario:** {concrete scenario}
-**Disposition:** Accept | Reject
-**Rationale:** {why accept/reject — be specific}
-```
-
-### Step 7: User Review
-
-Present the adjudicated findings to the user via `AskUserQuestion`:
-
-```
-Review red-team findings. Which dispositions do you want to change?
-```
-
-Options:
-- "Looks good, apply accepted findings" — proceed with current Accept/Reject
-- "Let me review each one" — walk through findings individually
-- "Reject all, plan is fine" — discard all findings
-
-**If "Let me review each one":**
-For each finding marked Accept, ask via `AskUserQuestion`:
-- "Apply this fix to the plan?"
-- Options: "Yes, apply" | "No, reject" | "Modify suggestion"
-
-**If "Modify suggestion":**
-Ask via `AskUserQuestion`: "Describe your modification to this finding's suggested fix:"
-(user provides free text via "Other" option)
-Record the modified suggestion in the finding's "Suggested fix" field.
-Set disposition to "Accept (modified)" in the Red Team Review table.
-
-### Step 8: Apply to Plan
-
-For each accepted finding:
-1. Locate the target phase file and section
-2. Add the fix/note inline with a marker:
-   ```markdown
-   <!-- Red Team: {finding title} — {date} -->
-   ```
-3. If finding requires new content, add to the most relevant section
-4. If finding requires removing/changing content, edit in place
-
-After applying, add a `## Red Team Review` section to `plan.md`.
-If section already exists (repeat run), **append** a new session block — never overwrite history.
-
-**Placement order in plan.md** (bottom of file):
-1. `## Red Team Review` (before validation)
-2. `## Validation Log` (after red-team)
-
-This ordering matches the execution sequence: red-team → validate.
-
-```markdown
-## Red Team Review
-
-### Session — {YYYY-MM-DD}
-**Findings:** {total} ({accepted} accepted, {rejected} rejected)
-**Severity breakdown:** {N} Critical, {N} High, {N} Medium
-
-| # | Finding | Severity | Disposition | Applied To |
-|---|---------|----------|-------------|------------|
-| 1 | {title} | Critical | Accept | Phase 2 |
-| 2 | {title} | High | Reject | — |
-```
-
-## Output
-
-After completion, provide summary:
-- Total findings by severity
-- Accepted vs rejected count
-- Files modified
-- Key risks addressed
-- Remaining concerns (if any rejected findings were borderline)
-
-## Next Steps (MANDATORY)
-
-After providing the summary, remind the user:
-
-> **Plan updated with red-team findings.** Consider running:
-> ```
-> /plan:validate {ABSOLUTE_PATH_TO_PLAN_DIR}/plan.md
-> ```
-> to re-validate decisions after changes, then:
-> ```
-> /cook --auto {ABSOLUTE_PATH_TO_PLAN_DIR}/plan.md
-> ```
-> to implement.
-
-## Important Notes
-
-**IMPORTANT:** Reviewers must be HOSTILE, not helpful. No softening language.
-**IMPORTANT:** Deduplicate aggressively — reviewers will find overlapping issues.
-**IMPORTANT:** Adjudication must be evidence-based. Don't reject valid findings to be nice.
-**IMPORTANT:** If plan has a Validation Log from `/plan:validate`, reviewers should check if validation answers introduced new assumptions.
-**IMPORTANT:** Sacrifice grammar for concision in reports.
-**IMPORTANT:** Reviewers read plan files directly — do NOT duplicate content in a summary.

package/templates/command-archive/plan/validate.md

@@ -1,188 +0,0 @@
----
-description: Validate plan with critical questions interview
-argument-hint: [plan-path]
----
-
-## 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 `$ARGUMENTS` 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 `/plan --hard` first
-
-## Configuration (from injected context)
-
-Check `## Plan Context` section for validation settings:
-- `mode` - Controls auto/prompt/off behavior
-- `questions` - Range like `3-8` (min-max)
-
-These values are automatically injected from user config. Use them as constraints.
-
-## Workflow
-
-### Step 1: Read Plan Files
-
-Read the plan directory:
-- `plan.md` - Overview and phases list
-- `phase-*.md` - All phase files
-- Look for decision points, assumptions, risks, tradeoffs
-
-### Step 2: Extract Question Topics
-
-Scan plan content for:
-
-| Category | Keywords to detect |
-|----------|-------------------|
-| **Architecture** | "approach", "pattern", "design", "structure", "database", "API" |
-| **Assumptions** | "assume", "expect", "should", "will", "must", "default" |
-| **Tradeoffs** | "tradeoff", "vs", "alternative", "option", "choice", "either/or" |
-| **Risks** | "risk", "might", "could fail", "dependency", "blocker", "concern" |
-| **Scope** | "phase", "MVP", "future", "out of scope", "nice to have" |
-
-### Step 3: Generate Questions
-
-For each detected topic, formulate a concrete question:
-
-**Question format rules:**
-- Each question must have 2-4 concrete options
-- Mark recommended option with "(Recommended)" suffix
-- Include "Other" option is automatic - don't add it
-- Questions should surface implicit decisions
-
-**Example questions:**
-
-```
-Category: Architecture
-Question: "How should the validation results be persisted?"
-Options:
-1. Save to plan.md frontmatter (Recommended) - Updates existing plan
-2. Create validation-answers.md - Separate file for answers
-3. Don't persist - Ephemeral validation only
-```
-
-```
-Category: Assumptions
-Question: "The plan assumes API rate limiting is not needed. Is this correct?"
-Options:
-1. Yes, rate limiting not needed for MVP
-2. No, add basic rate limiting now (Recommended)
-3. Defer to Phase 2
-```
-
-### Step 4: Interview User
-
-Use `AskUserQuestion` tool to present questions.
-
-**Rules:**
-- Use question count from `## Plan Context` → `Validation: mode=X, questions=MIN-MAX`
-- Group related questions when possible (max 4 questions per tool call)
-- Focus on: assumptions, risks, tradeoffs, architecture
-
-### Step 5: Document Answers
-
-After collecting answers, update `plan.md` with a detailed validation log. If a `## Validation Log` section already exists (from previous sessions), **append** a new session block — never overwrite history.
-
-1. Add or append to `## Validation Log` section in `plan.md`:
-
-```markdown
-## Validation Log
-
-### Session 1 — {YYYY-MM-DD}
-**Trigger:** {what prompted this validation — initial plan creation, re-validation after scope change, etc.}
-**Questions asked:** {count}
-
-#### Questions & Answers
-
-1. **[{Category}]** {full question text}
-   - Options: {A} | {B} | {C}
-   - **Answer:** {user's choice}
-   - **Custom input:** {verbatim "Other" text if user selected Other, otherwise omit this line}
-   - **Rationale:** {why this decision matters for implementation}
-
-2. **[{Category}]** {full question text}
-   - Options: {A} | {B} | {C}
-   - **Answer:** {user's choice}
-   - **Custom input:** {verbatim text, omit if N/A}
-   - **Rationale:** {why this matters}
-
-#### Confirmed Decisions
-- {decision}: {choice} — {brief why}
-
-#### Action Items
-- [ ] {specific change needed based on answers}
-
-#### Impact on Phases
-- Phase {N}: {what needs updating and why}
-```
-
-**Recording rules:**
-- **Full question text**: Copy the exact question asked, not a summary
-- **All options**: List every option that was presented
-- **Verbatim custom input**: If user selected "Other" and typed custom text, record it exactly as entered — this often contains critical context
-- **Rationale**: Explain why the decision affects implementation (helps future agents understand intent)
-- **Session numbering**: Increment session number from last existing session. First validation = Session 1
-- **Trigger**: State what prompted this validation round (initial, re-validation, scope change, etc.)
-
-2. If answers require plan changes, document them in `#### Impact on Phases` section.
-
-### Step 6: Propagate Changes to Phases (Auto-Apply)
-
-**Auto-propagate** validation decisions to affected phase files.
-
-**Process:**
-1. Parse "Impact on Phases" section → If empty, skip and report "No phase changes required"
-2. For each phase reference (accepts "Phase 2", "phase-02", "P2"):
-   - Glob for `phase-{N:02d}-*.md` → If missing, warn and skip
-   - Locate target section (exact → fuzzy → fallback to Key Insights)
-   - Apply change + add marker: `<!-- Updated: Validation Session N - {change} -->`
-   - Skip if same-session marker already exists (prevent duplication)
-
-**Section mapping:**
-| Change Type | Target Section |
-|-------------|----------------|
-| Requirements | Requirements |
-| Architecture | Architecture |
-| Scope | Overview / Implementation Steps |
-| Risk | Risk Assessment |
-| Unknown | Key Insights (new subsection) |
-
-**Error handling:** Best-effort — log warnings for missing files/sections, continue with others, report all in Output.
-
-## Output
-
-After validation completes, provide summary:
-- Number of questions asked
-- Key decisions confirmed
-- **Phase propagation results:**
-  - ✅ Files updated (with section names)
-  - ⚠️ Warnings (skipped phases, fallback sections)
-  - ❌ Errors (if any write failures)
-- Any items flagged for plan revision
-- Recommendation: proceed to implementation or revise plan first
-
-## Next Steps (MANDATORY)
-
-**IMPORTANT:** After providing the validation summary, you MUST remind the user with the **full absolute path**:
-
-> **Best Practice:** Run `/clear` before implementing to start with fresh context.
-> Then run:
-> ```
-> /cook --auto {ABSOLUTE_PATH_TO_PLAN_DIR}/plan.md
-> ```
-> *(Replace with actual absolute path, e.g., `/home/user/project/plans/260203-1234-feature/plan.md`)*
->
-> **Why `--auto`?** Plan was already validated - safe to skip review gates.
-> **Why absolute path?** After `/clear`, the new session loses context. Worktree paths won't be discoverable without the full path.
->
-> Fresh context helps Claude focus solely on implementation without planning context pollution, improving plan adherence.
-
-This reminder is **NON-NEGOTIABLE** - always output it at the end of validation with the actual absolute path.
-
-## 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.