thanh-kit 2.5.1 → 2.5.2

package/templates/commands/fix-issue.md

@@ -1,177 +0,0 @@
-# Fix GitHub Issue: $ARGUMENTS
-
-Fix a GitHub issue following the systematic debugging workflow based on the `bug-diagnosis` skill.
-
-**IMPORTANT**: Always use external memory at `ai_task_analysis_notes/issue-[number].ai_task_analysis_notes_temp.md` for structured analysis.
-
-## IMPORTANT: Anti-Hallucination Protocols
-
-Before any operation:
-
-1. "What assumptions am I making about this issue?"
-2. "Have I verified this with actual code evidence?"
-3. "Could I be wrong about the root cause?"
-
----
-
-## Phase 1: Fetch Issue Details
-
-1. **Get issue information:**
-
-    ```bash
-    gh issue view $ARGUMENTS
-    ```
-
-2. **Extract key information:**
-    - Issue title and description
-    - Labels (bug, feature, enhancement)
-    - Related PRs or issues
-    - Assignees and reviewers
-    - Stack traces or error messages
-
-3. **Create analysis notes** at `ai_task_analysis_notes/issue-[number].ai_task_analysis_notes_temp.md`
-
----
-
-## Phase 2: Understand the Issue
-
-1. **Analyze the issue:**
-    - What is the expected behavior?
-    - What is the actual behavior?
-    - Are there reproduction steps?
-    - Is there a stack trace or error message?
-
-2. **Search codebase for relevant code:**
-    - Use grep for error messages and keywords
-    - Search patterns: `.*EventHandler.*{Entity}`, `.*Consumer.*{Entity}`, etc.
-    - Find related entities/components
-    - Map the affected code paths
-
----
-
-## Phase 3: Evidence Gathering
-
-1. **Multi-pattern search:**
-    - Static imports and usages
-    - String literals (runtime/config references)
-    - Dynamic invocations (reflection, attributes)
-
-2. **Trace dependency chains:**
-    - Who calls this code?
-    - Who depends on this code?
-    - Cross-service message flows
-
-3. **Read actual implementations** (not just interfaces)
-
-4. **Document evidence** with file:line references
-
----
-
-## Phase 4: Root Cause Analysis
-
-Analyze across dimensions:
-
-1. **Technical**: Code defects, architectural issues
-2. **Business Logic**: Rule violations, validation failures
-3. **Data**: Corruption, integrity violations, race conditions
-4. **Integration**: API contract violations, cross-service failures
-5. **Environmental**: Configuration issues, deployment problems
-
-Document:
-
-- Potential root causes ranked by probability
-- Evidence with file:line references
-- Confidence level (High 90%+, Medium 70-89%, Low <70%)
-
----
-
-## Phase 5: Propose Fix
-
-1. **Design the fix:**
-    - Minimal changes principle
-    - Follow platform patterns from documentation
-    - Consider edge cases
-
-2. **Risk assessment:**
-    - Impact level (Low/Medium/High)
-    - Regression risk
-    - Affected components
-
-3. **Test plan:**
-    - Unit tests to add
-    - Manual testing steps
-    - Regression considerations
-
-4. **Rollback plan:**
-    - How to revert if fix causes issues
-
----
-
-## Phase 6: Wait for Approval
-
-**CRITICAL:** Present your analysis and proposed fix in this format:
-
-```markdown
-## Issue Analysis Complete - Approval Required
-
-### Issue
-
-#[number] - [title]
-
-### Root Cause Summary
-
-[Primary root cause with evidence at file:line]
-
-### Proposed Fix
-
-[Fix description with specific files and changes]
-
-### Risk Assessment
-
-- **Risk Level**: [Low/Medium/High]
-- **Regression Risk**: [assessment]
-
-### Confidence Level: [X%]
-
-### Files to Modify:
-
-1. `path/to/file.cs:line` - [change description]
-
-**Awaiting approval to proceed with implementation.**
-```
-
-**DO NOT** make any code changes without explicit user approval.
-
----
-
-## Phase 7: Implement Fix
-
-After approval:
-
-1. Make the code changes following platform patterns
-2. Add/update tests
-3. Verify fix works
-4. Create PR with issue reference using `gh pr create`
-
----
-
-## Quick Verification Checklist
-
-Before proposing any change:
-
-- [ ] Searched static imports?
-- [ ] Searched string literals?
-- [ ] Checked dynamic invocations?
-- [ ] Read actual implementations?
-- [ ] Traced dependencies?
-- [ ] Assessed what breaks?
-- [ ] Documented evidence?
-- [ ] Declared confidence?
-
-**If ANY unchecked → DO MORE INVESTIGATION**
-**If confidence < 90% → REQUEST USER CONFIRMATION**
-
----
-
-Use the `bug-diagnosis` skill for the complete debugging protocol.
-See `.github/AI-DEBUGGING-PROTOCOL.md` for comprehensive guidelines.

