@orderful/droid 0.6.0 → 0.8.0

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

@@ -31,12 +31,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

@@ -3,7 +3,7 @@ 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
+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:*)
 ---
 

package/dist/skills/project/SKILL.md

@@ -32,31 +32,33 @@ Chat history disappears. Projects persist.
 
 ## Configuration
 
-Check `~/.droid/skills/project/overrides.yaml` for user settings:
+**IMPORTANT:** Before using any default paths, ALWAYS read `~/.droid/skills/project/overrides.yaml` first. If `projects_dir` is configured there, use that path. Only fall back to defaults if the file doesn't exist or lacks a `projects_dir` setting.
 
 | Setting | Default | Description |
 |---------|---------|-------------|
-| `projects_dir` | `~/{ai_tool}/projects` | Where projects are stored (varies by AI tool) |
+| `projects_dir` | (see below) | Where projects are stored |
 | `preset` | `markdown` | Output format: `markdown` or `obsidian` |
 
-Default `projects_dir` by AI tool:
+Default `projects_dir` by AI tool (only if not configured):
 - **claude-code**: `~/.claude/projects`
-- **opencode**: `~/.opencode/projects`
+- **opencode**: `~/.config/opencode/projects`
 
 ## Commands
 
 | Command | Action |
 |---------|--------|
 | `/project` | List and select a project |
-| `/project {keywords}` | Fuzzy-match and load |
-| `/project create {name}` | Create new project |
+| `/project {keywords}` | **Search** for existing project (fuzzy-match and load) |
+| `/project create {name}` | Create new project (requires `create` keyword) |
 | `/project update` | Update from conversation context |
 
+**IMPORTANT:** The default action for `/project {keywords}` is to **SEARCH** for existing projects, NOT create. Only use `/project create {name}` when the user explicitly wants to create a new project.
+
 ## Loading a Project
 
 **Trigger:** `/project {keywords}` or user asks to load/open a project
 
-**TLDR:** Fuzzy-match keywords against project folders, read PROJECT.md, summarize context.
+**TLDR:** Search for and load an existing project. Fuzzy-match keywords against project folders, read PROJECT.md, summarize context.
 
 Full procedure: `references/loading.md`
 

package/dist/skills/project/SKILL.yaml

@@ -5,7 +5,7 @@ description: >-
   new learnings (/project update), or create new projects (/project create).
   Use when working on multi-session features, refactors, or any work that
   benefits from accumulated context.
-version: 0.1.0
+version: 0.1.1
 status: beta
 dependencies: []
 provides_output: false

package/dist/skills/project/commands/project.md

@@ -1,6 +1,6 @@
 ---
 description: Manage project context files for persistent AI memory across sessions
-argument-hint: [name | update [name] | create [name]]
+argument-hint: "[{keywords} | update | create {name}]"
 allowed-tools: Read, Write, Edit, Glob, Bash(mkdir:*), Bash(ls:*)
 ---
 
@@ -12,20 +12,25 @@ Entry point for project context management. See the **project skill** for full b
 
 $ARGUMENTS
 
+## Default Behavior
+
+**IMPORTANT:** When given keywords (e.g., `/project audit-log`), the default action is to **SEARCH** for existing projects, NOT create. Only create a project when the `create` keyword is explicitly used.
+
 ## Usage
 
 ```
 /project                    # List and select a project
-/project {keywords}         # Fuzzy-match and load
+/project {keywords}         # SEARCH: Fuzzy-match and load existing project
 /project update             # Update from conversation context
 /project update {name}      # Update specific project
 /project create             # Create new project interactively
-/project create {name}      # Create with name
+/project create {name}      # Create with name (requires "create" keyword)
 ```
 
 ## Configuration
 
-From `~/.droid/skills/project/overrides.yaml`:
+**ALWAYS read `~/.droid/skills/project/overrides.yaml` first.** Use configured values if present, only fall back to defaults if missing.
+
 - `projects_dir` - Where projects live (default varies by AI tool)
 - `preset` - Template format: `markdown` or `obsidian`
 

package/dist/skills/project/references/creating.md

@@ -4,21 +4,26 @@
 
 ## Procedure
 
-1. **Get project name**
+1. **Read config first**
+   - Read `~/.droid/skills/project/overrides.yaml`
+   - Use `projects_dir` if configured, otherwise use default for current AI tool
+   - Use `preset` if configured (markdown or obsidian)
+
+2. **Get project name**
    - Use provided name, or ask if not provided
    - Convert to kebab-case for folder name
    - Convert to Title Case for display name
 
-2. **Create project folder**
+3. **Create project folder**
    - Path: `{projects_dir}/{kebab-case-name}/`
    - Verify folder doesn't already exist
 
-3. **Create files from templates** (see `templates.md`)
+4. **Create files from templates** (see `templates.md`)
    - `PROJECT.md` - Main context file
    - `CHANGELOG.md` - Version history
    - Format varies by `preset` config (markdown vs obsidian)
 
-4. **Confirm creation**
+5. **Confirm creation**
    - Show created folder path
    - Offer to help fill in sections (Overview, Goals, Technical Details)
 

package/dist/skills/project/references/loading.md

@@ -2,25 +2,31 @@
 
 **Trigger:** `/project {keywords}` or user asks to load/open a project
 
+**IMPORTANT:** This is a SEARCH operation. When keywords are provided, search for existing projects - do NOT create a new project. Creating requires the explicit `/project create {name}` command.
+
 ## Procedure
 
-1. **List projects** in configured `projects_dir`
+1. **Read config first**
+   - Read `~/.droid/skills/project/overrides.yaml`
+   - Use `projects_dir` if configured, otherwise use default for current AI tool
+
+2. **List projects** in configured `projects_dir`
    - Each subfolder with a `PROJECT.md` is a project
 
-2. **If no name provided:**
+3. **If no name provided:**
    - Use AskUserQuestion to present available projects
    - Let user select which to load
 
-3. **If name/keywords provided:**
+4. **If name/keywords provided:**
    - Parse as space-separated keywords (e.g., "transaction templates" → `["transaction", "templates"]`)
    - Find folders where name contains ALL keywords (case-insensitive, hyphens as word separators)
 
-4. **Based on matches:**
+5. **Based on matches:**
    - **No matches**: List available projects, ask user to select
    - **One match**: Read `{folder}/PROJECT.md`
    - **Multiple matches**: Use AskUserQuestion to select from matches
 
-5. **After loading:**
+6. **After loading:**
    - Confirm which project was loaded
    - Summarize key context (2-3 sentences)
    - Use project contents for all subsequent work in the session

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@orderful/droid",
-  "version": "0.6.0",
+  "version": "0.8.0",
   "description": "AI workflow toolkit for sharing skills, commands, and agents across the team",
   "type": "module",
   "bin": {