@contextium/cli 1.0.18 → 1.0.19

package/skills/ium/contextium.md

@@ -1,158 +0,0 @@
----
-name: ium:contextium
-description: General behaviour rules for the Contextium MCP and CLI — scoping, lookup order, and workspace awareness
----
-
-# Contextium — General Behaviour Rules
-
-These rules apply whenever the Contextium MCP is connected or the CLI is in use, regardless of which slash command was run.
-
-## Session Auto-Restore
-
-At the start of any new session where no `--- WORKFLOW SESSION CONTEXT ---` block exists in the conversation yet, automatically restore the last used workspace and workflow:
-
-1. Silently check `.contextiumrc`:
-```bash
-cat .contextiumrc 2>/dev/null
-```
-
-2. If `last_workflow` and `last_workspace` are present, load the workflow immediately without asking:
-
-**CLI:** `contextium workflow "<last_workflow>" -w <last_workspace> --sync 2>/dev/null`
-**MCP:** call mcp__contextium__load_workflow with the workflow name
-
-3. Output the session context block as normal. Do not announce that you're auto-restoring — just do it transparently and continue with whatever the user asked.
-
-4. If `last_workflow` is not set, or loading fails silently, proceed as normal without mentioning it.
-
-This runs once per session — never repeat it once the session context block has been output.
-
----
-
-## Scope Rules
-
-### If a workflow has been loaded in this session
-
-A workflow is loaded when a `--- WORKFLOW SESSION CONTEXT ---` block has been output in the conversation.
-
-- Answer all questions about available agents, skills, and libraries **from that session context block only**
-- Do NOT call `list_agents`, `list_skills`, `list_context_libraries`, or any other listing tool to answer "what's available?" questions
-- If the user asks about something not in the session context, say so clearly — do not silently fall back to a full workspace query
-
-### If no workflow has been loaded
-
-Answer from whatever has been explicitly loaded or cat'd into the session. If nothing has been loaded, say so and offer to load a workflow or sync files.
-
-## Lookup Order
-
-Before querying the full workspace for anything (search, find, list), follow this order:
-
-1. **Check loaded session context first** — agents, skills, libraries, and files already in context
-2. **If not found, ask** — "That's not in the loaded context. Would you like me to search the full workspace?"
-3. **Only query the full workspace after the user confirms**
-
-Never silently expand scope to the full workspace. Always make it explicit and get confirmation first.
-
-## Data Model
-
-```
-Workspace
-├── Context Libraries  ← containers for documentation files
-│   └── Files
-├── Skills             ← reusable instruction documents
-├── Agents             ← roles combining a system prompt + skills
-└── Workflows          ← bind an agent + skills + libraries for a task
-```
-
-| Ask yourself | Use |
-|---|---|
-| Storing content, data, or docs? | Context Library + Files |
-| Reusable how-to instructions? | Skill |
-| A role combining multiple skills? | Agent |
-| Ready-to-use context package for a task? | Workflow |
-
-## Contextium Is the Source of Truth
-
-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.
-
-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.
-
-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.
-
-## Multi-Project Rule
-
-Each project must have its own dedicated context library. Never mix two projects into one library.
-
-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.
-
-## Decision Routing
-
-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.
-
-A decision qualifies if it:
-- Picks a technology or library
-- Sets an API contract or data model
-- Establishes a pattern future phases will depend on
-- Rules out an approach that was considered
-
-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.
-
-## File Routing — Writing Files When Contextium Is Connected
-
-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:
-
-> "Should this file go to a Contextium context library, or stay local?"
-
-**If a workflow is loaded in this session:**
-- Default to suggesting the most relevant library from the session context block
-- Offer: `[1] Write to "<library name>" in Contextium  [2] Keep local`
-- If the user picks Contextium, use `mcp__contextium__create_file` or `contextium files create` CLI with the library ID from session context — do NOT write it locally
-
-**If no workflow is loaded but the MCP/CLI is active:**
-- Ask: "Should this go to Contextium? If yes, which library?"
-- List available libraries only if the user says yes
-- Otherwise write locally as normal
-
-**Files that should NEVER be routed to Contextium — always write locally:**
-- Rich text formats: `.docx`, `.doc`, `.pdf`, `.rtf`, `.odt`, `.pages`, `.pptx`, `.xlsx`, and any binary or formatted document
-- Source code files (`.ts`, `.tsx`, `.js`, `.py`, etc.)
-- Config files (`package.json`, `.env`, `tsconfig.json`, etc.)
-- Git-tracked project files in general
-
-**Files that SHOULD be offered for Contextium routing (plain text / non-rich text only):**
-- Plain markdown (`.md`) that is NOT part of the project source (e.g. not `README.md`, `CLAUDE.md`)
-- Plain text (`.txt`), YAML (`.yaml`/`.yml`), or JSON files used as documentation or notes
-- Any plain-text file the user explicitly describes as "context", "reference", or "docs"
-
-This rule applies to both the `Write` tool and any CLI `echo`/`cat` file creation.
-
-## Silent Operation
-
-All tool calls and CLI commands must be completely silent — never show raw API responses, tool output, parameters, IDs, or intermediate results. Only surface the final answer or result.
-
-**Never say** "MCP", "tool", "API", "CLI command", "calling", or "contextium" as a system reference in any output. The user knows what they're using.
-
-Before any operation, output one short friendly progress line, then make the call silently. After the call, surface only the result. No confirmation text unless something went wrong.
-
-**Progress message guide:**
-
-| Operation | Say this |
-|-----------|----------|
-| Fetching a file | `Getting your file...` |
-| Listing files | `Fetching your files...` |
-| Creating a file | `Creating your file...` |
-| Updating a file | `Saving your changes...` |
-| Deleting a file | `Deleting the file...` |
-| Loading a workflow | `Loading your workflow...` |
-| Listing workflows | `Fetching your workflows...` |
-| Searching | `Searching...` |
-| Listing libraries | `Fetching your libraries...` |
-| Creating a library | `Creating your library...` |
-| Listing agents | `Fetching your agents...` |
-| Creating an agent | `Creating your agent...` |
-| Listing skills | `Fetching your skills...` |
-| Creating a skill | `Creating your skill...` |
-| Syncing | `Syncing your workspace...` |
-| Any other read | `Just a moment...` |
-
-Keep messages lowercase, short, and conversational. Never repeat the progress line after the call completes — just show the result.

