devtronic 1.0.0

package/templates/claude-code/.claude/skills/post-review/SKILL.md

@@ -0,0 +1,437 @@
+---
+name: post-review
+description: Post-feature review before PR. Checks requirements, architecture, quality, and captures lessons. Auto-invoke after completing a plan implementation. Use --strict for senior engineer mode.
+allowed-tools: Read, Grep, Glob, Bash, Edit, Write, Task
+argument-hint: "[--strict|--quick|files...]"
+---
+
+# Post-Feature Review
+
+Comprehensive review of implemented changes before PR creation. If `$ARGUMENTS` specifies files or flags (--strict, --quick), apply accordingly.
+
+## Modes
+
+| Mode | Command | Purpose |
+|------|---------|---------|
+| **Standard** | `/post-review` | Full review with lessons learned |
+| **Strict** | `/post-review --strict` | Senior engineer "grill me" mode |
+| **Quick** | `/post-review --quick` | Automated checks only |
+| **Files** | `/post-review src/file.ts` | Review specific files |
+
+**Note**: For GitHub PR review, use Claude Code's built-in `/review` command.
+
+---
+
+## When to Use
+
+**Standard mode (default):**
+- After completing a feature implementation
+- After fixing a bug
+- After a refactor
+- Before creating a PR
+
+**Strict mode (`--strict`):**
+- Want rigorous challenge on your approach
+- Need to catch subtle issues
+- Preparing for a critical PR
+
+**Quick mode (`--quick`):**
+- Small changes
+- Just need automated verification
+
+---
+
+## Standard Review Workflow
+
+```
+┌─────────────────────────────────────────────────────────────────┐
+│                    STANDARD REVIEW                               │
+├─────────────────────────────────────────────────────────────────┤
+│                                                                 │
+│  1. GATHER CONTEXT                                              │
+│     └── git diff, git log, understand changes                   │
+│                                                                 │
+│  2. REQUIREMENTS CHECK                                          │
+│     └── Did we deliver what was asked?                          │
+│                                                                 │
+│  3. ARCHITECTURE CHECK                                          │
+│     └── Clean Architecture, project patterns                    │
+│                                                                 │
+│  4. QUALITY CHECK                                               │
+│     └── Types, lint, tests passing                              │
+│                                                                 │
+│  5. CHANGE ANALYSIS                                             │
+│     └── Are changes proportional?                               │
+│                                                                 │
+│  6. IDENTIFY ISSUES                                             │
+│     └── Bugs, security, performance, maintainability            │
+│                                                                 │
+│  7. LESSONS LEARNED                                             │
+│     └── What patterns worked? What didn't?                      │
+│                                                                 │
+│  8. CLAUDE.MD UPDATE                                            │
+│     └── Add rules to prevent future mistakes                    │
+│                                                                 │
+│  9. VERDICT                                                     │
+│     └── Ready for PR or needs fixes                             │
+│                                                                 │
+└─────────────────────────────────────────────────────────────────┘
+```
+
+---
+
+## Step 1: Gather Context
+
+```bash
+# What changed?
+git diff main...HEAD --stat
+
+# What commits were made?
+git log main..HEAD --oneline
+
+# Full diff
+git diff main...HEAD
+```
+
+---
+
+## Step 2: Requirements Check (with Done Criteria)
+
+### 2a. Find Active Plan
+
+Look for the most recent plan file:
+```bash
+ls -t thoughts/plans/*.md 2>/dev/null | head -5
+```
+
+Also check `thoughts/STATE.md` for an `Active Plan` reference.
+
+### 2b. Extract Done Criteria
+
+If a plan with `## Done Criteria` is found, extract and validate each criterion:
+
+```markdown
+## Done Criteria Validation
+
+**Plan**: `thoughts/plans/[file].md`
+
+| # | Criterion | Status | Evidence |
+|---|-----------|--------|----------|
+| 1 | [text] | PASS/FAIL | [how verified] |
+| 2 | [text] | PASS/FAIL | [how verified] |
+
+**Result**: X/Y criteria met
+```
+
+### 2c. Fallback (No Plan Found)
+
+If no plan with done criteria exists, use the manual requirements checklist:
+
+```markdown
+## Requirements Checklist
+
+| Requirement | Status | Notes |
+|-------------|--------|-------|
+| [Req 1] | ✅ Done | |
+| [Req 2] | ⚠️ Partial | [what's missing] |
+| [Req 3] | ❌ Not done | [why] |
+```
+
+---
+
+## Step 3: Architecture Check (Automated)
+
+**Spawn the `architecture-checker` subagent** to validate compliance on changed files:
+
+```
+Use the Task tool with:
+  subagent_type: "devtronic:architecture-checker"
+  model: "sonnet"
+  prompt: "Check architecture compliance on these changed files: [file list from Step 1]"
+```
+
+The subagent reads architecture rules from `CLAUDE.md`, `docs/ARCHITECTURE.md`, or `.claude/architecture-rules.md`, then:
+1. Categorizes changed files by architecture layer
+2. Checks layer dependency direction, domain purity, pattern compliance
+3. Returns a structured report with violations (file:line) and a PASS/FAIL verdict
+
+**If the subagent returns FAIL:**
+- List each violation in the review
+- Mark the review as NEEDS FIXES
+- Violations MUST be resolved before proceeding
+
+**If the subagent is unavailable** (e.g., Task tool not available), fall back to manual checklist:
+
+```markdown
+## Architecture Compliance (manual fallback)
+
+### Clean Architecture
+- [ ] Domain has no external dependencies
+- [ ] Use cases in application layer
+- [ ] Infrastructure implements domain interfaces
+- [ ] UI only calls application layer
+
+### Project Patterns
+- [ ] Follows naming conventions
+- [ ] Uses established state management
+- [ ] Repository pattern for data access
+- [ ] Error handling follows standards
+```
+
+---
+
+## Step 4: Quality Check
+
+### Package Manager Detection
+
+First, detect the project's package manager by checking for lockfiles:
+- `pnpm-lock.yaml` → Use `pnpm`
+- `yarn.lock` → Use `yarn`
+- `bun.lockb` → Use `bun`
+- `package-lock.json` or none → Use `npm`
+
+Then run quality checks with the detected PM:
+
+```bash
+<pm> run typecheck && <pm> run lint && <pm> test
+```
+
+```markdown
+## Quality Metrics
+
+| Check | Status |
+|-------|--------|
+| TypeScript | ✅ Pass |
+| Lint | ✅ Pass |
+| Tests | ✅ Pass (X new) |
+```
+
+---
+
+## Step 5: Change Analysis
+
+```markdown
+## Change Analysis
+
+**Files**: X changed
+**Lines**: +Y / -Z
+
+### Red Flags to Check
+- [ ] No huge changes for small feature
+- [ ] No unrelated files modified
+- [ ] No console.logs left behind
+- [ ] No commented code
+```
+
+---
+
+## Step 6: Identify Issues
+
+| Severity | Description | Action |
+|----------|-------------|--------|
+| 🔴 Blocker | Bug, security issue | Must fix |
+| 🟠 Major | Logic flaw, bad pattern | Should fix |
+| 🟡 Minor | Style, naming | Consider |
+| 🟢 Nitpick | Optional enhancement | Optional |
+
+---
+
+## Step 7: Lessons Learned
+
+```markdown
+## Lessons Learned
+
+### What Worked Well
+1. [Effective pattern/approach]
+
+### What Was Difficult
+1. [Challenge and how solved]
+
+### Patterns Discovered
+- **Pattern**: [Description]
+- **When to use**: [Conditions]
+```
+
+Save to: `thoughts/notes/YYYY-MM-DD_[feature-name].md`
+
+---
+
+## Step 8: CLAUDE.md Update
+
+If mistakes were made that should be prevented:
+
+```markdown
+## CLAUDE.md Updates Needed?
+
+- [ ] New pattern worth documenting
+- [ ] Mistake to prevent
+- [ ] Clarification needed
+
+If yes → Update CLAUDE.md with new rule
+```
+
+---
+
+## Step 9: Verdict
+
+### ✅ Ready for PR
+```markdown
+## Review: READY FOR PR ✅
+
+**Summary**: [1-2 sentences]
+
+### Quality
+- Types: ✅ | Lint: ✅ | Tests: ✅
+
+### Architecture
+- Clean Architecture: ✅
+- Project patterns: ✅
+
+### Lessons Captured
+- Notes saved to: `thoughts/notes/...`
+- CLAUDE.md: [Updated / No changes needed]
+
+**Proceed with PR creation.**
+```
+
+### 🔄 Needs Fixes
+```markdown
+## Review: NEEDS FIXES 🔄
+
+### Must Fix
+1. `file.ts:45` - [Issue description]
+
+### Should Fix
+1. [Issue]
+
+**Fix and re-run `/post-review`.**
+```
+
+---
+
+## Strict Mode (`--strict`)
+
+Senior engineer mode that challenges every decision.
+
+### Additional Steps
+
+**Grill the Developer:**
+- "What happens if `user` is null here?"
+- "Why this approach over X?"
+- "How did you test the error path?"
+- "What's the rollback plan?"
+
+**The Test:**
+```markdown
+Before I approve, answer:
+
+1. What edge case is most likely to cause bugs?
+2. If this fails in production, how will you debug it?
+3. What would you change if you had more time?
+```
+
+**Verdicts:**
+- ✅ **APPROVED** - Ready to merge
+- 🔄 **CHANGES REQUESTED** - Fix blockers
+- 🚫 **BLOCKED** - Needs rearchitecting
+
+---
+
+## Quick Mode (`--quick`)
+
+Abbreviated review for small changes:
+
+1. Run automated checks (typecheck, lint, test)
+2. Quick architecture scan
+3. One-liner summary
+
+```markdown
+## Quick Review
+
+- Types: ✅ | Lint: ✅ | Tests: ✅
+- Architecture: ✅ No violations
+- **Ready for PR**
+```
+
+---
+
+## Output Template
+
+```markdown
+# Code Review
+
+**Feature**: [name]
+**Branch**: [branch]
+**Date**: [date]
+
+---
+
+## Summary
+
+[1-2 sentence overview]
+
+---
+
+## Requirements
+
+| Requirement | Status |
+|-------------|--------|
+| [Req 1] | ✅ |
+| [Req 2] | ✅ |
+
+---
+
+## Quality
+
+| Check | Status |
+|-------|--------|
+| Types | ✅ |
+| Lint | ✅ |
+| Tests | ✅ |
+
+---
+
+## Architecture
+
+- ✅ Clean Architecture respected
+- ✅ Project patterns followed
+
+---
+
+## Issues Found
+
+### 🔴 Blockers
+[None / List]
+
+### 🟠 Major
+[None / List]
+
+### 🟡 Minor
+[None / List]
+
+---
+
+## Lessons Learned
+
+1. [Key learning]
+
+---
+
+## Verdict
+
+[READY FOR PR / NEEDS FIXES / BLOCKED]
+
+## Next Steps
+
+- [ ] [Action items]
+```
+
+---
+
+## Tips
+
+1. **Run before PR creation** - Catch issues early
+2. **Be honest about difficulties** - That's where learning happens
+3. **Update CLAUDE.md** when you find patterns worth documenting
+4. **Use `--strict`** for critical features
+5. **Keep notes** for future reference

