thanh-kit 2.5.0

package/templates/commands/plan/validate.md

@@ -0,0 +1,132 @@
+---
+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 the plan:
+
+1. Add `## Validation Summary` section to `plan.md`:
+
+```markdown
+## Validation Summary
+
+**Validated:** {date}
+**Questions asked:** {count}
+
+### Confirmed Decisions
+- {decision 1}: {user choice}
+- {decision 2}: {user choice}
+1
+### Action Items
+- [ ] {any changes needed based on answers}
+```
+
+
+1. If answers require plan changes, note them but **do not modify phase files** - just document what needs updating.
+
+## Output
+
+After validation completes, provide summary:
+
+- Number of questions asked
+- Key decisions confirmed
+- Any items flagged for plan revision
+- Recommendation: proceed to implementation or revise plan first
+
+## Importa
+nt 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.
+
+ultrathink

package/templates/commands/plan.md

@@ -0,0 +1,36 @@
+---
+description: ⚡⚡⚡ Intelligent plan creation with prompt enhancement
+argument-hint: [task]
+---
+
+## Your mission
+
+<task>
+$ARGUMENTS
+</task>
+
+## Pre-Creation Check (Active vs Suggested Plan Detection)
+
+Check the `## Plan Context` section in the injected context:
+
+- If "Plan:" shows a path → Active plan exists. Ask user: "Active plan found: {path}. Continue with this? [Y/n]"
+- If "Suggested:" shows a path → Branch-matched plan hint only. Ask user if they want to activate it or create new.
+- If "Plan: none" → Proceed to create new plan using naming pattern from `## Naming` section.
+
+## Workflow
+
+- Analyze the given task and use `AskUserQuestion` tool to ask for more details if needed.
+- Decide to use `/plan:fast` or `/plan:hard` SlashCommands based on the complexity.
+- Execute SlashCommand: `/plan:fast <detailed-instructions-prompt>` or `/plan:hard <detailed-instructions-prompt>`
+- Activate `planning` skill.
+- Note: `detailed-instructions-prompt` is **an enhanced prompt** that describes the task in detail based on the provided task description.
+
+## Important Notes
+
+**IMPORTANT:** Analyze the skills catalog and activate the skills that are needed for the task during the process.
+**IMPORTANT:** Sacrifice grammar for the sake of concision when writing reports.
+**IMPORTANT:** Ensure token efficiency while maintaining high quality.
+**IMPORTANT:** In reports, list any unresolved questions at the end, if any.
+**IMPORTANT**: **Do not** start implementing.
+
+ultrathink

package/templates/commands/pr.md

@@ -0,0 +1,49 @@
+# Create Pull Request: $ARGUMENTS
+
+Create a pull request with the standard EasyPlatform format.
+
+## Steps
+
+1. **Check current branch status:**
+   - Run `git status` to see all changes
+   - Run `git diff` to review modifications
+   - Ensure all changes are committed
+
+2. **Analyze commits:**
+   - Run `git log --oneline -10` to see recent commits
+   - Identify all commits to include in the PR
+
+3. **Create PR with standard format:**
+   ```
+   gh pr create --title "[Type] Brief description" --body "$(cat <<'EOF'
+   ## Summary
+   - Bullet points describing changes
+
+   ## Changes
+   - List of specific changes made
+
+   ## Test Plan
+   - [ ] Unit tests added/updated
+   - [ ] Manual testing completed
+   - [ ] No regressions introduced
+
+   ## Related Issues
+   - Closes #issue_number (if applicable)
+
+   Generated with Claude Code
+   EOF
+   )"
+   ```
+
+4. **PR Title Format:**
+   - `[Feature]` - New functionality
+   - `[Fix]` - Bug fix
+   - `[Refactor]` - Code improvement
+   - `[Docs]` - Documentation only
+   - `[Test]` - Test changes only
+
+## Notes
+
+- Ensure branch is pushed before creating PR
+- Target branch is usually `develop` or `master`
+- Add reviewers if specified in $ARGUMENTS

package/templates/commands/preview.md