package/skills/ium/new-project.md

@@ -1,458 +0,0 @@
----
-name: ium:new-project
-description: Set up a new Contextium project — authenticate, pick a workspace, describe project, intelligently suggest and create libraries, agents, skills, tags, and a workflow
-allowed-tools:
-  - Bash
-  - mcp__contextium__list_workspaces
-  - mcp__contextium__create_context_library
-  - mcp__contextium__list_context_libraries
-  - mcp__contextium__create_agent
-  - mcp__contextium__list_agents
-  - mcp__contextium__create_skill
-  - mcp__contextium__list_skills
-  - mcp__contextium__create_workflow
-  - mcp__contextium__list_workflows
-  - mcp__contextium__list_tags
-  - mcp__contextium__list_tag_types
-  - mcp__contextium__create_tag
-  - mcp__contextium__create_tag_type
-  - AskUserQuestion
----
-
-<objective>
-Set up a new Contextium project intelligently — understand what the user is trying to do, quietly analyse the workspace for existing resources, then recommend exactly what to create (libraries, agents, skills, tags, workflow) with clear reasoning. Get confirmation before creating anything.
-</objective>
-
-<mode-detection>
-Run this once at the start, silently, to determine which mode to use for the entire session:
-
-```bash
-command -v contextium &>/dev/null && echo "cli" || echo "no-cli"
-```
-
-- If `cli`: use CLI commands throughout. Do not attempt MCP tools.
-- If `no-cli`: check if mcp__contextium__list_workspaces is available. If yes, use MCP tools throughout.
-- If neither: tell the user "Contextium doesn't appear to be installed. Install the CLI with `npm install -g @contextium/cli` or connect the MCP server, then re-run this." Stop here.
-
-Do not mention the mode to the user. Pick one path and stick with it.
-</mode-detection>
-
-<process>
-
-<step name="check_auth">
-**CLI only.** Run silently:
-```bash
-contextium whoami 2>/dev/null | grep -E "Token:|Name:" || echo "unauthenticated"
-```
-If token is expired or unauthenticated, tell the user: "Your Contextium session has expired — run `contextium login` in your terminal, then come back and re-run this." Stop here.
-
-MCP users are already authenticated via the server connection — skip this step.
-</step>
-
-<step name="select_workspace">
-**CLI:** run `contextium workspace list 2>/dev/null` silently, parse workspace names.
-**MCP:** call mcp__contextium__list_workspaces silently.
-
-Ask: "Which workspace is this project for?"
-
-Present names only — no IDs, no raw output.
-</step>
-
-<step name="existing_workflow_check">
-Before asking for a project description, ask:
-
-"Do you have an existing Contextium workflow you'd like to use as a base for this project?"
-
-Use AskUserQuestion:
-- "Yes, use an existing workflow"
-- "No, start fresh"
-
-If yes:
-1. Silently fetch all workflows in the selected workspace:
-   **CLI:** `contextium workflows list -w <slug> 2>/dev/null`
-   **MCP:** call mcp__contextium__list_workflows
-
-2. Present workflow names and ask: "Which workflow would you like to use?"
-
-3. Load the selected workflow silently and read its resources (libraries, agents, skills).
-
-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:
-   - Resources that already exist in the workflow and can be reused as-is
-   - Resources that exist but may need updating or extending for this project (flag as "Extend")
-   - Resources that are missing entirely and need to be created
-
-5. In the plan table, add an "Extend" action row type where relevant:
-
-| Action | Name | Purpose |
-|--------|------|---------|
-| Reuse  | "Agent Name" | already covers this need |
-| Extend | "Agent Name" | exists but needs updated system prompt for this project |
-| Create | "Agent Name" | not in the workflow, needs to be created |
-
-If no: continue to project description with a clean slate.
-</step>
-
-<step name="codebase_scan_check">
-Silently check whether any library in the selected workspace contains codebase analysis documents from `/ium:scan-existing`. Look for files named `stack.md`, `architecture.md`, `structure.md`, `conventions.md`, `concerns.md` in any library.
-
-**CLI:** `contextium library list --workspace <slug> 2>/dev/null` then check file lists per library
-**MCP:** call mcp__contextium__list_context_libraries, then mcp__contextium__list_files for each
-
-If found, read `architecture.md` and `stack.md` silently to understand what already exists. Store this as `has_codebase_scan = true` and `codebase_library = <library name>`. This will be used later to pre-populate validated capabilities in the project state.
-
-If not found, set `has_codebase_scan = false` and continue.
-
-Do not mention this check to the user.
-</step>
-
-<step name="project_description">
-Ask the user this question exactly:
-
-"Tell me about your project — what are you trying to do, what topics are involved, and what kind of work will you be doing with this? The more detail you give me, the better I can set things up for you."
-
-Wait for their response. Store it as the project description. Do not proceed until you have a meaningful answer.
-</step>
-
-<step name="quiet_analysis">
-Silently fetch all existing workspace resources. Do not show raw output or errors. Show only these progress lines as you go:
-
-```
-Searching libraries...
-Searching agents...
-Searching skills...
-Searching tags...
-```
-
-**CLI:**
-```bash
-contextium library list --workspace <slug> 2>/dev/null
-contextium agent list --workspace <slug> 2>/dev/null
-contextium skill list --workspace <slug> 2>/dev/null
-contextium tag list --workspace <slug> 2>/dev/null
-```
-
-**MCP:** call list_context_libraries, list_agents, list_skills, list_tags — all for the selected workspace. Suppress any errors silently.
-
-After all four searches complete, output this line:
-```
-Creating Contextium setup plan...
-```
-
-Then analyse the results against the project description:
-- Which existing libraries (if any) are relevant to what the user described?
-- Which existing agents (if any) could serve this project?
-- Which existing skills (if any) are applicable?
-- Which existing tags/tag types (if any) relate to the topics mentioned?
-
-Internally categorise everything as: **reuse** (relevant, already exists) or **create** (needed, does not exist).
-</step>
-
-<step name="intelligent_plan">
-Based on the project description and the analysis, build a setup plan. Think through:
-
-**Libraries:** What distinct knowledge areas did the user mention? Each major topic or type of content that needs to be stored separately should be its own library. If an existing library already covers one of these, mark it for reuse.
-
-**Agents:** Always include a "Project Architect" agent as the first agent — its role is to define the project process, break the work into phases, and track overall progress. Write its system prompt to be specific to this project's domain and goals. Then think about what other AI assistant roles would serve this project based on what the user described. If an existing agent fits one of the additional roles, mark it for reuse.
-
-**Skills:** What reusable knowledge blocks would help agents working on this project? Think about domain-specific guidelines, reference material, or persistent context the agent needs. If an existing skill fits, mark it for reuse.
-
-**Tags:** What topic or category labels would make sense for organising **files within context libraries** for this project? Tags apply to library files only — never suggest tags for agents or skills. Look for existing tag types that match. If none exist, suggest new ones. Think in terms of tag categories (e.g. `topic`, `source`, `status`) and the specific tag values within them (e.g. `topic:space-travel`, `topic:rocket-engineering`).
-
-Present the plan in this format (omit any section that has nothing in it):
-
----
-
-Here's what I'll set up for you:
-
-**Libraries**
-
-| Action | Name | Purpose |
-|--------|------|---------|
-| Create | "Library Name" | reason why this is needed |
-| Reuse  | "Library Name" | why it's relevant |
-
-**Agents**
-
-| Action | Name | Purpose |
-|--------|------|---------|
-| Create | "Agent Name" | what it will do for this project |
-| Reuse  | "Agent Name" | why it fits |
-
-**Skills**
-
-| Action | Name | Purpose |
-|--------|------|---------|
-| Create | "Skill Name" | what knowledge it will hold |
-| Reuse  | "Skill Name" | why it fits |
-
-**Tags**
-
-| Tag | Purpose |
-|-----|---------|
-| `category:value` | why this label is useful |
-
-Shall I go ahead and create all of this?
-
----
-
-Wait for the user to confirm, adjust, or say skip on any item before proceeding.
-</step>
-
-<step name="research_question">
-Ask the user:
-
-"Does this project need research before you start work? I can create a dedicated research agent to gather information, analyse sources, and summarise findings for your project."
-
-Use AskUserQuestion:
-- "Yes, add a research agent"
-- "No, skip"
-
-If yes: add a project-specific research agent to the creation plan. Name it something like "**[Project Name] Researcher**" and tailor its system prompt to the specific research domain (e.g. competitor analysis, technical investigation, market research — infer from the project description). Store this agent as `research_agent_planned = true` for use in later steps.
-
-If no: set `research_agent_planned = false` and continue.
-</step>
-
-<step name="planner_question">
-Ask the user:
-
-"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."
-
-Use AskUserQuestion:
-- "Yes, add a project planner"
-- "No, skip"
-
-If yes:
-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`.
-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:
-
-```markdown
-# [Project Name] — Project State
-
-## Current Position
-**Phase:** Phase 1: [Name]
-**Status:** Not Started
-**Last Updated:** [today's date]
-**Next Action:** Begin Phase 1
-
-## Already Built
-> Capabilities confirmed by codebase scan — these do not need to be built.
-> _(Remove this section if starting a greenfield project with no existing code)_
-
-- ✓ [Existing capability — e.g. "Express API with JWT auth"] — `src/server.ts`
-- ✓ [Existing capability] — `src/`
-
-## Phases
-
-### Phase 1: [Name]
-**Status:** Not Started
-[Brief description of what this phase covers]
-
-### Phase 2: [Name]
-**Status:** Not Started
-[Brief description]
-
-...
-
-## Decisions Log
-> Locked decisions — record here when a significant architectural, technical, or approach decision is made. Do not re-debate entries in this log.
-
-| Decision | Rationale | Phase |
-|----------|-----------|-------|
-| _(none yet)_ | | |
-
-## Seeds
-> Ideas and suggestions to revisit at the right time — not immediate work.
-
-| Idea | When to revisit | Context |
-|------|-----------------|---------|
-| _(none yet)_ | | |
-
-## Notes
-_(ad-hoc notes that don't fit elsewhere)_
-```
-
-Infer sensible phases from the project description. Title the file `project-state.md`.
-
-**If `has_codebase_scan = true`:** populate the `## Already Built` section from the `architecture.md` found in the codebase scan library — list the key capabilities that clearly already exist. Only plan phases for what is **not** in the Already Built list. If starting greenfield, remove the Already Built section entirely.
-
-**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.
-
-If no: set `planner_planned = false` and continue.
-</step>
-
-<step name="create_resources">
-Only create what the user confirmed across all steps. Create in this order: tag types → tags → libraries → skills → agents (including research and planner agents if confirmed).
-
-Do NOT create a workflow in this step.
-
-Show `✓ Created "Name"` for each item as it is created. Show `↗ Reusing "Name"` for each existing resource being included.
-
-If `planner_planned = true`, create the project state file in Contextium after all other resources are created:
-
-**CLI:**
-```bash
-cat << 'EOF' | contextium new <library-name> -t "[Project Name] — Project State" -p "project-state.md" --stdin -w <workspace>
-<generated state content>
-EOF
-```
-**MCP:** call mcp__contextium__create_file with the state content.
-
-Show `✓ Created project state "project-state.md"` when done.
-
-Suppress all errors silently — if something fails, skip it quietly and note it in the summary.
-
-**CLI commands:**
-```bash
-contextium library create "<name>" --workspace <slug>
-contextium agent create "<name>" --workspace <slug>
-contextium skill create "<name>" --workspace <slug>
-contextium tag create "<value>" --type <type-slug> --workspace <slug>
-contextium tag-type create "<name>" --workspace <slug>
-```
-
-**MCP:** use the corresponding create_* tools for each resource type.
-</step>
-
-<step name="workflow_prompt">
-After all other resources are created, ask the user:
-
-"Would you like me to create a workflow to bundle everything together for quick loading? If yes, what would you like to call it?"
-
-Use AskUserQuestion with two options:
-- "Yes, create a workflow" (and ask for the name as a follow-up if they say yes)
-- "No, skip workflow"
-
-If they say yes and provide a name, create the workflow:
-
-**CLI:** `contextium workflow create "<name>" --workspace <slug>`
-**MCP:** call mcp__contextium__create_workflow with the name and workspace.
-
-Then automatically load it:
-
-**CLI:** `contextium workflow load "<name>" --workspace <slug> 2>/dev/null`
-**MCP:** call mcp__contextium__load_workflow with the workflow name and workspace.
-
-If they say no, skip workflow creation and loading entirely.
-</step>
-
-<step name="post_workflow_actions">
-This step only runs if `research_agent_planned = true` or `planner_planned = true`.
-
-**If `research_agent_planned = true`:**
-
-Ask the user:
-
-"Would you like to start the research phase now? I can activate the [Project Name] Researcher and begin gathering information based on your project description."
-
-Use AskUserQuestion:
-- "Yes, start research now"
-- "No, not yet"
-
-If yes: activate the research agent — instruct it to begin researching based on the project description provided earlier. Let it run and surface findings to the user. Do not proceed to the planning question.
-
-If no: fall through to the planning question below (if applicable).
-
----
-
-**If `planner_planned = true` (and research was either not created or the user said no to starting it):**
-
-Ask the user:
-
-"Would you like to plan the project now? The [Project Name] Planner can work through the project description and produce a detailed phase-by-phase plan."
-
-Use AskUserQuestion:
-- "Yes, start planning now"
-- "No, I'll do it later"
-
-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.
-
-If no: continue to summary.
-</step>
-
-<step name="summary">
-Show a clean final summary:
-
-```
-✓ Project ready
-
-Workspace:   <name>
-Libraries:   <list — new + reused>
-Agents:      <list — new + reused, or none>
-Skills:      <list — new + reused, or none>
-Tags:        <list, or none>
-Workflow:    <name> — loaded and ready   (or "none" if skipped)
-```
-
-If anything failed to create, add a single line at the end:
-`⚠ Could not create: <list of names> — you can add these manually.`
-</step>
-
-</process>
-
-<rules>
-- Never say "the wizard", "Contextium would like to know", or "the next step is"
-- Never show raw bash output, API responses, or IDs to the user
-- Run all checks and fetches silently — only surface progress labels and the final plan
-- Only ask questions when genuinely needed — the description step and the confirmation step
-- Do not ask the user what to create — figure it out from the description, then ask them to confirm
-- Always create a "Project Architect" agent first, regardless of what the user described — tailor its system prompt to the specific project domain and goals
-- If a resource already exists and is relevant, always prefer reuse over creating a duplicate
-- The plan report must explain the reasoning for each item — not just list names
-- Never create anything before the user confirms the plan
-</rules>
-
-<ongoing-project-rules>
-These rules apply for the duration of the project, after setup is complete.
-
-**New suggestions and feature ideas**
-- 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?"
-- 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.
-- If no: note it and continue with the current work
-- Seeds are NOT immediate work — never promote a seed to a phase without the user asking
-
-**Decision locking**
-- 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.
-- 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
-- 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
-- Never ask the user's permission to log a decision — just do it silently and mention it in the phase summary
-
-**Tackling a new feature or phase**
-- When the user is ready to start work on a new feature or area of the project:
-  1. Update `## Current Position` in `project-state.md` in Contextium to reflect the new phase — set Phase, Status to "In Progress", and Next Action.
-  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
-  3. Ask: "Would you like a phased plan for this?" — if a planner agent exists, use it; otherwise offer to create one
-- If the user says no to both, continue directly using existing agents — no extra setup needed
-- Treat each new feature as its own mini-project using existing workspace resources — never create duplicate agents or skills if suitable ones already exist
-
-**Suggesting new agents and skills**
-- 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
-- Never create new agents or skills without the user's confirmation
-- Always check existing workspace resources before suggesting something new
-
-**Session usage check at end of every phase**
-- At the end of every completed phase, check the current session context usage (visible in the Claude Code status bar as a percentage)
-- If usage is **above 50%**, do the following automatically before prompting the user to continue:
-  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.
-  2. Tell the user:
-
-  ```
-  ⚠ Session is above 50% — recommended to start a fresh session before the next phase.
-
-  Project state has been saved to your Contextium library.
-  Run /ium:resume-project to pick up exactly where you left off.
-  ```
-
-- 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
-- Never skip this check at phase end — even if the user seems eager to continue
-
-**Multi-project rule**
-- 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.
-- 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.
-
-**Project completion — convert to product description**
-- When all phases in `project-state.md` are marked "Complete", automatically trigger the following:
-  1. Ask the user: "All phases are complete — congratulations! Would you like me to convert the project state into a Product Description document?"
-  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.
-  3. If no: leave the state file as-is and congratulate the user
-- Never convert automatically without asking — always get confirmation first
-</ongoing-project-rules>