@codemieai/code 0.0.44 → 0.0.46

package/dist/agents/plugins/claude/plugin/skills/claude-setup-audit/examples/good-agent.md

@@ -0,0 +1,145 @@
+---
+# ✅ GOOD AGENT EXAMPLE
+# Score: ~30/32 pts (Grade A)
+# What makes it good: See inline comments marked ✅
+#
+# ✅ A1.1: Descriptive, domain-specific name
+# ✅ A1.2: Description has "when" and "use" trigger context
+# ✅ A1.3: Model explicitly specified
+# ✅ A1.4: Bash justified with inline comment
+# ✅ A2.1: "You are..." role statement
+# ✅ A2.2: Output format section defined
+# ✅ A2.3: Scope + "When NOT to use"
+# ✅ A2.4: Anti-hallucination section
+# ✅ A3.1: 3+ usage examples
+# ✅ A3.2: Edge cases documented
+# ✅ A3.3: Error handling described
+# ✅ A4.1: Single responsibility (code review only)
+# ✅ A4.3: References related skills/agents
+#
+# ⚠️ Minor gap: A3.4 — integration docs could be more explicit
+---
+name: code-reviewer
+description: This agent should be used when the user asks to "review my code",
+  "check code quality", "review this PR", "look for bugs", "security review",
+  or "give feedback on my implementation". Reviews staged or committed changes
+  for quality, security, and correctness issues.
+model: claude-sonnet-4-6
+tools: [Read, Grep, Glob, Bash]
+# Bash required for: git diff, git log, running lint checks
+
+---
+
+# Code Reviewer Agent
+
+Reviews code changes for quality, security, and correctness. Provides structured
+feedback with severity levels and concrete improvement suggestions.
+
+## Role
+
+You are a senior code reviewer with expertise in security vulnerabilities,
+performance patterns, and maintainability. Your job is to identify real issues
+that would cause problems in production — not stylistic preferences or micro-
+optimizations. Focus on bugs, security vulnerabilities, logic errors, and
+maintainability problems.
+
+## Scope
+
+**Review**: Staged changes (`git diff --cached`), committed changes (`git diff HEAD~1`),
+or specific files provided by the user.
+
+**Do NOT review**: Generated files, `node_modules/`, `dist/`, `*.lock` files,
+binary files.
+
+**When NOT to use this agent**:
+- Architecture decisions → use `solution-architect` agent
+- Writing tests → use `test-writer` agent
+- Performance profiling → run profiler first, then use this agent on hotspots
+
+## Methodology
+
+1. Identify changed files: `git diff --name-only` or user-provided files
+2. For each file: read with context (surrounding code, not just diff)
+3. Evaluate against criteria below
+4. Generate structured report
+
+### Review Criteria
+
+**Security** (Critical — block production):
+- SQL injection, XSS, command injection vectors
+- Hardcoded credentials or secrets in code
+- Unvalidated input at system boundaries (user input, API responses, file reads)
+- Overly permissive CORS, auth bypass patterns
+
+**Correctness** (High — likely causes bugs):
+- Off-by-one errors, logic inversions
+- Unhandled exceptions or null/undefined dereferences
+- Race conditions in async code
+- Incorrect error propagation (swallowing errors)
+
+**Performance** (Medium — degrades at scale):
+- N+1 query patterns
+- Synchronous I/O in async contexts
+- Unbounded loops or missing pagination
+
+**Maintainability** (Low — increases tech debt):
+- Functions >40 lines without clear justification
+- Missing error context in catch blocks
+- Unclear naming in non-trivial logic
+
+## Output Format
+
+```markdown
+## Code Review: [file or PR title]
+
+**Summary**: [1–2 sentence overall assessment]
+**Verdict**: APPROVE / REQUEST CHANGES / BLOCKING
+
+### 🔴 Critical (must fix before merge)
+- **[File:Line]** [Issue]
+  - Impact: [what goes wrong in production]
+  - Fix: [concrete actionable suggestion]
+
+### 🟡 Important (should fix)
+- **[File:Line]** [Issue]
+  - Fix: [suggestion]
+
+### 🔵 Minor (optional polish)
+...
+
+### ✅ Positives
+[2–3 specific things done well — required, not optional]
+```
+
+## Source Verification
+
+- Base all feedback on actual code seen in the diff — never assume patterns not shown
+- If uncertain whether something is a bug: "This may cause issues if [condition]…"
+- Never invent API signatures, library behaviors, or version requirements
+- Do not cite performance numbers without measurement evidence
+
+## Examples
+
+1. "Review my changes before commit" → run `git diff --cached`, review staged changes
+2. "Review the auth PR" → run `git diff main...HEAD`, review branch changes
+3. "Check this file for security issues" → review specified file for security criteria only
+4. "Quick review" → focus on Critical and High issues only, skip Low
+
+## Edge Cases
+
+- **Empty diff**: Warn "No staged/changed files found" and exit
+- **Binary files**: Skip with note "Binary file skipped (not reviewable)"
+- **Very large diffs (>200 files)**: Ask user to scope to specific directories
+- **Generated code** (e.g., `*.generated.ts`): Skip automatically
+
+## Error Handling
+
+- If `git` is not available: switch to direct file analysis
+- If file cannot be read: note in report and continue with other files
+- If user provides invalid path: report "File not found: [path]"
+
+## Works With
+
+- After review: use `commit-helper` skill for conventional commit message
+- For test gaps found: mention `test-writer` agent for coverage
+- For architecture concerns: escalate to `solution-architect` agent

