aiblueprint-cli 1.4.22 → 1.4.24

package/claude-code-config/skills/git-commit/SKILL.md

@@ -0,0 +1,42 @@
+---
+name: commit
+description: Quick commit and push with minimal, clean messages
+model: haiku
+allowed-tools: Bash(git :*), Bash(npm :*), Bash(pnpm :*)
+---
+
+# Commit
+
+Quick commit with conventional message format, then push.
+
+## Context
+
+- Git state: !`git status`
+- Staged changes: !`git diff --cached --stat`
+- Unstaged changes: !`git diff --stat`
+- Recent commits: !`git log --oneline -5`
+- Current branch: !`git branch --show-current`
+
+## Workflow
+
+1. **Analyze**: Review git status
+   - Nothing staged but unstaged changes exist: `git add .`
+   - Nothing to commit: inform user and exit
+
+2. **Generate commit message**:
+   - Format: `type(scope): brief description`
+   - Types: `feat`, `fix`, `update`, `docs`, `chore`, `refactor`, `test`, `perf`, `revert`
+   - Under 72 chars, imperative mood, lowercase after colon
+   - Example: `update(statusline): refresh spend data`
+
+3. **Commit**: `git commit -m "message"`
+
+4. **Push**: `git push`
+
+## Rules
+
+- SPEED OVER PERFECTION: Generate one good message and commit
+- NO INTERACTION: Never ask questions - analyze and commit
+- AUTO-STAGE: If nothing staged, stage everything
+- AUTO-PUSH: Always push after committing
+- IMPERATIVE MOOD: "add", "update", "fix" not past tense

package/claude-code-config/{commands/git/create-pr.md → skills/git-create-pr/SKILL.md}

@@ -1,10 +1,13 @@
 ---
-allowed-tools: Bash(git :*), Bash(gh :*)
+name: create-pr
 description: Create and push PR with auto-generated title and description
 model: haiku
+allowed-tools: Bash(git :*), Bash(gh :*)
 ---
 
-You are a PR automation tool. Create pull requests with concise, meaningful descriptions.
+# Create PR
+
+Create pull request with concise, meaningful description.
 
 ## Context
 
@@ -15,14 +18,11 @@ You are a PR automation tool. Create pull requests with concise, meaningful desc
 
 ## Workflow
 
-1. **Verify**: `git status` and `git branch --show-current` to check state
-2. **Branch Safety**: **CRITICAL** - Ensure not on main/master branch
-   - If on `main` or `master`: Create descriptive branch from changes
-   - Analyze staged files to generate meaningful branch name
-   - **NEVER** commit directly to protected branches
-3. **Push**: `git push -u origin HEAD` to ensure remote tracking
-4. **Analyze**: `git diff origin/main...HEAD --stat` to understand changes
-5. **Generate**: Create PR with:
+1. **Verify**: Check `git status` and current branch
+2. **Branch Safety**: **CRITICAL** - If on main/master, create descriptive branch from changes
+3. **Push**: `git push -u origin HEAD`
+4. **Analyze**: `git diff origin/main...HEAD --stat`
+5. **Generate PR**:
    - Title: One-line summary (max 72 chars)
    - Body: Bullet points of key changes
 6. **Submit**: `gh pr create --title "..." --body "..."`
