@contextium/cli 1.0.60 → 1.0.61
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 +1 -1
- package/skills/ium/workflow.md +46 -0
package/package.json
CHANGED
package/skills/ium/workflow.md
CHANGED
|
@@ -112,6 +112,52 @@ If a workflow name was specified directly in the user's message, skip step 1 and
|
|
|
112
112
|
If no workspace is specified, use the default from .contextiumrc or ask the user.
|
|
113
113
|
</process>
|
|
114
114
|
|
|
115
|
+
<auto-planning>
|
|
116
|
+
## Auto-planning — triggered on first user goal after loading
|
|
117
|
+
|
|
118
|
+
Once the workflow is loaded and the user states what they want to do, apply this logic **before starting any work**:
|
|
119
|
+
|
|
120
|
+
**If `phaseCount === 0` (no phases set up yet):**
|
|
121
|
+
|
|
122
|
+
Assess the scope of the request silently, then act accordingly:
|
|
123
|
+
|
|
124
|
+
**Simple / single task** (one clear, bounded piece of work — e.g. "fix this bug", "write a readme", "add a button"):
|
|
125
|
+
- Create 1 phase file in the Project Library
|
|
126
|
+
- Call `update_workflow` with `projectConfig: { phaseCount: 1, completedCount: 0, contextLibraryId: "<projectLibraryId>" }`
|
|
127
|
+
- Say: "Added as 1 phase. Starting now." — then proceed immediately as the Builder
|
|
128
|
+
|
|
129
|
+
**Complex / multi-part ask** (a feature, a new system, multiple steps — e.g. "build an onboarding flow", "add payments", "create the admin panel"):
|
|
130
|
+
- Break the work down into logical phases (DB migrations first, then API, then MCP/CLI, then UI — in dependency order)
|
|
131
|
+
- Aim for 3–10 phases. Each phase = one coherent unit of work that can be built and reviewed independently
|
|
132
|
+
- Create one phase file per phase in the Project Library using `contextium new "<project-library>" -w <workspace> --stdin`
|
|
133
|
+
Each file must include: phase ID (e.g. `phase-001`), title, layer, status (`pending`), and a brief implementation spec
|
|
134
|
+
- Call `update_workflow` with `projectConfig: { phaseCount: <N>, completedCount: 0, contextLibraryId: "<projectLibraryId>" }`
|
|
135
|
+
- Show the user the phase breakdown:
|
|
136
|
+
```
|
|
137
|
+
Planned X phases:
|
|
138
|
+
1. <title>
|
|
139
|
+
2. <title>
|
|
140
|
+
...
|
|
141
|
+
Starting phase 1 now.
|
|
142
|
+
```
|
|
143
|
+
- Then immediately start the first phase as the Builder
|
|
144
|
+
|
|
145
|
+
**If `phaseCount > 0` (phases already exist):**
|
|
146
|
+
- Do NOT re-plan. Go straight to the next pending phase.
|
|
147
|
+
- If the user's request is new work unrelated to existing phases: create a new phase file, increment `phaseCount` via `update_workflow`, and begin it.
|
|
148
|
+
|
|
149
|
+
**Completing phases:**
|
|
150
|
+
- When a phase is done, call `mark_phase_complete` (MCP) or `update_workflow` with `completedCount` incremented
|
|
151
|
+
- Announce progress: "Phase 2 of 5 complete." then ask if the user wants to continue to the next phase
|
|
152
|
+
- Do not auto-start the next phase without confirmation
|
|
153
|
+
|
|
154
|
+
**Rules:**
|
|
155
|
+
- Never ask the user "should I plan this?" — just assess and act
|
|
156
|
+
- Never show raw file creation output — only the phase list summary
|
|
157
|
+
- Phase files go in the Project Library (the library whose name contains "Project Library")
|
|
158
|
+
- Keep phase titles short and action-oriented (e.g. "Add payments table migration", "Build checkout API endpoint")
|
|
159
|
+
</auto-planning>
|
|
160
|
+
|
|
115
161
|
<session-rules>
|
|
116
162
|
Once the session context block has been output, these rules apply for the rest of the conversation:
|
|
117
163
|
|