@orderful/droid 0.7.0 → 0.9.0

package/dist/skills/brain/commands/brain.md

@@ -1,6 +1,6 @@
 ---
-description: Collaborative scratch pad for planning and research
-argument-hint: [plan|research|review|note|add|check|done] {topic/text}
+description: Collaborative scratchpad for planning and research
+argument-hint: "[{topic} | plan|research|review {topic} | note|add {text} | check|done]"
 allowed-tools: Read, Write, Edit, Glob, Grep, Bash(mkdir:*), Bash(ls:*)
 ---
 
@@ -8,16 +8,22 @@ allowed-tools: Read, Write, Edit, Glob, Grep, Bash(mkdir:*), Bash(ls:*)
 
 Entry point for brain doc management. See the **brain skill** for full behavior.
 
+> **Alias:** This command also works as `/scratchpad` - use whichever feels natural.
+
 ## Arguments
 
 $ARGUMENTS
 
+## Default Behavior
+
+**IMPORTANT:** When given just a topic (e.g., `/brain auth-refactor`), the default action is to **SEARCH** for existing docs, NOT create. Only create docs with explicit `/brain plan {topic}` or `/brain research {topic}`.
+
 ## Usage
 
 ```
 /brain                      # List recent docs or create new
-/brain {topic}              # Open existing (fuzzy match) → active
-/brain plan {topic}         # Create planning doc → active
+/brain {topic}              # SEARCH: Open existing doc (fuzzy match) → active
+/brain plan {topic}         # CREATE: New planning doc → active
 /brain research {topic}     # Create research doc → active
 /brain review {topic}       # Create review doc → active
 /brain note {text}          # Quick capture (fire-and-forget)
@@ -28,7 +34,8 @@ $ARGUMENTS
 
 ## Configuration
 
-From `~/.droid/skills/brain/overrides.yaml`:
+**ALWAYS read `~/.droid/skills/brain/overrides.yaml` first.** Use configured values if present, only fall back to defaults if missing.
+
 - `brain_dir` - Where docs live (default varies by AI tool)
 - `inbox_folder` - Subfolder for new docs (empty = flat)
 

package/dist/skills/brain/commands/scratchpad.md

@@ -0,0 +1,52 @@
+---
+description: Collaborative scratchpad for planning and research
+argument-hint: "[{topic} | plan|research|review {topic} | note|add {text} | check|done]"
+allowed-tools: Read, Write, Edit, Glob, Grep, Bash(mkdir:*), Bash(ls:*)
+---
+
+# /scratchpad
+
+Your scratchpad for planning, research, and design. See the **brain skill** for full behavior.
+
+> **Alias:** This command also works as `/brain` - use whichever feels natural.
+
+## Arguments
+
+$ARGUMENTS
+
+## Default Behavior
+
+**IMPORTANT:** When given just a topic (e.g., `/scratchpad auth-refactor`), the default action is to **SEARCH** for existing docs, NOT create. Only create docs with explicit `/scratchpad plan {topic}` or `/scratchpad research {topic}`.
+
+## Usage
+
+```
+/scratchpad                      # List recent docs or create new
+/scratchpad {topic}              # SEARCH: Open existing doc (fuzzy match) → active
+/scratchpad plan {topic}         # CREATE: New planning doc → active
+/scratchpad research {topic}     # Create research doc → active
+/scratchpad review {topic}       # Create review doc → active
+/scratchpad note {text}          # Quick capture (fire-and-forget)
+/scratchpad add {text}           # Append to active doc
+/scratchpad check                # Address @droid comments in active doc
+/scratchpad done                 # Finalize active doc
+```
+
+## Configuration
+
+**ALWAYS read `~/.droid/skills/brain/overrides.yaml` first.** Use configured values if present, only fall back to defaults if missing.
+
+- `brain_dir` - Where docs live (default varies by AI tool)
+- `inbox_folder` - Subfolder for new docs (empty = flat)
+
+## Behavior
+
+Refer to the brain skill for:
+- **Opening**: How to fuzzy-match, handle multiple matches, set active
+- **Creating**: Template structure by preset, naming conventions
+- **Notes**: Quick capture workflow
+- **Adding**: Append to active doc with timestamp
+- **Checking**: Find and address @droid comments
+- **Finalizing**: Update status, suggest next steps
+
+The skill's `references/` folder contains detailed specs for workflows, templates, naming, and metadata.

package/dist/skills/brain/references/workflows.md

@@ -8,7 +8,9 @@ Detailed procedures for each brain operation.
 
 **Steps:**
 
-1. **Resolve brain_dir** from config (default: `~/.claude/brain` for claude-code)
+1. **Read config first**
+   - Read `~/.droid/skills/brain/overrides.yaml`
+   - Use `brain_dir` if configured, otherwise use default for current AI tool
 
 2. **Search for matches**
    ```
