You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: .claude/skills/dotular-module/SKILL.md
+35-40Lines changed: 35 additions & 40 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -7,6 +7,12 @@ description: Use when user asks to create a dotular module, add a tool to dotula
7
7
8
8
Create a complete dotular registry module for a tool by researching its config files, scanning the local machine, and writing the module YAML.
9
9
10
+
## Critical Rule
11
+
12
+
1.**NEVER use `dotular add`**. That command writes to the user's personal `dotular.yaml` and only sets the destination for the current platform. This skill creates **registry modules** — standalone YAML files in `modules/` with cross-platform destinations. Always create files manually as described in Step 4.
13
+
14
+
2.**NEVER copy personal config files into registry modules**. Registry modules are shared/generic — they define package items and file destination mappings only. The `file:` items tell dotular *where* a config file belongs, but the actual config content comes from the user's own store, not the registry module. Do NOT create a `modules/<tool>/` subdirectory or copy files like `~/.config/tool/config.toml` into it.
15
+
10
16
## Process
11
17
12
18
```dot
@@ -56,7 +62,7 @@ ls -la ~/.config/toolname/ 2>/dev/null
56
62
ls -la ~/Library/Application\ Support/ToolName/ 2>/dev/null
57
63
```
58
64
59
-
Record which files/directories exist. This validates your research and identifies files available to copy into the module store.
65
+
Record which files/directories exist. This validates your research and confirms the correct destination paths for the `file:` items in the module YAML. Do NOT copy these files — the scan is only to verify paths.
60
66
61
67
## Step 3: Present Summary
62
68
@@ -97,47 +103,34 @@ Include a clear recommendation. Wait for user confirmation before proceeding.
97
103
98
104
## Step 4: Execute
99
105
100
-
After user confirms:
101
-
102
-
1.**Create module directory** (if config files exist to store):
103
-
```bash
104
-
mkdir -p modules/<tool>/
105
-
```
106
-
107
-
2.**Copy existing config files** into the module store:
File placement rule: files go at `modules/<tool>/<filename>` where `<filename>` matches the `file:` value in the YAML. The runner prepends the module name as `sourcePrefix`.
112
-
113
-
3.**Write module YAML** at `modules/<tool>.yaml`:
114
-
115
-
```yaml
116
-
name: <tool-name>
117
-
version: "1.0.0"
118
-
items:
119
-
- package: <name>
120
-
via: brew
121
-
skip_if: command -v <name>
122
-
verify: <name> --version
123
-
124
-
- package: <name>
125
-
via: apt
126
-
skip_if: command -v <name>
127
-
128
-
- package: <name-or-id>
129
-
via: winget
130
-
131
-
- file: <filename>
132
-
destination:
133
-
macos: <path>
134
-
linux: <path>
135
-
windows: <path>
136
-
```
106
+
After user confirms, **write the module YAML** at `modules/<tool>.yaml`:
107
+
108
+
```yaml
109
+
name: <tool-name>
110
+
version: "1.0.0"
111
+
items:
112
+
- package: <name>
113
+
via: brew
114
+
skip_if: command -v <name>
115
+
verify: <name> --version
116
+
117
+
- package: <name>
118
+
via: apt
119
+
skip_if: command -v <name>
120
+
121
+
- package: <name-or-id>
122
+
via: winget
123
+
124
+
- file: <filename>
125
+
destination:
126
+
macos: <path>
127
+
linux: <path>
128
+
windows: <path>
129
+
```
137
130
138
-
**Multiple package items**: Create a separate `package` item for each platform's package manager (see `dotular.yaml` VS Code module for this pattern). Use `skip_if: command -v <tool>` so only the available manager runs. The runner executes all items — an unavailable package manager simply fails, but `skip_if` prevents redundant installs after the first succeeds.
131
+
**Multiple package items**: Create a separate `package` item for each platform's package manager (see `dotular.yaml` VS Code module for this pattern). Use `skip_if: command -v <tool>` so only the available manager runs. The runner executes all items — an unavailable package manager simply fails, but `skip_if` prevents redundant installs after the first succeeds.
139
132
140
-
4. If **no config files** to store (package-only module), skip creating the subdirectory.
133
+
**File items**: The `file:` and `directory:` items define destination mappings only — where config files belong on each platform. Do NOT create a `modules/<tool>/` subdirectory or copy personal config files into it. The user's own dotular store provides the actual file content at apply time.
141
134
142
135
## Step 5: Verify
143
136
@@ -172,6 +165,8 @@ Display the complete contents of the generated `modules/<tool>.yaml` for user re
172
165
| Missing `skip_if` on package items | Add `skip_if: command -v <tool>` for idempotency |
173
166
| Using trailing `/` in destination | Match existing convention: `~/.config/tool`not `~/.config/tool/` |
174
167
| Forgetting Windows paths | Always research all 3 platforms for PlatformMap |
168
+
| Using `dotular add` command | NEVER — it writes to personal `dotular.yaml` with single-platform destinations. Manually create `modules/<tool>.yaml` instead |
169
+
| Copying personal config files into module | NEVER — registry modules define destination mappings only, not file content. Do not create `modules/<tool>/` subdirectories or `cp` user configs into them |
175
170
| Editing user's `dotular.yaml` | This skill creates REGISTRY modules only — never touch personal config |
176
171
| Updating `modules/index.yaml` | Out of scope — tell user to add the entry manually |
0 commit comments