@zcy2nn/agent-forge 1.1.3 → 1.1.5
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/README.md +188 -247
- package/agent-forge.schema.json +2 -265
- package/dist/agents/orchestrator.d.ts +1 -1
- package/dist/cli/index.js +90 -259
- package/dist/cli/providers.d.ts +0 -44
- package/dist/cli/types.d.ts +0 -2
- package/dist/config/constants.d.ts +3 -8
- package/dist/config/index.d.ts +0 -1
- package/dist/config/loader.d.ts +1 -1
- package/dist/config/schema.d.ts +1 -184
- package/dist/hooks/index.d.ts +0 -6
- package/dist/hooks/json-error-recovery/hook.d.ts +1 -1
- package/dist/hooks/todo-continuation/index.d.ts +2 -1
- package/dist/index.d.ts +1 -1
- package/dist/index.js +7875 -31853
- package/dist/tools/index.d.ts +0 -3
- package/dist/tui.js +5 -61
- package/dist/utils/index.d.ts +0 -2
- package/package.json +95 -104
- package/src/skills/brainstorming/SKILL.md +185 -186
- package/src/skills/brainstorming/scripts/frame-template.html +214 -214
- package/src/skills/brainstorming/scripts/server.cjs +354 -354
- package/src/skills/brainstorming/spec-document-reviewer-prompt.md +1 -1
- package/src/skills/requesting-code-review/SKILL.md +1 -1
- package/src/skills/subagent-driven-development/SKILL.md +1 -1
- package/src/skills/systematic-debugging/SKILL.md +318 -318
- package/src/skills/test-driven-development/SKILL.md +392 -392
- package/src/skills/verification-before-completion/SKILL.md +153 -153
- package/src/skills/writing-plans/SKILL.md +2 -2
- package/src/skills/writing-skills/graphviz-conventions.dot +171 -171
- package/dist/agents/council.d.ts +0 -27
- package/dist/agents/councillor.d.ts +0 -2
- package/dist/agents/designer.d.ts +0 -2
- package/dist/agents/explorer.d.ts +0 -2
- package/dist/agents/fixer.d.ts +0 -2
- package/dist/agents/implementer.d.ts +0 -2
- package/dist/agents/librarian.d.ts +0 -2
- package/dist/agents/observer.d.ts +0 -2
- package/dist/agents/oracle.d.ts +0 -2
- package/dist/agents/reviewer.d.ts +0 -2
- package/dist/cli/migration.d.ts +0 -46
- package/dist/config/council-schema.d.ts +0 -127
- package/dist/council/council-manager.d.ts +0 -49
- package/dist/council/index.d.ts +0 -1
- package/dist/hooks/phase-reminder/index.d.ts +0 -26
- package/dist/hooks/post-file-tool-nudge/index.d.ts +0 -19
- package/dist/skills/systematic-debugging/condition-based-waiting-example.d.ts +0 -51
- package/dist/tools/council.d.ts +0 -10
- package/src/skills/codemap/README.md +0 -59
- package/src/skills/codemap/SKILL.md +0 -163
- package/src/skills/codemap/codemap.md +0 -36
- package/src/skills/codemap/scripts/codemap.mjs +0 -483
- package/src/skills/codemap/scripts/codemap.test.ts +0 -129
- package/src/skills/codemap.md +0 -40
- package/src/skills/simplify/README.md +0 -19
- package/src/skills/simplify/SKILL.md +0 -138
- package/src/skills/simplify/codemap.md +0 -36
- package/src/skills/using-git-worktrees/SKILL.md +0 -226
|
@@ -1,26 +0,0 @@
|
|
|
1
|
-
export declare const PHASE_REMINDER = "<internal_reminder>!IMPORTANT! Recall the workflow rules:\nUnderstand \u2192 choose the best parallelized path based on your capabilities and agents delegation rules \u2192 recall session reuse rules \u2192 execute \u2192 verify.\nIf delegating, launch the specialist in the same turn you mention it !END!</internal_reminder>";
|
|
2
|
-
interface MessageInfo {
|
|
3
|
-
role: string;
|
|
4
|
-
agent?: string;
|
|
5
|
-
sessionID?: string;
|
|
6
|
-
}
|
|
7
|
-
interface MessagePart {
|
|
8
|
-
type: string;
|
|
9
|
-
text?: string;
|
|
10
|
-
[key: string]: unknown;
|
|
11
|
-
}
|
|
12
|
-
interface MessageWithParts {
|
|
13
|
-
info: MessageInfo;
|
|
14
|
-
parts: MessagePart[];
|
|
15
|
-
}
|
|
16
|
-
/**
|
|
17
|
-
* Creates the experimental.chat.messages.transform hook for phase reminder injection.
|
|
18
|
-
* This hook runs right before sending to API, so it doesn't affect UI display.
|
|
19
|
-
* Only injects for the orchestrator agent.
|
|
20
|
-
*/
|
|
21
|
-
export declare function createPhaseReminderHook(): {
|
|
22
|
-
'experimental.chat.messages.transform': (_input: Record<string, never>, output: {
|
|
23
|
-
messages: MessageWithParts[];
|
|
24
|
-
}) => Promise<void>;
|
|
25
|
-
};
|
|
26
|
-
export {};
|
|
@@ -1,19 +0,0 @@
|
|
|
1
|
-
/**
|
|
2
|
-
* Post-tool nudge - queues a delegation reminder after file reads/writes.
|
|
3
|
-
* Catches the "inspect/edit files → implement myself" anti-pattern.
|
|
4
|
-
*/
|
|
5
|
-
interface ToolExecuteAfterInput {
|
|
6
|
-
tool: string;
|
|
7
|
-
sessionID?: string;
|
|
8
|
-
callID?: string;
|
|
9
|
-
}
|
|
10
|
-
interface ToolExecuteAfterOutput {
|
|
11
|
-
output?: unknown;
|
|
12
|
-
}
|
|
13
|
-
interface PostFileToolNudgeOptions {
|
|
14
|
-
shouldInject?: (sessionID: string) => boolean;
|
|
15
|
-
}
|
|
16
|
-
export declare function createPostFileToolNudgeHook(options?: PostFileToolNudgeOptions): {
|
|
17
|
-
'tool.execute.after': (input: ToolExecuteAfterInput, output: ToolExecuteAfterOutput) => Promise<void>;
|
|
18
|
-
};
|
|
19
|
-
export {};
|
|
@@ -1,51 +0,0 @@
|
|
|
1
|
-
import type { ThreadManager } from '~/threads/thread-manager';
|
|
2
|
-
import type { LaceEvent, LaceEventType } from '~/threads/types';
|
|
3
|
-
/**
|
|
4
|
-
* Wait for a specific event type to appear in thread
|
|
5
|
-
*
|
|
6
|
-
* @param threadManager - The thread manager to query
|
|
7
|
-
* @param threadId - Thread to check for events
|
|
8
|
-
* @param eventType - Type of event to wait for
|
|
9
|
-
* @param timeoutMs - Maximum time to wait (default 5000ms)
|
|
10
|
-
* @returns Promise resolving to the first matching event
|
|
11
|
-
*
|
|
12
|
-
* Example:
|
|
13
|
-
* await waitForEvent(threadManager, agentThreadId, 'TOOL_RESULT');
|
|
14
|
-
*/
|
|
15
|
-
export declare function waitForEvent(threadManager: ThreadManager, threadId: string, eventType: LaceEventType, timeoutMs?: number): Promise<LaceEvent>;
|
|
16
|
-
/**
|
|
17
|
-
* Wait for a specific number of events of a given type
|
|
18
|
-
*
|
|
19
|
-
* @param threadManager - The thread manager to query
|
|
20
|
-
* @param threadId - Thread to check for events
|
|
21
|
-
* @param eventType - Type of event to wait for
|
|
22
|
-
* @param count - Number of events to wait for
|
|
23
|
-
* @param timeoutMs - Maximum time to wait (default 5000ms)
|
|
24
|
-
* @returns Promise resolving to all matching events once count is reached
|
|
25
|
-
*
|
|
26
|
-
* Example:
|
|
27
|
-
* // Wait for 2 AGENT_MESSAGE events (initial response + continuation)
|
|
28
|
-
* await waitForEventCount(threadManager, agentThreadId, 'AGENT_MESSAGE', 2);
|
|
29
|
-
*/
|
|
30
|
-
export declare function waitForEventCount(threadManager: ThreadManager, threadId: string, eventType: LaceEventType, count: number, timeoutMs?: number): Promise<LaceEvent[]>;
|
|
31
|
-
/**
|
|
32
|
-
* Wait for an event matching a custom predicate
|
|
33
|
-
* Useful when you need to check event data, not just type
|
|
34
|
-
*
|
|
35
|
-
* @param threadManager - The thread manager to query
|
|
36
|
-
* @param threadId - Thread to check for events
|
|
37
|
-
* @param predicate - Function that returns true when event matches
|
|
38
|
-
* @param description - Human-readable description for error messages
|
|
39
|
-
* @param timeoutMs - Maximum time to wait (default 5000ms)
|
|
40
|
-
* @returns Promise resolving to the first matching event
|
|
41
|
-
*
|
|
42
|
-
* Example:
|
|
43
|
-
* // Wait for TOOL_RESULT with specific ID
|
|
44
|
-
* await waitForEventMatch(
|
|
45
|
-
* threadManager,
|
|
46
|
-
* agentThreadId,
|
|
47
|
-
* (e) => e.type === 'TOOL_RESULT' && e.data.id === 'call_123',
|
|
48
|
-
* 'TOOL_RESULT with id=call_123'
|
|
49
|
-
* );
|
|
50
|
-
*/
|
|
51
|
-
export declare function waitForEventMatch(threadManager: ThreadManager, threadId: string, predicate: (event: LaceEvent) => boolean, description: string, timeoutMs?: number): Promise<LaceEvent>;
|
package/dist/tools/council.d.ts
DELETED
|
@@ -1,10 +0,0 @@
|
|
|
1
|
-
import { type PluginInput, type ToolDefinition } from '@opencode-ai/plugin';
|
|
2
|
-
import type { CouncilManager } from '../council/council-manager';
|
|
3
|
-
/**
|
|
4
|
-
* Creates the council_session tool for multi-LLM orchestration.
|
|
5
|
-
*
|
|
6
|
-
* This tool triggers a full council session: parallel councillors →
|
|
7
|
-
* formatted results returned to the council agent for synthesis.
|
|
8
|
-
* Available to the council agent.
|
|
9
|
-
*/
|
|
10
|
-
export declare function createCouncilTool(_ctx: PluginInput, councilManager: CouncilManager): Record<string, ToolDefinition>;
|
|
@@ -1,59 +0,0 @@
|
|
|
1
|
-
# Codemap Skill
|
|
2
|
-
|
|
3
|
-
Repository understanding and hierarchical codemap generation.
|
|
4
|
-
|
|
5
|
-
## Overview
|
|
6
|
-
|
|
7
|
-
Codemap helps orchestrators map and understand codebases by:
|
|
8
|
-
|
|
9
|
-
1. Selecting relevant code/config files using LLM judgment
|
|
10
|
-
2. Creating `.slim/codemap.json` for change tracking
|
|
11
|
-
3. Generating empty `codemap.md` templates for fixers to fill in
|
|
12
|
-
|
|
13
|
-
Legacy `.slim/cartography.json` state is migrated to `.slim/codemap.json` automatically.
|
|
14
|
-
|
|
15
|
-
## Commands
|
|
16
|
-
|
|
17
|
-
```bash
|
|
18
|
-
# Initialize mapping
|
|
19
|
-
node codemap.mjs init --root /repo --include "src/**/*.ts" --exclude "node_modules/**"
|
|
20
|
-
|
|
21
|
-
# Check what changed
|
|
22
|
-
node codemap.mjs changes --root /repo
|
|
23
|
-
|
|
24
|
-
# Update hashes
|
|
25
|
-
node codemap.mjs update --root /repo
|
|
26
|
-
```
|
|
27
|
-
|
|
28
|
-
## Outputs
|
|
29
|
-
|
|
30
|
-
### .slim/codemap.json
|
|
31
|
-
|
|
32
|
-
```json
|
|
33
|
-
{
|
|
34
|
-
"metadata": {
|
|
35
|
-
"version": "1.0.0",
|
|
36
|
-
"last_run": "2026-01-25T19:00:00Z",
|
|
37
|
-
"include_patterns": ["src/**/*.ts"],
|
|
38
|
-
"exclude_patterns": ["node_modules/**"]
|
|
39
|
-
},
|
|
40
|
-
"file_hashes": {
|
|
41
|
-
"src/index.ts": "abc123..."
|
|
42
|
-
},
|
|
43
|
-
"folder_hashes": {
|
|
44
|
-
"src": "def456..."
|
|
45
|
-
}
|
|
46
|
-
}
|
|
47
|
-
```
|
|
48
|
-
|
|
49
|
-
### codemap.md (per folder)
|
|
50
|
-
|
|
51
|
-
Empty templates created in each folder for fixers to fill with:
|
|
52
|
-
- Responsibility
|
|
53
|
-
- Design patterns
|
|
54
|
-
- Data/control flow
|
|
55
|
-
- Integration points
|
|
56
|
-
|
|
57
|
-
## Installation
|
|
58
|
-
|
|
59
|
-
Installed automatically via agent-forge installer when custom skills are enabled.
|
|
@@ -1,163 +0,0 @@
|
|
|
1
|
-
---
|
|
2
|
-
name: codemap
|
|
3
|
-
description: Generate comprehensive hierarchical codemaps for UNFAMILIAR repositories. Expensive operation - only use when explicitly asked for codebase documentation or initial repository mapping
|
|
4
|
-
---
|
|
5
|
-
|
|
6
|
-
# Codemap Skill
|
|
7
|
-
|
|
8
|
-
You help users understand and map repositories by creating hierarchical codemaps.
|
|
9
|
-
|
|
10
|
-
## When to Use
|
|
11
|
-
|
|
12
|
-
- User asks to understand/map a repository
|
|
13
|
-
- User wants codebase documentation
|
|
14
|
-
- Starting work on an unfamiliar codebase
|
|
15
|
-
|
|
16
|
-
## Workflow
|
|
17
|
-
|
|
18
|
-
### Step 1: Check for Existing State
|
|
19
|
-
|
|
20
|
-
**First, check if `.slim/codemap.json` exists in the repo root.**
|
|
21
|
-
|
|
22
|
-
If it does not exist, check for legacy state at `.slim/cartography.json`.
|
|
23
|
-
|
|
24
|
-
If legacy state exists: move `.slim/cartography.json` to `.slim/codemap.json`, then continue with change detection.
|
|
25
|
-
|
|
26
|
-
If `.slim/codemap.json` exists: Skip to Step 3 (Detect Changes) - no need to re-initialize.
|
|
27
|
-
|
|
28
|
-
If neither file exists: Continue to Step 2 (Initialize).
|
|
29
|
-
|
|
30
|
-
### Step 2: Initialize (Only if no state exists)
|
|
31
|
-
|
|
32
|
-
1. **Analyze the repository structure** - List files, understand directories
|
|
33
|
-
2. **Infer patterns** for **core code/config files ONLY** to include:
|
|
34
|
-
- **Include**: `src/**/*.ts`, `package.json`, etc.
|
|
35
|
-
- **Exclude (MANDATORY)**: Do NOT include tests, documentation, or translations.
|
|
36
|
-
- Tests: `**/*.test.ts`, `**/*.spec.ts`, `tests/**`, `__tests__/**`
|
|
37
|
-
- Docs: `docs/**`, `*.md` (except root `README.md` if needed), `LICENSE`
|
|
38
|
-
- Build/Deps: `node_modules/**`, `dist/**`, `build/**`, `*.min.js`
|
|
39
|
-
- Respect `.gitignore` automatically
|
|
40
|
-
3. **Run codemap.mjs init**:
|
|
41
|
-
|
|
42
|
-
```bash
|
|
43
|
-
node ~/.config/opencode/skills/codemap/scripts/codemap.mjs init \
|
|
44
|
-
--root ./ \
|
|
45
|
-
--include "src/**/*.ts" \
|
|
46
|
-
--exclude "**/*.test.ts" --exclude "dist/**" --exclude "node_modules/**"
|
|
47
|
-
```
|
|
48
|
-
|
|
49
|
-
This creates:
|
|
50
|
-
- `.slim/codemap.json` - File and folder hashes for change detection
|
|
51
|
-
- Empty `codemap.md` files in all relevant subdirectories
|
|
52
|
-
|
|
53
|
-
4. **Delegate codemap writing to Implementer agents** - Spawn one implementer per folder to read code and create or update its specific `codemap.md` file.
|
|
54
|
-
|
|
55
|
-
### Step 3: Detect Changes (If state already exists)
|
|
56
|
-
|
|
57
|
-
1. **Run codemap.mjs changes** to see what changed:
|
|
58
|
-
|
|
59
|
-
```bash
|
|
60
|
-
node ~/.config/opencode/skills/codemap/scripts/codemap.mjs changes \
|
|
61
|
-
--root ./
|
|
62
|
-
```
|
|
63
|
-
|
|
64
|
-
2. **Review the output** - It shows:
|
|
65
|
-
- Added files
|
|
66
|
-
- Removed files
|
|
67
|
-
- Modified files
|
|
68
|
-
- Affected folders
|
|
69
|
-
|
|
70
|
-
3. **Only update affected codemaps** - Spawn one implementer per affected folder to update its `codemap.md`.
|
|
71
|
-
4. **Run update** to save new state:
|
|
72
|
-
|
|
73
|
-
```bash
|
|
74
|
-
node ~/.config/opencode/skills/codemap/scripts/codemap.mjs update \
|
|
75
|
-
--root ./
|
|
76
|
-
```
|
|
77
|
-
|
|
78
|
-
### Step 4: Finalize Repository Atlas (Root Codemap)
|
|
79
|
-
|
|
80
|
-
Once all specific directories are mapped, the Orchestrator must create or update the root `codemap.md`. This file serves as the **Master Entry Point** for any agent or human entering the repository.
|
|
81
|
-
|
|
82
|
-
1. **Map Root Assets**: Document the root-level files (e.g., `package.json`, `index.ts`, `plugin.json`) and the project's overall purpose.
|
|
83
|
-
2. **Aggregate Sub-Maps**: Create a "Repository Directory Map" section. For every folder that has a `codemap.md`, extract its **Responsibility** summary and include it in a table or list in the root map.
|
|
84
|
-
3. **Cross-Reference**: Ensure that the root map contains the absolute or relative paths to the sub-maps so agents can jump directly to the relevant details.
|
|
85
|
-
|
|
86
|
-
### Step 5: Register Codemap in AGENTS.md
|
|
87
|
-
|
|
88
|
-
**OpenCode auto-loads `AGENTS.md` into agent context on every session.** To ensure agents automatically discover and use the codemap, update (or create) `AGENTS.md` at the repo root:
|
|
89
|
-
|
|
90
|
-
1. If `AGENTS.md` already exists and already contains a `## Repository Map` section, **skip this step** — the reference is already set up.
|
|
91
|
-
2. If `AGENTS.md` exists but has no `## Repository Map` section, **append** the section below.
|
|
92
|
-
3. If `AGENTS.md` doesn't exist, **create** it with the section below.
|
|
93
|
-
|
|
94
|
-
```markdown
|
|
95
|
-
## Repository Map
|
|
96
|
-
|
|
97
|
-
A full codemap is available at `codemap.md` in the project root.
|
|
98
|
-
|
|
99
|
-
Before working on any task, read `codemap.md` to understand:
|
|
100
|
-
- Project architecture and entry points
|
|
101
|
-
- Directory responsibilities and design patterns
|
|
102
|
-
- Data flow and integration points between modules
|
|
103
|
-
|
|
104
|
-
For deep work on a specific folder, also read that folder's `codemap.md`.
|
|
105
|
-
```
|
|
106
|
-
|
|
107
|
-
This is idempotent — repeated codemap runs will detect the existing section and skip. No duplication.
|
|
108
|
-
|
|
109
|
-
## Codemap Content
|
|
110
|
-
|
|
111
|
-
Implementers are responsible for writing `codemap.md` files during this workflow. Use precise technical terminology to document the implementation:
|
|
112
|
-
|
|
113
|
-
- **Responsibility** - Define the specific role of this directory using standard software engineering terms (e.g., "Service Layer", "Data Access Object", "Middleware").
|
|
114
|
-
- **Design Patterns** - Identify and name specific patterns used (e.g., "Observer", "Singleton", "Factory", "Strategy"). Detail the abstractions and interfaces.
|
|
115
|
-
- **Data & Control Flow** - Explicitly trace how data enters and leaves the module. Mention specific function call sequences and state transitions.
|
|
116
|
-
- **Integration Points** - List dependencies and consumer modules. Use technical names for hooks, events, or API endpoints.
|
|
117
|
-
|
|
118
|
-
Example codemap:
|
|
119
|
-
|
|
120
|
-
```markdown
|
|
121
|
-
# src/agents/
|
|
122
|
-
|
|
123
|
-
## Responsibility
|
|
124
|
-
Defines agent personalities and manages their configuration lifecycle.
|
|
125
|
-
|
|
126
|
-
## Design
|
|
127
|
-
Each agent is a prompt + permission set. Config system uses:
|
|
128
|
-
- Default prompts (orchestrator.ts, researcher.ts, etc.)
|
|
129
|
-
- User overrides from ~/.config/opencode/agent-forge.json
|
|
130
|
-
- Permission wildcards for skill/MCP access control
|
|
131
|
-
|
|
132
|
-
## Flow
|
|
133
|
-
1. Plugin loads → calls getAgentConfigs()
|
|
134
|
-
2. Reads user config preset
|
|
135
|
-
3. Merges defaults with overrides
|
|
136
|
-
4. Applies permission rules (wildcard expansion)
|
|
137
|
-
5. Returns agent configs to OpenCode
|
|
138
|
-
|
|
139
|
-
## Integration
|
|
140
|
-
- Consumed by: Main plugin (src/index.ts)
|
|
141
|
-
- Depends on: Config loader, skills registry
|
|
142
|
-
```
|
|
143
|
-
|
|
144
|
-
Example **Root Codemap (Atlas)**:
|
|
145
|
-
|
|
146
|
-
```markdown
|
|
147
|
-
# Repository Atlas: agent-forge
|
|
148
|
-
|
|
149
|
-
## Project Responsibility
|
|
150
|
-
A high-performance, low-latency agent orchestration plugin for OpenCode, focusing on specialized sub-agent delegation and multiplexer-assisted child sessions.
|
|
151
|
-
|
|
152
|
-
## System Entry Points
|
|
153
|
-
- `src/index.ts`: Plugin initialization and OpenCode integration.
|
|
154
|
-
- `package.json`: Dependency manifest and build scripts.
|
|
155
|
-
- `agent-forge.json`: User configuration schema.
|
|
156
|
-
|
|
157
|
-
## Directory Map (Aggregated)
|
|
158
|
-
| Directory | Responsibility Summary | Detailed Map |
|
|
159
|
-
|-----------|------------------------|--------------|
|
|
160
|
-
| `src/agents/` | Defines agent personalities (Orchestrator, Researcher) and manages model routing. | [View Map](src/agents/codemap.md) |
|
|
161
|
-
| `src/features/` | Core logic for tmux integration and session state. | [View Map](src/features/codemap.md) |
|
|
162
|
-
| `src/config/` | Implements the configuration loading pipeline and environment variable injection. | [View Map](src/config/codemap.md) |
|
|
163
|
-
```
|
|
@@ -1,36 +0,0 @@
|
|
|
1
|
-
# src/skills/codemap/
|
|
2
|
-
|
|
3
|
-
## Responsibility
|
|
4
|
-
|
|
5
|
-
- Provide a command-style skill package that standardizes repository mapping workflows for unfamiliar codebases.
|
|
6
|
-
- Define the task contract used by Orchestrator/implementer agents via `SKILL.md` and operational guidance via `README.md`.
|
|
7
|
-
- Generate and evolve change-aware codemap state artifacts (`.slim/codemap.json`) and scaffold placeholders (`codemap.md`).
|
|
8
|
-
|
|
9
|
-
## Design
|
|
10
|
-
|
|
11
|
-
- Contract layer: `SKILL.md` (machine prompt contract) + `README.md` (human-facing operation notes).
|
|
12
|
-
- Execution layer: `scripts/codemap.mjs` exports deterministic helper functions:
|
|
13
|
-
- `parseArgs(argv)`
|
|
14
|
-
- `cmdInit`, `cmdChanges`, `cmdUpdate`
|
|
15
|
-
- `selectFiles`, `computeFileHash`, `computeFolderHash`, `createEmptyCodemap`
|
|
16
|
-
- `loadState`, `saveState`, `migrateLegacyState`
|
|
17
|
-
- Persistence model: JSON state at `.slim/codemap.json` with `metadata`, `file_hashes`, and `folder_hashes`.
|
|
18
|
-
- Testing layer: `scripts/codemap.test.ts` validates pattern matching, hash determinism, and migration behavior.
|
|
19
|
-
- The script intentionally avoids network and mutates only filesystem-local state and codemap templates.
|
|
20
|
-
|
|
21
|
-
## Flow
|
|
22
|
-
|
|
23
|
-
- Entry point `main(argv)` parses command and arguments (`init|changes|update`, `--root`, `--include`, `--exclude`, `--exception`) and dispatches via strict branches.
|
|
24
|
-
- `cmdInit()` computes include/exclude candidate sets using `selectFiles()` and writes:
|
|
25
|
-
1) `.slim/codemap.json` via `saveState()`
|
|
26
|
-
2) one `codemap.md` per discovered folder via `createEmptyCodemap()`.
|
|
27
|
-
- `cmdChanges()` reloads state (`loadState()` + `migrateLegacyState()`), recomputes current hashes, emits added/removed/modified diffs and affected folder list, and exits non-zero if state is absent.
|
|
28
|
-
- `cmdUpdate()` recomputes full state from existing metadata and persists it, used after targeted fixers finish updates.
|
|
29
|
-
- `codemap` skill invocation path in SKILL workflow is explicit: Step 1 checks `.slim/codemap.json` or `.slim/cartography.json`, then Step 2/3 selects init or incremental path.
|
|
30
|
-
|
|
31
|
-
## Integration
|
|
32
|
-
|
|
33
|
-
- Installed under OpenCode through `src/cli/custom-skills.ts` as `name: 'codemap'`, `sourcePath: 'src/skills/codemap'`.
|
|
34
|
-
- `src/cli/install.ts` copies this directory into the user skill directory; OpenCode executes `scripts/codemap.mjs` from that context.
|
|
35
|
-
- `src/hooks/filter-available-skills/index.ts` applies agent-level skill gating via names from `getSkillPermissionsForAgent()`.
|
|
36
|
-
- `scripts/verify-release-artifact.ts` includes codemap skill metadata and runtime checks as required packaged files.
|