@@ -35,7 +37,10 @@ Detailed procedures for each brain operation.
 
 **Steps:**
 
-1. **Resolve brain_dir** and **inbox_folder** from config
+1. **Read config first**
+   - Read `~/.droid/skills/brain/overrides.yaml`
+   - Use `brain_dir` if configured, otherwise use default for current AI tool
+   - Use `inbox_folder` if configured
 
 2. **Generate filename** using naming conventions (see `naming.md`):
    - Format: `{type}-{topic-slug}.md`
@@ -66,7 +71,10 @@ Detailed procedures for each brain operation.
 
 **Steps:**
 
-1. **Resolve brain_dir** and **inbox_folder** from config
+1. **Read config first**
+   - Read `~/.droid/skills/brain/overrides.yaml`
+   - Use `brain_dir` if configured, otherwise use default for current AI tool
+   - Use `inbox_folder` if configured
 
 2. **Generate filename:**
    - Format: `note-{date}-{slug}.md` where date is `YYYYMMDD`
@@ -169,7 +177,9 @@ Detailed procedures for each brain operation.
 
 **Steps:**
 
-1. **Resolve brain_dir** from config
+1. **Read config first**
+   - Read `~/.droid/skills/brain/overrides.yaml`
+   - Use `brain_dir` if configured, otherwise use default for current AI tool
 
 2. **Find recent docs:**
    ```

package/dist/skills/brain-obsidian/SKILL.md

@@ -1,9 +1,6 @@
 ---
 name: brain-obsidian
-description: >-
-  Obsidian extension for brain skill. Adds YAML frontmatter, wikilinks, and folder
-  organization. Requires brain skill. Install this to use brain docs with your
-  Obsidian vault.
+description: "Obsidian extension for brain skill. Adds YAML frontmatter, wikilinks, and folder organization. Requires brain skill. Install this to use brain docs with your Obsidian vault."
 globs:
   - "**/brain/**/*.md"
 alwaysApply: false

package/dist/skills/brain-obsidian/SKILL.yaml

@@ -1,8 +1,5 @@
 name: brain-obsidian
-description: >-
-  Obsidian extension for brain skill. Adds YAML frontmatter, wikilinks, and folder
-  organization. Requires brain skill. Install this to use brain docs with your
-  Obsidian vault.
+description: "Obsidian extension for brain skill. Adds YAML frontmatter, wikilinks, and folder organization. Requires brain skill. Install this to use brain docs with your Obsidian vault."
 version: 0.1.0
 status: beta
 dependencies:

package/dist/skills/code-review/SKILL.md

@@ -0,0 +1,54 @@
+---
+name: code-review
+description: "Comprehensive code review using specialized agents. Reviews PRs, staged changes, branches, or specific files. Includes EDI/partnership analysis, test coverage, error handling, and type safety checks with confidence scoring."
+globs:
+  - "**/*"
+alwaysApply: false
+---
+
+# Code Review Skill
+
+Run comprehensive code reviews using specialized agents, each focused on a specific concern.
+
+## How It Works
+
+The `/code-review` command orchestrates multiple specialized agents in parallel:
+
+1. **edi-standards-reviewer** - EDI patterns, partnership handling, billing concerns
+2. **test-coverage-analyzer** - Test completeness and edge cases
+3. **error-handling-reviewer** - Silent failures, missing error handling
+4. **type-reviewer** - TypeScript type design, interface contracts
+
+Each agent returns issues with confidence scores (0-100). Issues below 80% confidence are filtered out to reduce noise.
+
+## Usage
+
+```bash
+/code-review #123           # Review PR #123
+/code-review staged         # Review staged changes
+/code-review branch         # Review current branch vs main
+/code-review path/to/file   # Review specific file
+```
+
+## Output Format
+
+Reviews are presented in prioritized categories:
+
+🔴 **Critical** - Security, data loss, billing errors
+🟠 **Important** - Bugs, missing tests, type issues
+🟡 **Suggestions** - Style, readability improvements
+
+## Post-Review Actions
+
+After presenting findings, you can:
+- Post the review as a PR comment
+- Get suggested fixes for specific issues
+- Check out the branch and fix critical issues
+
+## Domain-Aware Reviews
+
+The EDI Standards Reviewer discovers project conventions by reading:
+- `.claude/CLAUDE.md` or `CLAUDE.md` for team conventions
+- `AGENTS.md` or `docs/` for architecture guidance
+
+This lets it apply your project's specific patterns rather than generic rules.

package/dist/skills/code-review/SKILL.yaml

@@ -0,0 +1,19 @@
+name: code-review
+description: "Comprehensive code review using specialized agents. Reviews PRs, staged changes, branches, or specific files. Includes EDI/partnership analysis, test coverage, error handling, and type safety checks with confidence scoring."
+version: 0.1.0
+status: alpha
+dependencies: []
+provides_output: false
+examples:
+  - title: "Review a PR"
+    code: |
+      /code-review #123
+  - title: "Review staged changes"
+    code: |
+      /code-review staged
+  - title: "Review current branch vs main"
+    code: |
+      /code-review branch
+  - title: "Review a specific file"
+    code: |
+      /code-review src/billing/BillingService.ts

package/dist/skills/code-review/agents/edi-standards-reviewer/AGENT.md

@@ -0,0 +1,39 @@
+You are a domain-aware code reviewer that understands EDI patterns and integration best practices.
+
+## How to Review
+
+1. **First, find project context:**
+   - Look for `.claude/CLAUDE.md` or `CLAUDE.md` for team conventions
+   - Look for `AGENTS.md` or `docs/` for architecture guidance
+   - These files define what "correct" looks like for this codebase
+
+2. **Review with that context:**
+   - Apply the project's stated conventions and patterns
+   - Flag deviations from documented best practices
+   - Consider EDI-specific concerns (partnerships, billing, transactions)
+
+## Output Format
+
+Return JSON:
+
+```json
+{
+  "issues": [
+    {
+      "file": "path/to/file.ts",
+      "line": 42,
+      "severity": "critical|important|suggestion",
+      "confidence": 85,
+      "issue": "Brief description",
+      "suggestion": "How to fix"
+    }
+  ],
+  "summary": "One-line summary"
+}
+```
+
+## Severity Guidelines
+
+- **critical**: Security, data loss, billing errors
+- **important**: Bugs, missing validations, pattern violations
+- **suggestion**: Style, documentation, minor improvements

package/dist/skills/code-review/agents/edi-standards-reviewer/AGENT.yaml

@@ -0,0 +1,14 @@
+name: edi-standards-reviewer
+description: >-
+  Review code for EDI integration patterns, partnership handling, and billing
+  system concerns. Use PROACTIVELY when changes touch trading partners,
+  transactions, or billing.
+version: 0.1.0
+status: alpha
+mode: subagent
+model: sonnet
+color: blue
+tools:
+  - Read
+  - Grep
+  - Glob

package/dist/skills/code-review/agents/error-handling-reviewer/AGENT.md

@@ -0,0 +1,51 @@
+You are a reliability engineer hunting for silent failures.
+
+## Silent Failure Patterns
+
+1. Empty catch blocks: `catch (e) {}`
+2. Catch-and-log-only: `catch (e) { console.log(e) }` without rethrowing
+3. Promises without `.catch()` or try/catch
+4. Optional chaining hiding real errors: `data?.value` when data should exist
+5. Missing validation before operations
+6. Ignored return values from functions that can fail
+
+## Review Process
+
+1. Grep for `catch` blocks - check they handle/rethrow appropriately
+2. Find async functions - verify error propagation
+3. Look for external calls - network, DB, APIs need error handling
+4. Check critical paths - billing, transactions, partnerships
+
+## Orderful-Specific
+
+- BillingEvent creation failures must be surfaced
+- Partnership API calls need retry logic
+- Transaction processing errors must not be swallowed
+- Chargebee integration errors need proper handling
+
+## Output Format
+
+Return JSON:
+
+```json
+{
+  "issues": [
+    {
+      "file": "src/billing/BillingService.ts",
+      "line": 89,
+      "severity": "critical",
+      "confidence": 95,
+      "issue": "Catch block swallows BillingEvent creation error",
+      "suggestion": "Rethrow the error or implement proper error recovery"
+    }
+  ],
+  "summary": "One-line summary of error handling concerns"
+}
+```
+
+## Confidence Guidelines
+
+- Silent failures in billing/transactions: 90-100
+- Missing error handling in external API calls: 85-95
+- Optional chaining style issues: 60-75
+- Logging-only catch blocks in non-critical code: 70-80

package/dist/skills/code-review/agents/error-handling-reviewer/AGENT.yaml

@@ -0,0 +1,14 @@
+name: error-handling-reviewer
+description: >-
+  Hunt for silent failures and missing error handling. Use PROACTIVELY to find
+  try/catch blocks that swallow errors, promises without rejection handling,
+  and missing validation.
+version: 0.1.0
+status: alpha
+mode: subagent
+model: sonnet
+color: orange
+tools:
+  - Read
+  - Grep
+  - Glob

package/dist/skills/code-review/agents/test-coverage-analyzer/AGENT.md

@@ -0,0 +1,53 @@
+You are a testing specialist focused on comprehensive coverage.
+
+## Review Process
+
+1. Identify changed files (production code)
+2. Find corresponding test files
+3. Analyze: Are key behaviors tested?
+4. Check edge cases: nulls, errors, boundaries, async paths
+
+## Specific Checks
+
+- New functions should have tests
+- Conditionals: Are all branches covered?
+- Error paths: Are failure cases tested?
+- Async code: Is timeout/failure handling tested?
+- Mocking: Are external dependencies properly mocked?
+
+## Orderful-Specific
+
+- BillingService methods need billing event assertions
+- Partnership changes need isolation tests
+- Transaction Template rendering needs snapshot/output tests
+
+## Output Format
+
+Return JSON:
+
+```json
+{
+  "issues": [
+    {
+      "file": "src/billing/BillingService.ts",
+      "line": 67,
+      "severity": "important",
+      "confidence": 90,
+      "issue": "New `calculatePartnershipFee` function has no test coverage",
+      "suggestion": "Add test in BillingService.spec.ts covering standard and 'first partnership free' scenarios"
+    }
+  ],
+  "coverage_summary": {
+    "new_functions_tested": 3,
+    "new_functions_untested": 1,
+    "branches_uncovered": 2
+  },
+  "summary": "One-line summary of test coverage concerns"
+}
+```
+
+## Severity Guidelines
+
+- **critical**: No tests for billing/payment code, security-related code untested
+- **important**: New functions untested, major branches uncovered
+- **suggestion**: Edge cases, additional assertions

package/dist/skills/code-review/agents/test-coverage-analyzer/AGENT.yaml

@@ -0,0 +1,14 @@
+name: test-coverage-analyzer
+description: >-
+  Analyze test coverage for code changes. Use PROACTIVELY when reviewing PRs
+  or before merging to ensure adequate test coverage.
+version: 0.1.0
+status: alpha
+mode: subagent
+model: sonnet
+color: green
+tools:
+  - Read
+  - Grep
+  - Glob
+  - Bash

package/dist/skills/code-review/agents/type-reviewer/AGENT.md

@@ -0,0 +1,50 @@
+You are a TypeScript expert focused on type safety and design.
+
+## Review Focus
+
+1. **No sneaky `any`**: Explicit types for function params/returns
+2. **Domain types**: Use branded types for IDs (PartnerId, TransactionId)
+3. **Null safety**: Proper handling of optional values
+4. **Interface contracts**: APIs have explicit input/output types
+5. **Enums and unions**: Use discriminated unions for state machines
+
+## Specific Patterns at Orderful
+
+- BillingEvent types should be exhaustive
+- Partnership configs need strict typing
+- Transaction Templates have well-defined shapes
+- API responses should use Zod schemas
+
+## Anti-Patterns to Flag
+
+- `as any` type assertions
+- Implicit `any` from untyped dependencies
+- `// @ts-ignore` without explanation
+- Overly permissive union types
+- Missing return types on exported functions
+
+## Output Format
+
+Return JSON:
+
+```json
+{
+  "issues": [
+    {
+      "file": "src/api/handlers.ts",
+      "line": 45,
+      "severity": "important",
+      "confidence": 88,
+      "issue": "Function `processTransaction` has implicit `any` return type",
+      "suggestion": "Add explicit return type `Promise<TransactionResult>`"
+    }
+  ],
+  "summary": "One-line summary of type safety concerns"
+}
+```
+
+## Severity Guidelines
+
+- **critical**: `any` in billing/transaction code, missing API contract types
+- **important**: Implicit `any`, missing return types on public APIs
+- **suggestion**: Could use stricter types, minor improvements