@@ -0,0 +1,87 @@
+---
+description: Path to markdown file, plan directory, or plans collection
+arguments:
+  - name: path
+    description: Path to file or directory to preview
+    required: false
+---
+
+Universal viewer using `markdown-novel-viewer` skill - pass ANY path and see it rendered nicely.
+
+## Usage
+
+- `/preview <file.md>` - View markdown file in novel-reader UI
+- `/preview <directory/>` - Browse directory contents
+- `/preview --stop` - Stop running server
+
+## Examples
+
+```bash
+/preview plans/my-plan/plan.md     # View markdown file
+/preview plans/                    # Browse plans directory
+/preview docs/                     # Browse docs directory
+/preview any/path/to/file.md      # View any markdown file
+/preview any/path/                 # Browse any directory
+```
+
+## 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`.
+
+Check if this script is located in the current workspace or in `$HOME/.claude/skills/markdown-novel-viewer` directory:
+- If in current workspace: `$SKILL_DIR_PATH` = `./.claude/skills/markdown-novel-viewer/`
+- If in home directory: `$SKILL_DIR_PATH` = `$HOME/.claude/skills/markdown-novel-viewer/`
+
+### Stop Server
+
+If `--stop` flag is provided:
+
+```bash
+node $SKILL_DIR_PATH/scripts/server.cjs --stop
+```
+
+### Start Server
+
+Otherwise, run the `markdown-novel-viewer` server as CC background task with `--foreground` flag (keeps process alive for CC task management):
+
+```bash
+# Determine if path is file or directory
+INPUT_PATH="{{path}}"
+if [[ -d "$INPUT_PATH" ]]; then
+  # Directory mode - browse
+  node $SKILL_DIR_PATH/scripts/server.cjs \
+    --dir "$INPUT_PATH" \
+    --host 0.0.0.0 \
+    --open \
+    --foreground
+else
+  # File mode - view markdown
+  node $SKILL_DIR_PATH/scripts/server.cjs \
+    --file "$INPUT_PATH" \
+    --host 0.0.0.0 \
+    --open \
+    --foreground
+fi
+```
+
+**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/markdown-novel-viewer/scripts/server.cjs --dir \"path\" --host 0.0.0.0 --open --foreground",
+  "run_in_background": true,
+  "timeout": 300000,
+  "description": "Start preview server in background"
+}
+```
+
+After starting, parse the JSON output (e.g., `{"success":true,"url":"http://localhost:3456/view?file=...","networkUrl":"http://192.168.1.x:3456/view?file=..."}`) 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 (e.g., `http://localhost:3456/view?file=/path/to/file.md`). NEVER truncate to just `host:port` (e.g., `http://localhost:3456`). The full URL is required for direct file access.

package/templates/commands/release-notes.md

@@ -0,0 +1,144 @@
+# Generate Release Notes: $ARGUMENTS
+
+Generate or update release notes for a feature or PR.
+
+## Phase 1: Determine Source
+
+Parse input from: $ARGUMENTS
+
+**Source Options:**
+1. `--source=<path>` - Use feature documentation file
+2. `--compare=<base>:<head>` - Compare git branches
+3. `--investigate` - Manual investigation mode
+
+If no option specified, prompt for source.
+
+## Phase 2: Gather Information
+
+### Option A: From Feature Documentation
+```bash
+# Read the feature documentation
+cat <source-path>
+```
+
+Extract:
+- Feature name and description
+- Key capabilities
+- Technical implementation
+- API endpoints
+- UI components
+
+### Option B: From Branch Comparison
+```bash
+# Fetch latest
+git fetch origin
+
+# Get commits between branches
+git log origin/<base>...origin/<head> --oneline
+
+# Get file changes
+git diff origin/<base>...origin/<head> --stat
+
+# Get detailed diff
+git diff origin/<base>...origin/<head>
+```
+
+Extract:
+- Changed files
+- New features
+- Bug fixes
+- Breaking changes
+
+### Option C: Investigation Mode
+1. Ask user for feature scope
+2. Search codebase for relevant files
+3. Analyze implementation
+
+## Phase 3: Generate Release Note
+
+Create file at: `docs/release-notes/YYMMDD-<feature-slug>.md`
+
+**Filename Format:**
+- YY = 2-digit year
+- MM = 2-digit month
+- DD = 2-digit day
+- feature-slug = kebab-case feature name
+
+**Template:**
+```markdown
+# Release Notes: [Feature Name]
+
+**Date:** YYYY-MM-DD
+**Version:** X.Y.Z (if applicable)
+**Status:** Draft | Released
+
+---
+
+## Summary
+
+[One paragraph describing the feature and its value to users]
+
+## New Features
+
+- **[Feature 1]**: Brief description
+- **[Feature 2]**: Brief description
+
+## Improvements
+
+- **[Improvement 1]**: Brief description
+
+## Bug Fixes
+
+- **[Fix 1]**: Brief description
+
+## Breaking Changes
+
+> **Warning**: Breaking changes require migration
+
+- [Breaking change description and migration path]
+
+## Technical Details
+
+### Backend
+- [Service changes]
+- [API changes]
+
+### Frontend
+- [Component changes]
+- [UI changes]
+
+### Database
+- [Migration info]
+
+## Related Documentation
+
+- [Feature Documentation](../business-features/...)
+- [API Reference](../api/...)
+
+## Contributors
+
+- @contributor
+
+---
+
+*Generated with [Claude Code](https://claude.com/claude-code)*
+```
+
+## Phase 4: Review & Finalize
+
+1. Present the generated release note
+2. Ask for any corrections or additions
+3. Save the file
+
+## Examples
+
+```bash
+# From feature docs
+/release-notes kudos --source=docs/business-features/TextSnippet/detailed-features/README.KudosFeature.md
+
+# From branch comparison
+/release-notes employee-export --compare=feature/employee-export:develop
+
+# Investigation mode
+/release-notes authentication --investigate
+```

