looply-triage

name	looply-triage
description	Use to classify bugs and issues by severity using looply artifacts as primary source. Recommends whether the problem requires formal investigation or immediate action.

Use this skill when the user explicitly invokes $looply-triage, asks to run /looply:triage, or when triaging bugs/issues before formal investigation. Workflow phase: diagnosis. Primary orchestrator: problem-investigator.

Quick usage:

• $looply-triage <feature-name> <scope-reference> "[problem-description]" "[constraints...]"

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
• Code context: ../../../../.looply/state/code-context.json
• Knowledge graph: ../../../../.looply/state/knowledge-graph.json

Usage:

• Explicit mention: $looply-triage
• Workflow alias to honor: /looply:triage
• Syntax in Codex: $looply-triage <feature-name> <scope-reference> "[problem-description]" "[constraints...]"

Example:

• $looply-triage pix-webhook-retry payments-api "webhooks fail intermittently during peak hours" "verify race condition"

When to use:

• User reports a bug without clear severity context
• Before deciding between formal investigation (problem-evaluator) or direct action
• To classify multiple bugs in backlog and prioritize

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.

Triage Flow

Stage 1: Artifact Triage

1. Read relevant looply artifacts:
   • feature's workflow-status.md (if it exists)
   • associated stories and specs
   • code-context.json for affected modules
   • knowledge-graph.json for dependencies
2. If artifacts are insufficient, inspect the codebase directly.

Stage 2: Severity Classification

Classify using the P0-P3 scale:

P0 - Critical: system unavailable, data loss, security failure P1 - High: core functionality broken, no workaround P2 - Medium: functionality partially affected, workaround available P3 - Low: cosmetic, low impact, rare edge case

Classification criteria:

• End-user impact
• Core vs peripheral functionality
• Workaround availability
• Occurrence frequency
• Data or security at risk

Stage 3: Recommendation

Based on severity:

Severity	Action
P0	Escalate immediately to problem-evaluator
P1	Escalate to problem-evaluator with full context
P2	Recommend problem-evaluator OR direct action (if cause is obvious)
P3	Recommend direct action or backlog

Stage 4: Triage Decision

Generate report in .looply/custom/features/<feature-name>/triage-report.md:

# Triage Report

## Classification
Severity: P1

## Analysis
- Artifacts consulted: stories, code-context.json
- Affected modules: payments-api, webhook-dispatcher
- Probable cause: race condition in consumer

## Recommendation
Escalate to problem-evaluator focusing on race condition in webhook consumer

Execution rules:

1. Start by reading the workflow playbook and the feature state file if it exists.
2. Run looply refresh-code-context --check to ensure code-context is fresh.
3. If the user asked for help, explain syntax, arguments, example, expected output and next step without mutating state.
4. Classify severity using looply artifacts as primary source.
5. If cause is obvious from artifacts and severity is P2 or P3, recommend direct action instead of escalating.
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.
13. Do not use emojis.

---

Composed Agent Context

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

Constraints

• Do not implement fixes during triage
• Do not invent causes without evidence from artifacts or codebase
• Use looply artifacts as primary source before deep diving into codebase

Escalation

• Escalate P0/P1 to problem-evaluator
• Escalate product ambiguity to pm-analyst
• Escalate implementation-level issues to backend Arguments:
• feature-name: short identifier for the feature or module being triaged (required)
• scope-reference: module, service or component under investigation (required)
• problem-description: description of the problem or observed symptom (optional)
• constraints: optional constraints, boundaries or specific areas to investigate (optional)