package/dist/agents/plugins/claude/plugin/skills/claude-setup-audit/examples/good-claude-md-snippet.md

@@ -0,0 +1,126 @@
+# ✅ GOOD CLAUDE.md SNIPPET EXAMPLE
+# Score: ~27/30 pts (Grade A)
+#
+# ✅ R1.1: Coding standards defined (TypeScript section)
+# ✅ R1.2: Workflow policies explicit (Git, Testing)
+# ✅ R1.3: Critical rules with MANDATORY/NEVER + triggers
+# ✅ R2.1: Actionable — starts with verbs (Use, Run, Add, Never)
+# ✅ R2.2: Trigger conditions stated ("when user says", "for TypeScript files")
+# ✅ R2.3: Explicit prohibitions with examples
+# ✅ R3.1: Organized H2 sections
+# ✅ R3.2: Quick-reference table
+# ✅ R3.3: ✅/❌ pattern examples
+# ✅ R4.2: Technology versions mentioned
+# ✅ R4.3: Project context stated
+#
+# ⚠️ Minor gap: R4.1 — one minor contradiction possible (needs manual check)
+
+---
+# CLAUDE.md — Acme API Service
+
+**Project**: REST API backend for Acme platform (Node.js 22, TypeScript 5.4)
+**Team**: Platform Engineering
+
+---
+
+## ⚡ Task Classifier (Scan First)
+
+| Keywords in request | Apply policy |
+|--------------------|-------------|
+| "commit", "push", "branch", "PR" | → Git Policy below |
+| "test", "spec", "vitest" | → Testing Policy below |
+| TypeScript, imports, types | → TypeScript Standards below |
+| "deploy", "release", "build" | → Build Policy below |
+
+---
+
+## 🚨 Critical Rules (MANDATORY)
+
+🚨 **NEVER commit to `main` directly.** Always use feature branches.
+
+🚨 **NEVER use `--no-verify` on git hooks.** If a hook fails, fix the underlying issue first.
+
+🚨 **NEVER write tests unless user explicitly asks.** Wait for "write tests", "add coverage", "create specs".
+
+🚨 **ALWAYS use `.js` extensions in TypeScript imports.** TypeScript compiles to ESM. Missing extension = runtime crash.
+
+---
+
+## TypeScript Standards
+
+**Imports** — ES modules only:
+```typescript
+✅ import { foo } from './utils.js'
+✅ import type { Bar } from './types.js'
+❌ import { foo } from './utils'          // missing .js extension
+❌ const { foo } = require('./utils')     // CommonJS not allowed
+```
+
+**Types** — strict mode, no `any` shortcuts:
+```typescript
+✅ function process(input: unknown): Result { ... }
+✅ const value = data as UserProfile       // explicit assertion
+❌ function process(input: any) { ... }    // defeats type safety
+```
+
+**Async patterns**:
+```typescript
+✅ const result = await Promise.all([a(), b()])  // parallel where possible
+❌ const r1 = await a()                           // sequential bottleneck
+❌ const r2 = await b()
+```
+
+---
+
+## Git Policy
+
+**Branch naming**: `<type>/<description>` — e.g., `feat/add-oauth`, `fix/token-refresh`
+
+**Commit format**: Conventional Commits:
+```
+feat(auth): add token refresh on 401 response
+fix(api): handle null user in profile endpoint
+chore: update eslint to v9
+```
+
+**PR requirements**:
+- [ ] Branch is up to date with `main`
+- [ ] All CI checks pass
+- [ ] No `console.log` or debug code
+
+**Never do**:
+- ❌ `git push --force` to `main` (destructive, permanently loses history)
+- ❌ `git commit --amend` on published commits (breaks teammates' history)
+
+---
+
+## Testing Policy
+
+**MANDATORY**: Write tests ONLY when user explicitly says "write tests", "add coverage", "create unit tests".
+
+**Never proactively write or suggest tests.**
+
+Test commands:
+```bash
+npm test              # all tests
+npm run test:unit     # unit only
+npm run test:coverage # with coverage report
+```
+
+Framework: Vitest 4.x. All tests use dynamic imports for mocking (not static).
+
+---
+
+## Build Policy
+
+**Node.js**: >= 22.0.0 required (`node --version`)
+**npm**: bundled with Node — no yarn or pnpm
+**Build output**: `dist/` (gitignored)
+
+```bash
+npm run build    # TypeScript → dist/
+npm run lint     # ESLint (zero warnings required)
+npm run ci       # Full pipeline: lint + build + test
+```
+
+**Before deploying**: All CI checks must pass. No bypassing.

package/dist/agents/plugins/claude/plugin/skills/claude-setup-audit/examples/good-command.md

@@ -0,0 +1,170 @@
+---
+# ✅ GOOD COMMAND EXAMPLE
+# Score: ~19/20 pts (Grade A)
+#
+# ✅ C1.1: Valid frontmatter with name + description
+# ✅ C1.2: argument-hint matches $ARGUMENTS usage
+# ✅ C1.3: Phase-based numbered workflow
+# ✅ C1.4: Usage examples section present
+# ✅ C2.1: Error handling table with failure cases
+# ✅ C2.2: Output format defined
+# ✅ C2.3: Validation gates (confirm before creating)
+# ✅ C2.4: Argument parsing with defaults shown
+#
+# ⚠️ Minor gap: C2.4 — could show more complex argument validation
+name: create-jira-ticket
+description: Create a structured Jira ticket from code context, error analysis, or user description
+argument-hint: "<type> <title> [--priority high|medium|low]"
+---
+
+# Create Jira Ticket
+
+Creates a well-structured Jira ticket in the EPM-CDME project based on code
+context, error analysis, or user description. Follows project template with
+acceptance criteria and technical notes.
+
+## Arguments
+
+| Argument | Values | Default | Description |
+|----------|--------|---------|-------------|
+| `<type>` | `bug`, `story`, `task`, `epic` | required | Ticket type |
+| `<title>` | string | required | Brief ticket title |
+| `--priority` | `high`, `medium`, `low` | `medium` | Priority level |
+
+## Usage
+
+```bash
+/create-jira-ticket bug "Login fails on mobile Safari"
+/create-jira-ticket story "Add dark mode toggle" --priority high
+/create-jira-ticket task "Update API documentation"
+/create-jira-ticket epic "Authentication system refactor"
+```
+
+---
+
+## Phase 1: Parse and Validate Arguments
+
+Parse `$ARGUMENTS`:
+
+1. Extract `<type>` — first token. If missing or invalid:
+   ```
+   Valid types: bug, story, task, epic
+   What type of ticket? [bug/story/task/epic]
+   ```
+
+2. Extract `<title>` — remaining text before flags. If missing:
+   ```
+   What should the ticket title be?
+   ```
+
+3. Extract `--priority` flag. Default: `medium`
+
+4. Validate:
+   - [ ] Type is one of: bug, story, task, epic
+   - [ ] Title is not empty
+   - [ ] Title length ≤ 255 characters (Jira limit)
+
+**Abort if**: `JIRA_TOKEN` env var is not set — print:
+```
+Error: JIRA_TOKEN environment variable is required.
+Set it with: export JIRA_TOKEN=your-token
+```
+
+---
+
+## Phase 2: Gather Context
+
+Collect relevant context based on type:
+
+**For `bug`**:
+- Run `git log --oneline -5` to show recent changes
+- Read any error output or stack traces mentioned by user
+- Identify affected file(s) if mentioned
+
+**For `story`**:
+- Read related files to understand current implementation
+- Note what's missing vs what's needed
+
+**For `task`** or **`epic`**:
+- Review scope from user description
+- Check for related existing tickets if mentioned
+
+---
+
+## Phase 3: Generate Ticket Description
+
+Use the EPM-CDME template:
+
+```markdown
+## Problem Statement
+[Concrete, observable description of the bug or need.
+For bugs: what happens vs what should happen.
+For stories: what capability is missing.]
+
+## Acceptance Criteria
+- [ ] Criterion 1 (testable, pass/fail)
+- [ ] Criterion 2
+- [ ] Criterion 3 (minimum 3 criteria)
+
+## Technical Notes
+[Implementation hints, related files, potential approach, dependencies]
+
+## Priority Justification
+[Why this priority level: high = user-blocking, medium = important, low = nice-to-have]
+```
+
+Checklist before proceeding:
+- [ ] Problem is concrete and observable (not vague)
+- [ ] Acceptance criteria are testable (binary pass/fail)
+- [ ] Technical notes reference actual files or components
+- [ ] Priority matches user impact
+
+---
+
+## Phase 4: Confirm Before Creating
+
+Show the draft ticket for user approval:
+
+```
+━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
+Creating Jira Ticket:
+  Project: EPM-CDME
+  Type: [Bug | Story | Task | Epic]
+  Title: [title]
+  Priority: [High | Medium | Low]
+
+Description preview:
+  [first 200 chars of description...]
+
+Create ticket? [y/n/edit]
+━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
+```
+
+- If `n`: Print "Cancelled." Exit cleanly.
+- If `edit`: Re-prompt for which field to change.
+- If `y`: Proceed to Phase 5.
+
+---
+
+## Phase 5: Create and Report
+
+1. POST to Jira API using `JIRA_TOKEN`
+2. On success:
+   ```
+   ✓ Created: EPM-CDME-1234
+     https://jira.example.com/browse/EPM-CDME-1234
+   ```
+3. On failure: see Error Handling
+
+---
+
+## Error Handling
+
+| Error | Action |
+|-------|--------|
+| `JIRA_TOKEN` not set | Print setup instructions. Exit without saving draft. |
+| API 401 Unauthorized | "Invalid token. Check JIRA_TOKEN value." |
+| API 403 Forbidden | "No permission for EPM-CDME project. Contact admin." |
+| API 429 Rate Limited | Wait 30s, retry once. If fails again: save draft. |
+| Network unreachable | Save draft to `./jira-ticket-draft.md`, print path. |
+| Title >255 chars | Truncate to 252 chars, append "...", warn user. |

package/dist/agents/plugins/claude/plugin/skills/claude-setup-audit/examples/good-hooks.json

@@ -0,0 +1,46 @@
+{
+  "_comment": "✅ GOOD HOOKS EXAMPLE — Score: ~18/20 pts (Grade A)",
+  "_notes": {
+    "H1.1": "✅ Valid JSON structure",
+    "H1.2": "✅ All event types are recognized (PreToolUse, PostToolUse)",
+    "H2.1": "✅ No hardcoded credentials — uses env var $AUDIT_WEBHOOK_URL",
+    "H2.2": "✅ Bash scripts use set -e and trap for error handling",
+    "H3.1": "✅ Matchers are scoped to specific tools (Write|Edit, Bash) not .*",
+    "H3.2": "✅ Each hook has a description field explaining its purpose"
+  },
+  "hooks": [
+    {
+      "event": "PreToolUse",
+      "description": "Block direct file writes to main branch — prevents accidental commits to protected branch",
+      "matcher": "Write|Edit",
+      "hooks": [
+        {
+          "type": "command",
+          "command": "bash -c 'set -e; trap \"echo Hook check failed >&2\" ERR; BRANCH=$(git branch --show-current 2>/dev/null || echo \"\"); if [ \"$BRANCH\" = \"main\" ] || [ \"$BRANCH\" = \"master\" ]; then echo \"ERROR: Direct writes to $BRANCH are blocked. Create a feature branch first.\" >&2; exit 1; fi'"
+        }
+      ]
+    },
+    {
+      "event": "PostToolUse",
+      "description": "Run ESLint after TypeScript file modifications to catch issues immediately",
+      "matcher": "Edit|Write",
+      "hooks": [
+        {
+          "type": "command",
+          "command": "bash -c 'set -e; trap \"echo Lint hook failed on line $LINENO >&2\" ERR; FILE=$(echo \"$CLAUDE_TOOL_OUTPUT\" | grep -o \"[^ ]*\\.ts\" | head -1 || true); if [ -n \"$FILE\" ] && [ -f \"$FILE\" ]; then npx eslint \"$FILE\" --max-warnings=0 --quiet 2>&1 | tail -10; fi'"
+        }
+      ]
+    },
+    {
+      "event": "PostToolUse",
+      "description": "Log tool usage for audit trail — posts to team webhook for compliance tracking",
+      "matcher": "Bash",
+      "hooks": [
+        {
+          "type": "command",
+          "command": "bash -c 'set -e; if [ -n \"$AUDIT_WEBHOOK_URL\" ]; then curl -sf -X POST \"$AUDIT_WEBHOOK_URL\" -H \"Content-Type: application/json\" -d \"{\\\"event\\\": \\\"bash_used\\\", \\\"session\\\": \\\"$CLAUDE_SESSION_ID\\\"}\" > /dev/null 2>&1 || true; fi'"
+        }
+      ]
+    }
+  ]
+}

package/dist/agents/plugins/claude/plugin/skills/claude-setup-audit/examples/good-skill.md

@@ -0,0 +1,144 @@
+---
+# ✅ GOOD SKILL EXAMPLE
+# Score: ~30/32 pts (Grade A)
+# What makes it good: See inline comments marked ✅
+#
+# ✅ S1.1: Named SKILL.md in skills/ directory
+# ✅ S1.2: name is [a-z0-9-]+ pattern
+# ✅ S1.3: Description >20 chars, third-person, specific triggers
+# ✅ S1.4: allowed-tools explicitly specified
+# ✅ S2.1: Step-by-step methodology
+# ✅ S2.2: Output format section defined
+# ✅ S2.3: Concrete examples provided
+# ✅ S2.4: Actionable checklists present
+# ✅ S3.1: No absolute paths
+# ✅ S3.2: No secrets
+# ✅ S4.1: Single focused purpose
+# ✅ S4.2: "When to use" section present
+#
+# ⚠️ Minor gap: S3.4 — no dependencies section (would add 1 pt)
+---
+name: commit-helper
+description: This skill should be used when the user asks to "commit my changes",
+  "create a conventional commit", "write a commit message", "stage and commit files",
+  or wants to follow conventional commits format. Guides through staged file review,
+  semantic commit message generation, and commit creation with pre-commit validation.
+allowed-tools: [Read, Bash, Glob]
+version: 1.0.0
+
+---
+
+# Commit Helper
+
+Guides staged commit creation following the Conventional Commits specification.
+Generates semantic commit messages based on diff analysis and confirms before committing.
+
+## When to Use
+
+Use this skill when:
+- User has staged changes and wants a commit message
+- User wants to follow conventional commits format automatically
+- User needs to review staged changes before committing
+- User says "commit", "create a commit", "stage and commit"
+
+Do NOT use this skill for:
+- Pushing to remote (that's a separate action requiring user confirmation)
+- Creating pull requests (use `pr-creator` skill)
+- Branch management operations
+
+## Methodology
+
+### Step 1: Review Staged Changes
+
+1. Run `git status` to list staged and unstaged files
+2. Run `git diff --cached` to review the full staged diff
+3. If no files staged: warn user and exit — do not commit unstaged work
+
+### Step 2: Determine Commit Type
+
+Map changes to conventional commit types:
+
+| Type | When to use |
+|------|-------------|
+| `feat` | New feature or behavior added |
+| `fix` | Bug fix |
+| `refactor` | Code change that neither fixes a bug nor adds feature |
+| `docs` | Documentation only |
+| `test` | Adding or updating tests |
+| `chore` | Build process, tooling, dependencies |
+| `ci` | CI/CD pipeline changes |
+| `perf` | Performance improvement |
+
+### Step 3: Generate Commit Message
+
+Format:
+```
+<type>(<scope>): <description>
+
+[optional body]
+
+[optional footer]
+```
+
+Checklist:
+- [ ] Type is lowercase and from the table above
+- [ ] Scope is the module, component, or area affected
+- [ ] Description is imperative mood ("add" not "added"), lowercase, <72 chars, no period
+- [ ] Body explains WHY (not WHAT — the diff shows WHAT)
+- [ ] Breaking changes use `feat!:` or `fix!:` and include `BREAKING CHANGE:` footer
+
+### Step 4: Confirm and Commit
+
+Show the proposed commit for user approval:
+```
+Staged files:
+  modified: src/auth/login.ts
+  modified: src/auth/token.ts
+
+Proposed commit:
+  fix(auth): refresh OAuth token before expiry on 401 response
+
+  Tokens were silently expiring mid-session causing user logout.
+  Refresh is now triggered proactively when token age > 80% of TTL.
+
+Commit? [y/n/edit]
+```
+
+- [ ] User confirmed `y` before running `git commit`
+- [ ] If user says `edit`: re-prompt for message
+- [ ] Never use `--no-verify` unless user explicitly requests it
+
+## Output Format
+
+```
+Staged: [list of files]
+
+Proposed message:
+  [type(scope): description]
+
+  [body if needed]
+
+✓ Committed: [hash] [message]
+```
+
+## Error Handling
+
+| Situation | Action |
+|-----------|--------|
+| No staged files | Print: "No staged files. Use `git add` first." Exit. |
+| User cancels | Print: "Commit cancelled." Exit cleanly. |
+| Pre-commit hook fails | Print hook output, do NOT retry, suggest fixing the issue |
+| `git commit` fails | Show error message, do not suppress it |
+
+## Examples
+
+```bash
+# User: "commit my changes"
+→ Run git status + diff, generate message, show for confirmation
+
+# User: "commit the auth fix as a hotfix"
+→ Use type=fix, analyze staged auth files, generate message
+
+# User: "commit with message 'update readme'"
+→ Use user's message, format to conventional commits if needed
+```