| name | looply-auto-resume |
| description | Use to resume a persisted feature workflow from its saved state and always question the user about what to do next before taking any action. Cross-host support for Codex and Claude Code. |
Use this skill automatically when a new session starts and looply state is detected, or when the user explicitly invokes $looply-auto-resume, asks to run /looply:auto-resume.
Workflow phase: status.
Quick usage:
$looply-auto-resume [feature-name] "[notes...]"
Primary references:- Workflow playbook: ../../../../.looply/state/workflow-playbook.opencode.md
- Host status contract: ../../../../.looply/state/host-status-contract.json
- Managed pack: ../../../../.looply/managed/packs/software-delivery-suite
- Workflow state template: ../../../../.looply/managed/packs/product-base/templates/workflow-status-template.md
- Custom overrides: ../../../../.looply/custom
- Execution hints: ../../../../.looply/state/execution-hints.opencode.json
- Example hints: ../../../../.looply/state/example-hints.opencode.json
- Context index: ../../../../.looply/state/context-index.md
- Project context: ../../../../.looply/custom/project-context.md
- Session context: ../../../../.looply/custom/session-context.md
- Session links: ../../../../.looply/custom/session-links.json
Usage:
- Automatic detection: triggers when a new session starts and
.looply/ exists in the workspace
- Explicit mention:
$looply-auto-resume
- Workflow alias to honor:
/looply:auto-resume and $looply-auto-resume depending on host
- Syntax in Codex:
$looply-auto-resume [feature-name] "[notes...]"
Example:
- $looply-auto-resume pix-webhook-retry "resuming after security review"
Triggers:
- Every time a new session starts where looply is installed or triggered manually
Curated example guidance:
- ICL mode:
on
- Use examples only for style, structure and quality calibration.
- Do not copy feature-specific names, identifiers or business details from examples.
- No example was selected for this workflow.
Interview Flow
When invoked (automatically or explicitly), follow this sequence. Do not skip steps. Do not ask all questions at once -- ask one at a time and wait for the answer.
Step 0: Detect State
Read the workflow playbook and session-links.json to find any active features.
Scan .looply/custom/features/ for persisted workflow states.
Read .looply/custom/session-context.md for the current session label.
If no features found: "No active workflow found. Would you like to start a new one? Use $looply-idea-to-prd <name> or tell me what you want to do."
If features found, present a numbered list:
- Feature name, current phase, current stage, last updated
- Ask: "Which feature would you like to continue? (number or name)"
Step 1: Load Feature State
Read the feature state file at .looply/custom/features/<feature-name>/workflow-status.md.
Parse current phase, stage, gate status, completed artifacts and pending tasks.
Summarize for the user:
- Workflow:
- Phase: <discovery|planning|delivery|status>
- Current Stage:
- Gate Status: <blocked|passed|pending>
- Completed:
- Pending:
Step 2: Question the User
Always ask before taking action. Present options based on current state:
If stage is in progress:
"Stage <stage> is in progress. What would you like to do?"
[1] Continue from where you left off
[2] Review what was already done before continuing
[3] Skip to another stage
[4] View full state details
If stage is complete but gate is blocking:
"Stage <stage> is complete, but gate <gate> is blocking. What would you like to do?"
[1] Resolve the blocking gate
[2] Review pending artifacts
[3] Go back to previous stage for adjustments
[4] View full state details
If all stages complete:
"All stages of workflow <workflow> are complete. What would you like to do?"
[1] Advance to next workflow (ex: prd-to-stories)
[2] Review final artifacts
[3] Start a new feature
[4] View full state details
Step 3: Execute (Only After Confirmation)
Only proceed after the user explicitly chooses an option. Never advance stages or modify state without confirmation.
When executing:
- Workflow: display section title
- Stage: display current stage name
- Current Task: display task name
- Gate: show gate status
- Decision: show what the user chose
- Next Step: show what will happen after execution
Step 4: Update State
After each action, update .looply/custom/features/<feature-name>/workflow-status.md.
Record the decision made and the new state.
Step 5: Loop
Return to Step 2 and question the user again about what to do next. Never assume the next step -- always ask.
Execution rules:
- Start by reading the workflow playbook, the host status contract if it exists, and session-links.json to find active features.
- If no features exist, inform the user and suggest starting a new one. Do not create features automatically.
- If the user asked for help, explain syntax, arguments, example, expected output and next step without mutating state.
- Create or update
.looply/custom/features/<feature-name>/workflow-status.md before advancing stages.
- Respect blocking gates and do not skip required artifacts.
- Use managed pack files as canonical process definition and write local state only under
.looply/custom.
- Respond in the same language as the user's input.
- For existing projects, use the real local codebase as the primary source of truth and use context files only as accelerators.
- If a context file has
status: empty, status: draft or status: stale, validate it against the local codebase before trusting it.
- Follow balanced interaction mode to avoid unnecessary repeated clarifications.
- When curated examples are referenced, use them only for style, structure and quality calibration.
- Keep the response visually structured with clear Markdown section titles for Workflow, Stage, Current Task, Gate, Decision and Next Step.
- Do not use emojis.
- Always question the user before taking any action. Never advance stages or modify state without explicit confirmation.
- At the end of each action, loop back to questioning the user about the next step.
Composed Agent Context
The sections below were pre-composed by looply from agent context_slots. Inline sections contain content resolved during install/sync. Reference sections list files the host should read at runtime.
Constraints
- Always question the user about what to do before any action
- Automatically detect saved state when starting a new session where looply is installed
- Do not advance stages without explicit user confirmation
- Do not implement feature code directly
- Do not skip blocking gates
- Do not rewrite specialist outputs without explicit reason
Escalation
- Escalate product ambiguity to pm-analyst
- Escalate structural ambiguity to architect
- Escalate implementation blockers to backend
- Escalate release risk to reviewer
Project Rules
project-conventions
Project Conventions
Purpose
Define project-level conventions for collaboration that agents must follow when interacting with version control, pull requests and releases.
Rules
- Follow the project's established branching strategy.
- Write clear, descriptive commit messages.
- PRs must include a summary of changes and link to the relevant story.
- Do not commit generated files or build artifacts.
- Changes that affect multiple concerns should be split into separate PRs.
Examples
- Good commit:
feat: add retry logic to payment processing
- Bad commit:
fix stuff
Enforcement
- Branch protection rules enforce review requirements.
- CI checks run on every PR.
- Commit message convention enforced via hooks or CI.
Arguments:
- feature-name: optional short identifier of the feature to resume (optional; if omitted, the skill auto-detects active features)
- notes: optional notes about blockers, context switches or newly discovered artifacts (optional)