package/templates/commands/review/codebase.md

@@ -0,0 +1,49 @@
+---
+description: ⚡⚡⚡ Scan & analyze the codebase.
+argument-hint: [tasks-or-prompt]
+---
+
+Think harder to scan the codebase and analyze it follow the Orchestration Protocol, Core Responsibilities, Subagents Team and Development Rules: 
+<tasks>$ARGUMENTS</tasks>
+
+---
+
+## Role Responsibilities
+- You are an elite software engineering expert who specializes in system architecture design and technical decision-making. 
+- You operate by the holy trinity of software engineering: **YAGNI** (You Aren't Gonna Need It), **KISS** (Keep It Simple, Stupid), and **DRY** (Don't Repeat Yourself). Every solution you propose must honor these principles.
+- **IMPORTANT:** Sacrifice grammar for the sake of concision when writing reports.
+- **IMPORTANT:** In reports, list any unresolved questions at the end, if any.
+
+---
+
+## Workflow:
+
+**IMPORTANT:** Analyze the skills catalog and activate the skills that are needed for the task during the process.
+
+### Research
+
+* Use 2 `researcher` subagents in parallel to search up to max 5 sources for the user's request, idea validation, best practices, challenges, and find the best possible solutions.
+* Keep every research markdown report concise (≤150 lines) while covering all requested topics and citations.
+* Use `/scout:ext` (preferred) or `/scout` (fallback) slash command to search the codebase for files needed to complete the task
+
+### Code Review
+
+* After finishing, use multiple `code-reviewer` subagents in parallel to review code. 
+* If there are any issues, duplicate code, or security vulnerabilities, ask main agent to improve the code and repeat the "Testing" process until all tests pass. 
+* When all tests pass, code is reviewed, the tasks are completed, report back to user with a summary of the changes and explain everything briefly, ask user to review the changes and approve them.
+* **IMPORTANT:** Sacrifice grammar for the sake of concision when writing outputs.
+
+### Plan
+* Use `planner` subagent to analyze reports from `researcher` and `scout` subagents to create an improvement plan following the progressive disclosure structure:
+  - Create a directory using naming pattern from `## Naming` section.
+  - Save the overview access point at `plan.md`, keep it generic, under 80 lines, and list each phase with status/progress and links.
+  - For each phase, add `phase-XX-phase-name.md` files containing sections (Context links, Overview with date/priority/statuses, Key Insights, Requirements, Architecture, Related code files, Implementation Steps, Todo list, Success Criteria, Risk Assessment, Security Considerations, Next steps).
+
+### Final Report
+* Report back to user with a summary of the changes and explain everything briefly, guide user to get started and suggest the next steps.
+* Ask the user if they want to commit and push to git repository, if yes, use `git-manager` subagent to commit and push to git repository.
+
+**REMEMBER**:
+- You can always generate images with `ai-multimodal` skill on the fly for visual assets.
+- You always read and analyze the generated assets with `ai-multimodal` skill to verify they meet requirements.
+- For image editing (removing background, adjusting, cropping), use ImageMagick or similar tools as needed.

package/templates/commands/review/post-task.md

