@jmylchreest/aide-plugin 0.0.26 → 0.0.28

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@jmylchreest/aide-plugin",
-  "version": "0.0.26",
+  "version": "0.0.28",
   "description": "aide plugin for OpenCode — multi-agent orchestration, memory, skills, and persistence",
   "type": "module",
   "main": "./src/opencode/index.ts",

package/skills/code-search/SKILL.md

@@ -29,6 +29,7 @@ Search for code symbols (functions, classes, methods, types) and find their call
 Find functions, classes, methods, interfaces, and types by name or signature.
 
 **Example usage:**
+
 ```
 Search for: "getUserById"
 → Uses code_search tool
@@ -40,6 +41,7 @@ Search for: "getUserById"
 Find all places where a symbol is called/used.
 
 **Example usage:**
+
 ```
 Who calls "getUserById"?
 → Uses code_references tool
@@ -51,6 +53,7 @@ Who calls "getUserById"?
 List all symbols defined in a specific file.
 
 **Example usage:**
+
 ```
 What functions are in src/auth.ts?
 → Uses code_symbols tool
@@ -62,6 +65,7 @@ What functions are in src/auth.ts?
 Check if the codebase has been indexed.
 
 **Example usage:**
+
 ```
 Is the code indexed?
 → Uses code_stats tool
@@ -72,7 +76,9 @@ Is the code indexed?
 
 1. **First, check if codebase is indexed:**
    - Use `code_stats` to verify indexing
-   - If not indexed, tell user to run: `aide code index`
+   - If not indexed, tell user to run: `./.aide/bin/aide code index`
+
+**Binary location:** The aide binary is at `.aide/bin/aide`. If it's on your `$PATH`, you can use `aide` directly.
 
 2. **Search for symbols:**
    - Use `code_search` with the symbol name or pattern
@@ -91,18 +97,20 @@ Is the code indexed?
 **User:** "Where is the authentication function?"
 
 **Assistant action:**
+
 1. Use `code_search` with query "auth" or "authenticate"
 2. Show matching functions with file locations
 
 **User:** "Who calls authenticateUser?"
 
 **Assistant action:**
+
 1. Use `code_references` with symbol "authenticateUser"
 2. Show all call sites grouped by file
 
 ## Notes
 
-- Code must be indexed first: `aide code index`
+- Code must be indexed first: `./.aide/bin/aide code index`
 - Indexing is incremental - only changed files are re-parsed
 - Supports: TypeScript, JavaScript, Go, Python, Rust, and more
 - For file watching: `AIDE_CODE_WATCH=1 claude`

package/skills/decide/SKILL.md

@@ -10,7 +10,7 @@ triggers:
   - which option
   - trade-offs
   - pros and cons
-allowed-tools: Bash(aide decision set *)
+allowed-tools: Bash(./.aide/bin/aide decision set *)
 ---
 
 # Decision Mode
@@ -28,12 +28,14 @@ When facing a significant technical decision, this workflow guides you through s
 ### Phase 1: IDENTIFY
 
 Ask the user to clarify:
+
 - What decision needs to be made?
 - What is the context? (new system, migration, constraint?)
 - What are the requirements? (scale, team, timeline?)
 - Are there any hard constraints?
 
 **Example questions:**
+
 - "What technical decision do you need to make?"
 - "What problem are you trying to solve?"
 - "Are there any constraints I should know about?"
@@ -41,11 +43,13 @@ Ask the user to clarify:
 ### Phase 2: EXPLORE
 
 Research and propose options:
+
 - List 3-5 viable alternatives
 - Include the obvious choices AND less common ones
 - For each option, note what it's best suited for
 
 **Output format:**
+
 ```markdown
 ## Options
 
@@ -62,22 +66,25 @@ Research and propose options:
 ### Phase 3: ANALYZE
 
 For each option, evaluate:
+
 - **Pros**: What are the benefits?
 - **Cons**: What are the drawbacks?
 - **Fit**: How well does it match the requirements?
 
 **Output format:**
+
 ```markdown
 ## Analysis
 
