@contextium/cli 1.0.21 → 1.0.22
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/dist/commands/projects.js +1 -1
- package/dist/commands/projects.js.map +1 -1
- package/dist/lib/claude-permissions.d.ts.map +1 -1
- package/dist/lib/claude-permissions.js +2 -4
- package/dist/lib/claude-permissions.js.map +1 -1
- package/package.json +1 -1
- package/skills/ium/contextium.md +148 -83
- package/skills/ium/help.md +6 -0
- package/skills/ium/new-project.legacy.md +274 -27
- package/skills/ium/resume-project.md +127 -0
- package/skills/ium/scan-existing.md +422 -0
- package/skills/ium/search.md +11 -0
- package/skills/ium/workflow.md +29 -11
- package/skills/ium/workspace.md +11 -10
- package/dist/commands/load-skill.d.ts +0 -3
- package/dist/commands/load-skill.d.ts.map +0 -1
- package/dist/commands/load-skill.js +0 -35
- package/dist/commands/load-skill.js.map +0 -1
|
@@ -0,0 +1,422 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: ium:scan-existing
|
|
3
|
+
description: Scan an existing codebase and write analysis documents to a Contextium context library — tech stack, architecture, structure, conventions, and concerns. Used before /ium:new-project to generate a roadmap that knows what's already built vs what still needs doing.
|
|
4
|
+
allowed-tools:
|
|
5
|
+
- Bash
|
|
6
|
+
- Glob
|
|
7
|
+
- Grep
|
|
8
|
+
- Read
|
|
9
|
+
- mcp__contextium__list_workspaces
|
|
10
|
+
- mcp__contextium__list_context_libraries
|
|
11
|
+
- mcp__contextium__list_workflows
|
|
12
|
+
- mcp__contextium__load_workflow
|
|
13
|
+
- mcp__contextium__create_context_library
|
|
14
|
+
- mcp__contextium__create_file
|
|
15
|
+
- mcp__contextium__update_file
|
|
16
|
+
- mcp__contextium__list_files
|
|
17
|
+
- mcp__contextium__get_file
|
|
18
|
+
- AskUserQuestion
|
|
19
|
+
---
|
|
20
|
+
|
|
21
|
+
<objective>
|
|
22
|
+
Analyse an existing codebase across five domains and write the findings as structured documents to a Contextium context library. The output gives any agent full context about what exists, how it's built, and what's already working — without re-analysing the codebase every session. When followed by /ium:new-project, the roadmap will know what's already done and only plan phases for what's missing.
|
|
23
|
+
</objective>
|
|
24
|
+
|
|
25
|
+
<mode-detection>
|
|
26
|
+
Run once at the start, silently:
|
|
27
|
+
|
|
28
|
+
```bash
|
|
29
|
+
command -v contextium &>/dev/null && echo "cli" || echo "no-cli"
|
|
30
|
+
```
|
|
31
|
+
|
|
32
|
+
- If `cli`: use CLI commands throughout.
|
|
33
|
+
- If `no-cli`: use MCP tools throughout.
|
|
34
|
+
- If neither: tell the user "Contextium doesn't appear to be installed." and stop.
|
|
35
|
+
</mode-detection>
|
|
36
|
+
|
|
37
|
+
<process>
|
|
38
|
+
|
|
39
|
+
<step name="check_auth">
|
|
40
|
+
**CLI only.** Run silently:
|
|
41
|
+
```bash
|
|
42
|
+
contextium whoami 2>/dev/null | grep -E "Token:|Name:" || echo "unauthenticated"
|
|
43
|
+
```
|
|
44
|
+
If unauthenticated or token expired, tell the user to run `contextium login` and stop.
|
|
45
|
+
|
|
46
|
+
MCP users are already authenticated — skip.
|
|
47
|
+
</step>
|
|
48
|
+
|
|
49
|
+
<step name="select_library">
|
|
50
|
+
Determine where to write the codebase documents.
|
|
51
|
+
|
|
52
|
+
If a workflow is already loaded in this session, check whether any of its libraries have an obvious "codebase" or "technical" purpose. If yes, suggest it. If not, ask which library to use.
|
|
53
|
+
|
|
54
|
+
If no workflow is loaded:
|
|
55
|
+
|
|
56
|
+
**CLI:** `contextium library list --workspace <slug> 2>/dev/null`
|
|
57
|
+
**MCP:** call mcp__contextium__list_context_libraries
|
|
58
|
+
|
|
59
|
+
Ask: "Which library should I write the codebase analysis to? Or I can create a new one — for example, 'Codebase Analysis'."
|
|
60
|
+
|
|
61
|
+
Use AskUserQuestion:
|
|
62
|
+
- Present existing library names
|
|
63
|
+
- "Create a new library for this"
|
|
64
|
+
|
|
65
|
+
If creating new: use the name the user provides, or default to "[Project Name] Codebase". Create it:
|
|
66
|
+
|
|
67
|
+
**CLI:** `contextium library create "<name>" --workspace <slug>`
|
|
68
|
+
**MCP:** call mcp__contextium__create_context_library
|
|
69
|
+
|
|
70
|
+
Store the target library ID as `target_library_id`.
|
|
71
|
+
</step>
|
|
72
|
+
|
|
73
|
+
<step name="check_existing">
|
|
74
|
+
Check whether any of the five analysis documents already exist in the target library by listing its files and looking for: `stack.md`, `architecture.md`, `structure.md`, `conventions.md`, `concerns.md`.
|
|
75
|
+
|
|
76
|
+
If any exist, ask:
|
|
77
|
+
|
|
78
|
+
"I found existing analysis documents in this library. What would you like to do?"
|
|
79
|
+
|
|
80
|
+
Use AskUserQuestion:
|
|
81
|
+
- "Refresh all documents (overwrite)"
|
|
82
|
+
- "Update specific documents only"
|
|
83
|
+
- "Cancel"
|
|
84
|
+
|
|
85
|
+
If "Update specific": ask which ones to update. Only run analysis passes for those.
|
|
86
|
+
If "Refresh all" or no existing docs: run all five passes.
|
|
87
|
+
</step>
|
|
88
|
+
|
|
89
|
+
<step name="orient">
|
|
90
|
+
Before analysing, silently orient yourself to the project. Run:
|
|
91
|
+
|
|
92
|
+
```bash
|
|
93
|
+
ls -la 2>/dev/null | head -40
|
|
94
|
+
```
|
|
95
|
+
|
|
96
|
+
Then look for the project's primary language and framework indicators:
|
|
97
|
+
|
|
98
|
+
```bash
|
|
99
|
+
ls package.json requirements.txt Cargo.toml go.mod pyproject.toml composer.json 2>/dev/null
|
|
100
|
+
```
|
|
101
|
+
|
|
102
|
+
```bash
|
|
103
|
+
ls -d src/ app/ lib/ pkg/ internal/ api/ 2>/dev/null
|
|
104
|
+
```
|
|
105
|
+
|
|
106
|
+
Do not show this output to the user. Use it to focus the analysis passes that follow.
|
|
107
|
+
|
|
108
|
+
Tell the user:
|
|
109
|
+
```
|
|
110
|
+
Scanning codebase — this will take a moment.
|
|
111
|
+
|
|
112
|
+
○ Tech stack & integrations
|
|
113
|
+
○ Architecture & structure
|
|
114
|
+
○ Conventions & testing
|
|
115
|
+
○ Concerns & tech debt
|
|
116
|
+
```
|
|
117
|
+
|
|
118
|
+
Update each `○` to `✓` as each pass completes.
|
|
119
|
+
</step>
|
|
120
|
+
|
|
121
|
+
<step name="pass_1_tech">
|
|
122
|
+
**Tech Stack & Integrations**
|
|
123
|
+
|
|
124
|
+
Analyse and write `stack.md`:
|
|
125
|
+
|
|
126
|
+
Read dependency manifests:
|
|
127
|
+
```bash
|
|
128
|
+
cat package.json 2>/dev/null
|
|
129
|
+
cat requirements.txt pyproject.toml 2>/dev/null
|
|
130
|
+
cat Cargo.toml go.mod 2>/dev/null
|
|
131
|
+
cat composer.json 2>/dev/null
|
|
132
|
+
```
|
|
133
|
+
|
|
134
|
+
Read config files:
|
|
135
|
+
```bash
|
|
136
|
+
cat tsconfig.json 2>/dev/null
|
|
137
|
+
ls *.config.* 2>/dev/null
|
|
138
|
+
cat .nvmrc .node-version .python-version 2>/dev/null
|
|
139
|
+
```
|
|
140
|
+
|
|
141
|
+
Check for external service patterns:
|
|
142
|
+
```bash
|
|
143
|
+
grep -rn "process\.env\." src/ app/ lib/ 2>/dev/null | grep -v "node_modules" | head -40
|
|
144
|
+
cat .env.example .env.sample 2>/dev/null
|
|
145
|
+
```
|
|
146
|
+
|
|
147
|
+
Produce `stack.md` in this structure:
|
|
148
|
+
|
|
149
|
+
```markdown
|
|
150
|
+
# Tech Stack
|
|
151
|
+
**Analysis Date:** [today]
|
|
152
|
+
|
|
153
|
+
## Runtime & Language
|
|
154
|
+
[language, version, runtime]
|
|
155
|
+
|
|
156
|
+
## Frameworks & Libraries
|
|
157
|
+
[list key dependencies with versions and purpose]
|
|
158
|
+
|
|
159
|
+
## Build & Tooling
|
|
160
|
+
[build system, bundler, linter, formatter, type checker]
|
|
161
|
+
|
|
162
|
+
## External Services & Integrations
|
|
163
|
+
[APIs, databases, auth providers, storage, email — with env var names]
|
|
164
|
+
|
|
165
|
+
## Platform & Deployment
|
|
166
|
+
[inferred from config files — Docker, Vercel, Railway, etc.]
|
|
167
|
+
```
|
|
168
|
+
|
|
169
|
+
Every item must reference the actual config file or env var it was found in. No vague summaries.
|
|
170
|
+
|
|
171
|
+
Write to Contextium:
|
|
172
|
+
**CLI:** `cat << 'EOF' | contextium new <library-name> -t "Tech Stack" -p "stack.md" --stdin -w <workspace>`
|
|
173
|
+
**MCP:** call mcp__contextium__create_file (or update_file if refreshing)
|
|
174
|
+
|
|
175
|
+
Update the progress indicator to `✓ Tech stack & integrations`.
|
|
176
|
+
</step>
|
|
177
|
+
|
|
178
|
+
<step name="pass_2_architecture">
|
|
179
|
+
**Architecture & Structure**
|
|
180
|
+
|
|
181
|
+
Analyse and write `architecture.md` and `structure.md`:
|
|
182
|
+
|
|
183
|
+
Get the full directory tree:
|
|
184
|
+
```bash
|
|
185
|
+
find . -type f -not -path "*/node_modules/*" -not -path "*/.git/*" -not -path "*/dist/*" -not -path "*/.next/*" -not -path "*/build/*" | head -120
|
|
186
|
+
```
|
|
187
|
+
|
|
188
|
+
Find entry points:
|
|
189
|
+
```bash
|
|
190
|
+
ls src/index.* src/main.* src/app.* src/server.* app/page.* app/layout.* 2>/dev/null
|
|
191
|
+
```
|
|
192
|
+
|
|
193
|
+
Sample key files to understand patterns:
|
|
194
|
+
```bash
|
|
195
|
+
head -60 $(ls src/index.* src/main.* src/app.* 2>/dev/null | head -3) 2>/dev/null
|
|
196
|
+
```
|
|
197
|
+
|
|
198
|
+
Produce `architecture.md`:
|
|
199
|
+
|
|
200
|
+
```markdown
|
|
201
|
+
# Architecture
|
|
202
|
+
**Analysis Date:** [today]
|
|
203
|
+
|
|
204
|
+
## Pattern
|
|
205
|
+
[MVC / layered / feature-based / monolith / microservices / etc — with evidence]
|
|
206
|
+
|
|
207
|
+
## Layers
|
|
208
|
+
[list each layer: what it contains, what it depends on, example files]
|
|
209
|
+
|
|
210
|
+
## Data Flow
|
|
211
|
+
[how a typical request flows through the system — entry point → handler → service → data layer]
|
|
212
|
+
|
|
213
|
+
## Key Abstractions
|
|
214
|
+
[important interfaces, base classes, shared utilities — with file paths]
|
|
215
|
+
|
|
216
|
+
## Error Handling
|
|
217
|
+
[how errors propagate — try/catch, result types, middleware, etc.]
|
|
218
|
+
```
|
|
219
|
+
|
|
220
|
+
Produce `structure.md`:
|
|
221
|
+
|
|
222
|
+
```markdown
|
|
223
|
+
# Structure
|
|
224
|
+
**Analysis Date:** [today]
|
|
225
|
+
|
|
226
|
+
## Directory Map
|
|
227
|
+
[annotated directory tree showing purpose of each folder]
|
|
228
|
+
|
|
229
|
+
## Key File Locations
|
|
230
|
+
| Purpose | Path |
|
|
231
|
+
|---------|------|
|
|
232
|
+
| Entry point | `src/index.ts` |
|
|
233
|
+
| Route definitions | `src/routes/` |
|
|
234
|
+
| [etc] | [etc] |
|
|
235
|
+
|
|
236
|
+
## Where to Add New Code
|
|
237
|
+
[specific guidance: "New API routes go in src/routes/, follow the pattern in src/routes/users.ts"]
|
|
238
|
+
|
|
239
|
+
## Naming Conventions
|
|
240
|
+
[file naming, folder naming, component naming patterns with examples]
|
|
241
|
+
```
|
|
242
|
+
|
|
243
|
+
Write both files to Contextium. Update progress to `✓ Architecture & structure`.
|
|
244
|
+
</step>
|
|
245
|
+
|
|
246
|
+
<step name="pass_3_conventions">
|
|
247
|
+
**Conventions & Testing**
|
|
248
|
+
|
|
249
|
+
Analyse and write `conventions.md` and `testing.md`:
|
|
250
|
+
|
|
251
|
+
Read linting/formatting config:
|
|
252
|
+
```bash
|
|
253
|
+
cat .eslintrc* eslint.config.* .prettierrc* biome.json 2>/dev/null
|
|
254
|
+
```
|
|
255
|
+
|
|
256
|
+
Sample source files to extract conventions:
|
|
257
|
+
```bash
|
|
258
|
+
head -80 $(find src/ app/ lib/ -name "*.ts" -o -name "*.tsx" -o -name "*.js" 2>/dev/null | grep -v test | grep -v spec | head -5) 2>/dev/null
|
|
259
|
+
```
|
|
260
|
+
|
|
261
|
+
Check testing setup:
|
|
262
|
+
```bash
|
|
263
|
+
cat jest.config.* vitest.config.* pytest.ini setup.cfg 2>/dev/null
|
|
264
|
+
find . -name "*.test.*" -o -name "*.spec.*" 2>/dev/null | grep -v node_modules | head -20
|
|
265
|
+
```
|
|
266
|
+
|
|
267
|
+
Produce `conventions.md`:
|
|
268
|
+
|
|
269
|
+
```markdown
|
|
270
|
+
# Conventions
|
|
271
|
+
**Analysis Date:** [today]
|
|
272
|
+
|
|
273
|
+
## Naming
|
|
274
|
+
[variables, functions, classes, files, folders — with real examples from the codebase]
|
|
275
|
+
|
|
276
|
+
## Code Style
|
|
277
|
+
[formatting rules, import order, export patterns — reference linting config]
|
|
278
|
+
|
|
279
|
+
## Function Design
|
|
280
|
+
[pure vs stateful, async patterns, error handling style]
|
|
281
|
+
|
|
282
|
+
## State Management
|
|
283
|
+
[how state is managed — context, stores, props — with example file paths]
|
|
284
|
+
|
|
285
|
+
## Comments & Documentation
|
|
286
|
+
[what gets documented and how]
|
|
287
|
+
```
|
|
288
|
+
|
|
289
|
+
Produce `testing.md`:
|
|
290
|
+
|
|
291
|
+
```markdown
|
|
292
|
+
# Testing
|
|
293
|
+
**Analysis Date:** [today]
|
|
294
|
+
|
|
295
|
+
## Framework & Setup
|
|
296
|
+
[test runner, assertion library, config file location]
|
|
297
|
+
|
|
298
|
+
## File Organisation
|
|
299
|
+
[where tests live relative to source — colocated, __tests__, etc.]
|
|
300
|
+
|
|
301
|
+
## Test Structure
|
|
302
|
+
[describe/it patterns, setup/teardown conventions — with example from an existing test]
|
|
303
|
+
|
|
304
|
+
## Mocking Approach
|
|
305
|
+
[how dependencies are mocked — with example]
|
|
306
|
+
|
|
307
|
+
## Coverage
|
|
308
|
+
[what's covered, what's not, any coverage thresholds configured]
|
|
309
|
+
|
|
310
|
+
## How to Run Tests
|
|
311
|
+
[exact commands]
|
|
312
|
+
```
|
|
313
|
+
|
|
314
|
+
Write both files to Contextium. Update progress to `✓ Conventions & testing`.
|
|
315
|
+
</step>
|
|
316
|
+
|
|
317
|
+
<step name="pass_4_concerns">
|
|
318
|
+
**Concerns & Tech Debt**
|
|
319
|
+
|
|
320
|
+
Analyse and write `concerns.md`:
|
|
321
|
+
|
|
322
|
+
Find tech debt markers:
|
|
323
|
+
```bash
|
|
324
|
+
grep -rn "TODO\|FIXME\|HACK\|XXX\|TEMP\|@deprecated" --include="*.ts" --include="*.tsx" --include="*.js" --include="*.py" . 2>/dev/null | grep -v node_modules | head -60
|
|
325
|
+
```
|
|
326
|
+
|
|
327
|
+
Find large/complex files:
|
|
328
|
+
```bash
|
|
329
|
+
find . -name "*.ts" -o -name "*.tsx" -o -name "*.js" -o -name "*.py" 2>/dev/null | grep -v node_modules | grep -v dist | xargs wc -l 2>/dev/null | sort -rn | head -20
|
|
330
|
+
```
|
|
331
|
+
|
|
332
|
+
Find empty stubs or incomplete implementations:
|
|
333
|
+
```bash
|
|
334
|
+
grep -rn "throw new Error.*not implemented\|TODO.*implement\|return null\|pass$" --include="*.ts" --include="*.tsx" --include="*.js" --include="*.py" . 2>/dev/null | grep -v node_modules | head -30
|
|
335
|
+
```
|
|
336
|
+
|
|
337
|
+
Check for hardcoded values that should be config:
|
|
338
|
+
```bash
|
|
339
|
+
grep -rn "localhost\|127\.0\.0\.1\|hardcoded\|magic number" --include="*.ts" --include="*.js" . 2>/dev/null | grep -v node_modules | grep -v test | head -20
|
|
340
|
+
```
|
|
341
|
+
|
|
342
|
+
Produce `concerns.md`:
|
|
343
|
+
|
|
344
|
+
```markdown
|
|
345
|
+
# Concerns & Tech Debt
|
|
346
|
+
**Analysis Date:** [today]
|
|
347
|
+
|
|
348
|
+
## Tech Debt
|
|
349
|
+
| Issue | Location | Suggested Fix |
|
|
350
|
+
|-------|----------|---------------|
|
|
351
|
+
| [specific issue] | `src/path/file.ts:42` | [concrete fix approach] |
|
|
352
|
+
|
|
353
|
+
## Known Gaps / Incomplete Features
|
|
354
|
+
[stubs, TODOs marked as incomplete, features with placeholder implementations — file paths required]
|
|
355
|
+
|
|
356
|
+
## Fragile Areas
|
|
357
|
+
[files or patterns that are high-risk to modify — explain why and how to modify safely]
|
|
358
|
+
|
|
359
|
+
## Security Observations
|
|
360
|
+
[anything that looks like a security concern — never log secrets, only note patterns]
|
|
361
|
+
|
|
362
|
+
## Test Coverage Gaps
|
|
363
|
+
[areas with no tests that clearly need them]
|
|
364
|
+
|
|
365
|
+
## Dependencies to Watch
|
|
366
|
+
[outdated, deprecated, or high-risk dependencies found in package manifest]
|
|
367
|
+
```
|
|
368
|
+
|
|
369
|
+
Write to Contextium. Update progress to `✓ Concerns & tech debt`.
|
|
370
|
+
</step>
|
|
371
|
+
|
|
372
|
+
<step name="update_project_state">
|
|
373
|
+
If a `project-state.md` file exists in any library in the loaded workflow, read it and check the `## Phases` section.
|
|
374
|
+
|
|
375
|
+
For each phase whose described functionality clearly already exists in the codebase (based on what was found in the analysis), add a note under that phase:
|
|
376
|
+
|
|
377
|
+
```
|
|
378
|
+
> **Already built** — confirmed by codebase scan [date]
|
|
379
|
+
```
|
|
380
|
+
|
|
381
|
+
And update its status to "Complete" if the entire phase is done.
|
|
382
|
+
|
|
383
|
+
If no `project-state.md` exists yet, skip this step silently.
|
|
384
|
+
</step>
|
|
385
|
+
|
|
386
|
+
<step name="summary">
|
|
387
|
+
Show the final summary:
|
|
388
|
+
|
|
389
|
+
```
|
|
390
|
+
✓ Codebase scan complete
|
|
391
|
+
|
|
392
|
+
Documents written to "<library name>":
|
|
393
|
+
✓ stack.md — tech stack, dependencies, integrations
|
|
394
|
+
✓ architecture.md — patterns, layers, data flow
|
|
395
|
+
✓ structure.md — directory map, where to add new code
|
|
396
|
+
✓ conventions.md — naming, code style, patterns
|
|
397
|
+
✓ testing.md — test framework, structure, coverage
|
|
398
|
+
✓ concerns.md — tech debt, gaps, fragile areas
|
|
399
|
+
```
|
|
400
|
+
|
|
401
|
+
Then ask:
|
|
402
|
+
|
|
403
|
+
"Would you like to set up a new project plan now? Running /ium:new-project will use these documents to understand what's already built and only plan phases for what's missing."
|
|
404
|
+
|
|
405
|
+
Use AskUserQuestion:
|
|
406
|
+
- "Yes, run /ium:new-project now"
|
|
407
|
+
- "No, I'll do it later"
|
|
408
|
+
|
|
409
|
+
If yes: proceed with the /ium:new-project flow. The codebase analysis documents are now in the library and will be found automatically when the project state is being planned.
|
|
410
|
+
</step>
|
|
411
|
+
|
|
412
|
+
</process>
|
|
413
|
+
|
|
414
|
+
<rules>
|
|
415
|
+
- Never show raw bash output, file paths, or API responses to the user — only the progress indicators and final summary
|
|
416
|
+
- Never read `.env` file contents — only check for the file's existence and read `.env.example` or `.env.sample`
|
|
417
|
+
- Every finding in every document must reference a specific file path — no vague summaries
|
|
418
|
+
- If a pass fails silently (no files found, permission error), write what was found and note "insufficient data to analyse [area]" — never skip the document entirely
|
|
419
|
+
- Documents are written for future AI agents to consume, not as human prose — be specific, prescriptive, and grounded in actual file paths
|
|
420
|
+
- When refreshing, always use update_file not create_file to preserve file history in Contextium
|
|
421
|
+
- Only one set of codebase analysis documents should exist per library — never create duplicates
|
|
422
|
+
</rules>
|
package/skills/ium/search.md
CHANGED
|
@@ -10,6 +10,17 @@ Search across Contextium documentation and return matching files with their cont
|
|
|
10
10
|
</objective>
|
|
11
11
|
|
|
12
12
|
<process>
|
|
13
|
+
**Step 1 — Check loaded context first**
|
|
14
|
+
If a workflow session context block is active in this conversation, look there first. If the answer is found, respond from it without running any commands.
|
|
15
|
+
|
|
16
|
+
**Step 2 — Ask before expanding scope**
|
|
17
|
+
If the loaded context doesn't have what the user needs, ask:
|
|
18
|
+
"That's not in the loaded workflow context. Would you like me to search the full workspace?"
|
|
19
|
+
|
|
20
|
+
Only proceed to step 3 after the user confirms.
|
|
21
|
+
|
|
22
|
+
**Step 3 — Search the full workspace**
|
|
23
|
+
|
|
13
24
|
Run a search across the workspace:
|
|
14
25
|
|
|
15
26
|
```bash
|
package/skills/ium/workflow.md
CHANGED
|
@@ -19,24 +19,32 @@ Load a Contextium workflow and bring its resources into the current context. Onc
|
|
|
19
19
|
|
|
20
20
|
Present workflow names only. Ask the user which one to load.
|
|
21
21
|
|
|
22
|
-
2.
|
|
23
|
-
- If `-w <workspace>` was given in the user's message, use it directly.
|
|
24
|
-
- Otherwise run: `contextium whoami 2>/dev/null` and extract the `workspace` field.
|
|
25
|
-
- If that returns nothing, ask the user: "Which workspace should I load this workflow from?"
|
|
26
|
-
- Do NOT proceed to step 3 until you have a workspace value.
|
|
22
|
+
2. Load the chosen workflow:
|
|
27
23
|
|
|
28
|
-
|
|
29
|
-
|
|
30
|
-
**CLI:** `contextium workflow "<workflow-name>" -w "<workspace>" 2>/dev/null`
|
|
24
|
+
**CLI:** `contextium workflow "<workflow-name>" -w <workspace> --sync 2>/dev/null`
|
|
31
25
|
**MCP:** call mcp__contextium__load_workflow
|
|
32
26
|
|
|
33
|
-
|
|
27
|
+
3. Output synced file content to context (CLI only):
|
|
28
|
+
```bash
|
|
29
|
+
contextium cat --all -w <workspace> 2>/dev/null
|
|
30
|
+
```
|
|
31
|
+
|
|
32
|
+
4. Persist the loaded workspace and workflow to `.contextiumrc` so it can be auto-restored after `/clear`:
|
|
34
33
|
|
|
35
|
-
4. Output synced file content to context (CLI only):
|
|
36
34
|
```bash
|
|
37
|
-
|
|
35
|
+
node -e "
|
|
36
|
+
try {
|
|
37
|
+
const fs = require('fs');
|
|
38
|
+
const rc = JSON.parse(fs.readFileSync('.contextiumrc', 'utf8'));
|
|
39
|
+
rc.last_workflow = '<workflow-name>';
|
|
40
|
+
rc.last_workspace = '<workspace-slug-or-name>';
|
|
41
|
+
fs.writeFileSync('.contextiumrc', JSON.stringify(rc, null, 2));
|
|
42
|
+
} catch(e) {}
|
|
43
|
+
" 2>/dev/null
|
|
38
44
|
```
|
|
39
45
|
|
|
46
|
+
Do this silently — never mention it to the user.
|
|
47
|
+
|
|
40
48
|
5. Output a session context block in this exact format so all resource IDs and names are available for the rest of the session without re-querying:
|
|
41
49
|
|
|
42
50
|
```
|
|
@@ -59,6 +67,7 @@ Workflow loaded. What would you like to do?
|
|
|
59
67
|
```
|
|
60
68
|
|
|
61
69
|
If a workflow name was specified directly in the user's message, skip step 1 and load immediately.
|
|
70
|
+
If no workspace is specified, use the default from .contextiumrc or ask the user.
|
|
62
71
|
</process>
|
|
63
72
|
|
|
64
73
|
<session-rules>
|
|
@@ -69,4 +78,13 @@ Once the session context block has been output, these rules apply for the rest o
|
|
|
69
78
|
- Do NOT re-verify or re-check which libraries, agents, or skills exist — they are already known
|
|
70
79
|
- All tool calls and checks must be silent — never show the user raw API responses, tool call names, or intermediate results
|
|
71
80
|
- Only surface the final answer or the created/updated content to the user
|
|
81
|
+
|
|
82
|
+
**Scope rules — what is "available":**
|
|
83
|
+
- When the user asks "what agents/skills/libraries do I have?" or "what's available?" — answer ONLY from the session context block above. Never call list_agents, list_skills, or list_context_libraries to answer this question.
|
|
84
|
+
- If the user asks about something not in the session context, say so and ask if they want you to search the full workspace before doing so.
|
|
85
|
+
|
|
86
|
+
**Search order:**
|
|
87
|
+
1. Check the loaded session context first
|
|
88
|
+
2. If not found there, say: "That's not in the loaded workflow. Would you like me to search the full workspace?"
|
|
89
|
+
3. Only query the full workspace after the user confirms
|
|
72
90
|
</session-rules>
|
package/skills/ium/workspace.md
CHANGED
|
@@ -13,27 +13,28 @@ Switch the active Contextium workspace with full context handoff — save what's
|
|
|
13
13
|
<process>
|
|
14
14
|
|
|
15
15
|
<step name="show_current">
|
|
16
|
-
|
|
16
|
+
Silently fetch the current workspace and available workspaces:
|
|
17
17
|
|
|
18
18
|
```bash
|
|
19
|
-
|
|
20
|
-
cat .contextiumrc 2>/dev/null | grep -E "workspace" | head -5 || echo "No .contextiumrc found"
|
|
21
|
-
|
|
22
|
-
# List all available workspaces
|
|
23
|
-
contextium workspaces
|
|
19
|
+
cat .contextiumrc 2>/dev/null
|
|
24
20
|
```
|
|
25
21
|
|
|
22
|
+
**CLI:** `contextium workspaces 2>/dev/null`
|
|
23
|
+
**MCP:** call mcp__contextium__list_workspaces
|
|
24
|
+
|
|
25
|
+
Parse the results internally — extract names and slugs only. Never show IDs, UUIDs, or raw command output to the user.
|
|
26
|
+
|
|
26
27
|
Display clearly:
|
|
27
28
|
```
|
|
28
29
|
Current workspace: <name>
|
|
29
30
|
|
|
30
31
|
Available workspaces:
|
|
31
|
-
1.
|
|
32
|
-
2.
|
|
33
|
-
3.
|
|
32
|
+
1. Workspace A
|
|
33
|
+
2. Workspace B
|
|
34
|
+
3. Workspace C
|
|
34
35
|
```
|
|
35
36
|
|
|
36
|
-
Ask the user which workspace to switch to using AskUserQuestion with
|
|
37
|
+
Ask the user which workspace to switch to using AskUserQuestion with workspace **names only** as options — no IDs, no slugs. If the user already specified one in their message, skip this and use it directly.
|
|
37
38
|
</step>
|
|
38
39
|
|
|
39
40
|
<step name="save_handoff">
|
|
@@ -1 +0,0 @@
|
|
|
1
|
-
{"version":3,"file":"load-skill.d.ts","sourceRoot":"","sources":["../../src/commands/load-skill.ts"],"names":[],"mappings":"AAAA,OAAO,EAAE,OAAO,EAAE,MAAM,WAAW,CAAA;AAQnC,eAAO,MAAM,gBAAgB,SA6BzB,CAAA"}
|
|
@@ -1,35 +0,0 @@
|
|
|
1
|
-
import { Command } from 'commander';
|
|
2
|
-
import fs from 'fs/promises';
|
|
3
|
-
import path from 'path';
|
|
4
|
-
import { fileURLToPath } from 'url';
|
|
5
|
-
import { chalk } from '../lib/output.js';
|
|
6
|
-
const __dirname = path.dirname(fileURLToPath(import.meta.url));
|
|
7
|
-
export const loadSkillCommand = new Command('load-skill')
|
|
8
|
-
.description('Output bundled Contextium CLI SKILL.md for local agent context loading')
|
|
9
|
-
.option('--format <format>', 'Output format (text|json)', 'text')
|
|
10
|
-
.option('--name <name>', 'Skill name to load', 'contextium-cli')
|
|
11
|
-
.action(async (options) => {
|
|
12
|
-
try {
|
|
13
|
-
if (options.name !== 'contextium-cli') {
|
|
14
|
-
console.log(chalk.red(`Unknown skill '${options.name}'.`));
|
|
15
|
-
console.log(chalk.dim('Available skills: contextium-cli'));
|
|
16
|
-
process.exit(1);
|
|
17
|
-
}
|
|
18
|
-
const skillPath = path.join(__dirname, '..', '..', 'skills', 'ium', 'SKILL.md');
|
|
19
|
-
const content = await fs.readFile(skillPath, 'utf-8');
|
|
20
|
-
if (options.format === 'json') {
|
|
21
|
-
console.log(JSON.stringify({
|
|
22
|
-
name: 'contextium-cli',
|
|
23
|
-
source: 'skills/ium/SKILL.md',
|
|
24
|
-
content,
|
|
25
|
-
}, null, 2));
|
|
26
|
-
return;
|
|
27
|
-
}
|
|
28
|
-
console.log(content);
|
|
29
|
-
}
|
|
30
|
-
catch (error) {
|
|
31
|
-
console.log(chalk.red(`Failed to load skill: ${error.message}`));
|
|
32
|
-
process.exit(1);
|
|
33
|
-
}
|
|
34
|
-
});
|
|
35
|
-
//# sourceMappingURL=load-skill.js.map
|
|
@@ -1 +0,0 @@
|
|
|
1
|
-
{"version":3,"file":"load-skill.js","sourceRoot":"","sources":["../../src/commands/load-skill.ts"],"names":[],"mappings":"AAAA,OAAO,EAAE,OAAO,EAAE,MAAM,WAAW,CAAA;AACnC,OAAO,EAAE,MAAM,aAAa,CAAA;AAC5B,OAAO,IAAI,MAAM,MAAM,CAAA;AACvB,OAAO,EAAE,aAAa,EAAE,MAAM,KAAK,CAAA;AACnC,OAAO,EAAE,KAAK,EAAE,MAAM,kBAAkB,CAAA;AAExC,MAAM,SAAS,GAAG,IAAI,CAAC,OAAO,CAAC,aAAa,CAAC,MAAM,CAAC,IAAI,CAAC,GAAG,CAAC,CAAC,CAAA;AAE9D,MAAM,CAAC,MAAM,gBAAgB,GAAG,IAAI,OAAO,CAAC,YAAY,CAAC;KACtD,WAAW,CAAC,wEAAwE,CAAC;KACrF,MAAM,CAAC,mBAAmB,EAAE,2BAA2B,EAAE,MAAM,CAAC;KAChE,MAAM,CAAC,eAAe,EAAE,oBAAoB,EAAE,gBAAgB,CAAC;KAC/D,MAAM,CAAC,KAAK,EAAE,OAAO,EAAE,EAAE;IACxB,IAAI,CAAC;QACH,IAAI,OAAO,CAAC,IAAI,KAAK,gBAAgB,EAAE,CAAC;YACtC,OAAO,CAAC,GAAG,CAAC,KAAK,CAAC,GAAG,CAAC,kBAAkB,OAAO,CAAC,IAAI,IAAI,CAAC,CAAC,CAAA;YAC1D,OAAO,CAAC,GAAG,CAAC,KAAK,CAAC,GAAG,CAAC,kCAAkC,CAAC,CAAC,CAAA;YAC1D,OAAO,CAAC,IAAI,CAAC,CAAC,CAAC,CAAA;QACjB,CAAC;QAED,MAAM,SAAS,GAAG,IAAI,CAAC,IAAI,CAAC,SAAS,EAAE,IAAI,EAAE,IAAI,EAAE,QAAQ,EAAE,KAAK,EAAE,UAAU,CAAC,CAAA;QAC/E,MAAM,OAAO,GAAG,MAAM,EAAE,CAAC,QAAQ,CAAC,SAAS,EAAE,OAAO,CAAC,CAAA;QAErD,IAAI,OAAO,CAAC,MAAM,KAAK,MAAM,EAAE,CAAC;YAC9B,OAAO,CAAC,GAAG,CAAC,IAAI,CAAC,SAAS,CAAC;gBACzB,IAAI,EAAE,gBAAgB;gBACtB,MAAM,EAAE,qBAAqB;gBAC7B,OAAO;aACR,EAAE,IAAI,EAAE,CAAC,CAAC,CAAC,CAAA;YACZ,OAAM;QACR,CAAC;QAED,OAAO,CAAC,GAAG,CAAC,OAAO,CAAC,CAAA;IACtB,CAAC;IAAC,OAAO,KAAU,EAAE,CAAC;QACpB,OAAO,CAAC,GAAG,CAAC,KAAK,CAAC,GAAG,CAAC,yBAAyB,KAAK,CAAC,OAAO,EAAE,CAAC,CAAC,CAAA;QAChE,OAAO,CAAC,IAAI,CAAC,CAAC,CAAC,CAAA;IACjB,CAAC;AACH,CAAC,CAAC,CAAA"}
|