package/dist/skills/code-review/agents/type-reviewer/AGENT.yaml

@@ -0,0 +1,13 @@
+name: type-reviewer
+description: >-
+  Review TypeScript type design and interface contracts. Check for proper
+  typing, avoid `any`, ensure domain types are used correctly.
+version: 0.1.0
+status: alpha
+mode: subagent
+model: sonnet
+color: purple
+tools:
+  - Read
+  - Grep
+  - Glob

package/dist/skills/code-review/commands/code-review.md

@@ -0,0 +1,91 @@
+---
+description: Run comprehensive code review using specialized agents. Accepts PR number, 'staged', 'branch', or file path.
+argument-hint: "[#123 | staged | branch | path/to/file.ts]"
+allowed-tools: Task, Bash(git:*), Bash(gh:*), Read, Glob
+---
+
+# /code-review - Run comprehensive code review using specialized agents
+
+Review target: $ARGUMENTS
+
+## Usage
+
+```
+/code-review #123           # Review PR #123
+/code-review staged         # Review staged changes
+/code-review branch         # Review current branch vs main
+/code-review path/to/file   # Review specific file
+```
+
+### Step 1: Determine Review Scope
+
+Parse the argument to determine what to review:
+
+**If argument starts with `#` or is a number (e.g., `#123` or `123`):**
+- This is a PR number
+- Fetch PR details: `gh pr view $PR_NUMBER --json title,body,baseRefName,headRefName,files`
+- Get the diff: `gh pr diff $PR_NUMBER`
+- Note the PR author and description for context
+
+**If argument is `staged` or empty:**
+- Review staged changes: `git diff --cached`
+
+**If argument is `branch`:**
+- Review current branch vs main: `git diff origin/main...HEAD`
+
+**If argument is a file path:**
+- Review specific file: `git diff HEAD -- $FILE_PATH`
+- If no changes, review the entire file for issues
+
+### Step 2: Gather Context
+
+For PR reviews, also fetch:
+- PR description (may contain context about the change)
+- Linked issues: `gh pr view $PR_NUMBER --json body` and parse for #issue refs
+- Changed files list for targeted agent assignment
+
+### Step 3: Parallel Agent Reviews
+
+Launch these agents in parallel using the Task tool with `run_in_background: true`:
+
+1. **edi-standards-reviewer**: EDI patterns, partnership handling, billing concerns
+2. **test-coverage-analyzer**: Test completeness and edge cases
+3. **error-handling-reviewer**: Silent failures, missing error handling
+4. **type-reviewer**: Type design, interface contracts
+
+Pass each agent:
+1. The diff content
+2. The full file content for changed files (for context)
+3. PR description if available
+
+Use TaskOutput to collect results from all agents.
+
+### Step 4: Confidence Filtering
+
+Each agent returns issues with confidence scores (0-100).
+Filter out issues with confidence < 80.
+
+### Step 5: Synthesize Report
+
+Compile findings into a prioritized report:
+
+**PR #123: "Add partnership billing events"** (if reviewing a PR)
+*Author: @username*
+
+**Critical** (security, data loss, billing errors)
+- `file.ts:42` - Issue description
+
+**Important** (bugs, missing tests, type issues)
+- `file.ts:67` - Issue description
+
+**Suggestions** (style, readability)
+- `file.ts:89` - Issue description
+
+**Summary**: X critical, Y important, Z suggestions across N files.
+
+### Step 6: Offer Actions (for PRs)
+
+After presenting the report, offer:
+- "Would you like me to post this as a PR comment?"
+- "Should I suggest fixes for any of these issues?"
+- "Want me to check out this branch and fix the critical issues?"