-| Option | Pros | Cons | Fit |
-|--------|------|------|-----|
-| Option A | Fast, simple | Limited scale | Good for MVP |
-| Option B | Scalable | Complex setup | Good for growth |
-| Option C | Flexible | Learning curve | Good if team knows it |
+| Option   | Pros         | Cons           | Fit                   |
+| -------- | ------------ | -------------- | --------------------- |
+| Option A | Fast, simple | Limited scale  | Good for MVP          |
+| Option B | Scalable     | Complex setup  | Good for growth       |
+| Option C | Flexible     | Learning curve | Good if team knows it |
 ```
 
 Consider:
+
 - Complexity (implementation, maintenance)
 - Team familiarity
 - Scalability
@@ -93,6 +100,7 @@ Provide a clear recommendation with rationale:
 ## Recommendation
 
 I recommend **[Option]** because:
+
 1. [Primary reason tied to requirements]
 2. [Secondary benefit]
 3. [Risk mitigation]
@@ -101,6 +109,7 @@ This choice [addresses constraint X] while [enabling future Y].
 ```
 
 Ask for confirmation:
+
 - "Does this recommendation align with your goals?"
 - "Would you like to proceed with this decision?"
 - "Any concerns before we record this?"
@@ -108,31 +117,36 @@ Ask for confirmation:
 ### Phase 5: CONFIRM
 
 Wait for explicit user approval before recording:
+
 - User says "yes", "go ahead", "let's do it" → proceed to record
 - User has concerns → address them, refine recommendation
 - User wants different option → adjust and confirm
 
 ### Phase 6: RECORD
 
-Store the decision using the `aide decision set` CLI command via Bash:
+Store the decision using the `./.aide/bin/aide decision set` CLI command via Bash:
 
 ```bash
-aide decision set "<topic-slug>" "<decision summary>" --rationale="<why this was chosen>"
+./.aide/bin/aide decision set "<topic-slug>" "<decision summary>" --rationale="<why this was chosen>"
 ```
 
+**Binary location:** The aide binary is at `.aide/bin/aide`. If it's on your `$PATH`, you can use `aide` directly.
+
 **Topic naming:**
+
 - Use kebab-case: `auth-strategy`, `database-choice`, `api-design`
 - Be specific: `user-auth-method` not just `auth`
 - Include scope if relevant: `payments-queue-strategy`
 
 **Verify** the decision was stored:
+
 ```bash
-aide decision get "<topic-slug>"
+./.aide/bin/aide decision get "<topic-slug>"
 ```
 
 ## Example Session
 
-```
+````
 User: help me decide how to handle background jobs
 
 Claude: [IDENTIFY]
@@ -183,22 +197,23 @@ Do you want to proceed with this decision?
 User: yes, let's go with BullMQ
 
 Claude: [RECORD]
-[Calls aide decision set via Bash]
+[Calls ./.aide/bin/aide decision set via Bash]
 
 ```bash
-aide decision set "background-jobs-queue" "Use BullMQ with Redis for background job processing (emails, webhooks)" --rationale="Native TypeScript support, built-in retries/delays/rate-limiting, Bull Board for visibility, 10K/day well within capacity. Rejected: SQS+Lambda (AWS lock-in, cold starts), DB queue (limited scale), RabbitMQ (over-engineered)"
-```
+./.aide/bin/aide decision set "background-jobs-queue" "Use BullMQ with Redis for background job processing (emails, webhooks)" --rationale="Native TypeScript support, built-in retries/delays/rate-limiting, Bull Board for visibility, 10K/day well within capacity. Rejected: SQS+Lambda (AWS lock-in, cold starts), DB queue (limited scale), RabbitMQ (over-engineered)"
+````
 
 Decision recorded. Future sessions will follow this architectural choice.
+
 ```
 
 ## Integration
 