@@ -42,7 +42,7 @@ You are a PR automation tool. Create pull requests with concise, meaningful desc
 [feat/fix/refactor/docs/chore]
 ```
 
-## Execution Rules
+## Rules
 
 - NO verbose descriptions
 - NO "Generated with" signatures
@@ -50,10 +50,4 @@ You are a PR automation tool. Create pull requests with concise, meaningful desc
 - Use HEREDOC for multi-line body
 - If PR exists, return existing URL
 
-## Priority
-
-Clarity > Completeness. Keep PRs scannable and actionable.
-
----
-
-User: #$ARGUMENTS
+User: $ARGUMENTS

package/claude-code-config/skills/git-fix-pr-comments/SKILL.md

@@ -0,0 +1,51 @@
+---
+name: fix-pr-comments
+description: Fetch PR review comments and implement all requested changes
+allowed-tools: Bash(gh :*), Bash(git :*), Read, Edit, MultiEdit
+---
+
+# Fix PR Comments
+
+Systematically address ALL unresolved review comments until PR is approved.
+
+## Context
+
+- Current branch: !`git branch --show-current`
+- Working tree status: !`git status --short`
+- Recent commits: !`git log --oneline -3`
+
+## Workflow
+
+1. **FETCH COMMENTS**:
+   - Identify PR: `gh pr status --json number,headRefName`
+   - Get reviews: `gh pr review list --state CHANGES_REQUESTED`
+   - Get inline: `gh api repos/{owner}/{repo}/pulls/{number}/comments`
+   - Capture BOTH review comments AND inline code comments
+   - STOP if no PR found - ask user for PR number
+
+2. **ANALYZE & PLAN**:
+   - Extract exact file:line references
+   - Group by file for MultiEdit efficiency
+   - STAY IN SCOPE: NEVER fix unrelated issues
+   - Create checklist: one item per comment
+
+3. **IMPLEMENT FIXES**:
+   - BEFORE editing: ALWAYS `Read` target file first
+   - Batch changes with `MultiEdit` for same-file modifications
+   - Make EXACTLY what reviewer requested
+   - Check off each resolved comment
+
+4. **COMMIT & PUSH**:
+   - Stage: `git add -A`
+   - Commit: `fix: address PR review comments`
+   - Push: `git push`
+   - NEVER include co-author tags
+
+## Rules
+
+- Every unresolved comment MUST be addressed
+- Read files BEFORE any edits - no exceptions
+- FORBIDDEN: Style changes beyond reviewer requests
+- On failure: Return to ANALYZE phase, never skip comments
+
+User: $ARGUMENTS

package/claude-code-config/skills/git-merge/SKILL.md

@@ -0,0 +1,68 @@
+---
+name: merge
+description: Intelligently merge branches with context-aware conflict resolution
+allowed-tools: Bash(git :*), Bash(gh :*), Read, Edit, MultiEdit, Task
+argument-hint: <branch-name>
+---
+
+# Merge
+
+Merge branches intelligently by understanding feature context and resolving conflicts efficiently.
+
+## Context
+
+- Current branch: !`git branch --show-current`
+- Working tree status: !`git status --short`
+- Target branch: $1
+- Recent commits: !`git log --oneline -5`
+
+## Workflow
+
+1. **CONTEXT GATHERING**:
+   - `git branch --show-current` to identify current branch
+   - `git status` to ensure clean working tree
+   - **CRITICAL**: Abort if uncommitted changes exist
+
+2. **FEATURE ANALYSIS**:
+   - Search PR with `gh pr list --head <branch-name>`
+   - Get PR details with `gh pr view <number> --json title,body,files`
+   - Use Task agents to gather context from PR/issue descriptions
+
+3. **MERGE ATTEMPT**:
+   - `git fetch origin <branch-name>`
+   - `git merge origin/<branch-name> --no-commit`
+   - Check status with `git status --porcelain`
+
+4. **CONFLICT DETECTION**:
+   - Clean merge: `git commit` with descriptive message
+   - Conflicts: Parse `git diff --name-only --diff-filter=U`
+
+5. **SMART RESOLUTION**: For each conflicted file:
+   - Read file to understand conflict markers
+   - Apply resolution based on context:
+     - **Feature additions**: Keep both if non-overlapping
+     - **Bug fixes**: Prefer incoming if fixing known issue
+     - **Refactors**: Analyze intent and merge carefully
+   - Use MultiEdit to resolve all conflicts
+   - **STOP**: If >10 files conflicted, ask user
+
+6. **VERIFICATION**:
+   - `git diff --cached` to review changes
+   - Check no conflict markers remain: `grep -r "<<<<<<< HEAD"`
+   - `git add -A` and commit
+
+## Conflict Resolution by Type
+
+- **package.json**: Merge dependencies, prefer higher versions
+- **Config files**: Combine settings unless mutually exclusive
+- **Source code**: Use PR/issue context to understand intent
+- **Tests**: Keep all tests unless duplicates
+- **Imports**: Merge all, deduplicate
+
+## Rules
+
+- ALWAYS gather context before merging
+- NEVER blindly accept theirs/ours without analysis
+- ABORT if conflicts exceed 10 files
+- Max 3 resolution attempts per file
+- If stuck: `git merge --abort` and report blockers

package/claude-code-config/skills/{claude-memory → meta-claude-memory}/SKILL.md

@@ -144,7 +144,8 @@ Rules can be scoped to specific files using YAML frontmatter:
 
 ```yaml
 ---
-paths: src/api/**/*.ts
+paths:
+  - "src/api/**/*.ts"
 ---
 # API Development Rules
 
@@ -162,6 +163,8 @@ paths: src/api/**/*.ts
 | `src/**/*.{ts,tsx}`    | TypeScript and TSX files (brace expansion) |
 | `{src,lib}/**/*.ts`    | Files in multiple directories              |
 
+**Syntax note:** The `paths` field must be a YAML array (list format with `-` prefix and quoted strings).
+
 **Rules without `paths` frontmatter** load unconditionally for all files.
 </path_scoped_rules>
 