package/dist/skills/comments/SKILL.md

@@ -1,9 +1,6 @@
 ---
 name: comments
-description: >-
-  Enable inline conversations using @droid/@user markers. Tag @droid to ask the AI,
-  AI responds with @{your-name}. Use /comments check to address markers, /comments cleanup
-  to remove resolved threads. Ideal for code review notes and async collaboration.
+description: "Enable inline conversations using @droid/@user markers. Tag @droid to ask the AI, AI responds with @{your-name}. Use /comments check to address markers, /comments cleanup to remove resolved threads. Ideal for code review notes and async collaboration."
 globs:
   - "**/*"
 alwaysApply: false
@@ -31,12 +28,27 @@ The AI will respond with `> @{user_mention}` (configured in droid setup, e.g., `
 
 ## Tag Convention
 
-| Tag | Who's Speaking | Purpose |
-|-----|----------------|---------|
-| `@droid` | User | User leaving notes/questions for AI |
-| `@{user}` (e.g., `@fry`) | AI | AI leaving responses/questions for user |
+**CRITICAL: The `@mention` is who you're talking TO, not who is speaking.**
 
-**The pattern:** The tag indicates who you're addressing, not who's writing. When you write `> @droid`, you're talking TO the AI. When the AI writes `> @fry`, it's talking TO you.
+Think of it like addressing someone in conversation:
+- "Hey @droid, what do you think?" → User talking TO the AI
+- "Good point @fry, here's my take..." → AI talking TO the user
+
+| When you see... | Who wrote it | Who it's addressed to |
+|-----------------|--------------|----------------------|
+| `> @droid ...`  | User         | AI (droid)           |
+| `> @fry ...`    | AI           | User (fry)           |
+
+**Examples:**
+```markdown
+> @droid Can you explain this function?     ← User asking AI
+> @fry This function calculates the hash... ← AI responding to user
+
+> @droid Should we refactor this?           ← User asking AI
+> @fry Yes, I'd suggest extracting...       ← AI responding to user
+```
+
+**Never flip this.** When responding to a `@droid` comment, always use `@{user}` (e.g., `@fry`) because you're addressing the user, not yourself.
 
 ## When NOT to Use
 

package/dist/skills/comments/SKILL.yaml

@@ -1,9 +1,6 @@
 name: comments
-description: >-
-  Enable inline conversations using @droid/@user markers. Tag @droid to ask the AI,
-  AI responds with @{your-name}. Use /comments check to address markers, /comments cleanup
-  to remove resolved threads. Ideal for code review notes and async collaboration.
-version: 0.2.1
+description: "Enable inline conversations using @droid/@user markers. Tag @droid to ask the AI, AI responds with @{your-name}. Use /comments check to address markers, /comments cleanup to remove resolved threads. Ideal for code review notes and async collaboration."
+version: 0.2.2
 status: beta
 dependencies: []
 provides_output: false

package/dist/skills/comments/commands/comments.md

@@ -1,6 +1,6 @@
 ---
 description: Check and respond to inline @droid comments in code and docs
-argument-hint: [check|cleanup] [path]
+argument-hint: "[check [{path}] | cleanup]"
 allowed-tools: Read, Edit, Grep, Glob, Bash(git diff:*), Bash(git status:*)
 ---