package/templates/claude-code/.claude/skills/quick/SKILL.md

@@ -0,0 +1,188 @@
+---
+name: quick
+description: Fast ad-hoc task execution. Skips spec/research/plan — just implement, verify, commit. For small, well-defined tasks.
+allowed-tools: Read, Write, Edit, Bash, Glob, Grep
+argument-hint: "<task description>"
+---
+
+# Quick - Fast Ad-Hoc Task Execution
+
+Execute `$ARGUMENTS` quickly without the full workflow ceremony. Implement, verify, commit.
+
+## When to Use
+
+- Small, well-defined tasks (< 5 files)
+- Obvious bug fixes with clear solution
+- Simple config changes
+- Adding a single test or function
+- Renaming, moving, or deleting files
+
+**Escalate to `/create-plan` if:**
+- Task touches 5+ files
+- Design decisions needed
+- Multiple valid approaches exist
+- Task requires research first
+
+---
+
+## Process
+
+```
+1. UNDERSTAND (30 seconds)
+   └── Parse task, identify target files
+
+2. GUARD CHECK
+   └── If > 5 files or needs design → suggest /create-plan
+
+3. IMPLEMENT
+   └── Make changes directly
+
+4. VERIFY
+   └── Detect PM, run typecheck + lint (+ test if test files affected)
+
+5. COMMIT
+   └── git add specific files + commit
+
+6. UPDATE STATE
+   └── If thoughts/STATE.md exists, note the quick task
+```
+
+---
+
+## Step 1: Understand
+
+Parse `$ARGUMENTS` to determine:
+
+- **What**: The specific change needed
+- **Where**: Which files to modify (should be < 5)
+- **How**: The implementation approach (should be obvious)
+
+```markdown
+**Task**: [parsed task]
+**Files**: [list of files to touch]
+**Approach**: [1-2 sentence description]
+```
+
+---
+
+## Step 2: Guard Check
+
+Before implementing, verify this is appropriate for `/quick`:
+
+| Check | Threshold | Action if exceeded |
+|-------|-----------|-------------------|
+| Files to modify | > 5 | Suggest `/create-plan` |
+| Design decisions | Any | Suggest `/create-plan` |
+| New architecture | Any | Suggest `/create-plan` |
+| Unclear requirements | Any | Ask user to clarify |
+
+If guard triggers:
+
+```markdown
+This task looks more complex than a quick fix:
+- [reason: e.g., "touches 8 files", "needs design decision about X"]
+
+Recommend: `/create-plan [task]` for a proper plan.
+Continue anyway? (not recommended)
+```
+
+---
+
+## Step 3: Implement
+
+Make changes directly. Follow existing patterns in the codebase.
+
+- Read target files before modifying
+- Follow existing code style
+- Keep changes minimal and focused
+
+---
+
+## Step 4: Verify
+
+### Package Manager Detection
+
+Check for lockfiles:
+- `pnpm-lock.yaml` → `pnpm`
+- `yarn.lock` → `yarn`
+- `bun.lockb` → `bun`
+- `package-lock.json` or none → `npm`
+
+### Run Checks
+
+```bash
+# Always run
+<pm> run typecheck
+<pm> run lint
+
+# Run if test files were modified or new tests added
+<pm> test
+```
+
+Fix any issues before proceeding to commit.
+
+---
+
+## Step 5: Commit
+
+Invoke the **commit-changes** agent to handle staging and committing. It will:
+- Analyze the changes and group them logically
+- Stage specific files (never `git add .`)
+- Create conventional commit messages
+
+If the commit-changes agent is not available, fall back to manual commit:
+```bash
+git add [specific files]
+git commit -m "[type]: [description]"
+```
+
+---
+
+## Step 6: Update State
+
+If `thoughts/STATE.md` exists, append a note about the quick task:
+
+```markdown
+## Quick Tasks (this session)
+
+- [description] — [files changed] (committed: [hash])
+```
+
+---
+
+## Output Format
+
+```markdown
+## Quick: [task name]
+
+**Files changed**: [count]
+- `path/to/file.ts` — [what changed]
+
+**Verification**:
+- Types: PASS/FAIL
+- Lint: PASS/FAIL
+- Tests: PASS/FAIL (or skipped)
+
+**Commit**: `[hash]` [message]
+```
+
+---
+
+## Examples
+
+```bash
+/quick fix typo in README.md
+/quick add index export for UserService
+/quick rename handleClick to handleSubmit in LoginForm
+/quick add test for edge case in parseDate utility
+/quick update eslint config to enable new rule
+```
+
+---
+
+## Tips
+
+1. **Be specific** in the task description — the more detail, the better
+2. **One task at a time** — don't combine unrelated changes
+3. **Trust the guard** — if it suggests `/create-plan`, listen
+4. **Quick means quick** — if you're spending more than 5 minutes, escalate