@@ -576,7 +579,8 @@ Use AskUserQuestion to present these options before proceeding.
 3. Add path-scoped rules as needed:
    ```yaml
    ---
-   paths: src/api/**/*.ts
+   paths:
+     - "src/api/**/*.ts"
    ---
    # API rules here
    ```
@@ -682,6 +686,7 @@ A well-crafted Claude memory system:
 <reference_guides>
 For deeper topics:
 
+- **Rules directory guide**: [references/rules-directory-guide.md](references/rules-directory-guide.md) - Complete guide to .claude/rules/ with official documentation, path-scoping, YAML syntax, and examples
 - **Prompting techniques**: [references/prompting-techniques.md](references/prompting-techniques.md) - Master guide for writing effective instructions, emphasis strategies, clarity techniques
 - **Comprehensive example**: [references/comprehensive-example.md](references/comprehensive-example.md) - Full production SaaS CLAUDE.md
 - **Section templates**: [references/section-templates.md](references/section-templates.md) - Copy-paste templates for each section

package/claude-code-config/skills/meta-claude-memory/references/rules-directory-guide.md

@@ -0,0 +1,298 @@
+# .claude/rules/ Directory - Official Guide
+
+Complete guide to using modular rules with `.claude/rules/` directory, based on official Claude Code documentation.
+
+## Overview
+
+For larger projects, organize instructions into multiple files using the `.claude/rules/` directory. This allows teams to maintain focused, well-organized rule files instead of one large CLAUDE.md.
+
+## Basic Structure
+
+Place markdown files in your project's `.claude/rules/` directory:
+
+```
+your-project/
+├── .claude/
+│   ├── CLAUDE.md           # Main project instructions
+│   └── rules/
+│       ├── code-style.md   # Code style guidelines
+│       ├── testing.md      # Testing conventions
+│       └── security.md     # Security requirements
+```
+
+**Key points:**
+- All `.md` files in `.claude/rules/` are automatically loaded as project memory
+- Same priority as `.claude/CLAUDE.md`
+- No imports or configuration needed
+
+## Path-Specific Rules
+
+Rules can be scoped to specific files using YAML frontmatter with the `paths` field. These conditional rules only apply when Claude is working with files matching the specified patterns.
+
+### Syntax
+
+```yaml
+---
+paths:
+  - "src/api/**/*.ts"
+---
+
+# API Development Rules
+
+- All API endpoints must include input validation
+- Use the standard error response format
+- Include OpenAPI documentation comments
+```
+
+**Important:**
+- `paths` must be a YAML array (list format with `-` prefix)
+- Rules **without** a `paths` field are loaded unconditionally
+- Conditional rules only load when working with matching files
+
+### Glob Patterns
+
+The `paths` field supports standard glob patterns:
+
+| Pattern                | Matches                                  |
+| ---------------------- | ---------------------------------------- |
+| `**/*.ts`              | All TypeScript files in any directory    |
+| `src/**/*`             | All files under `src/` directory         |
+| `*.md`                 | Markdown files in the project root       |
+| `src/components/*.tsx` | React components in a specific directory |
+
+### Multiple Patterns
+
+Specify multiple patterns in the array:
+
+```yaml
+---
+paths:
+  - "src/**/*.ts"
+  - "lib/**/*.ts"
+  - "tests/**/*.test.ts"
+---
+```
+
+### Brace Expansion
+
+Use brace expansion for matching multiple extensions or directories:
+
+```yaml
+---
+paths:
+  - "src/**/*.{ts,tsx}"
+  - "{src,lib}/**/*.ts"
+---
+
+# TypeScript/React Rules
+```
+
+This expands `src/**/*.{ts,tsx}` to match both `.ts` and `.tsx` files.
+
+## Subdirectories
+
+Rules can be organized into subdirectories for better structure:
+
+```
+.claude/rules/
+├── frontend/
+│   ├── react.md
+│   └── styles.md
+├── backend/
+│   ├── api.md
+│   └── database.md
+└── general.md
+```
+
+All `.md` files are discovered recursively in any subdirectory depth.
+
+## Symlinks
+
+The `.claude/rules/` directory supports symlinks, allowing you to share common rules across multiple projects:
+
+```bash
+# Symlink a shared rules directory
+ln -s ~/shared-claude-rules .claude/rules/shared
+
+# Symlink individual rule files
+ln -s ~/company-standards/security.md .claude/rules/security.md
+```
+
+**Behavior:**
+- Symlinks are resolved and their contents are loaded normally
+- Circular symlinks are detected and handled gracefully
+- Great for sharing company standards across projects
+
+## User-Level Rules
+
+Create personal rules that apply to all your projects in `~/.claude/rules/`:
+
+```
+~/.claude/rules/
+├── preferences.md    # Your personal coding preferences
+└── workflows.md      # Your preferred workflows
+```
+
+**Priority:**
+- User-level rules load before project rules
+- Project rules take higher priority (can override user rules)
+- User rules typically **don't** need `paths` frontmatter (apply globally)
+
+## Examples
+
+### Unconditional Project Rule
+
+File: `.claude/rules/testing.md`
+
+```markdown
+# Testing Conventions
+
+- Write tests in `__tests__/` directories
+- Use Vitest for unit tests
+- Minimum 80% coverage for new code
+- Run `pnpm test` before committing
+```
+
+No frontmatter needed - applies to entire project.
+
+### Path-Specific Rule
+
+File: `.claude/rules/api-standards.md`
+
+```yaml
+---
+paths:
+  - "src/api/**/*.ts"
+  - "src/routes/**/*.ts"
+---
+
+# API Development Standards
+
+- All endpoints must validate input with Zod
+- Use standard error response format
+- Include rate limiting for public endpoints
+- Document with OpenAPI comments
+```
+
+Only loads when working with API-related TypeScript files.
+
+### Frontend-Specific Rules
+
+File: `.claude/rules/frontend/react.md`
+
+```yaml
+---
+paths:
+  - "src/components/**/*.{tsx,ts}"
+  - "src/app/**/*.tsx"
+---
+
+# React Component Guidelines
+
+- Prefer Server Components (Next.js App Router)
+- Use `"use client"` only when needed for interactivity
+- Keep components under 300 lines
+- Extract hooks to separate files
+```
+
+### User-Level Global Rule
+
+File: `~/.claude/rules/preferences.md`
+
+```markdown
+# My Personal Coding Preferences
+
+- I prefer concise variable names (no unnecessary verbosity)
+- Always add error boundaries around async operations
+- Use early returns to reduce nesting
+```
+
+No frontmatter - applies to all projects globally.
+
+## Best Practices
+
+### Keep Rules Focused
+
+Each file should cover one topic:
+- ✅ `testing.md` - All testing conventions
+- ✅ `api-design.md` - API-specific patterns
+- ✅ `security.md` - Security requirements
+- ❌ `everything.md` - Mixed concerns
+
+### Use Descriptive Filenames
+
+The filename should indicate what the rules cover:
+- ✅ `database-migrations.md`
+- ✅ `error-handling.md`
+- ❌ `stuff.md`
+- ❌ `misc.md`
+
+### Use Conditional Rules Sparingly
+
+Only add `paths` frontmatter when rules **truly** apply to specific file types:
+- ✅ API validation rules → `paths: ["src/api/**/*.ts"]`
+- ✅ React component rules → `paths: ["**/*.tsx"]`
+- ❌ General project conventions → No paths needed
+
+### Organize with Subdirectories
+
+Group related rules:
+
+```
+.claude/rules/
+├── frontend/
+│   ├── components.md
+│   ├── styling.md
+│   └── state-management.md
+├── backend/
+│   ├── api.md
+│   ├── database.md
+│   └── auth.md
+└── general.md
+```
+
+### Avoid Duplication
+
+Don't repeat the same rules in multiple files. If a rule applies globally, put it in:
+1. Root-level rule file (e.g., `.claude/rules/general.md`)
+2. Or in `.claude/CLAUDE.md`
+
+## Troubleshooting
+
+| Problem | Solution |
+|---------|----------|
+| Rules not loading | Ensure file extension is `.md` and in `.claude/rules/` |
+| Path rules not applying | Verify glob pattern matches target files exactly |
+| Rules conflicting | Check for duplicates across multiple files |
+| Too many rules loading | Use `paths` frontmatter to scope appropriately |
+
+## When to Use .claude/rules/ vs CLAUDE.md
+
+**Use `.claude/rules/` when:**
+- Project has many distinct concerns (testing, security, API, frontend)
+- Different rules apply to different file types
+- Team members maintain different areas
+- You want to update one concern without touching others
+- CLAUDE.md exceeds 200 lines
+
+**Use CLAUDE.md when:**
+- Project is small/simple (< 100 lines of instructions)
+- All rules are universal across the project
+- You prefer a single source of truth
+- Quick setup is priority
+
+## Migration Path
+
+When CLAUDE.md grows too large (200+ lines):
+
+1. **Identify sections**: testing, API, frontend, security, etc.
+2. **Create `.claude/rules/` directory**
+3. **Move each section** to its own file
+4. **Add `paths` frontmatter** where rules are file-type specific
+5. **Keep universal essentials** in CLAUDE.md (or remove it entirely)
+6. **Test** to ensure rules load correctly
+
+## Reference
+
+Based on official Claude Code documentation:
+https://code.claude.com/docs/mcp/claude-md#modular-rules-with-clauderules