looply-next

name	looply-next
description	Use to show the next recommended step for a persisted feature workflow without restarting the whole flow.

Use this skill when the user explicitly invokes $looply-next, asks to run /looply:next, or clearly requests the workflow-status workflow. Workflow phase: status. Primary orchestrator: delivery-orchestrator. Category: navigation. Quick usage:

• $looply-next <feature-name> [session-label] "[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
• Context ledger: .looply/custom/features//context-ledger.db (SQLite, use looply ledger read/append/summary)
• 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
• Knowledge graph: ../../../../.looply/state/knowledge-graph.json (use para impacto, dependencias entre modulos e schema de banco) Usage:
• Explicit mention: $looply-next
• Workflow alias to honor: /looply:next and $looply-next depending on host
• Syntax in Codex: $looply-next <feature-name> [session-label] [notes...] Example:
• $looply-next pix-webhook-retry backend-afternoon 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. Execution rules:

1. Start by reading the workflow playbook, the host status contract if it exists, the feature state file if it already exists, and the context ledger via looply ledger read --feature <feature-name> [--summary-only].
2. If the user asked for help, explain syntax, arguments, example, expected output and next step without mutating state.
3. Create or update .looply/custom/features/<feature-name>/workflow-status.md before advancing stages.
4. After completing a workflow stage, append decisions, rationale, constraints and risks via looply ledger append --feature <feature-name> --stage <stage> --decision <text> --rationale <text> --constraints <text> --risks <text>. Update the summary via looply ledger summary update --feature <feature-name> --text <summary>.
5. Respect blocking gates and do not skip required artifacts.
6. Use managed pack files as canonical process definition and write local state only under .looply/custom.
7. Respond in the same language as the user's input.
8. For existing projects, use the real local codebase as the primary source of truth and use context files only as accelerators.
9. If a context file has status: empty, status: draft or status: stale, validate it against the local codebase before trusting it.
10. Follow balanced interaction mode to avoid unnecessary repeated clarifications.
11. When curated examples are referenced, use them only for style, structure and quality calibration.
12. Keep the response visually structured with clear Markdown section titles for Workflow, Stage, Current Task, Gate, Decision and Next Step.
13. Do not use emojis.

---

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

• 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: short identifier of the feature being resumed (required)
• session-label: optional label used to distinguish parallel sessions for the same project or feature (optional)
• notes: optional notes about blockers, context switches or newly discovered artifacts (optional)