@contextium/cli 1.0.13 → 1.0.15

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/package.json CHANGED
@@ -1,6 +1,6 @@
1
1
  {
2
2
  "name": "@contextium/cli",
3
- "version": "1.0.13",
3
+ "version": "1.0.15",
4
4
  "description": "Command-line tool for managing Contextium documentation, agents, skills, and workflows — pipe context to AI coding assistants",
5
5
  "keywords": [
6
6
  "contextium",
@@ -49,6 +49,32 @@ Workspace
49
49
  | A role combining multiple skills? | Agent |
50
50
  | Ready-to-use context package for a task? | Workflow |
51
51
 
52
+ ## Contextium Is the Source of Truth
53
+
54
+ All AI-relevant information — project state, SOPs, constraints, decisions, research, planning — lives in Contextium. It is always written to Contextium first. Local files are only for things that belong in git: source code, config, READMEs.
55
+
56
+ Never write AI planning or knowledge files locally by default. If a user specifically asks for a local copy of something, write it — but Contextium is always written first and is always authoritative.
57
+
58
+ This gives users something local file-based tools cannot: state survives machine loss, team members share the same context, and multiple projects run in parallel — one workflow loaded per terminal session — with no interference between them.
59
+
60
+ ## Multi-Project Rule
61
+
62
+ Each project must have its own dedicated context library. Never mix two projects into one library.
63
+
64
+ The project state file (`project-state.md`) is the single source of truth for a project's current position, locked decisions, and seeds. **Only one `project-state.md` should ever exist per library.** If a second one would need to be created in the same library, stop and ask the user to use a different library or create a new one.
65
+
66
+ ## Decision Routing
67
+
68
+ When a significant architectural, technical, or approach decision is made during any session, write it to the `## Decisions Log` in `project-state.md` immediately — no user permission needed. Log it silently and mention it in the phase summary.
69
+
70
+ A decision qualifies if it:
71
+ - Picks a technology or library
72
+ - Sets an API contract or data model
73
+ - Establishes a pattern future phases will depend on
74
+ - Rules out an approach that was considered
75
+
76
+ Decisions in the log are **locked**. Future sessions must not re-debate them. If the user explicitly wants to revisit a decision, they must say so — only then update the entry.
77
+
52
78
  ## File Routing — Writing Files When Contextium Is Connected
53
79
 
54
80
  When the Contextium MCP is connected or the CLI is active, **any time a new file is about to be created**, intercept it with a routing question before writing:
@@ -31,6 +31,8 @@ CONTENT
31
31
  /ium:create Create an agent, skill, or workflow interactively
32
32
  /ium:search Search docs by query, filename, or tag
33
33
  /ium:workflow Load a workflow and sync its resources into context
34
+ /ium:resume-project Resume a project from a session handoff — picks up
35
+ exactly where you left off in the project plan
34
36
 
35
37
  MARKETPLACE
36
38
  /ium:marketplace Browse, install, or publish skills, agents & MCP servers
@@ -58,6 +58,40 @@ Ask: "Which workspace is this project for?"
58
58
  Present names only — no IDs, no raw output.
59
59
  </step>
60
60
 
61
+ <step name="existing_workflow_check">
62
+ Before asking for a project description, ask:
63
+
64
+ "Do you have an existing Contextium workflow you'd like to use as a base for this project?"
65
+
66
+ Use AskUserQuestion:
67
+ - "Yes, use an existing workflow"
68
+ - "No, start fresh"
69
+
70
+ If yes:
71
+ 1. Silently fetch all workflows in the selected workspace:
72
+ **CLI:** `contextium workflows list -w <slug> 2>/dev/null`
73
+ **MCP:** call mcp__contextium__list_workflows
74
+
75
+ 2. Present workflow names and ask: "Which workflow would you like to use?"
76
+
77
+ 3. Load the selected workflow silently and read its resources (libraries, agents, skills).
78
+
79
+ 4. After the user provides their project description (next step), compare the workflow's existing resources against what the new project needs. In the plan step, flag:
80
+ - Resources that already exist in the workflow and can be reused as-is
81
+ - Resources that exist but may need updating or extending for this project (flag as "Extend")
82
+ - Resources that are missing entirely and need to be created
83
+
84
+ 5. In the plan table, add an "Extend" action row type where relevant:
85
+
86
+ | Action | Name | Purpose |
87
+ |--------|------|---------|
88
+ | Reuse | "Agent Name" | already covers this need |
89
+ | Extend | "Agent Name" | exists but needs updated system prompt for this project |
90
+ | Create | "Agent Name" | not in the workflow, needs to be created |
91
+
92
+ If no: continue to project description with a clean slate.
93
+ </step>
94
+
61
95
  <step name="project_description">
62
96
  Ask the user this question exactly:
63
97
 
@@ -168,7 +202,7 @@ If no: set `research_agent_planned = false` and continue.
168
202
  <step name="planner_question">
169
203
  Ask the user:
170
204
 
171
- "Would you like a project planner to break your project into phases and track progress? I'll create a planning agent and a phase tracker document you can follow from start to finish."
205
+ "Would you like a project planner to break your project into phases and track progress? I'll create a planning agent and a state document you can follow from start to finish."
172
206
 
173
207
  Use AskUserQuestion:
174
208
  - "Yes, add a project planner"
@@ -176,23 +210,50 @@ Use AskUserQuestion:
176
210
 
177
211
  If yes:
178
212
  1. Add a "**[Project Name] Planner**" agent to the creation plan — its role is to define project phases, estimate scope, and guide execution in order. Tailor its system prompt to the project domain. Store as `planner_planned = true`.
179
- 2. After all resources are created, create a planning document file in the most relevant library. The file should contain a phased breakdown of the project inferred from the user's description structured like:
213
+ 2. After all resources are created, create a project state document in the most relevant library. This is the living memory for the project not just a phase list. Use this exact structure:
180
214
 
181
215
  ```markdown
182
- # [Project Name] — Project Plan
216
+ # [Project Name] — Project State
183
217
 
184
- ## Phase 1: [Name]
218
+ ## Current Position
219
+ **Phase:** Phase 1: [Name]
220
+ **Status:** Not Started
221
+ **Last Updated:** [today's date]
222
+ **Next Action:** Begin Phase 1
223
+
224
+ ## Phases
225
+
226
+ ### Phase 1: [Name]
185
227
  **Status:** Not Started
186
228
  [Brief description of what this phase covers]
187
229
 
188
- ## Phase 2: [Name]
230
+ ### Phase 2: [Name]
189
231
  **Status:** Not Started
190
232
  [Brief description]
191
233
 
192
234
  ...
235
+
236
+ ## Decisions Log
237
+ > Locked decisions — record here when a significant architectural, technical, or approach decision is made. Do not re-debate entries in this log.
238
+
239
+ | Decision | Rationale | Phase |
240
+ |----------|-----------|-------|
241
+ | _(none yet)_ | | |
242
+
243
+ ## Seeds
244
+ > Ideas and suggestions to revisit at the right time — not immediate work.
245
+
246
+ | Idea | When to revisit | Context |
247
+ |------|-----------------|---------|
248
+ | _(none yet)_ | | |
249
+
250
+ ## Notes
251
+ _(ad-hoc notes that don't fit elsewhere)_
193
252
  ```
194
253
 
195
- Infer sensible phases from the project description. Use "Not Started" for all phases. Title the file something like `project-plan.md`.
254
+ Infer sensible phases from the project description. Title the file `project-state.md`.
255
+
256
+ **Important:** Only one `project-state.md` should ever exist per context library. This is the single source of truth for this project. Never create a second one or split state across multiple files.
196
257
 
197
258
  If no: set `planner_planned = false` and continue.
198
259
  </step>
@@ -204,17 +265,17 @@ Do NOT create a workflow in this step.
204
265
 
205
266
  Show `✓ Created "Name"` for each item as it is created. Show `↗ Reusing "Name"` for each existing resource being included.
206
267
 
207
- If `planner_planned = true`, create the project plan file after all other resources are created:
268
+ If `planner_planned = true`, create the project state file in Contextium after all other resources are created:
208
269
 
209
270
  **CLI:**
210
271
  ```bash
211
- cat << 'EOF' | contextium new <library-name> -t "[Project Name] — Project Plan" -p "project-plan.md" --stdin -w <workspace>
212
- <generated phase content>
272
+ cat << 'EOF' | contextium new <library-name> -t "[Project Name] — Project State" -p "project-state.md" --stdin -w <workspace>
273
+ <generated state content>
213
274
  EOF
214
275
  ```
215
- **MCP:** call mcp__contextium__create_file with the phase content.
276
+ **MCP:** call mcp__contextium__create_file with the state content.
216
277
 
217
- Show `✓ Created project plan "project-plan.md"` when done.
278
+ Show `✓ Created project state "project-state.md"` when done.
218
279
 
219
280
  Suppress all errors silently — if something fails, skip it quietly and note it in the summary.
220
281
 
@@ -281,7 +342,7 @@ Use AskUserQuestion:
281
342
  - "Yes, start planning now"
282
343
  - "No, I'll do it later"
283
344
 
284
- If yes: activate the planner agent — instruct it to analyse the project description and produce a detailed phased plan, updating the `project-plan.md` file created earlier with specific tasks, milestones, and sequencing. Let it run and surface the plan to the user.
345
+ If yes: activate the planner agent — instruct it to analyse the project description and produce a detailed phased plan, updating the `project-state.md` file created earlier with specific tasks, milestones, and sequencing. Let it run and surface the plan to the user.
285
346
 
286
347
  If no: continue to summary.
287
348
  </step>
@@ -322,19 +383,54 @@ If anything failed to create, add a single line at the end:
322
383
  These rules apply for the duration of the project, after setup is complete.
323
384
 
324
385
  **New suggestions and feature ideas**
325
- - Whenever a new feature, idea, or suggestion comes up during the project, ask: "Would you like to add this to the project plan to tackle after the current work is done?"
326
- - If yes: append it to `project-plan.md` as a new phase with status "Not Started"
386
+ - Whenever a new feature, idea, or suggestion comes up during the project, ask: "Would you like to add this to the project state as a seed to revisit later?"
387
+ - If yes: append it to the `## Seeds` section of `project-state.md` in Contextium with a "When to revisit" trigger (e.g. "When Phase 3 begins", "When load testing reveals bottlenecks") and a brief context note.
327
388
  - If no: note it and continue with the current work
328
-
329
- **Tackling a new feature or setting**
330
- - When the user is ready to start work on a new feature or area of the project, ask:
331
- 1. "Would you like to run a research phase on this first?" if a research agent exists, use it; otherwise offer to create one
332
- 2. "Would you like a phased plan for this?" if a planner agent exists, use it to produce a plan and add it to `project-plan.md`; otherwise offer to create one
333
- - If the user says no to both, continue directly using the existing agents based on their instructions no extra setup needed
334
- - Treat each new feature as its own mini-project using the existing workspace resources never create duplicate agents or skills if suitable ones already exist
389
+ - Seeds are NOT immediate work — never promote a seed to a phase without the user asking
390
+
391
+ **Decision locking**
392
+ - Whenever a significant architectural, technical, or approach decision is made during a phase, write it to the `## Decisions Log` table in `project-state.md` in Contextium immediately.
393
+ - A decision qualifies if it: picks a technology, sets an API contract, defines a data model, or establishes a pattern that future phases will depend on
394
+ - Decisions in the log are **locked** — do not re-debate them in future sessions. If the user wants to revisit a decision, they must explicitly say so; only then remove or update the entry
395
+ - Never ask the user's permission to log a decisionjust do it silently and mention it in the phase summary
396
+
397
+ **Tackling a new feature or phase**
398
+ - When the user is ready to start work on a new feature or area of the project:
399
+ 1. Update `## Current Position` in `project-state.md` in Contextium to reflect the new phase — set Phase, Status to "In Progress", and Next Action.
400
+ 2. Ask: "Would you like to run a research phase on this first?" — if a research agent exists, use it; otherwise offer to create one
401
+ 3. Ask: "Would you like a phased plan for this?" — if a planner agent exists, use it; otherwise offer to create one
402
+ - If the user says no to both, continue directly using existing agents — no extra setup needed
403
+ - Treat each new feature as its own mini-project using existing workspace resources — never create duplicate agents or skills if suitable ones already exist
335
404
 
336
405
  **Suggesting new agents and skills**
337
406
  - If the work the user is describing would clearly benefit from an agent or skill that doesn't exist yet, proactively suggest creating one — explain what it would do and why it would help
338
407
  - Never create new agents or skills without the user's confirmation
339
408
  - Always check existing workspace resources before suggesting something new
409
+
410
+ **Session usage check at end of every phase**
411
+ - At the end of every completed phase, check the current session context usage (visible in the Claude Code status bar as a percentage)
412
+ - If usage is **above 50%**, do the following automatically before prompting the user to continue:
413
+ 1. Update `project-state.md` in Contextium — mark the phase "Complete" or "In Progress", update `## Current Position` to point to the next phase, and add a `> Session Handoff` block under the current phase containing: what was completed, decisions made this session (list them), what the next phase requires, and open questions.
414
+ 2. Tell the user:
415
+
416
+ ```
417
+ ⚠ Session is above 50% — recommended to start a fresh session before the next phase.
418
+
419
+ Project state has been saved to your Contextium library.
420
+ Run /ium:resume-project to pick up exactly where you left off.
421
+ ```
422
+
423
+ - If usage is **below 50%**, confirm the phase is complete, update `## Current Position` to the next phase, and ask if the user is ready to move on
424
+ - Never skip this check at phase end — even if the user seems eager to continue
425
+
426
+ **Multi-project rule**
427
+ - Only one `project-state.md` should ever exist per context library. If a user has multiple projects, each project must have its own dedicated library — never mix two projects' state into one library.
428
+ - If a second `project-state.md` would need to be created in the same library, stop and ask the user to either use a different library or create a new one for this project.
429
+
430
+ **Project completion — convert to product description**
431
+ - When all phases in `project-state.md` are marked "Complete", automatically trigger the following:
432
+ 1. Ask the user: "All phases are complete — congratulations! Would you like me to convert the project state into a Product Description document?"
433
+ 2. If yes: rewrite the content in Contextium as a clean Product Description — summarise what was built, the decisions made (draw from the Decisions Log), the architecture or approach used, and outcomes. Remove phase status markers and the Decisions Log table. Title it "[Project Name] — Product Description". This document serves as a reference for future projects.
434
+ 3. If no: leave the state file as-is and congratulate the user
435
+ - Never convert automatically without asking — always get confirmation first
340
436
  </ongoing-project-rules>
@@ -0,0 +1,127 @@
1
+ ---
2
+ name: ium:resume-project
3
+ description: Resume a Contextium project from a session handoff — loads the project plan, finds the last handoff note, and picks up exactly where you left off
4
+ allowed-tools:
5
+ - Bash
6
+ - mcp__contextium__list_workflows
7
+ - mcp__contextium__load_workflow
8
+ - mcp__contextium__list_context_libraries
9
+ - mcp__contextium__list_files
10
+ - mcp__contextium__get_file
11
+ - mcp__contextium__update_file
12
+ - AskUserQuestion
13
+ ---
14
+
15
+ <objective>
16
+ Resume a project session from a handoff note — load the workflow, read the project plan, find where work stopped, and brief the user so they can continue without losing context.
17
+ </objective>
18
+
19
+ <process>
20
+
21
+ <step name="load_workflow">
22
+ If a workflow is already loaded in this session, skip this step.
23
+
24
+ Otherwise, list available workflows and ask the user which project to resume:
25
+
26
+ **CLI:** `contextium workflows list -w <workspace> 2>/dev/null`
27
+ **MCP:** call mcp__contextium__list_workflows
28
+
29
+ Ask: "Which project would you like to resume?"
30
+
31
+ Load the chosen workflow silently:
32
+
33
+ **CLI:** `contextium workflow "<name>" -w <workspace> --sync 2>/dev/null`
34
+ **MCP:** call mcp__contextium__load_workflow
35
+ </step>
36
+
37
+ <step name="find_project_state">
38
+ Contextium is the source of truth. Always read from there first.
39
+
40
+ **1. Contextium first** — search the loaded workflow's libraries for `project-state.md`:
41
+
42
+ **CLI:** `contextium find "project-state" -w <workspace> 2>/dev/null`
43
+ **MCP:** search list_files across the workflow's libraries for a file with path matching `project-state.md`
44
+
45
+ If found, fetch the full content:
46
+
47
+ **CLI:** `contextium cat <fileId> -w <workspace> 2>/dev/null`
48
+ **MCP:** call mcp__contextium__get_file with the file ID
49
+
50
+ **2. Legacy fallback** — if `project-state.md` is not found, search for the older `project-plan.md` filename in the same libraries and treat it the same way.
51
+
52
+ **3. Not found** — if not found in Contextium, tell the user:
53
+ "No project state found in your Contextium workspace. If you set up this project with `/ium:new-project`, the state should be in one of your libraries. Would you like me to search the full workspace?"
54
+ </step>
55
+
56
+ <step name="parse_state">
57
+ Read the project state file and extract:
58
+
59
+ 1. **Current Position** — from the `## Current Position` section: current phase name, status, and next action
60
+ 2. **Handoff note** — look for a `> Session Handoff` block under the current phase. Contains what was completed, decisions made, what's needed next, open questions
61
+ 3. **Completed phases** — all phases marked "Complete"
62
+ 4. **Remaining phases** — all phases still "Not Started" or "In Progress"
63
+ 5. **Recent decisions** — the last 3 entries from the `## Decisions Log` table (if it exists and has entries)
64
+ 6. **Pending seeds** — any entries in the `## Seeds` table (surface only if relevant to the current phase)
65
+
66
+ Present a clear resumption brief:
67
+
68
+ ```
69
+ ── Resuming: [Project Name] ──────────────────────
70
+
71
+ Completed:
72
+ ✓ Phase 1: [Name]
73
+ ✓ Phase 2: [Name]
74
+
75
+ Current:
76
+ → Phase 3: [Name] — In Progress
77
+ Next action: [from Current Position]
78
+
79
+ Last session notes:
80
+ [Handoff note content, or phase description if no handoff]
81
+
82
+ Up next:
83
+ [What the handoff says needs to happen]
84
+
85
+ Remaining:
86
+ ○ Phase 4: [Name]
87
+ ○ Phase 5: [Name]
88
+
89
+ Locked decisions:
90
+ • [Decision] — [Rationale]
91
+ • [Decision] — [Rationale]
92
+
93
+ ─────────────────────────────────────────────────
94
+ ```
95
+
96
+ Only show the "Locked decisions" section if the Decisions Log has entries — these are facts the session must not re-debate.
97
+ If no handoff note exists under the current phase, summarise the phase description instead.
98
+ </step>
99
+
100
+ <step name="confirm_and_continue">
101
+ Ask the user:
102
+
103
+ "Ready to continue with Phase [N]: [Name]?"
104
+
105
+ Use AskUserQuestion:
106
+ - "Yes, let's go"
107
+ - "Give me a summary of what we're building first"
108
+ - "I want to start a different phase"
109
+
110
+ If "Yes, let's go": activate the appropriate agent(s) from the loaded workflow and begin the phase work. Update the phase status in `project-state.md` to "In Progress" if it isn't already.
111
+
112
+ If "Give me a summary": provide a concise overview of the full project and current phase goals drawn from the plan, then ask again if they're ready to continue.
113
+
114
+ If "I want to start a different phase": list the available phases and let them pick one. Update that phase to "In Progress" in `project-state.md`.
115
+ </step>
116
+
117
+ </process>
118
+
119
+ <rules>
120
+ - Never show raw file IDs, API responses, or CLI output to the user
121
+ - Always load the workflow before reading the project state — never search the full workspace without it
122
+ - If the state file has no handoff note, still resume gracefully using the phase description and Current Position
123
+ - When continuing work, always update `## Current Position` and phase status in `project-state.md` in Contextium
124
+ - Decisions in the `## Decisions Log` are locked — surface them in the resumption brief so the session starts with full context, but never re-debate them unless the user explicitly asks to
125
+ - At the end of each phase, follow the session usage check rule — if above 50%, write a new handoff note and update Current Position in Contextium, then prompt the user to start a fresh session with `/ium:resume-project`
126
+ - If all phases are marked "Complete" when reading the state, ask the user if they want to convert it into a Product Description document before resuming — do not start new phase work on a completed project without asking
127
+ </rules>