triage

triage — Phase 2 Orchestration

Version: 3.0.0 Phase: 2 — Triage MCP Tools: pattern-match, case-get (primary when MCP server available) Gate: confidence ≥ 70% (see skills/gate/SKILL.md) Reasoning Libraries: skills/curator/SKILL.md, skills/gate/SKILL.md

---

Status Output (MANDATORY — print before any tool call)

At the very start of execution, output this exact block:

[ Phase 2 — Triage ]
Tools: pattern DB search (jq), case context (websearch/SF CLI)

Then before each tool call, output a one-liner: → {tool-name} {key parameter}

---

Purpose

Execute Phase 2 triage. Search the local pattern database for symptom matches, retrieve SF case context, correlate results, register verified claims, and check the Phase 2 gate.

---

Loop Awareness

If this skill is invoked via SP-LOOP-2 (loop re-triage), the spawn prompt will contain a <loop_context> block. Before executing any step, read it:

loop_iteration        ← current iteration number
previous_pattern_ids  ← JSON array of pattern IDs already found (exclude these)
refined_symptom       ← use this instead of the original {symptom} for Step 2
loop_reason           ← why the loop was triggered (guides keyword strategy)

If no <loop_context> block is present, this is a first-pass triage — proceed normally.

Loop keyword strategy (when refined_symptom is provided):

• Use refined_symptom as the primary search term
• Also try 2-3 component-level keyword variations extracted from Phase 3/4 evidence
• If all variations return zero new patterns → set evidence_ceiling_hit: true in inv_context.json and mark gate_status: "CEILING" in return JSON

---

Procedure

Step 1 — Retrieve SF case context

Primary (MCP available):

call_tool({ operation: "execute", tool: "case-get",
  params: { case_number: "{sf_number}" }})

Fallback (native): Use case context already gathered in Phase 0-1, passed in the spawn prompt <case_context> block. If missing, ask Main Claude via the HITL checkpoint before proceeding.

Extract: customer name, product, version, build, symptom description, severity. Write to inv_context.json case and environment sections.

Step 2 — Run pattern matching

Primary (MCP available):

call_tool({ operation: "execute", tool: "pattern-match",
  params: { symptom: "{symptom}", product: "{product}", version: "{version}" }})

Fallback (native) — weighted keyword search via the pattern search script:

# Primary native: weighted scoring across symptoms, match_patterns, error_pattern
python3 "${CLAUDE_PLUGIN_ROOT}/scripts/pattern_search.py" \
  "{refined_symptom_or_symptom}" \
  --product "{product}" \
  --top 10 \
  --db "${CLAUDE_PLUGIN_ROOT}/databases/cappy-cache_latest.json" \
  --json

The script scores patterns by:

• Phrase match in symptoms (40pts) > token overlap in symptoms (12pts/token)
• Match in match_patterns[] error codes (20pts/token)
• Match in error_pattern field (15pts/token)
• Confidence boost: DEFINITIVE ×1.5, STRONG ×1.2, MODERATE ×1.0

Loop iterations: Pass --product to narrow results. The script auto-excludes zero-score patterns so previous IDs don't need explicit exclusion — just use the refined symptom.

Evidence ceiling check (loop iterations only): If the script returns zero results, retry with 2 alternative keyword sets derived from error messages or component names found in Phase 3 evidence. If all 3 attempts return zero new patterns:

jq '.investigation.evidence_ceiling = true' inv_context.json > tmp.json && mv tmp.json inv_context.json

Fallback-of-fallback (if Python unavailable): raw jq keyword search:

