thanh-kit 2.5.4 → 2.5.6

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "thanh-kit",
-  "version": "2.5.4",
+  "version": "2.5.6",
   "description": "CLI tool to scaffold AI agent projects with pre-configured kits (Claude, OpenCode, Codex)",
   "type": "module",
   "bin": {

package/templates/command-archive/ask.md

@@ -0,0 +1,56 @@
+---
+description: ⚡ Answer technical and architectural questions.
+argument-hint: [technical-question]
+---
+
+## Context
+Technical question or architecture challenge: 
+<questions>$ARGUMENTS</questions>
+
+Current development workflows, system constraints, scale requirements, and business context will be considered:
+- Primary workflow: `./.claude/rules/primary-workflow.md`
+- Development rules: `./.claude/rules/development-rules.md`
+- Orchestration protocols: `./.claude/rules/orchestration-protocol.md`
+- Documentation management: `./.claude/rules/documentation-management.md`
+
+**Project Documentation:**
+```
+./docs
+├── project-overview-pdr.md
+├── code-standards.md
+├── codebase-summary.md
+├── design-guidelines.md
+├── deployment-guide.md
+├── system-architecture.md
+└── project-roadmap.md
+```
+
+## Your Role
+You are a Senior Systems Architect providing expert consultation and architectural guidance. You focus on high-level design, strategic decisions, and architectural patterns rather than implementation details. You orchestrate four specialized architectural advisors:
+1. **Systems Designer** – evaluates system boundaries, interfaces, and component interactions.
+2. **Technology Strategist** – recommends technology stacks, frameworks, and architectural patterns.
+3. **Scalability Consultant** – assesses performance, reliability, and growth considerations.
+4. **Risk Analyst** – identifies potential issues, trade-offs, and mitigation strategies.
+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.
+
+## Process
+1. **Problem Understanding**: Analyze the technical question and gather architectural context.
+   - If the architecture context doesn't contain the necessary information, use the `scout` skill to scout the codebase again.
+2. **Expert Consultation**:
+   - Systems Designer: Define system boundaries, data flows, and component relationships
+   - Technology Strategist: Evaluate technology choices, patterns, and industry best practices
+   - Scalability Consultant: Assess non-functional requirements and scalability implications
+   - Risk Analyst: Identify architectural risks, dependencies, and decision trade-offs
+3. **Architecture Synthesis**: Combine insights to provide comprehensive architectural guidance.
+4. **Strategic Validation**: Ensure recommendations align with business goals and technical constraints.
+
+## Output Format
+**Be honest, be brutal, straight to the point, and be concise.**
+1. **Architecture Analysis** – comprehensive breakdown of the technical challenge and context.
+2. **Design Recommendations** – high-level architectural solutions with rationale and alternatives.
+3. **Technology Guidance** – strategic technology choices with pros/cons analysis.
+4. **Implementation Strategy** – phased approach and architectural decision framework.
+5. **Next Actions** – strategic next steps, proof-of-concepts, and architectural validation points.
+
+## Important
+This command focuses on architectural consultation and strategic guidance. Do not start implementing anything.

package/templates/command-archive/ck-help.md

@@ -0,0 +1,129 @@
+---
+description: ClaudeKit usage guide - just type naturally
+argument-hint: [category|command|task description]
+---
+
+Think harder.
+All-in-one ClaudeKit guide. Run the script and present output based on type markers.
+
+## Intent Validation
+
+The script uses keyword matching with smart weighting. After getting results, **validate** against these heuristics:
+
+| Sentence Pattern | Primary Intent | Example |
+|------------------|----------------|---------|
+| `[action verb] my [object]` | The action verb | "commit my changes" → git |
+| `[context] [subject noun]` | The subject noun | "setup notifications" → notifications |
+| `[noun] [noun]` | Last noun (topic) | "discord webhook" → notifications |
+
+**Action verbs** (high intent when first): fix, test, commit, push, build, create, review, deploy, run, check, find, plan, refactor
+
+**Context words** (low intent, modify subject): setup, add, start, new, my, the, configure
+
+**Override script only if:** result clearly mismatches the sentence pattern above. Otherwise trust the algorithm.
+
+## Translation
+
+**IMPORTANT: Always translate `$ARGUMENTS` to English before passing to script.**
+
+The Python script only understands English keywords. If `$ARGUMENTS` is in another language:
+1. Translate `$ARGUMENTS` to English
+2. Pass the translated English string to the script
+
+## Execution
+
+```bash
+python .claude/scripts/ck-help.py "$ARGUMENTS"
+```
+
+## Output Type Detection
+
+The script outputs a type marker on the first line: `@CK_OUTPUT_TYPE:<type>`
+
+**Read this marker and adjust your presentation accordingly:**
+
+### `@CK_OUTPUT_TYPE:comprehensive-docs`
+
+Full documentation (config, schema, setup guides).
+
+**Presentation:**
+1. Show the **COMPLETE** script output verbatim - every section, every code block
+2. **THEN ADD** helpful context:
+   - Real-world usage examples ("For example, if you're working on multiple projects...")
+   - Common gotchas and tips ("Watch out for: ...")
+   - Practical scenarios ("This is useful when...")
+3. End with a specific follow-up question
+
+**Example enhancement after showing full output:**
+```
+## Additional Tips
+
+**When to use global vs local config:**
+- Use global (~/.claude/.ck.json) for personal preferences like language, issue prefix style
+- Use local (./.claude/.ck.json) for project-specific paths, naming conventions
+
+**Common setup for teams:**
+Each team member sets their locale globally, but projects share local config via git.
+
+Need help setting up a specific configuration?
+```
+
+### `@CK_OUTPUT_TYPE:category-guide`
+
+Workflow guides for command categories (fix, plan, cook, etc.).
+
+**Presentation:**
+1. Show the complete workflow and command list
+2. **ADD** practical context:
+   - When to use this workflow vs alternatives
+   - Real example: "If you encounter a bug in authentication, start with..."
+   - Transition tips between commands
+3. Offer to help with a specific task
+
+### `@CK_OUTPUT_TYPE:command-details`
+
+Single command documentation.
+
+**Presentation:**
+1. Show full command info from script
+2. **ADD**:
+   - Concrete usage example with realistic input
+   - When this command shines vs alternatives
+   - Common flags or variations
+3. Offer to run the command for them
+
+### `@CK_OUTPUT_TYPE:search-results`
+
+Search matches for a keyword.
+
+**Presentation:**
+1. Show all matches from script
+2. **HELP** user navigate:
+   - Group by relevance if many results
+   - Suggest most likely match based on context
+   - Offer to explain any specific command
+3. Ask what they're trying to accomplish
+
+### `@CK_OUTPUT_TYPE:task-recommendations`
+
+Task-based command suggestions.
+
+**Presentation:**
+1. Show recommended commands from script
+2. **EXPLAIN** the reasoning:
+   - Why these commands fit the task
+   - Suggested order of execution
+   - What each step accomplishes
+3. Offer to start with the first recommended command
+
+## Key Principle
+
+**Script output = foundation. Your additions = value-add.**
+
+Never replace or summarize the script output. Always show it fully, then enhance with your knowledge and context.
+
+## Important: Correct Workflows
+
+- **`/plan` → `/cook`**: Plan first, then execute the plan
+- **`/cook`**: Standalone - plans internally, no separate `/plan` needed
+- **NEVER** suggest `/plan` → `/cook` (cook has its own planning)

package/templates/command-archive/coding-level.md

@@ -0,0 +1,48 @@
+Set your coding experience level for tailored explanations and output format.
+
+## Usage
+
+`/coding-level [0-5]`
+
+## Levels
+
+| Level | Name | Description |
+|-------|------|-------------|
+| 0 | ELI5 | Zero coding experience - analogies, no jargon, step-by-step |
+| 1 | Junior | 0-2 years - concepts explained, WHY not just HOW |
+| 2 | Mid-Level | 3-5 years - design patterns, system thinking |
+| 3 | Senior | 5-8 years - trade-offs, business context, architecture |
+| 4 | Tech Lead | 8-10 years - risk assessment, business impact, strategy |
+| 5 | God Mode | Expert - default behavior, maximum efficiency (default) |
+
+## How It Works
+
+1. Set `codingLevel` in `.claude/.ck.json`
+2. Guidelines are **automatically injected** on every session start
+3. No manual activation needed - it just works!
+
+## Example
+
+Set level 1 in `.claude/.ck.json`:
+```json
+{
+  "codingLevel": 1,
+  ...
+}
+```
+
+Next session, Claude will automatically:
+- Explain concepts and techniques clearly
+- Always explain WHY, not just HOW
+- Point out common mistakes
+- Add "Key Takeaways" after implementations
+
+## Optional: Manual Output Styles
+
+For finer control, you can also use `/output-style` with these styles:
+- `coding-level-0-eli5`
+- `coding-level-1-junior`
+- `coding-level-2-mid`
+- `coding-level-3-senior`
+- `coding-level-4-lead`
+- `coding-level-5-god`

package/templates/command-archive/docs/init.md

@@ -0,0 +1,38 @@
+---
+description: ⚡⚡⚡⚡ Analyze the codebase and create initial documentation
+---
+
+## Phase 1: Parallel Codebase Scouting
+
+1. Scan the codebase and calculate the number of files with LOC in each directory (skip credentials, cache or external modules directories, such as `.claude`, `.opencode`, `.git`, `tests`, `node_modules`, `__pycache__`, `secrets`, etc.)
+2. Target directories **that actually exist** - adapt to project structure, don't hardcode paths
+3. Activate `scout` skill to explore the code base and return detailed summary reports to the main agent
+4. Merge scout reports into context summary
+
+## Phase 2: Documentation Creation (docs-manager Agent)
+
+**CRITICAL:** You MUST spawn `docs-manager` agent via Task tool with merged reports. Do not wait for user input.
+
+Pass the gathered context to docs-manager agent to create initial documentation:
+- `README.md`: Update README with initial documentation (keep it under 300 lines)
+- `docs/project-overview-pdr.md`: Project overview and PDR (Product Development Requirements)
+- `docs/codebase-summary.md`: Codebase summary
+- `docs/code-standards.md`: Codebase structure and code standards
+- `docs/system-architecture.md`: System architecture
+- `docs/project-roadmap.md`: Project roadmap
+- `docs/deployment-guide.md` [optional]: Deployment guide
+- `docs/design-guidelines.md` [optional]: Design guidelines
+
+Use `docs/` directory as the source of truth for documentation.
+
+## Phase 3: Size Check (Post-Generation)
+
+After docs-manager completes:
+1. Run `wc -l docs/*.md 2>/dev/null | sort -rn` to check LOC
+2. Use `docs.maxLoc` from session context (default: 800)
+3. For files exceeding limit:
+   - Report which files exceed and by how much
+   - docs-manager should have already split proactively per Section 6 guidelines
+   - If still oversized, ask user: split now or accept as-is?
+
+**IMPORTANT**: **Do not** start implementing.

package/templates/command-archive/docs/summarize.md

@@ -0,0 +1,22 @@
+---
+description: '⚡ Analyze the codebase and update documentation'
+argument-hint: '[focused-topics] [should-scan-codebase]'
+---
+
+Activate `scout` skill to analyze the codebase and update `docs/codebase-summary.md` and respond with a summary report.
+
+## Arguments:
+$1: Focused topics (default: all)
+$2: Should scan codebase (`Boolean`, default: `false`)
+
+## Focused Topics:
+<focused_topics>$1</focused_topics>
+
+## Should Scan Codebase:
+<should_scan_codebase>$2</should_scan_codebase>
+
+## Important:
+- Use `docs/` directory as the source of truth for documentation.
+- Do not scan the entire codebase unless the user explicitly requests it.
+
+**IMPORTANT**: **Do not** start implementing.

package/templates/command-archive/docs/update.md

@@ -0,0 +1,76 @@
+---
+description: ⚡⚡⚡ Analyze the codebase and update documentation
+---
+
+## Phase 1: Parallel Codebase Scouting
+
+1. Scan the codebase and calculate the number of files with LOC in each directory (skip credentials, cache or external modules directories, such as `.claude`, `.opencode`, `.git`, `tests`, `node_modules`, `__pycache__`, `secrets`, etc.)
+2. Target directories **that actually exist** - adapt to project structure, don't hardcode paths
+3. Activate `scout` skill to explore the code base and return detailed summary reports to the main agent
+4. Merge scout reports into context summary
+
+## Phase 1.5: Parallel Documentation Reading
+
+**You (main agent) must spawn readers** - subagents cannot spawn subagents.
+
+1. Count docs: `ls docs/*.md 2>/dev/null | wc -l`
+2. Get LOC: `wc -l docs/*.md 2>/dev/null | sort -rn`
+3. Strategy:
+   - 1-3 files: Skip parallel reading, docs-manager reads directly
+   - 4-6 files: Spawn 2-3 `Explore` agents
+   - 7+ files: Spawn 4-5 `Explore` agents (max 5)
+4. Distribute files by LOC (larger files get dedicated agent)
+5. Each agent prompt: "Read these docs, extract: purpose, key sections, areas needing update. Files: {list}"
+6. Merge results into context for docs-manager
+
+### Workload Distribution Example
+
+| Agent | Files | Est. LOC |
+|-------|-------|----------|
+| 1 | codebase-summary.md (800) | 800 |
+| 2 | system-architecture.md (400), code-standards.md (300) | 700 |
+| 3 | project-overview-pdr.md (500), project-roadmap.md (200) | 700 |
+
+## Phase 2: Documentation Update (docs-manager Agent)
+
+**CRITICAL:** You MUST spawn `docs-manager` agent via Task tool with merged reports and doc readings. Do not wait for user input.
+
+Pass the gathered context to docs-manager agent to update documentation:
+- `README.md`: Update README (keep it under 300 lines)
+- `docs/project-overview-pdr.md`: Update project overview and PDR (Product Development Requirements)
+- `docs/codebase-summary.md`: Update codebase summary
+- `docs/code-standards.md`: Update codebase structure and code standards
+- `docs/system-architecture.md`: Update system architecture
+- `docs/project-roadmap.md`: Update project roadmap
+- `docs/deployment-guide.md` [optional]: Update deployment guide
+- `docs/design-guidelines.md` [optional]: Update design guidelines
+
+## Additional requests
+<additional_requests>
+  $ARGUMENTS
+</additional_requests>
+
+## Phase 3: Size Check (Post-Update)
+
+After docs-manager completes:
+1. Run `wc -l docs/*.md 2>/dev/null | sort -rn` to check LOC
+2. Use `docs.maxLoc` from session context (default: 800)
+3. For files exceeding limit:
+   - Report which files exceed and by how much
+   - docs-manager should have already split proactively per Section 6 guidelines
+   - If still oversized, ask user: split now or accept as-is?
+
+## Phase 4: Documentation Validation (Post-Update)
+
+Run validation to detect potential hallucinations:
+1. Run: `node .claude/scripts/validate-docs.cjs docs/`
+2. Display validation report (warnings only, non-blocking)
+3. Checks performed:
+   - Code references: Verify `functionName()` and `ClassName` exist in codebase
+   - Internal links: Verify `[text](./path.md)` links point to existing files
+   - Config keys: Verify `ENV_VAR` mentioned in docs exist in `.env.example`
+
+## Important
+- Use `docs/` directory as the source of truth for documentation.
+
+**IMPORTANT**: **Do not** start implementing.

package/templates/command-archive/journal.md

@@ -0,0 +1,18 @@
+---
+description: ⚡ Write some journal entries.
+---
+
+## Writing Style Detection
+
+Before writing, check for a writing-styles directory:
+1. Check `docs/writing-styles/` — if exists, read all `.md` files inside
+2. Check `assets/writing-styles/` — if exists and step 1 not found, read all `.md` files inside
+3. If writing styles found → adopt tone, vocabulary, sentence structure, and formatting rules from those files
+4. If no writing-styles directory found → write freely in a natural, conversational tone
+
+## Journal Writing
+
+Use the `journal-writer` subagent to explore the memories and recent code changes, and write journal entries.
+- Concise, focused on important events, key changes, impacts, and decisions
+- Apply detected writing style (if any) to the journal voice
+- Keep journal entries in `docs/journal/` directory

package/templates/command-archive/kanban.md

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

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