-Decisions stored via `aide decision set` are:
+Decisions stored via `./.aide/bin/aide decision set` are:
 1. Persisted in the aide memory database
 2. Injected into future session contexts at startup
 3. Visible to swarm agents (they won't contradict decisions)
-4. Queryable via `aide decision get`, `aide decision list`, or the MCP tools `decision_get`/`decision_list`
+4. Queryable via `./.aide/bin/aide decision get`, `./.aide/bin/aide decision list`, or the MCP tools `decision_get`/`decision_list`
 
 ## When to Use This Skill
 
@@ -223,3 +238,4 @@ Decisions can be superseded:
 1. Run `/aide:decide` again for the same topic
 2. New decision replaces old (history preserved)
 3. Use `mcp__plugin_aide_aide__decision_history` to see evolution
+```

package/skills/design/SKILL.md

@@ -21,6 +21,7 @@ Output a technical design specification that downstream SDLC stages can consume.
 ## Purpose
 
 Create a structured design document that defines:
+
 1. **What** to build (interfaces, types, components)
 2. **How** it fits together (data flow, interactions)
 3. **Why** key decisions were made (rationale)
@@ -31,6 +32,7 @@ Create a structured design document that defines:
 ### Step 1: Understand the Request
 
 Read the request and identify:
+
 - Core functionality required
 - Constraints (tech stack, patterns, performance)
 - Integration points with existing code
@@ -88,13 +90,15 @@ Request → Controller → Service → Repository → Database
 Store architectural decisions for future reference:
 
 ```bash
-aide decision set "<feature>-storage" "PostgreSQL with JSONB for metadata" \
+./.aide/bin/aide decision set "<feature>-storage" "PostgreSQL with JSONB for metadata" \
   --rationale="Need flexible schema for user preferences"
 
-aide decision set "<feature>-auth" "JWT with refresh tokens" \
+./.aide/bin/aide decision set "<feature>-auth" "JWT with refresh tokens" \
   --rationale="Stateless auth, mobile client support"
 ```
 
+**Binary location:** The aide binary is at `.aide/bin/aide`. If it's on your `$PATH`, you can use `aide` directly.
+
 ### Step 6: Define Acceptance Criteria
 
 List specific, testable criteria for the TEST stage:
@@ -117,58 +121,68 @@ List specific, testable criteria for the TEST stage:
 # Design: [Feature Name]
 
 ## Overview
+
 [1-2 sentence summary of what this feature does]
 
 ## Interfaces
 
 ### [Interface/Type Name]
+
 \`\`\`typescript
 // Interface definition with comments
 \`\`\`
 
 ## Data Flow
+
 [Diagram or description of component interactions]
 
 ## Key Decisions
 
-| Decision | Choice | Rationale |
-|----------|--------|-----------|
-| Storage | PostgreSQL | [why] |
-| Auth | JWT | [why] |
+| Decision | Choice     | Rationale |
+| -------- | ---------- | --------- |
+| Storage  | PostgreSQL | [why]     |
+| Auth     | JWT        | [why]     |
 
 ## Acceptance Criteria
+
 - [ ] Criterion 1
 - [ ] Criterion 2
 - [ ] Criterion 3
 
 ## Files to Create/Modify
+
 - `path/to/file.ts` - [purpose]
 - `path/to/test.ts` - [test scope]
 
 ## Dependencies
+
 - [External packages needed]
 - [Internal modules to import]
 
 ## Out of Scope
+
 - [Explicitly excluded items]
 ```
 
 ## Failure Handling
 
 ### Unclear Requirements
+
 1. List specific ambiguities
 2. State assumptions you're making
-3. Record assumptions: `aide memory add --category=decision "Assumed X because Y"`
+3. Record assumptions: `./.aide/bin/aide memory add --category=decision "Assumed X because Y"`
 4. Proceed with reasonable defaults
 
 ### Conflicting Patterns Found
+
 1. Document the conflicting patterns
 2. Choose one and record the decision:
    ```bash
-   aide decision set "<topic>" "<choice>" --rationale="<why this over alternatives>"
+   ./.aide/bin/aide decision set "<topic>" "<choice>" --rationale="<why this over alternatives>"
    ```
 
 ### Too Large / Too Vague
+
 1. Break into smaller, focused designs
 2. Design the core/MVP first
 3. Note future phases in "Out of Scope"
@@ -176,6 +190,7 @@ List specific, testable criteria for the TEST stage:
 ## Verification Checklist
 
 Before completing design:
+
 - [ ] Interfaces are defined with types
 - [ ] Data flow is documented
 - [ ] Key decisions are recorded in aide
@@ -186,6 +201,7 @@ Before completing design:
 ## Completion
 
 When design is complete:
+
 1. Output the full design document
 2. Confirm: "Design complete. Ready for TEST stage."
 

package/skills/implement/SKILL.md

@@ -22,6 +22,7 @@ This is the DEV stage of the SDLC pipeline. Tests already exist from the TEST st
 ## Prerequisites
 
 Before starting:
+
 - Tests exist and are failing (from TEST stage)
 - Design/spec is available (from DESIGN stage)
 - You know which files to create/modify
@@ -44,6 +45,7 @@ go test ./pkg/feature/...
 ### Step 2: Read the Tests
 
 Understand what the tests expect:
+
 - What functions/methods need to exist?
 - What are the expected inputs and outputs?
 - What edge cases are covered?
@@ -87,6 +89,7 @@ go test -v ./pkg/feature/...
 ```
 
 **BLOCKING RULE**: If any test fails:
+
 1. Analyze the failure
 2. Fix the issue
 3. Re-run tests
@@ -125,11 +128,14 @@ git commit -m "feat: implement <feature> - tests passing"
 
 ```typescript
 // Read test expectations
-describe('UserService', () => {
-  it('should create user with email and name', async () => {
-    const user = await service.createUser({ email: 'test@example.com', name: 'Test' });
+describe("UserService", () => {
+  it("should create user with email and name", async () => {
+    const user = await service.createUser({
+      email: "test@example.com",
+      name: "Test",
+    });
     expect(user.id).toBeDefined();
-    expect(user.email).toBe('test@example.com');
+    expect(user.email).toBe("test@example.com");
   });
 });
 
@@ -181,7 +187,7 @@ func (s *UserService) CreateUser(ctx context.Context, input CreateUserInput) (*U
 3. Check design decisions - is implementation matching spec?
 4. Record blocker:
    ```bash
-   aide memory add --category=blocker "Cannot pass test X: <reason>"
+   ./.aide/bin/aide memory add --category=blocker "Cannot pass test X: <reason>"
    ```
 5. If stuck after 3 attempts, ask for help
 
@@ -199,13 +205,16 @@ func (s *UserService) CreateUser(ctx context.Context, input CreateUserInput) (*U
 2. Don't refactor during implement stage
 3. Note concerns for future:
    ```bash
-   aide memory add --category=issue "Implementation of X could be improved: <how>"
+   ./.aide/bin/aide memory add --category=issue "Implementation of X could be improved: <how>"
    ```
 4. Proceed - refactoring is a separate concern
 
+**Binary location:** The aide binary is at `.aide/bin/aide`. If it's on your `$PATH`, you can use `aide` directly.
+
 ## Verification Checklist
 
 Before completing:
+
 - [ ] All tests pass (not just some)
 - [ ] Build succeeds
 - [ ] Changes are committed

package/skills/memorise/SKILL.md

@@ -12,7 +12,7 @@ triggers:
   - store this
   - for future
   - keep in mind
-allowed-tools: Bash(aide memory add *)
+allowed-tools: Bash(./.aide/bin/aide memory add *)
 ---
 
 # Memorise
@@ -23,12 +23,14 @@ Capture important information for future sessions by storing it in the aide memo
 
 ## How to Store
 
-Use the `aide memory add` CLI command via Bash:
+Use the `./.aide/bin/aide memory add` CLI command via Bash:
 
 ```bash
-aide memory add --category=<category> --tags=<comma,separated,tags> "<content>"
+./.aide/bin/aide memory add --category=<category> --tags=<comma,separated,tags> "<content>"
 ```
 
+**Binary location:** The aide binary is at `.aide/bin/aide`. If it's on your `$PATH`, you can use `aide` directly.
+
 ## Categories
 
 - `learning` - Something discovered about the codebase or tools
@@ -48,23 +50,27 @@ aide memory add --category=<category> --tags=<comma,separated,tags> "<content>"
 ## Examples
 
 ### Simple preference (global - injected at session start)
+
 ```bash
-aide memory add --category=learning --tags=preferences,colour,scope:global "User's favourite colour is blue"
+./.aide/bin/aide memory add --category=learning --tags=preferences,colour,scope:global "User's favourite colour is blue"
 ```
 
 ### Technical learning (project-specific)
+
 ```bash
-aide memory add --category=learning --tags=testing,vitest,project:myapp,session:abc12345 "Vitest requires .js extensions for ESM imports even for .ts files. Configure moduleResolution: NodeNext in tsconfig."
+./.aide/bin/aide memory add --category=learning --tags=testing,vitest,project:myapp,session:abc12345 "Vitest requires .js extensions for ESM imports even for .ts files. Configure moduleResolution: NodeNext in tsconfig."
 ```
 
 ### Session summary
+
 ```bash
-aide memory add --category=session --tags=auth,api,project:myapp,session:abc12345 "Implemented JWT auth with 15min access tokens, 7day refresh tokens in httpOnly cookies. Files: src/auth/jwt.ts, src/middleware/auth.ts, src/routes/auth.ts"
+./.aide/bin/aide memory add --category=session --tags=auth,api,project:myapp,session:abc12345 "Implemented JWT auth with 15min access tokens, 7day refresh tokens in httpOnly cookies. Files: src/auth/jwt.ts, src/middleware/auth.ts, src/routes/auth.ts"
 ```
 
 ### Gotcha (global - applies everywhere)
+
 ```bash
-aide memory add --category=gotcha --tags=hooks,claude-code,scope:global "Hooks must not write to stderr - Claude Code interprets any stderr as error. Debug logging must go to files only."
+./.aide/bin/aide memory add --category=gotcha --tags=hooks,claude-code,scope:global "Hooks must not write to stderr - Claude Code interprets any stderr as error. Debug logging must go to files only."
 ```
 
 ## Instructions
@@ -78,7 +84,7 @@ When the user invokes `/aide:memorise <something>`:
    - **Session summary** → add `project:<project-name>,session:${CLAUDE_SESSION_ID:0:8}`
 3. Choose appropriate category and descriptive tags
 4. Format the content concisely but completely
-5. Call `aide memory add` via Bash to store it
+5. Call `./.aide/bin/aide memory add` via Bash to store it
 6. **Verify success** - check exit code is 0 and output contains the memory ID
 7. Confirm what was stored
 
@@ -86,7 +92,7 @@ Keep content concise - aim for 1-3 sentences unless it's a complex session summa
 
 ## Failure Handling
 
-If `aide memory add` fails:
+If `./.aide/bin/aide memory add` fails:
 
 1. **Check error message** - common issues:
    - Database not accessible: ensure aide MCP server is running
@@ -104,24 +110,26 @@ If `aide memory add` fails:
 ## Verification
 
 A successful memory add returns:
+
 ```
 Added memory: <ULID>
 ```
 
 You can verify by searching for the memory:
+
 ```bash
-aide memory search "<key term from content>" --limit=1
+./.aide/bin/aide memory search "<key term from content>" --limit=1
 ```
 
 ## Scope Tags
 
 Use scope tags to control when memories are injected:
 
-| Tag | When to Use | Injection |
-|-----|-------------|-----------|
-| `scope:global` | User preferences, universal learnings | Every session |
-| `project:<name>` | Project-specific learnings | Sessions in that project |
-| `session:<id>` | Context for this work session | Recent session injection |
+| Tag              | When to Use                           | Injection                |
+| ---------------- | ------------------------------------- | ------------------------ |
+| `scope:global`   | User preferences, universal learnings | Every session            |
+| `project:<name>` | Project-specific learnings            | Sessions in that project |
+| `session:<id>`   | Context for this work session         | Recent session injection |
 
 ### Tagging Rules
 
@@ -134,6 +142,7 @@ Get the project name from the git remote or directory name. Session ID is availa
 ## For Swarm/Multi-Agent
 
 Add agent context to tags:
+
 ```bash
-aide memory add --category=session --tags=swarm,agent:main "Overall task outcome..."
+./.aide/bin/aide memory add --category=session --tags=swarm,agent:main "Overall task outcome..."
 ```

package/skills/plan-swarm/SKILL.md

@@ -40,16 +40,19 @@ Do NOT ask questions yet. Build understanding first.
 Conduct 2-3 rounds of focused questions. Each round has 2-4 questions. Max 3 rounds total.
 
 **Round 1: Scope & Boundaries**
+
 - What is in scope vs out of scope?
 - What are the success criteria?
 - Are there any constraints (time, tech, compatibility)?
 
 **Round 2: Dependencies & Risks**
+
 - What shared state or files will multiple stories touch?
 - What could go wrong? What are the risky parts?
 - Are there external dependencies (APIs, services, data)?
 
 **Round 3: Acceptance Criteria** (if needed)
+
 - How will we know each story is done?
 - What tests should exist?
 - What does "good enough" look like?
@@ -72,6 +75,7 @@ Output a structured story list. Each story must be:
 ## Stories
 
 ### 1. [Story Name]
+
 - **Description**: What this story implements
 - **Files**: List of files this story will create or modify
 - **Acceptance Criteria**:
@@ -81,10 +85,12 @@ Output a structured story list. Each story must be:
 - **Notes**: Any special considerations
 
 ### 2. [Story Name]
+
 ...
 ```
 
 **Independence check**: Verify that no two stories modify the same file. If they do, either:
+
 1. Merge the stories
 2. Restructure so each story owns its files
 3. Sequence them (one blocks the other)
@@ -94,14 +100,17 @@ Output a structured story list. Each story must be:
 1. **Present the plan** to the user for review
 2. **Store as decision** once approved:
    ```bash
-   aide decision set "swarm-plan" "<N> stories: <story-1>, <story-2>, ..." \
+   ./.aide/bin/aide decision set "swarm-plan" "<N> stories: <story-1>, <story-2>, ..." \
      --details='<JSON object>' \
      --rationale="<brief description of scope and approach>"
    ```
 3. **Record shared decisions** discovered during planning:
    ```bash
-   aide decision set "<topic>" "<decision>"
+   ./.aide/bin/aide decision set "<topic>" "<decision>"
    ```
+
+**Binary location:** The aide binary is at `.aide/bin/aide`. If it's on your `$PATH`, you can use `aide` directly.
+
 4. **Instruct the user**: Run `/aide:swarm` to execute the plan
 
 ## Output Format