DB="${CLAUDE_PLUGIN_ROOT}/databases/cappy-cache_latest.json"
SYMPTOM="{refined_symptom_or_symptom}"
PRODUCT="{product}"
jq --arg s "$SYMPTOM" --arg p "$PRODUCT" '
  .patterns[] | select(
    ($p == "" or $p == "ALL" or .product == $p or .product == "ALL") and
    ((.symptoms // [] | any(ascii_downcase | test($s | ascii_downcase))) or
     (.match_patterns // [] | any(ascii_downcase | test($s | ascii_downcase))))
  ) | {id, product, confidence, symptoms: .symptoms[:2]}
' "$DB"

Step 3 — OBSERVE

List every pattern returned. For each record:

• id, confidence, product, symptoms[], match_patterns[]

Do not interpret — list exactly what the query returned.

Step 4 — CORRELATE patterns with symptom

Group patterns into:

• STRONG — symptom overlap >50% with reported symptom AND correct product
• PARTIAL — overlaps but incomplete or product is ALL (not specific)
• WEAK — tangential match only

Also search JIRA for related engineering tickets:

mcp__mcp-gateway__mcp_jira__jira_search({
  jql: "project = XSUP AND text ~ \"{symptom}\" ORDER BY updated DESC",
  fields: "summary,status,resolution",
  limit: 5
})

Step 4b — Search Cortex documentation

Always run this in parallel with pattern matching. Cortex docs often contain the authoritative answer for documentation gaps, deprecated features, and version-specific behavior changes — categories that may have zero patterns in the DB.

~/.cappy/tools/web-fallback/websearch.sh "site:docs-cortex.paloaltonetworks.com {symptom} {product}" 5

Record any doc results that:

• Describe the symptom behavior as expected/documented
• Reference a deprecation or UI change that matches the symptom
• Provide a setup procedure that may differ from what the customer followed

These doc findings feed directly into the confidence score (TERTIARY evidence) and issue classification. A doc match confirming a deprecation or behavior change is sufficient for product_bug or known_issue classification even at low pattern confidence.

Also run in parallel — Similar TAC cases (KCS precedent):

SF CLI (closed TAC cases — primary):

SANDBOX_OK=$(docker ps --filter name=cappy-client --format "{{.Status}}" 2>/dev/null | grep -c "Up")
if [ "$SANDBOX_OK" -gt 0 ]; then
  docker exec cappy-client sf data query \
    --query "SELECT CaseNumber, Subject, Product__c, Status, Cause__c, Resolution_Steps__c FROM Case WHERE (Subject LIKE '%{symptom}%' OR Description LIKE '%{symptom}%') AND Status = 'Closed' LIMIT 5" \
    --target-org panw --json 2>/dev/null
fi

If auth is expired: ~/.cappy/tools/sandbox-auth.sh or sf org login web -a panw --instance-url https://paloaltonetworks.my.salesforce.com

Fallback (sandbox unavailable or auth expired):

mcp__mcp-gateway__mcp_jira__jira_search({
  jql: "project IN (XSUP, XSOAR) AND text ~ \"{symptom}\" AND status = Closed ORDER BY updated DESC",
  fields: "summary,status,resolution",
  limit: 5
})

Also run — TAC playbooks and KCS articles (Confluence):

mcp__mcp-gateway__confluence__confluence_search({
  query: "{symptom} {product}",
  limit: 10
})

Fallback (native):

mcp__mcp-gateway__confluence__confluence_search({
  query: "{symptom} {product}",
  limit: 10
})

A resolved similar case or KCS article that documents the same root cause raises confidence directly to STRONG — cite it as SECONDARY evidence.

Step 5 — Register claims (Chain-of-Verification per skills/curator/SKILL.md)

For each STRONG or PARTIAL pattern:

<claim id="C-{N}">
  STATEMENT: "Pattern {id} matches symptom because {reason}"
  <verify>
    Q: Do this pattern's symptoms overlap with the reported symptom?
    A: {specific symptom overlap, yes/no}
    Q: Is this pattern scoped to the correct product?
    A: {product check}
  </verify>
  STATUS: VERIFIED | REJECTED
</claim>

Register only VERIFIED claims. REJECTED claims are discarded.

Step 6 — Derive confidence score

If pattern-match (MCP) returns an overall_confidence field, use it directly.

Otherwise derive: (STRONG_count × 1.0 + PARTIAL_count × 0.5) / max(total_patterns_searched, 1) × 100

Cap at 95% unless a DEFINITIVE-confidence pattern matches exactly.

Step 7 — Check Phase 2 gate (per skills/gate/SKILL.md)

IF confidence ≥ 70%: gate PASSES → return result to Main Claude.

IF confidence < 70%:

• Identify which patterns scored lowest and why
• Consider refining symptom keywords and re-running the jq query
• Recovery options:
  1. Refine symptom terms and re-run
  2. Request more context from customer before proceeding
  3. Proceed at low confidence with explicit caveat in inv_context.json

---

Return Format

{
  "phase": 2,
  "gate_status": "PASS | FAIL | CEILING",
  "confidence_score": 0,
  "threshold": 70,
  "patterns_found": [
    { "id": "P-XXX", "confidence": "DEFINITIVE | STRONG | MODERATE", "match_strength": "STRONG | PARTIAL | WEAK" }
  ],
  "patterns_found_ids": ["P-XXX"],
  "sf_context": { "customer": "...", "product": "...", "version": "...", "severity": "..." },
  "claims_registered": 0,
  "claims_rejected": 0,
  "evidence_ceiling_hit": false,
  "loop_iteration": 0,
  "recommendation": "Proceed to Phase 3 | Gate blocked: {reason} | Ceiling: no new patterns found",
  "recovery_options": []
}

patterns_found_ids accumulates across loop iterations — handoff reads inv_context.json → investigation.all_pattern_ids_found[] (a running list) and passes it to SP-LOOP-2 as {previous_pattern_ids_json} to prevent re-matching.

Do NOT proceed to Phase 3. Return this JSON to Main Claude.