looply-prototype

name	looply-prototype
description	Use to create a disposable prototype and validate design decisions before implementation. Integrates as optional gate in planning or early delivery.

Use this skill when the user explicitly invokes $looply-prototype, asks to run /looply:prototype, or when design decisions need validation before full implementation. Workflow phase: planning. Primary orchestrator: delivery-orchestrator.

Quick usage:

• $looply-prototype <feature-name> <scope-reference> "[validation-criteria]"

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
• Custom overrides: ../../../../.looply/custom
• Execution hints: ../../../../.looply/state/execution-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

Usage:

• Explicit mention: $looply-prototype
• Workflow alias to honor: /looply:prototype
• Syntax in Codex: $looply-prototype <feature-name> <scope-reference> "[validation-criteria]"

Example:

• $looply-prototype pix-webhook-retry retry-queue "validate retry queue latency with 1000/s volume"

When to use:

• Uncertain design decision (new technology, complex integration, performance trade-off)
• Before committing to full implementation
• To validate technical hypotheses with real but disposable code

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.

Prototype Flow

Stage 1: Scope Definition

1. Define the prototype scope:
   • What to validate (specific hypothesis)
   • Prototype acceptance criteria
   • What NOT to include (out of scope)
2. Document in .looply/custom/features/<feature-name>/prototype-scope.md

Stage 2: Prototype Build

1. Create isolated code on a separate branch: prototype/<feature-name>-<timestamp>
2. Focus only on the validation defined in scope
3. Ignore production best practices (tests, documentation, error handling)
4. Code must be functional but disposable

Stage 3: Prototype Validate

1. Run the prototype against defined criteria
2. Collect evidence (logs, metrics, results)
3. Compare results with acceptance criteria
4. Document in prototype-report.md

Stage 4: Decision Gate

Generate report and present decision:

"Prototype completed. Validation results:"

Report: .looply/custom/features/<feature-name>/prototype-report.md

# Prototype Report

## Hypothesis
[The hypothesis tested]

## Results
- Criterion 1: [PASS/FAIL]
- Criterion 2: [PASS/FAIL]

## Evidence
[Logs, metrics, results]

## Decision
[v] Design validated - proceed with implementation
[x] Design invalid - revise approach

Post-decision action:

• If validated: delete prototype code, keep only the report
• If invalid: delete prototype code, revise design, suggest new approach

Execution rules:

1. Start by reading the workflow playbook and the feature state file if it exists.
2. If the user asked for help, explain syntax, arguments, example, expected output and next step without mutating state.
3. All generated code is disposable. Do not commit to main branch.
4. The validation report is the only preserved artifact.
5. Create separate branch prototype/<feature-name>-<timestamp>.
6. Delete prototype code after final decision.
7. Use managed pack files as canonical process definition and write local state only under .looply/custom.
8. Respond in the same language as the user's input.
9. For existing projects, use the real local codebase as the primary source of truth and use context files only as accelerators.
10. If a context file has status: empty, status: draft or status: stale, validate it against the local codebase before trusting it.
11. Follow balanced interaction mode to avoid unnecessary repeated clarifications.
12. Keep the response visually structured with clear Markdown section titles.
13. Do not use emojis.

---

Composed Agent Context

The sections below were pre-composed by looply from agent context_slots.

Constraints

• All prototype code is disposable - do not commit to main branch
• Focus only on the validation defined in scope
• Do not include error handling, tests or production documentation
• Preserve only the validation report

Escalation

• Escalate design ambiguity to architect
• Escalate product decisions to pm-analyst Arguments:
• feature-name: short identifier for the feature (required)
• scope-reference: what to prototype and validate (required)
• validation-criteria: specific criteria to validate against (optional)