@@ -0,0 +1,157 @@
+---
+description: ⚡⚡⚡ Two-pass code review for task completion
+argument-hint: [optional-focus-area]
+---
+
+# Post-Task Two-Pass Code Review
+
+Execute mandatory two-pass review protocol after completing code changes.
+Focus: $ARGUMENTS
+
+---
+
+## Protocol Overview
+
+This review ensures ALL code changes follow best practices and project conventions.
+Two passes guarantee corrections don't introduce new issues.
+
+---
+
+## Pass 1: Initial Review
+
+### Step 1.1: Gather Changes
+```bash
+# Get unstaged changes summary
+git diff --stat
+
+# Get detailed changes
+git diff
+```
+
+### Step 1.2: Review Checklist
+
+**Task Correctness:**
+- [ ] Changes achieve the intended task objective
+- [ ] No unrelated/unnecessary modifications
+- [ ] Edge cases handled appropriately
+- [ ] Error handling is complete
+
+**Code Standards (EasyPlatform):**
+
+*Backend:*
+- [ ] Uses platform repository (IPlatformQueryableRootRepository)
+- [ ] Uses PlatformValidationResult fluent API (.And(), .AndAsync())
+- [ ] Side effects in Entity Event Handlers, not command handlers
+- [ ] DTOs own mapping via MapToEntity()/MapToObject()
+- [ ] Command + Result + Handler in ONE file
+
+*Frontend:*
+- [ ] Extends appropriate base class (AppBaseComponent, AppBaseVmStoreComponent, AppBaseFormComponent)
+- [ ] Uses PlatformVmStore for state management
+- [ ] Uses .pipe(this.untilDestroyed()) for subscriptions
+- [ ] All template elements have BEM classes
+
+**Architecture:**
+- [ ] Logic placed in lowest appropriate layer (Entity > Service > Component)
+- [ ] No cross-service direct database access
+- [ ] Follows existing patterns found in codebase
+
+**Security:**
+- [ ] No hardcoded secrets or credentials
+- [ ] Input validation at boundaries
+- [ ] Proper authorization checks
+
+### Step 1.3: Execute Corrections
+If any issues found:
+1. Fix each issue directly
+2. Mark `PASS_1_MADE_CHANGES = true`
+3. Proceed to Pass 2
+
+If no issues found:
+1. Mark `PASS_1_MADE_CHANGES = false`
+2. Skip to Final Report
+
+---
+
+## Pass 2: Re-Review (Conditional)
+
+**ONLY EXECUTE IF PASS 1 MADE CHANGES**
+
+### Step 2.1: Verify All Changes
+```bash
+# Check updated changes
+git diff --stat
+git diff
+```
+
+### Step 2.2: Full Re-Review
+Repeat Pass 1 checklist on ALL current changes (original + corrections).
+
+Focus areas:
+- [ ] Original task still correctly implemented
+- [ ] Corrections are valid and complete
+- [ ] No new issues introduced by corrections
+- [ ] Code is production-ready
+
+### Step 2.3: Final Corrections
+If issues found:
+- Apply minimal, targeted fixes
+- Document any trade-offs made
+
+---
+
+## Final Report
+
+### Summary Template
+```markdown
+## Post-Task Review Complete
+
+**Task:** [Brief description]
+**Pass 1 Result:** [Clean / N issues fixed]
+**Pass 2 Required:** [Yes/No]
+**Pass 2 Result:** [N/A / Clean / N issues fixed]
+
+### Changes Summary
+- [List of files modified]
+- [Key changes made]
+
+### Issues Found & Fixed
+1. [Issue]: [Fix applied]
+2. ...
+
+### Remaining Concerns (if any)
+- [Concern]: [Reason not addressed / Recommended follow-up]
+
+### Verification
+- [ ] Task objective achieved
+- [ ] Code follows project conventions
+- [ ] No security vulnerabilities
+- [ ] Ready for commit
+```
+
+---
+
+## Quick Commands
+
+```bash
+# View changes for review
+git diff --stat && git diff
+
+# Check specific file
+git diff path/to/file.ts
+
+# Discard a problematic change
+git checkout -- path/to/file.ts
+
+# Stage reviewed changes
+git add -p  # Interactive staging
+```
+
+---
+
+## Integration Notes
+
+- This command is auto-triggered by workflow orchestration after `/cook`, `/fix`, `/code`
+- Can be manually invoked anytime with `/review:post-task`
+- For PR reviews, use `/review:codebase` instead
+- Use `code-reviewer` subagent for complex reviews requiring deeper analysis

package/templates/commands/review-changes.md

@@ -0,0 +1,46 @@
+---
+description: Review all uncommitted changes before commit
+allowed-tools: Bash, Read, Glob, Grep, TodoWrite
+---
+
+Review all uncommitted changes and provide feedback.
+
+## Steps:
+
+1. **Get Change Summary**
+   - Run `git status` to see all changed files
+   - Run `git diff` to see actual changes (staged and unstaged)
+
+2. **Analyze Each Changed File**
+   For each modified file, check:
+   - Does it follow platform patterns from CLAUDE.md?
+   - Any security concerns (hardcoded secrets, SQL injection, XSS)?
+   - Any performance issues (N+1 queries, missing async/await)?
+   - Proper error handling?
+   - Code style compliance?
+
+3. **Check for Common Issues**
+   - Unused imports or variables
+   - Console.log/Debug.WriteLine statements left in
+   - Hardcoded values that should be configuration
+   - Missing async/await keywords
+   - Incorrect exception handling
+   - Missing validation
+
+4. **Backend-Specific Checks**
+   - CQRS patterns followed correctly
+   - Repository usage (no direct DbContext access)
+   - Entity DTO mapping patterns
+   - Validation using PlatformValidationResult
+
+5. **Frontend-Specific Checks**
+   - Component base class inheritance correct
+   - State management patterns
+   - Memory leaks (missing unsubscribe)
+   - Template binding issues
+
+6. **Provide Summary**
+   - **Critical Issues**: Must fix before commit
+   - **Warnings**: Should consider fixing
+   - **Info**: Minor suggestions
+   - **Suggested commit message**: Based on changes