ccjk 1.5.0 → 2.0.2

package/templates/common/skills/en/executing-plans.md

@@ -0,0 +1,75 @@
+---
+name: executing-plans
+description: Execute implementation plans with checkpoint verification
+version: 1.0.0
+author: CCJK
+category: dev
+triggers:
+  - /execute
+  - /ep
+  - /run-plan
+use_when:
+  - "User has approved plan"
+  - "Ready to implement"
+  - "User mentions executing or starting implementation"
+auto_activate: false
+priority: 6
+difficulty: intermediate
+tags:
+  - execution
+  - implementation
+  - checkpoints
+---
+
+# Executing Plans
+
+## Context
+$ARGUMENTS
+
+## Instructions
+
+Execute the implementation plan systematically:
+
+### Execution Protocol
+
+1. **Before Each Step**
+   - Confirm current step with user
+   - Check prerequisites are met
+   - Identify potential blockers
+
+2. **During Implementation**
+   - Work in small, verifiable increments
+   - Write tests before production code (TDD)
+   - Commit frequently with clear messages
+
+3. **At Checkpoints**
+   - Verify all criteria are met
+   - Run relevant tests
+   - Get user confirmation before proceeding
+
+4. **If Issues Arise**
+   - Stop and report the issue
+   - Propose solutions
+   - Wait for user decision
+
+### Checkpoint Verification
+
+```markdown
+## Checkpoint: [Name]
+
+### Completed Steps
+- [x] Step 1
+- [x] Step 2
+
+### Verification
+- [ ] Tests passing
+- [ ] Code reviewed
+- [ ] Documentation updated
+
+### Ready to proceed? (y/n)
+```
+
+### Rules
+- Never skip checkpoints
+- Always verify before moving forward
+- Document any deviations from plan

package/templates/common/skills/en/git-commit.md

