Need ability to resume a skill/command

[ngbrown]

I was working in propose mode and ran out of context window so prompted for the prompt to start with in a new session. I got a prompt to read the current changes files, but the skill was not loaded.

When I manually loaded the skill into the session and asked it to resume at item 3 (Get the artifact build order), it did that, but it then didn't run the openspec instructions command because each artifact's state was done and not ready.

There should be some way to resume the working on a proposed change.

[1code-async]

Task completed.

I'll analyze this GitHub issue and provide a helpful comment. Let me first explore the codebase to understand the relevant components.

---

View full conversation

Powered by 1Code

[1code-async]

Issue Analysis

Root Cause

The problem has two parts:

1. Skill not loaded in new session: When a session runs out of context window and the user starts a new session, the skill (e.g., openspec-propose) is not automatically loaded. The user gets a prompt to read current changed files, but without the skill's instructions loaded, the agent doesn't know the workflow.

2. Artifact state prevents resumption: When manually loading the skill and asking to resume at a specific step, the openspec instructions command is never called because the openspec status --json output shows all artifacts as done (since the files already exist on disk). The propose workflow (step 4a in src/core/templates/workflows/propose.ts:57) only processes artifacts with status: "ready" — there is no path for re-processing done artifacts.

The state detection is purely filesystem-based — src/core/artifact-graph/state.ts:24-31 checks if the generated file exists, and if so, marks the artifact as done. This is correct for normal operation but creates a problem when you need to resume the apply phase after artifacts are already created.

Relevant Code

Component	File	Key Lines
Propose workflow (skill instructions)	src/core/templates/workflows/propose.ts	L51-77 — artifact creation loop only processes ready artifacts
Continue workflow (existing resume)	src/core/templates/workflows/continue-change.ts	L42-80 — same pattern, skips done artifacts
Artifact state detection	src/core/artifact-graph/state.ts	L16-31 — detectCompleted() marks artifacts as done based on file existence
Status formatting	src/core/artifact-graph/instruction-loader.ts	L326-349 — maps artifacts to done/ready/blocked states
Apply instructions state	src/commands/workflow/instructions.ts	L364-387 — determines blocked/all_done/ready for apply phase

What the User Likely Expected

After running /opsx:propose and creating all artifacts (proposal, specs, design, tasks), the next step is /opsx:apply which reads the tasks from tasks.md and implements them. When resuming in a new session, the user expected to be able to pick up at the apply phase — but the propose skill doesn't transition to apply, and the apply skill wasn't loaded.

Existing Workarounds

The existing /opsx:continue skill (src/core/templates/workflows/continue-change.ts) and /opsx:apply skill handle partially-completed changes. If all artifacts are done, /opsx:continue shows a completion message and suggests running /opsx:apply. The /opsx:apply workflow tracks progress via checkboxes in tasks.md. However, neither is automatically loaded when resuming a session.

Related Issues

Several open issues touch on the same themes of session continuity and skill persistence:

• #35150 — Allow tools/skills to programmatically clear context and inject a continuation prompt
• #40018 — Expose context window usage to enable session handoff before context runs out
• #42146 — Resume with initial command runs command before large-context compaction prompt
• #40193 — Skill invocations persist through context compaction and are re-executed as new requests
• #34039 — Regression: SessionStart hook and skills listing re-injected on every --resume
• #38210 — Session auto-restart with project context persistence
• #36924 — Allow resuming a conversation from an arbitrary JSONL file path

Potential Approaches

1. Workflow-aware resume prompt: When a session ends mid-workflow, persist the current workflow state (skill name, change name, current step) and include it in the resume prompt for the new session. This could be stored alongside the session data or in a .openspec.yaml metadata field.

2. Auto-load skill on resume: If a session is resumed (--resume) and the previous session had an active skill, automatically inject the skill instructions into the new session context. This relates to #34039 and #40193.

3. Propose-to-apply transition: The propose workflow could detect when all artifacts are already done and automatically suggest/trigger the apply workflow instead of silently completing. In propose.ts step 4b, when applyRequires artifacts are all done on first status check, it should recognize this as a "resume apply" scenario rather than "nothing to do."

4. openspec resume CLI command: A new CLI command that outputs the current workflow state (active change, which skill was running, current step, what's next) so that any agent can pick up where the previous session left off — regardless of which skill was originally loaded.

[ngbrown]

Where do these related issues come from? There is no #35150 in this repository.

[ngbrown]

I reviewed the workflow, and it seems like the resume skill is the answer to that. I didn't have that workflow loaded, so I switch the workflow over to the more modern list (explore, new, continue/ff, apply, verify, archive). However, now the custom rules per artifact don't get read in on continue in a new session, since all artifacts are "done". So this is still an issue. There needs to be a way to resume/continue in a new LLM session where the necessary context is loaded to continue refining the proposal, design, tasks, and specs.

I ran the line in the agent Read the openspec instructions for all the artifact types., and that did what it needed to do, but I feel I shouldn't have to do that.

[TabishB]

@ngbrown Yeah this is always a little tricky with models.

I'm pretty sure you can just tell the model exactly that like:

/opsx:propose Hey let's continue working on this existing change and figure out where I left off.

I agree the UX could maybe be better, but I also think people need to rely less on commands and utilize model capabilities more to do more custom things.