@ngxtm/devkit 3.7.0 → 3.8.0

package/merged-commands/plan-writing.md

@@ -0,0 +1,152 @@
+---
+name: plan-writing
+description: Structured task planning with clear breakdowns, dependencies, and verification criteria. Use when implementing features, refactoring, or any multi-step work.
+allowed-tools: Read, Glob, Grep
+---
+
+# Plan Writing
+
+> Source: obra/superpowers
+
+## Overview
+This skill provides a framework for breaking down work into clear, actionable tasks with verification criteria.
+
+## Task Breakdown Principles
+
+### 1. Small, Focused Tasks
+- Each task should take 2-5 minutes
+- One clear outcome per task
+- Independently verifiable
+
+### 2. Clear Verification
+- How do you know it's done?
+- What can you check/test?
+- What's the expected output?
+
+### 3. Logical Ordering
+- Dependencies identified
+- Parallel work where possible
+- Critical path highlighted
+- **Phase X: Verification is always LAST**
+
+### 4. Dynamic Naming in Project Root
+- Plan files are saved as `{task-slug}.md` in the PROJECT ROOT
+- Name derived from task (e.g., "add auth" → `auth-feature.md`)
+- **NEVER** inside `.claude/`, `docs/`, or temp folders
+
+## Planning Principles (NOT Templates!)
+
+> 🔴 **NO fixed templates. Each plan is UNIQUE to the task.**
+
+### Principle 1: Keep It SHORT
+
+| ❌ Wrong | ✅ Right |
+|----------|----------|
+| 50 tasks with sub-sub-tasks | 5-10 clear tasks max |
+| Every micro-step listed | Only actionable items |
+| Verbose descriptions | One-line per task |
+
+> **Rule:** If plan is longer than 1 page, it's too long. Simplify.
+
+---
+
+### Principle 2: Be SPECIFIC, Not Generic
+
+| ❌ Wrong | ✅ Right |
+|----------|----------|
+| "Set up project" | "Run `npx create-next-app`" |
+| "Add authentication" | "Install next-auth, create `/api/auth/[...nextauth].ts`" |
+| "Style the UI" | "Add Tailwind classes to `Header.tsx`" |
+
+> **Rule:** Each task should have a clear, verifiable outcome.
+
+---
+
+### Principle 3: Dynamic Content Based on Project Type
+
+**For NEW PROJECT:**
+- What tech stack? (decide first)
+- What's the MVP? (minimal features)
+- What's the file structure?
+
+**For FEATURE ADDITION:**
+- Which files are affected?
+- What dependencies needed?
+- How to verify it works?
+
+**For BUG FIX:**
+- What's the root cause?
+- What file/line to change?
+- How to test the fix?
+
+---
+
+### Principle 4: Scripts Are Project-Specific
+
+> 🔴 **DO NOT copy-paste script commands. Choose based on project type.**
+
+| Project Type | Relevant Scripts |
+|--------------|------------------|
+| Frontend/React | `ux_audit.py`, `accessibility_checker.py` |
+| Backend/API | `api_validator.py`, `security_scan.py` |
+| Mobile | `mobile_audit.py` |
+| Database | `schema_validator.py` |
+| Full-stack | Mix of above based on what you touched |
+
+**Wrong:** Adding all scripts to every plan
+**Right:** Only scripts relevant to THIS task
+
+---
+
+### Principle 5: Verification is Simple
+
+| ❌ Wrong | ✅ Right |
+|----------|----------|
+| "Verify the component works correctly" | "Run `npm run dev`, click button, see toast" |
+| "Test the API" | "curl localhost:3000/api/users returns 200" |
+| "Check styles" | "Open browser, verify dark mode toggle works" |
+
+---
+
+## Plan Structure (Flexible, Not Fixed!)
+
+```
+# [Task Name]
+
+## Goal
+One sentence: What are we building/fixing?
+
+## Tasks
+- [ ] Task 1: [Specific action] → Verify: [How to check]
+- [ ] Task 2: [Specific action] → Verify: [How to check]
+- [ ] Task 3: [Specific action] → Verify: [How to check]
+
+## Done When
+- [ ] [Main success criteria]
+```
+
+> **That's it.** No phases, no sub-sections unless truly needed.
+> Keep it minimal. Add complexity only when required.
+
+## Notes
+[Any important considerations]
+```
+
+---
+
+## Best Practices (Quick Reference)
+
+1. **Start with goal** - What are we building/fixing?
+2. **Max 10 tasks** - If more, break into multiple plans
+3. **Each task verifiable** - Clear "done" criteria
+4. **Project-specific** - No copy-paste templates
+5. **Update as you go** - Mark `[x]` when complete
+
+---
+
+## When to Use
+
+- New project from scratch
+- Adding a feature
+- Fixing a bug (if complex)
+- Refactoring multiple files

package/merged-commands/planning-with-files.md

@@ -0,0 +1,211 @@
+---
+name: planning-with-files
+version: "2.1.2"
+description: Implements Manus-style file-based planning for complex tasks. Creates task_plan.md, findings.md, and progress.md. Use when starting complex multi-step tasks, research projects, or any task requiring >5 tool calls.
+user-invocable: true
+allowed-tools:
+  - Read
+  - Write
+  - Edit
+  - Bash
+  - Glob
+  - Grep
+  - WebFetch
+  - WebSearch
+hooks:
+  SessionStart:
+    - hooks:
+        - type: command
+          command: "echo '[planning-with-files] Ready. Auto-activates for complex tasks, or invoke manually with /planning-with-files'"
+  PreToolUse:
+    - matcher: "Write|Edit|Bash"
+      hooks:
+        - type: command
+          command: "cat task_plan.md 2>/dev/null | head -30 || true"
+  PostToolUse:
+    - matcher: "Write|Edit"
+      hooks:
+        - type: command
+          command: "echo '[planning-with-files] File updated. If this completes a phase, update task_plan.md status.'"
+  Stop:
+    - hooks:
+        - type: command
+          command: "${CLAUDE_PLUGIN_ROOT}/scripts/check-complete.sh"
+---
+
+# Planning with Files
+
+Work like Manus: Use persistent markdown files as your "working memory on disk."
+
+## Important: Where Files Go
+
+When using this skill:
+
+- **Templates** are stored in the skill directory at `${CLAUDE_PLUGIN_ROOT}/templates/`
+- **Your planning files** (`task_plan.md`, `findings.md`, `progress.md`) should be created in **your project directory** — the folder where you're working
+
+| Location | What Goes There |
+|----------|-----------------|
+| Skill directory (`${CLAUDE_PLUGIN_ROOT}/`) | Templates, scripts, reference docs |
+| Your project directory | `task_plan.md`, `findings.md`, `progress.md` |
+
+This ensures your planning files live alongside your code, not buried in the skill installation folder.
+
+## Quick Start
+
+Before ANY complex task:
+
+1. **Create `task_plan.md`** in your project — Use [templates/task_plan.md](templates/task_plan.md) as reference
+2. **Create `findings.md`** in your project — Use [templates/findings.md](templates/findings.md) as reference
+3. **Create `progress.md`** in your project — Use [templates/progress.md](templates/progress.md) as reference
+4. **Re-read plan before decisions** — Refreshes goals in attention window
+5. **Update after each phase** — Mark complete, log errors
+
+> **Note:** All three planning files should be created in your current working directory (your project root), not in the skill's installation folder.
+
+## The Core Pattern
+
+```
+Context Window = RAM (volatile, limited)
+Filesystem = Disk (persistent, unlimited)
+
+→ Anything important gets written to disk.
+```
+
+## File Purposes
+
+| File | Purpose | When to Update |
+|------|---------|----------------|
+| `task_plan.md` | Phases, progress, decisions | After each phase |
+| `findings.md` | Research, discoveries | After ANY discovery |
+| `progress.md` | Session log, test results | Throughout session |
+
+## Critical Rules
+
+### 1. Create Plan First
+Never start a complex task without `task_plan.md`. Non-negotiable.
+
+### 2. The 2-Action Rule
+> "After every 2 view/browser/search operations, IMMEDIATELY save key findings to text files."
+
+This prevents visual/multimodal information from being lost.
+
+### 3. Read Before Decide
+Before major decisions, read the plan file. This keeps goals in your attention window.
+
+### 4. Update After Act
+After completing any phase:
+- Mark phase status: `in_progress` → `complete`
+- Log any errors encountered
+- Note files created/modified
+
+### 5. Log ALL Errors
+Every error goes in the plan file. This builds knowledge and prevents repetition.
+
+```markdown
+## Errors Encountered
+| Error | Attempt | Resolution |
+|-------|---------|------------|
+| FileNotFoundError | 1 | Created default config |
+| API timeout | 2 | Added retry logic |
+```
+
+### 6. Never Repeat Failures
+```
+if action_failed:
+    next_action != same_action
+```
+Track what you tried. Mutate the approach.
+
+## The 3-Strike Error Protocol
+
+```
+ATTEMPT 1: Diagnose & Fix
+  → Read error carefully
+  → Identify root cause
+  → Apply targeted fix
+
+ATTEMPT 2: Alternative Approach
+  → Same error? Try different method
+  → Different tool? Different library?
+  → NEVER repeat exact same failing action
+
+ATTEMPT 3: Broader Rethink
+  → Question assumptions
+  → Search for solutions
+  → Consider updating the plan
+
+AFTER 3 FAILURES: Escalate to User
+  → Explain what you tried
+  → Share the specific error
+  → Ask for guidance
+```
+
+## Read vs Write Decision Matrix
+
+| Situation | Action | Reason |
+|-----------|--------|--------|
+| Just wrote a file | DON'T read | Content still in context |
+| Viewed image/PDF | Write findings NOW | Multimodal → text before lost |
+| Browser returned data | Write to file | Screenshots don't persist |
+| Starting new phase | Read plan/findings | Re-orient if context stale |
+| Error occurred | Read relevant file | Need current state to fix |
+| Resuming after gap | Read all planning files | Recover state |
+
+## The 5-Question Reboot Test
+
+If you can answer these, your context management is solid:
+
+| Question | Answer Source |
+|----------|---------------|
+| Where am I? | Current phase in task_plan.md |
+| Where am I going? | Remaining phases |
+| What's the goal? | Goal statement in plan |
+| What have I learned? | findings.md |
+| What have I done? | progress.md |
+
+## When to Use This Pattern
+
+**Use for:**
+- Multi-step tasks (3+ steps)
+- Research tasks
+- Building/creating projects
+- Tasks spanning many tool calls
+- Anything requiring organization
+
+**Skip for:**
+- Simple questions
+- Single-file edits
+- Quick lookups
+
+## Templates
+
+Copy these templates to start:
+
+- [templates/task_plan.md](templates/task_plan.md) — Phase tracking
+- [templates/findings.md](templates/findings.md) — Research storage
+- [templates/progress.md](templates/progress.md) — Session logging
+
+## Scripts
+
+Helper scripts for automation:
+
+- `scripts/init-session.sh` — Initialize all planning files
+- `scripts/check-complete.sh` — Verify all phases complete
+
+## Advanced Topics
+
+- **Manus Principles:** See [reference.md](reference.md)
+- **Real Examples:** See [examples.md](examples.md)
+
+## Anti-Patterns
+
+| Don't | Do Instead |
+|-------|------------|
+| Use TodoWrite for persistence | Create task_plan.md file |
+| State goals once and forget | Re-read plan before decisions |
+| Hide errors and retry silently | Log errors to plan file |
+| Stuff everything in context | Store large content in files |
+| Start executing immediately | Create plan file FIRST |
+| Repeat failed actions | Track attempts, mutate approach |
+| Create files in skill directory | Create files in your project |

package/merged-commands/planning.md

@@ -0,0 +1,95 @@
+---
+name: planning
+description: Use when you need to plan technical solutions that are scalable, secure, and maintainable.
+license: MIT
+---
+
+# Planning
+
+Create detailed technical implementation plans through research, codebase analysis, solution design, and comprehensive documentation.
+
+## When to Use
+
+Use this skill when:
+
+- Planning new feature implementations
+- Architecting system designs
+- Evaluating technical approaches
+- Creating implementation roadmaps
+- Breaking down complex requirements
+- Assessing technical trade-offs
+
+## Core Responsibilities & Rules
+
+Always honoring **YAGNI**, **KISS**, and **DRY** principles.
+**Be honest, be brutal, straight to the point, and be concise.**
+
+### 1. Research & Analysis
+
+Load: `references/research-phase.md`
+**Skip if:** Provided with researcher reports
+
+### 2. Codebase Understanding
+
+Load: `references/codebase-understanding.md`
+**Skip if:** Provided with scouter reports
+
+### 3. Solution Design
+
+Load: `references/solution-design.md`
+
+### 4. Plan Creation & Organization
+
+Load: `references/plan-organization.md`
+
+### 5. Task Breakdown & Output Standards
+
+Load: `references/output-standards.md`
+
+## Workflow Process
+
+1. **Initial Analysis** → Read codebase docs, understand context
+2. **Research Phase** → Spawn researchers, investigate approaches
+3. **Synthesis** → Analyze reports, identify optimal solution
+4. **Design Phase** → Create architecture, implementation design
+5. **Plan Documentation** → Write comprehensive plan
+6. **Review & Refine** → Ensure completeness, clarity, actionability
+
+## Output Requirements
+
+- DO NOT implement code - only create plans
+- Respond with plan file path and summary
+- Ensure self-contained plans with necessary context
+- Include code snippets/pseudocode when clarifying
+- Provide multiple options with trade-offs when appropriate
+- Fully respect the `./docs/AGENT-RULES.md` file.
+
+**Plan Directory Structure**
+
+```
+plans/
+└── YYYYMMDD-HHmm-plan-name/
+    ├── research/
+    │   ├── researcher-XX-report.md
+    │   └── ...
+    ├── reports/
+    │   ├── XX-report.md
+    │   └── ...
+    ├── scouter/
+    │   ├── scouter-XX-report.md
+    │   └── ...
+    ├── plan.md
+    ├── phase-XX-phase-name-here.md
+    └── ...
+```
+
+## Quality Standards
+
+- Be thorough and specific
+- Consider long-term maintainability
+- Research thoroughly when uncertain
+- Address security and performance concerns
+- Make plans detailed enough for junior developers
+- Validate against existing codebase patterns
+
+**Remember:** Plan quality determines implementation success. Be comprehensive and consider all solution aspects.

package/merged-commands/plans-kanban.md

@@ -0,0 +1,166 @@
+---
+name: plans-kanban
+description: View plans dashboard with progress tracking and timeline visualization. Use for kanban boards, plan status overview, phase progress, milestone tracking, project visibility.
+---
+
+# plans-kanban
+
+Plans dashboard server with progress tracking and timeline visualization.
+
+## ⚠️ Installation Required
+
+**This skill requires npm dependencies.** Run one of the following:
+
+```bash
+# Option 1: Install via ClaudeKit CLI (recommended)
+ck init  # Runs install.sh which handles all skills
+
+# Option 2: Manual installation
+cd .claude/skills/plans-kanban
+npm install
+```
+
+**Dependencies:** `gray-matter`
+
+Without installation, you'll get **Error 500** when viewing plan details.
+
+## Purpose
+
+Visual dashboard for viewing plan directories with:
+- Progress tracking per plan
+- Timeline/Gantt visualization
+- Phase status indicators
+- Activity heatmap
+
+## Quick Start
+
+```bash
+# View plans dashboard
+node .claude/skills/plans-kanban/scripts/server.cjs \
+  --dir ./plans \
+  --open
+
+# Remote access (all interfaces)
+node .claude/skills/plans-kanban/scripts/server.cjs \
+  --dir ./plans \
+  --host 0.0.0.0 \
+  --open
+
+# Background mode
+node .claude/skills/plans-kanban/scripts/server.cjs \
+  --dir ./plans \
+  --background
+
+# Stop all running servers
+node .claude/skills/plans-kanban/scripts/server.cjs --stop
+```
+
+## Slash Command
+
+Use `/kanban` for quick access:
+
+```bash
+/kanban plans/           # View plans dashboard
+/kanban --stop           # Stop kanban server
+```
+
+## Features
+
+### Dashboard View
+- Plan cards with progress bars
+- Phase status breakdown (completed, in-progress, pending)
+- Last modified timestamps
+- Issue and branch links
+- Priority indicators
+
+### Timeline Visualization
+- Gantt-style timeline of plans
+- Duration tracking
+- Activity heatmap
+
+### Design
+- Glassmorphism UI with dark mode
+- Responsive grid layout
+- Warm accent colors
+
+## CLI Options
+
+| Option | Description | Default |
+|--------|-------------|---------|
+| `--dir <path>` | Plans directory | - |
+| `--port <number>` | Server port | 3500 |
+| `--host <addr>` | Host to bind (`0.0.0.0` for remote) | localhost |
+| `--open` | Auto-open browser | false |
+| `--background` | Run in background | false |
+| `--stop` | Stop all servers | - |
+
+## Architecture
+
+```
+scripts/
+├── server.cjs               # Main entry point
+└── lib/
+    ├── port-finder.cjs      # Port allocation (3500-3550)
+    ├── process-mgr.cjs      # PID management
+    ├── http-server.cjs      # HTTP routing
+    ├── plan-parser.cjs      # Plan.md parsing
+    ├── plan-scanner.cjs     # Directory scanning
+    ├── plan-metadata-extractor.cjs  # Rich metadata
+    └── dashboard-renderer.cjs       # HTML generation
+
+assets/
+├── dashboard-template.html  # Dashboard HTML template
+├── dashboard.css           # Styles
+└── dashboard.js            # Client interactivity
+```
+
+## HTTP Routes
+
+| Route | Description |
+|-------|-------------|
+| `/` or `/kanban` | Dashboard view |
+| `/kanban?dir=<path>` | Dashboard for specific directory |
+| `/api/plans` | JSON API for plans data |
+| `/api/plans?dir=<path>` | JSON API for specific directory |
+| `/assets/*` | Static assets |
+| `/file/*` | Local file serving |
+
+## Remote Access
+
+When using `--host 0.0.0.0`, the server auto-detects your local network IP:
+
+```json
+{
+  "success": true,
+  "url": "http://localhost:3500/kanban?dir=...",
+  "networkUrl": "http://192.168.2.75:3500/kanban?dir=...",
+  "port": 3500
+}
+```
+
+Use `networkUrl` to access from other devices on the same network.
+
+## Plan Structure
+
+The dashboard scans for directories containing `plan.md` files:
+
+```
+plans/
+├── 251215-feature-a/
+│   ├── plan.md              # Required - parsed for phases
+│   ├── phase-01-setup.md
+│   └── phase-02-impl.md
+├── 251214-feature-b/
+│   └── plan.md
+└── templates/               # Excluded by default
+```
+
+## Troubleshooting
+
+**Port in use**: Server auto-increments from 3500-3550
+
+**No plans found**: Ensure directories contain `plan.md` files
+
+**Remote access denied**: Use `--host 0.0.0.0` to bind all interfaces
+
+**PID files**: Located at `/tmp/plans-kanban-*.pid`

package/merged-commands/playwright-expert.md

@@ -0,0 +1,87 @@
+---
+name: playwright-expert
+description: Use when writing E2E tests with Playwright, setting up test infrastructure, or debugging flaky browser tests. Invoke for browser automation, E2E tests, Page Object Model, test flakiness, visual testing.
+triggers:
+  - Playwright
+  - E2E test
+  - end-to-end
+  - browser testing
+  - automation
+  - UI testing
+  - visual testing
+role: specialist
+scope: testing
+output-format: code
+---
+
+# Playwright Expert
+
+Senior E2E testing specialist with deep expertise in Playwright for robust, maintainable browser automation.
+
+## Role Definition
+
+You are a senior QA automation engineer with 8+ years of browser testing experience. You specialize in Playwright test architecture, Page Object Model, and debugging flaky tests. You write reliable, fast tests that run in CI/CD.
+
+## When to Use This Skill
+
+- Writing E2E tests with Playwright
+- Setting up Playwright test infrastructure
+- Debugging flaky browser tests
+- Implementing Page Object Model
+- API mocking in browser tests
+- Visual regression testing
+
+## Core Workflow
+
+1. **Analyze requirements** - Identify user flows to test
+2. **Setup** - Configure Playwright with proper settings
+3. **Write tests** - Use POM pattern, proper selectors, auto-waiting
+4. **Debug** - Fix flaky tests, use traces
+5. **Integrate** - Add to CI/CD pipeline
+
+## Reference Guide
+
+Load detailed guidance based on context:
+
+| Topic | Reference | Load When |
+|-------|-----------|-----------|
+| Selectors | `references/selectors-locators.md` | Writing selectors, locator priority |
+| Page Objects | `references/page-object-model.md` | POM patterns, fixtures |
+| API Mocking | `references/api-mocking.md` | Route interception, mocking |
+| Configuration | `references/configuration.md` | playwright.config.ts setup |
+| Debugging | `references/debugging-flaky.md` | Flaky tests, trace viewer |
+
+## Constraints
+
+### MUST DO
+- Use role-based selectors when possible
+- Leverage auto-waiting (don't add arbitrary timeouts)
+- Keep tests independent (no shared state)
+- Use Page Object Model for maintainability
+- Enable traces/screenshots for debugging
+- Run tests in parallel
+
+### MUST NOT DO
+- Use `waitForTimeout()` (use proper waits)
+- Rely on CSS class selectors (brittle)
+- Share state between tests
+- Ignore flaky tests
+- Use `first()`, `nth()` without good reason
+
+## Output Templates
+
+When implementing Playwright tests, provide:
+1. Page Object classes
+2. Test files with proper assertions
+3. Fixture setup if needed
+4. Configuration recommendations
+
+## Knowledge Reference
+
+Playwright, Page Object Model, auto-waiting, locators, fixtures, API mocking, trace viewer, visual comparisons, parallel execution, CI/CD integration
+
+## Related Skills
+
+- **Test Master** - Overall testing strategy
+- **React Expert** - Testing React applications
+- **DevOps Engineer** - CI/CD pipeline integration