codingbuddy-rules 4.5.0 → 5.1.0

package/.ai-rules/skills/rule-authoring/examples/trigger-patterns.md

@@ -0,0 +1,126 @@
+# Rule Trigger Patterns
+
+Patterns for writing clear, unambiguous trigger conditions in AI coding rules. A trigger defines **when** a rule activates — ambiguous triggers cause inconsistent AI behavior.
+
+## Trigger Anatomy
+
+```
+**When:** <scope> + <condition> + <qualifier (optional)>
+```
+
+| Part | Purpose | Example |
+|------|---------|---------|
+| Scope | What code area | "In TypeScript files" |
+| Condition | What is happening | "writing a new function" |
+| Qualifier | Narrows further | "that is exported" |
+
+## Pattern Catalog
+
+### File-Scoped Triggers
+
+```markdown
+**When:** Creating or modifying a TypeScript file (.ts, .tsx)
+**When:** Adding a new test file
+**When:** Editing files in the `src/api/` directory
+**When:** Working with migration files (`*.migration.ts`)
+```
+
+### Action-Scoped Triggers
+
+```markdown
+**When:** Writing a new function or method
+**When:** Adding a dependency to package.json
+**When:** Creating a new React component
+**When:** Defining an API endpoint
+**When:** Writing a database query
+```
+
+### Context-Scoped Triggers
+
+```markdown
+**When:** Implementing a feature that handles user input
+**When:** Adding authentication or authorization logic
+**When:** Modifying shared utility code used by 3+ modules
+**When:** Changing code that runs in a CI/CD pipeline
+```
+
+### Negation Triggers (When NOT to Apply)
+
+```markdown
+**When:** NOT applicable:
+- Prototype or spike code (marked with `// SPIKE:`)
+- Generated code (auto-generated files)
+- Third-party type definitions (`.d.ts`)
+```
+
+## Ambiguity Antipatterns
+
+| Ambiguous Trigger | Problem | Fixed Trigger |
+|-------------------|---------|---------------|
+| "When appropriate" | Who decides? | "When the function has > 3 parameters" |
+| "When necessary" | Always unclear | "When the module is imported by 2+ files" |
+| "When writing code" | Too broad | "When writing exported functions" |
+| "When dealing with errors" | Vague scope | "When implementing catch blocks in async functions" |
+| "When it makes sense" | Subjective | "When the function performs I/O operations" |
+| "In complex scenarios" | Undefined threshold | "When cyclomatic complexity exceeds 10" |
+
+## Combining Triggers
+
+### AND (all conditions must be true)
+
+```markdown
+**When:** Writing a new API endpoint AND the endpoint accepts user input
+```
+
+### OR (any condition activates)
+
+```markdown
+**When:** Creating a new module OR modifying a module's public API (exported types/functions)
+```
+
+### Conditional (if-then)
+
+```markdown
+**When:** Adding a new dependency
+  - IF the dependency has no TypeScript types → also add `@types/<pkg>`
+  - IF the dependency is > 50KB → document the size justification
+```
+
+## Trigger Strength Vocabulary
+
+| Keyword | Strength | Meaning |
+|---------|----------|---------|
+| ALWAYS / MUST | Mandatory | No exceptions — rule fires every time |
+| SHOULD / PREFER | Default | Rule fires unless there's a documented reason not to |
+| CONSIDER / MAY | Advisory | Rule is a suggestion, not a requirement |
+| NEVER / MUST NOT | Prohibition | Rule prevents an action unconditionally |
+
+### Using Strength in Context
+
+```markdown
+### Input Validation
+
+**When:** Writing a function that accepts external input (API request, form data, URL params)
+
+**Do:** ALWAYS validate and sanitize input before processing.
+
+**When:** Writing internal utility functions called only by trusted code
+
+**Do:** CONSIDER adding input validation for defense-in-depth.
+```
+
+## Testing Your Triggers
+
+For each trigger, ask:
+
+1. **Can I give 3 concrete examples where this trigger fires?**
+   - If not, the trigger is too vague.
+
+2. **Can I give 3 concrete examples where this trigger does NOT fire?**
+   - If not, the trigger is too broad.
+
+3. **Would two different AI tools interpret this the same way?**
+   - If not, add more specificity.
+
+4. **Is the trigger observable from the code?**
+   - Triggers based on intent ("when optimizing") are weaker than triggers based on observable state ("when the file contains a database query").

package/.ai-rules/skills/security-audit/SKILL.md

@@ -1,6 +1,10 @@
 ---
 name: security-audit
 description: Use when reviewing code for security vulnerabilities, before shipping features, or conducting security assessments. Covers OWASP Top 10, secrets exposure, authentication, and authorization flaws.
+context: fork
+agent: general-purpose
+allowed-tools: Read, Grep, Glob, Bash(git:*)
+argument-hint: [scope-or-path]
 ---
 
 # Security Audit

package/.ai-rules/skills/ship/SKILL.md

@@ -0,0 +1,242 @@
+---
+name: ship
+description: "Run local CI checks and ship changes — create branch, commit, push, and PR. Optionally link to a GitHub issue. Use when changes are ready to ship."
+---
+
+# Ship Changes
+
+Run local CI checks, then create branch, commit, push, and PR in one workflow.
+
+Follow every step in order. Stop and report if any step fails.
+
+## Step 1: Determine Issue Context
+
+Check if `$ARGUMENTS` is provided:
+
+- **With issue** (`/ship 613` or `/ship https://github.com/.../issues/613`):
+  ```bash
+  gh issue view <number> --json title,body,labels
+  ```
+  Use the issue title and labels to inform branch name, commit message, and PR description.
+
+- **Without issue** (`/ship`):
+  Skip issue fetch. Derive context entirely from the changed files and `git diff`. The user will be asked to confirm the commit message and PR title before proceeding.
+
+## Step 2: Check Working Tree
+
+```bash
+git status
+git diff --stat
+```
+
+If there are no changes to ship, stop and inform the user.
+
+## Step 3: Detect Project Structure
+
+Detect whether the project is a **monorepo** or **single-repo** by checking for configuration:
+
+### Option A: Configured via `codingbuddy.config.json`
+
+If `codingbuddy.config.json` exists and contains `custom.ship`, use it:
+
+```jsonc
+// codingbuddy.config.json
+{
+  "custom": {
+    "ship": {
+      "packageManager": "yarn",        // "yarn" | "npm" | "pnpm" | "bun"
+      "structure": "monorepo",          // "monorepo" | "single"
+      "workspaces": [
+        {
+          "name": "my-app",
+          "paths": ["apps/my-app/**"],
+          "checks": ["lint", "format:check", "typecheck", "test:coverage", "build"]
+        },
+        {
+          "name": "my-lib",
+          "paths": ["packages/my-lib/**"],
+          "checks": ["lint", "typecheck", "test"]
+        }
+      ],
+      "globalChecks": [
+        {
+          "name": "schema-validation",
+          "command": "npx ajv-cli validate -s schema.json -d 'data/*.json'"
+        },
+        {
+          "name": "markdown-lint",
+          "command": "npx markdownlint-cli2 '**/*.md'"
+        }
+      ],
+      "skipPaths": ["docs/**", "*.md", ".github/**"]
+    }
+  }
+}
+```
+
+### Option B: Auto-detection (no config)
+
+If no `custom.ship` config exists, auto-detect:
+
+1. **Package manager**: Check for lock files in order: `bun.lock` → `pnpm-lock.yaml` → `yarn.lock` → `package-lock.json`. Default to `npm`.
+2. **Structure**: Check `package.json` for `workspaces` field. If present → monorepo; otherwise → single-repo.
+3. **Workspaces** (monorepo): Parse `workspaces` from `package.json`, resolve glob patterns against `git diff --name-only` to find affected workspaces.
+4. **Checks** (auto): Run standard checks for each affected workspace:
+   ```bash
+   <pm> [workspace <name>] lint
+   <pm> [workspace <name>] typecheck
+   <pm> [workspace <name>] test
+   <pm> [workspace <name>] build
+   ```
+   Where `<pm>` is the detected package manager and `workspace <name>` is included only for monorepos.
+
+## Step 4: Classify Changed Files
+
+Run `git diff --name-only` (include both staged and unstaged) and classify into workspaces.
+
+**Monorepo**: Match changed file paths against workspace `paths` patterns to find affected workspaces.
+
+**Single-repo**: All changes belong to the single workspace.
+
+If changed files match only `skipPaths` (or don't match any workspace in auto-detect), skip CI checks entirely and proceed to Step 6.
+
+## Step 5: Run Local CI Checks
+
+### Workspace checks
+
+Run checks **only for affected workspaces**. Execute checks sequentially within each workspace. Stop at first failure.
+
+**Configured** (from `custom.ship.workspaces`):
+```bash
+# For each affected workspace, run each check:
+<pm> workspace <workspace-name> <check>
+```
+
+**Auto-detected**:
+```bash
+# Monorepo — run for each affected workspace:
+<pm> workspace <workspace-name> lint
+<pm> workspace <workspace-name> typecheck
+<pm> workspace <workspace-name> test
+<pm> workspace <workspace-name> build
+
+# Single-repo — run at project root:
+<pm> run lint
+<pm> run typecheck
+<pm> run test
+<pm> run build
+```
+
+Skip any script that does not exist in the workspace's `package.json` — check with `<pm> run --json` or by reading `package.json` scripts.
+
+### Global checks
+
+If `custom.ship.globalChecks` is configured, run each global check command after workspace checks pass:
+
+```bash
+<command>   # executed from project root
+```
+
+If ANY check fails, stop and report the failure. Do NOT proceed to shipping.
+
+## Step 6: Check Commit Convention
+
+```bash
+git log --oneline -10
+```
+
+Identify the commit message convention from recent history. Common conventions:
+- `type(scope): description` (Conventional Commits)
+- `type: description`
+- Free-form
+
+## Step 7: Create Branch and Commit
+
+### Branch naming
+
+- **With issue:** `<type>/<short-description>-<issue-number>` (e.g., `feat/add-auth-613`)
+- **Without issue:** `<type>/<short-description>` (e.g., `fix/login-redirect`)
+
+### Commit
+
+```bash
+git checkout -b <branch-name>
+
+# Stage relevant files (never use git add -A)
+git add <specific-files>
+
+# Exclude task artifacts from staging
+git reset HEAD RESULT.json TASK.md 2>/dev/null || true
+
+# Commit with convention — use HEREDOC for message
+git commit -m "$(cat <<'EOF'
+type(scope): concise description
+
+- Detail 1
+- Detail 2
+
+Closes #<issue-number>   ← only if issue provided
+EOF
+)"
+```
+
+**Rules:**
+- Write commit message in **English**
+- Do NOT include author information
+- Follow the detected convention from Step 6
+- Use specific file paths in `git add` (never `git add -A` or `git add .`)
+- Only include `Closes #<number>` if an issue was provided
+
+## Step 8: Push and Create PR
+
+```bash
+git push -u origin <branch-name>
+```
+
+Create PR using `gh pr create`:
+
+### With issue
+
+```bash
+gh pr create --title "<type>(scope): description" --label "<labels>" --body "$(cat <<'EOF'
+## Summary
+<bullet points summarizing changes>
+
+## Test plan
+<verification steps>
+
+Closes #<issue-number>
+EOF
+)"
+```
+
+- Labels: detect from issue labels, add relevant ones
+
+### Without issue
+
+```bash
+gh pr create --title "<type>(scope): description" --label "<labels>" --body "$(cat <<'EOF'
+## Summary
+<bullet points summarizing changes>
+
+## Test plan
+<verification steps>
+EOF
+)"
+```
+
+- Labels: infer from change type (e.g., `enhancement` for feat, `bug` for fix)
+
+**PR Rules:**
+- Title: under 70 characters, English, follows commit convention
+- Body: English, include Summary + Test plan sections
+- Do NOT include author information
+
+## Step 9: Report Result
+
+Print the PR URL and a summary of:
+- Which CI checks were run and passed (or "skipped — no matching workspace")
+- Branch name
+- Commit hash
+- PR URL
+- Linked issue (or "none")