thanh-kit 2.5.0 → 2.5.2

package/templates/skills/dual-pass-review/SKILL.md

@@ -1,249 +0,0 @@
----
-name: dual-pass-review
-description: Use AFTER any code changes (feature implementation, bug fix, refactor) to enforce mandatory dual-pass review. First pass reviews unstaged changes for correctness and convention compliance. Second pass ONLY executes if first pass made any corrections. Ensures work follows project conventions, development rules, and best practices before task completion.
-allowed-tools: Read, Write, Edit, Grep, Glob, Bash, Task
----
-
-# Dual-Pass Code Review Workflow
-
-Mandatory review checkpoint that runs after any code changes to ensure quality and convention compliance.
-
-## Core Principle
-
-**Every code change requires verification before task completion.**
-
-Two review passes:
-1. **First Pass**: Review unstaged changes for correctness + convention compliance
-2. **Second Pass**: Conditional - ONLY if first pass made changes, review again
-
-## When to Use
-
-Trigger AUTOMATICALLY after:
-- Feature implementation (`/cook`, `/code`)
-- Bug fixes (`/fix`, `/debug`)
-- Refactoring (`/refactor`)
-- Any edit/write operations that modify code
-
-## Review Dimensions
-
-### 1. Task Correctness
-- [ ] Changes address the original task/requirement
-- [ ] No missing pieces or incomplete logic
-- [ ] Edge cases handled appropriately
-- [ ] No unintended side effects
-
-### 2. Project Conventions
-- [ ] Follows Clean Architecture layers
-- [ ] Uses correct repository pattern (service-specific, not generic)
-- [ ] CQRS patterns: Command + Handler + Result in ONE file
-- [ ] Entity patterns: static expressions, computed properties have empty `set { }`
-- [ ] Frontend: correct base class hierarchy
-- [ ] Frontend: BEM class naming on ALL elements
-
-### 3. Development Rules Compliance
-- [ ] YAGNI - No unnecessary features/abstractions
-- [ ] KISS - Simplest solution that works
-- [ ] DRY - No code duplication (search first, reuse existing)
-- [ ] Logic in LOWEST layer (Entity > Service > Component)
-- [ ] DTO mapping in DTO class, not handler
-- [ ] Side effects in event handlers, not command handlers
-
-### 4. Code Quality
-- [ ] No syntax errors, code compiles
-- [ ] Meaningful naming
-- [ ] Single Responsibility Principle
-- [ ] Proper error handling
-- [ ] No security vulnerabilities
-
-## Execution Protocol
-
-### Step 1: Get Unstaged Changes
-
-```bash
-# Check for unstaged changes
-git status --short
-
-# Get full diff of unstaged changes
-git diff
-
-# Get diff of staged changes (if any)
-git diff --staged
-```
-
-### Step 2: First Pass Review
-
-For EACH changed file, verify:
-
-```markdown
-## First Pass Review Checklist
-
-### File: [filename]
-
-**Task Correctness:**
-- [ ] Addresses original requirement
-- [ ] Logic is complete and correct
-- [ ] No missing edge cases
-
-**Convention Compliance:**
-- [ ] Follows platform patterns from CLAUDE.md
-- [ ] Uses correct base classes
-- [ ] Naming conventions followed
-- [ ] BEM classes on all template elements (frontend)
-
-**Development Rules:**
-- [ ] YAGNI/KISS/DRY compliance
-- [ ] Logic in correct layer
-- [ ] No anti-patterns (side effects in handlers, generic repos, etc.)
-
-**Quality:**
-- [ ] Compiles without errors
-- [ ] No security issues
-- [ ] Proper error handling
-```
-
-### Step 3: First Pass Corrections
-
-If issues found:
-1. Document each issue clearly
-2. Fix issues immediately
-3. Track that corrections were made
-
-```markdown
-## First Pass Corrections Made
-
-1. [File:Line] - [Issue] → [Fix Applied]
-2. [File:Line] - [Issue] → [Fix Applied]
-...
-```
-
-### Step 4: Conditional Second Pass
-
-**CRITICAL DECISION POINT:**
-
-```
-IF first_pass_made_changes == true:
-    EXECUTE full second pass review
-ELSE:
-    SKIP second pass, proceed to summary
-```
-
-### Step 5: Second Pass Review (If Needed)
-
-Re-run complete review on current unstaged changes:
-
-```bash
-# Get fresh diff after corrections
-git diff
-```
-
-Verify ALL checklist items again:
-- Task correctness
-- Convention compliance
-- Development rules
-- Code quality
-
-### Step 6: Generate Summary
-
-```markdown
-## Dual-Pass Review Summary
-
-**First Pass:**
-- Files reviewed: [count]
-- Issues found: [count]
-- Corrections made: [yes/no]
-
-**Second Pass:**
-- Executed: [yes/no]
-- Reason: [first pass made changes / first pass clean]
-- Additional issues: [count if executed]
-
-**Final Status:** [APPROVED / NEEDS ATTENTION]
-
-**Remaining Concerns:**
-- [List any minor items for future consideration]
-```
-
-## Common Issues to Check
-
-### Backend Anti-Patterns
-
-```csharp
-// Side effect in handler (WRONG)
-await notificationService.SendAsync(...);
-// → Move to UseCaseEvents/ event handler
-
-// Generic repository (WRONG)
-IPlatformRootRepository<Entity>
-// → Use service-specific: IMyServiceRootRepository<Entity>
-
-// Mapping in handler (WRONG)
-var entity = new Entity { Name = req.Name };
-// → Use DTO.MapToEntity() or Command.MapToNewEntity()
-
-// Missing eager loading (WRONG)
-await repo.GetAllAsync(...)
-// → Add: ct, e => e.Related
-```
-
-### Frontend Anti-Patterns
-
-```typescript
-// Missing BEM class (WRONG)
-<div><span>{{ name }}</span></div>
-// → <div class="user-card__content"><span class="user-card__name">{{ name }}</span></div>
-
-// Missing untilDestroyed (WRONG)
-this.data$.subscribe(...)
-// → this.data$.pipe(this.untilDestroyed()).subscribe(...)
-
-// Logic in component (WRONG)
-readonly types = [{ value: 1, label: 'Type A' }];
-// → Move to Entity: static readonly dropdownOptions = [...]
-
-// Direct HttpClient (WRONG)
-constructor(private http: HttpClient) {}
-// → Extend PlatformApiService
-```
-
-## Integration with Workflows
-
-This skill is the FINAL step before task completion in:
-
-| Workflow | Sequence (Updated) |
-|----------|-------------------|
-| Feature | plan → cook → test → **dual-pass-review** → docs-update → watzup |
-| Bug Fix | debug → plan → fix → test → **dual-pass-review** |
-| Refactor | plan → code → test → **dual-pass-review** |
-
-## Review Commands
-
-```bash
-# Quick convention check
-grep -r "IPlatformRootRepository" --include="*.cs"  # Should be service-specific
-grep -r "new Entity {" --include="*Handler.cs"  # Should be in DTO
-grep -r "SendAsync\|NotifyAsync" --include="*CommandHandler.cs"  # Should be in event handler
-
-# Frontend checks
-grep -r "class=\"\"" --include="*.html"  # Empty class (suspicious)
-grep -r "subscribe()" --include="*.ts" | grep -v "untilDestroyed"  # Missing cleanup
-```
-
-## Key Rules
-
-1. **NEVER skip first pass** - Always review unstaged changes
-2. **Second pass is CONDITIONAL** - Only if first pass made corrections
-3. **Be honest and brutal** - Flag all issues, don't be lenient
-4. **Evidence-based** - Cite specific files and lines
-5. **Follow project conventions** - Check CLAUDE.md patterns
-
-## Output Format
-
-Always end with clear status:
-
-```markdown
----
-**Review Status:** [APPROVED / CORRECTIONS NEEDED]
-**Passes Executed:** [1 / 2]
-**Ready for Commit:** [Yes / No]
----
-```