@@ -0,0 +1,216 @@
+---
+name: git-commit
+description: Smart commit message generation with conventional commits
+version: 1.0.0
+author: CCJK
+category: git
+triggers:
+  - /commit
+  - /gc
+  - /git-commit
+use_when:
+  - "User wants to commit changes"
+  - "User mentions commit or committing"
+  - "User has staged changes ready"
+  - "Working with git repository"
+auto_activate: true
+priority: 7
+difficulty: beginner
+tags:
+  - git
+  - commit
+  - conventional-commits
+---
+
+# Claude Command: Commit (Git-only)
+
+This command works **without any package manager/build tools**, using only **Git** to:
+
+- Read changes (staged/unstaged)
+- Determine if changes should be **split into multiple commits**
+- Generate **Conventional Commits** style messages with optional emoji for each commit
+- Execute `git add` and `git commit` as needed (runs local Git hooks by default; use `--no-verify` to skip)
+
+---
+
+## Usage
+
+```bash
+/git-commit
+/git-commit --no-verify
+/git-commit --emoji
+/git-commit --all --signoff
+/git-commit --amend
+/git-commit --scope ui --type feat --emoji
+```
+
+### Options
+
+- `--no-verify`: Skip local Git hooks (`pre-commit`/`commit-msg` etc.).
+- `--all`: When staging area is empty, automatically `git add -A` to include all changes in the commit.
+- `--amend`: **Amend** the last commit without creating a new one (preserves author and timestamp unless local Git config specifies otherwise).
+- `--signoff`: Add `Signed-off-by` line (use when following DCO process).
+- `--emoji`: Include emoji prefix in commit message (omit for plain text).
+- `--scope <scope>`: Specify commit scope (e.g., `ui`, `docs`, `api`), written to message header.
+- `--type <type>`: Force commit type (e.g., `feat`, `fix`, `docs`), overrides automatic detection.
+
+> Note: If the framework doesn't support interactive confirmation, enable `confirm: true` in front-matter to avoid mistakes.
+
+---
+
+## What This Command Does
+
+1. **Repository/Branch Validation**
+   - Check if in a Git repository using `git rev-parse --is-inside-work-tree`.
+   - Read current branch/HEAD status; if in rebase/merge conflict state, prompt to resolve conflicts first.
+
+2. **Change Detection**
+   - Get staged and unstaged changes using `git status --porcelain` and `git diff`.
+   - If staged files = 0:
+     - If `--all` is passed → Execute `git add -A`.
+     - Otherwise prompt choice: continue analyzing unstaged changes for **suggestions**, or cancel to manually group staging.
+
+3. **Split Suggestions (Split Heuristics)**
+   - Cluster by **concerns**, **file modes**, **change types** (e.g., source code vs docs/tests; different directories/packages; additions vs deletions).
+   - If **multiple independent changesets** or large diff detected (e.g., > 300 lines / across multiple top-level directories), suggest splitting commits with pathspecs for each group (for subsequent `git add <paths>`).
+
+4. **Commit Message Generation (Conventional with Optional Emoji)**
+   - Auto-infer `type` (`feat`/`fix`/`docs`/`refactor`/`test`/`chore`/`perf`/`style`/`ci`/`revert`...) and optional `scope`.
+   - Generate message header: `[<emoji>] <type>(<scope>)?: <subject>` (first line ≤ 72 chars, imperative mood, emoji included only with `--emoji` flag).
+   - Generate message body:
+     - Must have a blank line after the subject.
+     - Use list format, each item starts with `-`.
+     - Each item **must use imperative verb-first sentences** (e.g., "add…", "fix…", "update…").
+     - **Colon-separated formats are prohibited** (e.g., ~~"Feature: description"~~, ~~"Impl: content"~~).
+     - Describe the motivation, implementation details, or impact scope (3 items or fewer recommended).
+   - Generate message footer (if any):
+     - Must have a blank line after the Body.
+     - **BREAKING CHANGE**: If there are breaking changes, must include `BREAKING CHANGE: <description>`, or add exclamation mark after type (e.g., `feat!:`).
+     - Other footers use git trailer format (e.g., `Closes #123`, `Refs: #456`, `Reviewed-by: Name`).
+   - Select message language to match the predominant language in Git history. Inspect recent commit subjects (e.g., `git log -n 50 --pretty=%s`) to decide Chinese vs English; if unclear, fall back to the repository's primary locale or English.
+   - Write draft to `.git/COMMIT_EDITMSG` for use with `git commit`.
+
+5. **Execute Commit**
+   - Single commit scenario: `git commit [-S] [--no-verify] [-s] -F .git/COMMIT_EDITMSG`
+   - Multiple commit scenario (if split accepted): Provide clear instructions for `git add <paths> && git commit ...` per group; execute sequentially if allowed.
+
+6. **Safe Rollback**
+   - If mistakenly staged, use `git restore --staged <paths>` to unstage (command provides instructions, doesn't modify file contents).
+
+---
+
+## Best Practices for Commits
+
+- **Atomic commits**: One commit does one thing, easier to trace and review.
+- **Group before committing**: Split by directory/module/feature.
+- **Clear subject**: First line ≤ 72 chars, imperative mood.
+- **Body with context**: Explain motivation, solution, and impact scope (colon-separated formats prohibited).
+- **Follow Conventional Commits**: `<type>(<scope>): <subject>`.
+
+---
+
+## Type to Emoji Mapping (When --emoji is Used)
+
+- ✨ `feat`: New feature
+- 🐛 `fix`: Bug fix (includes 🔥 remove code/files, 🚑️ hotfix, 👽️ adapt to external API changes, 🔒️ security fix, 🚨 fix warnings, 💚 fix CI)
+- 📝 `docs`: Documentation and comments
+- 🎨 `style`: Code style/formatting (no semantic changes)
+- ♻️ `refactor`: Refactoring (no new features, no bug fixes)
+- ⚡️ `perf`: Performance improvements
+- ✅ `test`: Add/fix tests, snapshots
+- 🔧 `chore`: Build/tools/misc tasks (merge branches, update configs, release tags, pin dependencies, .gitignore, etc.)
+- 👷 `ci`: CI/CD configuration and scripts
+- ⏪️ `revert`: Revert commits
+- 💥 `feat`: Breaking changes (explained in `BREAKING CHANGE:` section)
+
+> If `--type`/`--scope` is passed, it will **override** auto-detection.
+> Emoji is only included when `--emoji` flag is specified.
+
+---
+
+## Guidelines for Splitting Commits
+
+1. **Different concerns**: Unrelated feature/module changes should be split.
+2. **Different types**: Don't mix `feat`, `fix`, `refactor` in the same commit.
+3. **File modes**: Source code vs docs/tests/configs should be grouped separately.
+4. **Size threshold**: Large diffs (e.g., >300 lines or across multiple top-level directories) should be split.
+5. **Revertability**: Ensure each commit can be independently reverted.
+
+---
+
+## Examples
+
+**Good (with --emoji)**
+
+```text
+- ✨ feat(ui): add user authentication flow
+- 🐛 fix(api): handle token refresh race condition
+- 📝 docs: update API usage examples
+- ♻️ refactor(core): extract retry logic into helper
+- ✅ test: add unit tests for rate limiter
+- 🔧 chore: update git hooks and repository settings
+- ⏪️ revert: revert "feat(core): introduce streaming API"
+```
+
+**Good (without --emoji)**
+
+```text
+- feat(ui): add user authentication flow
+- fix(api): handle token refresh race condition
+- docs: update API usage examples
+- refactor(core): extract retry logic into helper
+- test: add unit tests for rate limiter
+- chore: update git hooks and repository settings
+- revert: revert "feat(core): introduce streaming API"
+```
+
+**Good (with Body)**
+
+```text
+feat(auth): add OAuth2 login flow
+
+- implement Google and GitHub third-party login
+- add user authorization callback handling
+- improve login state persistence logic
+
+Closes #42
+```
+
+```text
+fix(ui): fix button spacing on mobile devices
+
+- adjust button padding to fit small screens
+- fix styling issues on iOS Safari
+- optimize touch target size
+```
+
+**Good (with BREAKING CHANGE)**
+
+```text
+feat(api)!: redesign authentication API
+
+- migrate from session-based to JWT authentication
+- update all endpoint signatures
+- remove deprecated login methods
+
+BREAKING CHANGE: authentication API has been completely redesigned, all clients must update their integration
+```
+
+**Split Example**
+
+```text
+- `feat(types): add new type defs for payment method`
+- `docs: update API docs for new types`
+- `test: add unit tests for payment types`
+- `fix: address linter warnings in new files` ← (if your repo has hook errors)
+```
+
+---
+
+## Important Notes
+
+- **Git only**: No package manager/build commands (`pnpm`/`npm`/`yarn` etc.).
+- **Respects hooks**: Executes local Git hooks by default; use `--no-verify` to skip.
+- **No source code changes**: Command only reads/writes `.git/COMMIT_EDITMSG` and staging area; doesn't directly edit working directory files.
+- **Safety prompts**: In rebase/merge conflicts, detached HEAD states, prompts to handle/confirm before continuing.
+- **Auditable and controllable**: If `confirm: true` is enabled, each actual `git add`/`git commit` step requires confirmation.

package/templates/common/skills/en/interview.md

@@ -0,0 +1,223 @@
+---
+name: interview
+description: Interview-Driven Development - gather requirements through structured conversation
+version: 1.0.0
+author: CCJK
+category: planning
+triggers:
+  - /interview
+  - /idd
+use_when:
+  - "User wants to start a new feature with requirements gathering"
+  - "User mentions interview or requirements"
+  - "User asks about understanding project needs"
+  - "Starting a new project or feature"
+auto_activate: false
+priority: 5
+difficulty: beginner
+tags:
+  - requirements
+  - planning
+  - discovery
+---
+
+# Interview-Driven Development
+
+> **Core Principle**: "Interview first. Spec second. Code last."
+>
+> Based on the viral workflow by Thariq (@trq212) from Anthropic's Claude Code team (1.2M views)
+
+## Usage
+
+```bash
+/ccjk:interview [SPEC_FILE.md] [--deep] [--quick] [--category <type>]
+```
+
+## The Problem This Solves
+
+**The Gap in Traditional Prompting:**
+```
+Prompt -> Claude Assumes -> Code That's "Close" -> Rework
+"Add auth" -> "JWT? OAuth? Sessions?" -> Wrong implementation -> "Actually I wanted..."
+```
+
+Hidden assumptions are buried and discovered during code review. The Interview approach surfaces these decisions **before** any code is written.
+
+## Your Role
+
+You are an expert requirements analyst and technical interviewer. Your job is to surface every hidden assumption, edge case, and decision point that the user hasn't explicitly stated. Ask non-obvious questions that the user didn't know they needed to answer.
+
+## Interview Dimensions
+
+Ask about literally anything across these dimensions:
+
+### Technical Implementation
+- Architecture patterns and decisions
+- Data models and relationships
+- API design and integrations
+- State management approach
+- Error handling strategies
+
+### UI & UX
+- User flows and interactions
+- Accessibility requirements
+- Responsive design needs
+- Loading states and feedback
+- Edge cases in the interface
+
+### Concerns
+- Security requirements
+- Performance constraints
+- Scalability needs
+- Data privacy (GDPR, HIPAA, etc.)
+- Edge cases and error scenarios
+
+### Tradeoffs
+- Build vs buy decisions
+- Complexity vs simplicity
+- Speed vs quality
+- Flexibility vs simplicity
+- Short-term vs long-term
+
+### Business Logic
+- Validation rules
+- Workflow states
+- Business constraints
+- Integration requirements
+- Reporting needs
+
+## Interview Rules
+
+1. **Non-obvious questions only** - Don't ask what's clearly stated in the spec
+2. **Go very in-depth** - Surface decisions the user didn't know they needed to make
+3. **Continue until complete** - For big features, ask 40+ questions
+4. **Use progress indicators** - Show category progress (Industry -> Customer -> Features -> Validation -> Submit)
+5. **Provide context** - Each option should have a brief description
+6. **Allow custom input** - Always include "Type something..." as the last option
+7. **Write spec when done** - Output detailed specification to the spec file
+
+## Question Format
+
+Use the AskUserQuestion tool with this structure:
+
+```json
+{
+  "questions": [
+    {
+      "header": "Category",
+      "question": "Clear, specific question?",
+      "multiSelect": false,
+      "options": [
+        { "label": "Option 1", "description": "Brief explanation of what this means" },
+        { "label": "Option 2", "description": "Brief explanation of what this means" }
+      ]
+    }
+  ]
+}
+```
+
+## Common Question Patterns
+
+### Project Foundation
+- What is the primary purpose of this app? (SaaS/Web App, Marketing/Landing, E-commerce, Dashboard/Admin, API Service)
+- What is your target platform? (Web, Mobile Native, Mobile PWA, Desktop, CLI)
+
+### Target Audience
+- What's your target customer segment? (SMB, Enterprise, Individual/Prosumer, Developers/Technical)
+- Geographic focus? (Global, US/EU, Asia, Specific country)
+
+### Technical Decisions
+- Authentication strategy? (JWT tokens, OAuth 2.0, Session-based, Magic links, SSO/SAML)
+- Primary database? (PostgreSQL, MySQL, MongoDB, SQLite, Supabase)
+- State management? (Server state, Global store, URL state, Local state only)
+
+### Features & Scope
+- Which features are must-have for MVP? (Multi-select)
+- Third-party integrations needed? (Multi-select)
+
+### Security & Compliance
+- Security requirements? (Standard, SOC2, HIPAA, GDPR, PCI DSS)
+- Data retention policy?
+
+### Tradeoffs
+- Speed vs Quality tradeoff? (Ship fast, Get it right, Balanced)
+- Build vs Buy preference? (Build custom, Use services, Hybrid)
+
+## Progress Display
+
+Show progress at each question:
+
+```
+Category Progress: [X] Industry -> [ ] Customer -> [ ] Features -> [ ] Validation
+
+Question 12 of ~40: What's your target customer segment?
+```
+
+## Interview Depth Levels
+
+- **--quick**: 10 questions - Fast validation, surface-level decisions
+- **default**: 25 questions - Standard coverage of all major areas
+- **--deep**: 40+ questions - Comprehensive exploration for complex features
+
+## Output Format
+
+After interview completion, write comprehensive spec to the specified file:
+
+```markdown
+# Feature Specification: [Feature Name]
+
+Generated: [timestamp]
+Interview Questions: [count]
+
+## Overview
+- Project Type: [answer]
+- Target Audience: [answer]
+- MVP Scope: [answer]
+
+## Technical Architecture
+- Authentication: [answer]
+- Database: [answer]
+- State Management: [answer]
+- Integrations: [list]
+
+## UI/UX Requirements
+- Platforms: [list]
+- Design System: [answer]
+- Accessibility: [answer]
+
+## Security & Compliance
+- Requirements: [list]
+- Compliance: [list]
+
+## Decisions Made
+1. [Decision with rationale]
+2. [Decision with rationale]
+...
+
+## Edge Cases Identified
+1. [Edge case and how to handle]
+2. [Edge case and how to handle]
+...
+
+## Open Questions
+1. [Questions to revisit later]
+...
+```
+
+## Execution Flow
+
+1. **Read spec file** (if provided) - Understand existing context
+2. **Determine interview depth** - quick (10), standard (25), or deep (40+)
+3. **Start with foundation questions** - Project type, audience, platform
+4. **Progress through categories** - Technical, Features, Security, Tradeoffs
+5. **Ask follow-up questions** - Based on previous answers
+6. **Summarize decisions** - Recap key choices made
+7. **Write specification** - Generate comprehensive spec file
+
+## Begin Interview
+
+**Spec File**: $ARGUMENTS (or create new spec file)
+
+Start the interview session. Read any existing spec file first, then begin asking questions using the AskUserQuestion tool. Show progress after each question and continue until all necessary information is gathered.
+
+Remember: Your goal is to ensure the user has thought through every important decision BEFORE any code is written. This prevents wasted effort and "Actually, I wanted..." moments later.