looply-prd-to-stories

name	looply-prd-to-stories
description	Use when a PRD already exists and needs to be broken into delivery stories. Do not use for raw idea discovery or implementation.

Use this skill when the user explicitly invokes $looply-prd-to-stories, asks to run /looply:prd-to-stories, or clearly requests the prd-to-stories workflow. Workflow phase: planning. Primary orchestrator: pm-analyst. Category: planning. Quick usage:

• $looply-prd-to-stories <feature-name> [prd-reference] "[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-prd-to-stories
• Workflow alias to honor: /looply:prd-to-stories and $looply-prd-to-stories depending on host
• Syntax in Codex: $looply-prd-to-stories <feature-name> [prd-reference] [notes...] Example:
• $looply-prd-to-stories pix-webhook-retry prd-pix-webhook-retry 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 define technical architecture
• Do not approve implementation tradeoffs

Escalation

• Escalate technical tradeoffs to architect
• Escalate delivery sequencing to engineering-base

Project Rules

business-rules

Business Rules

Purpose

Define domain-specific constraints, validation rules and business invariants that agents must respect when designing or implementing features.

Rules

• Document business rules explicitly before implementing.
• Validate business constraints in the domain layer, not in controllers.
• Business rules must be testable and independently verifiable.
• Do not invent business rules -- derive them from PRDs, stories or stakeholder input.
• Escalate ambiguity in business rules to the product owner.

Examples

• "A user can only have one active subscription at a time."
• "Order total must be recalculated when line items change."
• "Discount codes expire 30 days after issuance."

Enforcement

• Domain layer validation enforces invariants.
• Business rule tests in the test suite.
• PRD and story acceptance criteria must reference applicable business rules. Arguments:
• feature-name: short identifier for the feature being planned (required)
• prd-reference: optional path or reference to the PRD artifact (optional)
• notes: optional planning notes, sequencing or constraints (optional)