dimcode-darwin-arm64 0.2.17 → 0.2.18
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/bin/dimcode +0 -0
- package/bin/skills-assets/dim-workflow/SKILL.md +77 -0
- package/bin/skills-assets/dim-workflow/agents/openai.yaml +6 -0
- package/bin/skills-assets/plugin-creator/references/installing-and-updating.md +9 -2
- package/bin/skills-assets/plugin-creator/references/plugin-json-spec.md +37 -9
- package/package.json +1 -1
package/bin/dimcode
CHANGED
|
Binary file
|
|
@@ -0,0 +1,77 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: dim-workflow
|
|
3
|
+
description: Use when the user asks to create, modify, or save a reusable Dim workflow script. This skill explains the Dim workflow file contract and where saved workflow files must live. Do not use it for running, stopping, opening, revealing, or checking workflow runs.
|
|
4
|
+
---
|
|
5
|
+
|
|
6
|
+
# Dim Workflow
|
|
7
|
+
|
|
8
|
+
Use this skill only for authoring reusable Dim workflow scripts.
|
|
9
|
+
|
|
10
|
+
## When To Use
|
|
11
|
+
|
|
12
|
+
Use this skill when the user asks to:
|
|
13
|
+
|
|
14
|
+
- Create a reusable workflow.
|
|
15
|
+
- Modify an existing saved workflow.
|
|
16
|
+
- Save a conversation-generated workflow script for later reuse.
|
|
17
|
+
|
|
18
|
+
Do not use this skill when the user only wants to:
|
|
19
|
+
|
|
20
|
+
- Run `/workflow <name>`.
|
|
21
|
+
- Add runtime args to a workflow command.
|
|
22
|
+
- Stop, open, reveal, or inspect a workflow run.
|
|
23
|
+
- Check workflow progress.
|
|
24
|
+
|
|
25
|
+
## Saved Workflow Location
|
|
26
|
+
|
|
27
|
+
Saved workflows live under:
|
|
28
|
+
|
|
29
|
+
```text
|
|
30
|
+
<workflowDataDir>/workflows/saved/
|
|
31
|
+
```
|
|
32
|
+
|
|
33
|
+
Desktop defaults:
|
|
34
|
+
|
|
35
|
+
```text
|
|
36
|
+
DIMCODE_HOME=~/.dimcode/v2
|
|
37
|
+
workflowDataDir=<DIMCODE_HOME>/data
|
|
38
|
+
saved workflows=~/.dimcode/v2/data/workflows/saved/
|
|
39
|
+
```
|
|
40
|
+
|
|
41
|
+
If the configured `workflowDataDir` is known, use that absolute path.
|
|
42
|
+
|
|
43
|
+
If it is not known, say that the workflow data directory is missing and ask for it. Do not guess a project-local path and do not save reusable workflows under the current repo.
|
|
44
|
+
|
|
45
|
+
## File Contract
|
|
46
|
+
|
|
47
|
+
Create one file per workflow:
|
|
48
|
+
|
|
49
|
+
```text
|
|
50
|
+
<workflowDataDir>/workflows/saved/<workflowName>.mjs
|
|
51
|
+
```
|
|
52
|
+
|
|
53
|
+
The file must export `meta` and default-export an async workflow function:
|
|
54
|
+
|
|
55
|
+
```js
|
|
56
|
+
export const meta = {
|
|
57
|
+
name: "example-workflow",
|
|
58
|
+
description: "Short user-facing description",
|
|
59
|
+
}
|
|
60
|
+
|
|
61
|
+
export default async function workflow(api) {
|
|
62
|
+
api.phase("Start")
|
|
63
|
+
api.log("Running workflow")
|
|
64
|
+
return { ok: true }
|
|
65
|
+
}
|
|
66
|
+
```
|
|
67
|
+
|
|
68
|
+
Rules:
|
|
69
|
+
|
|
70
|
+
- `meta.name` must be a non-empty unique workflow name.
|
|
71
|
+
- `meta.description` must be non-empty.
|
|
72
|
+
- Use `.mjs` when the workflow imports local helpers.
|
|
73
|
+
- `.js` and `.ts` are only for self-contained scripts that the Dim runtime can compile.
|
|
74
|
+
- Use `api.tool()` for current-session tools and `api.agent()` for child agents.
|
|
75
|
+
- Keep workflow files trusted and explicit; do not hide required inputs in hard-coded local paths.
|
|
76
|
+
|
|
77
|
+
After writing or modifying a saved workflow file, tell the user to refresh the Desktop workflow list so the runtime reloads `workflows/saved/`.
|
|
@@ -0,0 +1,6 @@
|
|
|
1
|
+
interface:
|
|
2
|
+
display_name: "Dim Workflow"
|
|
3
|
+
short_description: "Create or edit reusable Dim workflows"
|
|
4
|
+
default_prompt: "Use $dim-workflow when creating, modifying, or saving reusable Dim workflow scripts. Do not use it for normal workflow execution."
|
|
5
|
+
policy:
|
|
6
|
+
allow_implicit_invocation: true
|
|
@@ -29,8 +29,10 @@ removes the plugin.
|
|
|
29
29
|
- **Hooks** — read from the file named by the manifest `hooks` field and registered on session
|
|
30
30
|
start. Command paths use `${CLAUDE_PLUGIN_ROOT}`, which Dim replaces with the plugin's
|
|
31
31
|
absolute root.
|
|
32
|
-
- **MCP servers** — read from `.mcp.json`
|
|
33
|
-
the MCP runtime.
|
|
32
|
+
- **MCP servers** — read from the `.mcp.json` file named by the manifest `mcpServers` field and
|
|
33
|
+
merged into the MCP runtime. An inline `mcpServers` object in `plugin.json` itself is not
|
|
34
|
+
supported — Dim silently ignores it (no error), so the component never loads. Server ids are
|
|
35
|
+
namespaced `plugin:<plugin-name>/<serverId>`.
|
|
34
36
|
|
|
35
37
|
## Toggling components
|
|
36
38
|
|
|
@@ -57,3 +59,8 @@ python3 scripts/create_basic_plugin.py my-plugin --path ./plugins --with-skills
|
|
|
57
59
|
|
|
58
60
|
Updating a git-installed plugin is done from the same Add-plugin flow (reinstall from the
|
|
59
61
|
source) or by editing the on-disk copy under `~/.agents/plugins` for local tweaks.
|
|
62
|
+
|
|
63
|
+
The desktop app also has a separate Plugin Store tab that installs from a hosted marketplace
|
|
64
|
+
(a zip archive, not a git clone) and marks the install with its own `.dimcode-market.json`
|
|
65
|
+
provenance file instead of `dim-install.json`. That path is unrelated to plugin *creation* —
|
|
66
|
+
it only matters if you're pointing a user at how to distribute a finished plugin.
|
|
@@ -1,8 +1,9 @@
|
|
|
1
1
|
# Plugin manifest spec (`.claude-plugin/plugin.json`)
|
|
2
2
|
|
|
3
|
-
Dim recognizes a plugin by the presence of `.claude-plugin/plugin.json` at the plugin root
|
|
4
|
-
|
|
5
|
-
|
|
3
|
+
Dim recognizes a plugin by the presence of `.claude-plugin/plugin.json` at the plugin root (it
|
|
4
|
+
also accepts the Codex-format `.codex-plugin/plugin.json` at the same root — this skill always
|
|
5
|
+
scaffolds the Claude format, which both Dim and Claude Code read). It parses only the fields
|
|
6
|
+
below; any other field is ignored. Keep the manifest minimal and valid.
|
|
6
7
|
|
|
7
8
|
```json
|
|
8
9
|
{
|
|
@@ -90,11 +91,25 @@ runtime:
|
|
|
90
91
|
}
|
|
91
92
|
```
|
|
92
93
|
|
|
94
|
+
Only these event names are recognized: `SessionStart`, `SubagentStart`, `PreToolUse`,
|
|
95
|
+
`PermissionRequest`, `PostToolUse`, `PreCompact`, `PostCompact`, `UserPromptSubmit`,
|
|
96
|
+
`SubagentStop`, `Stop`. An unrecognized event name is not a partial failure — Dim drops every
|
|
97
|
+
hook in that `hooks.json` file (logs a warning, registers nothing). Do not invent event names;
|
|
98
|
+
when unsure which event fits, ask rather than guess.
|
|
99
|
+
|
|
100
|
+
`type` must be the literal string `"command"` and `command` must be a non-empty string; that is
|
|
101
|
+
the only spec shape Dim parses. Plugin hooks run with the same full host environment as the
|
|
102
|
+
user's own hooks (not a restricted subset), so a plugin hook can read provider keys/tokens from
|
|
103
|
+
the process env — call this out to the user if the plugin's hook touches secrets.
|
|
104
|
+
|
|
93
105
|
### MCP servers
|
|
94
106
|
|
|
95
|
-
`mcpServers` points to an `.mcp.json` file
|
|
96
|
-
`plugin
|
|
97
|
-
|
|
107
|
+
`mcpServers` points to an `.mcp.json` file — a relative path string, never an inline object (an
|
|
108
|
+
inline `mcpServers` object in `plugin.json` is silently ignored, not an error). Server ids are
|
|
109
|
+
namespaced as `plugin:<plugin-name>/<serverId>`. Command paths support the same
|
|
110
|
+
`${CLAUDE_PLUGIN_ROOT}` substitution (it resolves through the same `${VAR}` template mechanism as
|
|
111
|
+
any other env var, so other `${VAR}` references also resolve against the host environment). The
|
|
112
|
+
referenced `.mcp.json` has this shape:
|
|
98
113
|
|
|
99
114
|
```json
|
|
100
115
|
{
|
|
@@ -108,13 +123,26 @@ substitution. The referenced `.mcp.json` has this shape:
|
|
|
108
123
|
}
|
|
109
124
|
```
|
|
110
125
|
|
|
126
|
+
`type: "http"` is also supported (`{"type": "http", "url": "...", "headers": {...}}`, optionally
|
|
127
|
+
`"auth": {"type": "bearer", "token": "..."}`); `sse` / `streamable-http` are not supported.
|
|
128
|
+
|
|
111
129
|
## Validation notes
|
|
112
130
|
|
|
113
|
-
- `name` must be a non-empty string; the folder name must match it.
|
|
114
|
-
|
|
131
|
+
- `name` must be a non-empty string; the folder name must match it. Dim does not verify this
|
|
132
|
+
invariant itself — for a locally-placed plugin, mismatched folder/`name` silently uses the
|
|
133
|
+
folder name for skills/hooks/mcp resolution while the manifest `name` becomes only a display
|
|
134
|
+
label. Keep the two in lockstep.
|
|
135
|
+
- `version`, when present, must be strict semver by this skill's convention. Dim's runtime does
|
|
136
|
+
not itself validate `version` — it accepts any non-empty string — so this rule is a
|
|
137
|
+
authoring-quality convention, not something a load failure would confirm.
|
|
115
138
|
- `interface.logo` and any declared component path must point to real files/directories inside
|
|
116
139
|
the plugin.
|
|
117
|
-
-
|
|
140
|
+
- The manifest `skills` field only toggles a UI "has skills" indicator; skill discovery always
|
|
141
|
+
scans `<plugin-root>/skills` regardless of this field's value or presence. Keep skills at
|
|
142
|
+
`./skills/` — pointing `skills` elsewhere does not relocate discovery.
|
|
143
|
+
- Sub-skill `SKILL.md` files must have non-empty `name` and `description` frontmatter, and a
|
|
144
|
+
non-empty body after the closing `---`. A frontmatter-only file with no body is silently
|
|
145
|
+
dropped (not an error) — the skill just never appears.
|
|
118
146
|
- The manifest must not contain `[TODO: ...]` placeholders.
|
|
119
147
|
|
|
120
148
|
Run `scripts/validate_plugin.py <plugin-path>` before handing back a generated plugin.
|