package/templates/commands/fix.md

@@ -1,43 +0,0 @@
----
-description: ⚡⚡ Analyze and fix issues [INTELLIGENT ROUTING]
-argument-hint: [issues]
----
-
-**Analyze issues and route to specialized fix command:**
-<issues>$ARGUMENTS</issues>
-
-## Decision Tree
-
-**1. Check for existing plan:**
-- If markdown plan exists → `/code <path-to-plan>`
-
-**2. Route by issue type:**
-
-**A) Type Errors** (keywords: type, typescript, tsc, type error)
-→ `/fix:types`
-
-**B) UI/UX Issues** (keywords: ui, ux, design, layout, style, visual, button, component, css, responsive)
-→ `/fix:ui <detailed-description>`
-
-**C) CI/CD Issues** (keywords: github actions, pipeline, ci/cd, workflow, deployment, build failed)
-→ `/fix:ci <github-actions-url-or-description>`
-
-**D) Test Failures** (keywords: test, spec, jest, vitest, failing test, test suite)
-→ `/fix:test <detailed-description>`
-
-**E) Log Analysis** (keywords: logs, error logs, log file, stack trace)
-→ `/fix:logs <detailed-description>`
-
-**F) Multiple Independent Issues** (2+ unrelated issues in different areas)
-→ `/fix:parallel <detailed-description>`
-
-**G) Complex Issues** (keywords: complex, architecture, refactor, major, system-wide, multiple components)
-→ `/fix:hard <detailed-description>`
-
-**H) Simple/Quick Fixes** (default: small bug, single file, straightforward)
-→ `/fix:fast <detailed-description>`
-
-## Notes
-- `detailed-description` = enhanced prompt describing issue in detail
-- If unclear, ask user for clarification before routing
-- Can combine routes: e.g., multiple type errors + UI issue → `/fix:parallel`

package/templates/commands/generate-dto.md

@@ -1,67 +0,0 @@
----
-description: Generate entity DTO from an existing entity
-allowed-tools: Read, Write, Glob, Grep, TodoWrite
----
-
-Generate DTO for entity: $ARGUMENTS
-
-## Instructions
-
-1. **Parse arguments**:
-   - Entity name (required): e.g., `Employee`, `TextSnippetText`
-   - Options: `--with-mapping` (include MapToEntity), `--minimal` (core props only)
-
-2. **Find the entity**:
-   - Search in `*.Domain/Entities/` folders
-   - Read the entity class to understand its properties
-
-3. **Generate DTO following platform patterns**:
-
-   Location: `*.Application/EntityDtos/<EntityName>Dto.cs`
-
-   Template:
-
-   ```csharp
-   public class {Entity}Dto : PlatformEntityDto<{Entity}, string>
-   {
-       // Empty constructor required
-       public {Entity}Dto() { }
-
-       // Constructor maps from entity
-       public {Entity}Dto({Entity} entity) : base(entity)
-       {
-           // Map core properties
-       }
-
-       // CORE PROPERTIES
-       public string? Id { get; set; }
-       // ... other properties from entity
-
-       // OPTIONAL LOAD PROPERTIES (for With* methods)
-       public RelatedDto? Related { get; set; }
-
-       // WITH* FLUENT METHODS
-       public {Entity}Dto WithRelated(RelatedEntity related)
-       {
-           Related = new RelatedDto(related);
-           return this;
-       }
-
-       // PLATFORM OVERRIDES
-       protected override object? GetSubmittedId() => Id;
-       protected override string GenerateNewId() => Ulid.NewUlid().ToString();
-       protected override {Entity} MapToEntity({Entity} entity, MapToEntityModes mode)
-       {
-           // Map DTO properties back to entity
-           return entity;
-       }
-   }
-   ```
-
-4. **Read the template file** for complete pattern:
-   - `.github/prompts/create-entity-dto.prompt.md`
-
-5. **After generation**:
-   - Show the generated DTO
-   - Ask if any properties should be excluded or modified
-   - Offer to create the file

package/templates/commands/git/cm.md

@@ -1,5 +0,0 @@
----
-description: Stage all files and create a commit.
----
-Use `git-manager` agent to stage all files and create a commit.
-**IMPORTANT: DO NOT push the changes to remote repository**

package/templates/commands/git/cp.md

@@ -1,4 +0,0 @@
----
-description: Stage, commit and push all code in the current branch
----
-Use `git-manager` agent to stage all files, create a meaningful commit based on the changes and push to remote repository.

package/templates/commands/git/merge.md