package/templates/skills/feature-docs/SKILL.md

@@ -1,294 +0,0 @@
----
-name: feature-docs
-description: Use when the user asks to generate comprehensive feature documentation with verified test cases, create feature README with code evidence, or document a complete feature with test verification. Triggers on keywords like "feature documentation", "document feature", "comprehensive docs", "feature README", "test verification", "verified documentation".
-allowed-tools: Read, Write, Edit, Bash, Grep, Glob, Task, TodoWrite
----
-
-# Feature Documentation Generation & Verification
-
-You are to operate as an expert full-stack dotnet angular principle developer, software architect, and technical documentation specialist to generate comprehensive feature documentation with verified test cases.
-
-**IMPORTANT**: Always thinks hard, plan step by step to-do list first before execute. Always remember to-do list, never compact or summary it when memory context limit reach. Always preserve and carry your to-do list through every operation.
-
----
-
-## CRITICAL TASK MANAGEMENT FOR LONG-RUNNING DOCUMENTATION
-
-- This is a multi-phase, long-running task that generates large documentation files
-- Break ALL tasks into the smallest possible atomic units
-- Each sub-task MUST include a brief summary of previous task results to maintain context
-- Before each new sub-task, read the current state of generated files to re-establish context
-- Update progress tracking after EVERY operation
-- Never assume previous context is retained - always verify by reading files
-
-### MANDATORY TODO LIST MANAGEMENT
-
-1. **At START**: Create comprehensive TODO list covering ALL phases (1A through 5)
-2. **Before EACH phase**: Mark current task as "in_progress"
-3. **After EACH phase**: Mark task as "completed", update "Last Task Summary"
-4. **Never skip**: If context is lost, re-read analysis file's `## Progress` section
-5. **Never compact**: Keep full detailed TODO list even if long
-
-### MANDATORY BEFORE EACH PHASE CHECKLIST
-
-```
-[ ] Read the `## Progress` section from analysis notes file
-[ ] Read the `Last Task Summary` from previous phase
-[ ] Read the current state of generated documentation file(s)
-[ ] Confirm what was completed and what needs to be done next
-[ ] Update current task status to "in_progress"
-[ ] Only then proceed with the phase work
-```
-
----
-
-## Core Anti-Hallucination Protocols
-
-### ASSUMPTION_VALIDATION_CHECKPOINT
-
-Before every major operation:
-
-1. "What assumptions am I making about [X]?"
-2. "Have I verified this with actual code evidence?"
-3. "Could I be wrong about [specific pattern/relationship]?"
-
-### EVIDENCE_CHAIN_VALIDATION
-
-Before claiming any relationship:
-
-- "I believe X calls Y because..." → show actual code
-- "This follows pattern Z because..." → cite specific examples
-
-### DOCUMENTATION_ACCURACY_CHECKPOINT
-
-Before writing any documentation:
-
-- "Have I read the actual code that implements this?"
-- "Are my line number references accurate and current?"
-- "Can I provide a code snippet as evidence?"
-
-### CONTEXT_ANCHOR_SYSTEM
-
-Every 10 operations:
-
-1. Re-read the original task description
-2. Verify current operation aligns with original goals
-3. Update `Current Focus` in `## Progress` section
-4. **CRITICAL**: Re-read last 50 lines of documentation being generated
-
----
-
-## PHASE 1: EXTERNAL MEMORY-DRIVEN FEATURE ANALYSIS
-
-Build knowledge model in `ai_task_analysis_notes/[feature-name].ai_task_analysis_notes_temp.md`.
-
-### PHASE 1A: INITIALIZATION AND DISCOVERY
-
-Initialize with:
-
-- `## Metadata`, `## Progress`, `## Errors`, `## Assumption Validations`
-- `## Performance Metrics`, `## Memory Management`, `## Processed Files`
-- `## File List`, `## Knowledge Graph`, `## Feature Summary`
-
-**Populate `## Progress`** with:
-
-- **Phase**: 1A
-- **Items Processed**: 0
-- **Total Items**: 0
-- **Current Operation**: "initialization"
-- **Current Focus**: "[feature documentation task]"
-- **Last Task Summary**: "Starting feature documentation generation"
-
-### FEATURE-SPECIFIC DISCOVERY
-
-1. **Domain Entity Discovery**: Entities, value objects, enums → `## Domain Model Discovery`
-2. **Workflow Discovery**: Commands, Queries, Event Handlers, Background Jobs, Consumers → `## Workflow Discovery`
-3. **API Discovery**: Controllers, endpoints, DTOs → `## API Discovery`
-4. **Frontend Discovery**: Components, Services, Stores → `## Frontend Discovery`
-5. **Cross-Service Discovery**: Message Bus messages, producers, consumers → `## Cross-Service Discovery`
-6. **Configuration Discovery**: Configuration classes, settings → `## Configuration Discovery`
-
-### PHASE 1B: KNOWLEDGE GRAPH CONSTRUCTION
-
-**IMPORTANT: MUST DO WITH TODO LIST**
-
-For each file, document:
-
-- Standard fields plus:
-- `testableAspects`: What aspects should be tested (P0/P1/P2)
-- `codeSnippets`: Key code snippets with line numbers for documentation
-
-### PHASE 1C: OVERALL ANALYSIS
-
-Write `## Feature Summary`:
-
-- **Feature Overview**: What the feature does
-- **Complete End-to-End Workflows**: From trigger to completion
-- **Key Architectural Patterns**: Design patterns used
-- **Service Responsibilities**: Which service owns what
-- **Integration Points**: Cross-service communication
-- **Security Considerations**: Auth, authz, encryption
-- **Performance Considerations**: Pagination, caching, parallelism
-- **Error Handling Patterns**: How errors are handled
-
----
-
-## PHASE 2: FEATURE README GENERATION
-
-Generate at `docs/README.[FeatureName].md`.
-
-**CRITICAL**: Break into sub-tasks, update file incrementally.
-
-### PHASE 2A: Overview & Architecture Sections
-
-- Title and Overview
-- Table of Contents
-- Key Capabilities
-- Architecture diagram (ASCII art)
-- Service Responsibilities table
-- Design Patterns table
-
-**After**: Update `Last Task Summary`
-
-### PHASE 2B: Domain Model & Workflow Sections
-
-- Entity Relationship Diagram (ASCII art)
-- Entity descriptions with properties
-- Enumerations with values
-- Workflow diagrams and step-by-step processes
-- Code snippets with file paths and line numbers
-
-**After**: Update `Last Task Summary`
-
-### PHASE 2C: API Reference & Configuration
-
-- Endpoint table
-- Request/Response models
-- Configuration settings
-- Security Considerations
-- Performance Tuning
-
-**After**: Update `Last Task Summary`
-
-### PHASE 2D: Test Specifications Section
-
-**CRITICAL**: Largest section - break into sub-tasks by category.
-
-**Test Case Format**:
-
-```markdown
-### [Category] Test Specs
-
-#### P0 - Critical
-
-##### TS-[CATEGORY]-P0-001: [Test Name]
-
-**Priority:** P0 - Critical
-**Category:** [Category]
-**Component:** [Component]
-
-**Preconditions:**
-
-- [List preconditions]
-
-**Test Steps:**
-| Step | Action | Expected Result |
-| ---- | -------- | --------------- |
-| 1 | [Action] | [Expected] |
-
-**GIVEN** [initial context]
-**WHEN** [action performed]
-**THEN** [expected outcome]
-
-**Code Reference:**
-
-- File: `[file-path]`
-- Lines: [line-range]
-- Key Logic: [description]
-```
-
-Execute one category at a time:
-
-- **Phase 2D-1**: Summary table + first category
-- **Phase 2D-2 through 2D-N**: Remaining categories
-- **Phase 2D-Final**: Update summary table with counts
-
-**After each**: Update `Last Task Summary`
-
-### PHASE 2E: Final Sections
-
-- Troubleshooting
-- Adding New Providers (if applicable)
-- Related Documentation
-- Version History
-
----
-
-## PHASE 3: README VERIFICATION - FIRST PASS
-
-**PURPOSE**: Verify README matches actual code. NO HALLUCINATION ALLOWED.
-
-Verify one section at a time:
-
-- Read ENTIRE section
-- For EACH code reference:
-  - Read actual source file at referenced lines
-  - Compare character-by-character
-  - Verify line numbers are accurate
-  - Log mismatches in `## Verification Log - First Pass`
-  - Correct immediately
-
-**After**: Update `Last Task Summary`
-
----
-
-## PHASE 4: README VERIFICATION - SECOND PASS
-
-Re-verify all first-pass corrections:
-
-- Random sampling (10 code references)
-- Cross-reference and TOC verification
-- Completeness check
-
-**CRITICAL**: If Second Pass finds MORE THAN 5 issues, HALT and re-run Phase 3.
-
----
-
-## PHASE 5: FINAL VALIDATION AND CLEANUP
-
-### Phase 5-1: README Consistency Check
-
-- Verify test case IDs are unique and sequential
-- Verify table of contents matches sections
-- Verify counts match in summary tables
-
-### Phase 5-2: Final Quality Report
-
-- Count total lines in README
-- Count test cases by priority (P0, P1, P2)
-- Count issues found and corrected during verification
-- Calculate verification coverage percentage
-
-### Phase 5-3: Generate Final Summary
-
-Document under `## Final Validation`:
-
-- **README Accuracy:** [VERIFIED after 2 passes]
-- **Total Issues Found and Corrected:** [X issues]
-- **Generated Files:** List all files
-- **Final Task Summary:** Complete metrics
-
----
-
-## Feature Documentation Guidelines
-
-- **Evidence-based documentation**: Every claim must have code evidence with file path and line numbers
-- **No hallucination tolerance**: If uncertain, mark as "inferred" and verify
-- **Incremental generation**: Break large documents into sections, verify each
-- **Context preservation**: Always re-read generated content before continuing
-- **Multiple verification passes**: Minimum 2 verification passes for README
-- **BDD test format**: All test cases must follow GIVEN/WHEN/THEN format
-- **Priority classification**: P0 (critical), P1 (high), P2 (medium)
-- **Code snippets**: Include actual code with file paths and line numbers for reference
-- **Line number accuracy**: Always verify line numbers are current
-- **Cross-reference consistency**: Ensure all internal references within README are accurate