@@ -1,40 +0,0 @@
----
-description: ⚠️ Merge code from one branch to another
-argument-hint: [branch] [from-branch]
----
-
-## Variables
-
-TO_BRANCH: $1 (defaults to `main`)
-FROM_BRANCH: $2 (defaults to current branch)
-
-## Workflow
-
-### Step 1: Sync with remote (CRITICAL)
-```bash
-git fetch origin
-git checkout {TO_BRANCH}
-git pull origin {TO_BRANCH}
-```
-
-### Step 2: Merge from REMOTE tracking branch
-```bash
-# Use origin/{FROM_BRANCH} to merge remote state, not local WIP
-git merge origin/{FROM_BRANCH} --no-ff -m "merge: {FROM_BRANCH} into {TO_BRANCH}"
-```
-
-**Why `origin/{FROM_BRANCH}`:** Ensures merging only committed+pushed changes, not local uncommitted work.
-
-### Step 3: Resolve conflicts if any
-- If conflicts exist, resolve them manually
-- After resolution: `git add . && git commit`
-
-### Step 4: Push merged result
-```bash
-git push origin {TO_BRANCH}
-```
-
-## Notes
-- If `gh` command is not available, instruct the user to install and authorize GitHub CLI first.
-- If you need more clarifications, use `AskUserQuestion` tool to ask the user for more details.
-- Always fetch and pull latest remote state before merging to avoid stale conflicts.

package/templates/commands/git/pr.md

@@ -1,48 +0,0 @@
----
-description: Create a pull request
-argument-hint: [branch] [from-branch]
----
-
-## Variables
-
-TO_BRANCH: $1 (defaults to `main`)
-FROM_BRANCH: $2 (defaults to current branch)
-
-## Workflow
-
-### Step 1: Ensure remote is synced
-```bash
-git fetch origin
-git push -u origin HEAD  # Push current branch if not pushed
-```
-
-### Step 2: Analyze REMOTE diff (CRITICAL)
-**IMPORTANT:** Always compare REMOTE branches, not local:
-```bash
-# Get commits between remote branches (what PR will actually contain)
-git log origin/{TO_BRANCH}...origin/{FROM_BRANCH} --oneline
-
-# Get file diff between remote branches
-git diff origin/{TO_BRANCH}...origin/{FROM_BRANCH} --stat
-git diff origin/{TO_BRANCH}...origin/{FROM_BRANCH}
-```
-
-**DO NOT use:**
-- `git diff {TO_BRANCH}...HEAD` (includes unpushed local changes)
-- `git diff --cached` (staged local changes)
-- `git status` (local working tree state)
-
-### Step 3: Generate PR content from remote diff
-Based on the REMOTE diff analysis:
-- **Title:** Conventional commit format from the primary change (no version/release numbers)
-- **Body:** Summary of changes that exist ON REMOTE, not local WIP
-
-### Step 4: Create PR
-```bash
-gh pr create --base {TO_BRANCH} --head {FROM_BRANCH} --title "..." --body "..."
-```
-
-## Notes
-- If `gh` command is not available, instruct the user to install and authorize GitHub CLI first.
-- If local has unpushed commits, push first before analyzing diff.
-- PR content must reflect REMOTE state since PRs are based on remote branches.

package/templates/commands/integrate/polar.md

@@ -1,28 +0,0 @@
----
-description: ⚡⚡ Implement payment integration with Polar.sh
-argument-hint: [tasks]
----
-
-Think harder.
-Activate `payment-integration` skill.
-Plan & start implementing payment integration with [Polar.sh](https://polar.sh/docs/llms-full.txt) 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.
-
----
-
-**IMPORTANT**: Analyze the list of skills  at `.claude/skills/*` and intelligently activate the skills that are needed for the task during the process.
-**Ensure token efficiency while maintaining high quality.**
-
-## Workflow:
-
-- **Scout**: Use `scout` subagent to find related resources, documents, and code snippets in the current codebase.
-- **Plan**: Trigger slash command `/plan:fast <detailed-instruction-prompt>` to create an implementation plan based on the reports from `scout` subagent.
-- **Implementation**: Trigger slash command `/code <plan>` to implement the plan.

package/templates/commands/integrate/sepay.md

@@ -1,28 +0,0 @@
----
-description: ⚡⚡ Implement payment integration with SePay.vn
-argument-hint: [tasks]
----
-
-Think harder.
-Activate `payment-integration` skill.
-Plan & start implementing payment integration with [https://developer.sepay.vn/vi](https://developer.sepay.vn/vi) 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.
-
----
-
-**IMPORTANT**: Analyze the list of skills  at `.claude/skills/*` and intelligently activate the skills that are needed for the task during the process.
-**Ensure token efficiency while maintaining high quality.**
-
-## Workflow:
-
-- **Scout**: Use `scout` subagent to find related resources, documents, and code snippets in the current codebase.
-- **Plan**: Trigger slash command `/plan:fast <detailed-instruction-prompt>` to create an implementation plan based on the reports from `scout` subagent.
-- **Implementation**: Trigger slash command `/code <plan>` to implement the plan.