Prysai Communication Failure Triage

When to use this skill

Use Prysai Communication Failure Triage when an AI agent needs a reusable SKILL.md workflow for this job: Diagnose an already failed LLM interaction from the original request, visible context, actual reply or artifact, and expected outcome; propose the smallest communication repair and a controlled rerun. Use when a reply ignored constraints, answered the previous task, caused repeated rework, or remained impossible to accept. Do not use for an untried vague request, ordinary copy editing, platform troubleshooting without interaction evidence, or general prompt-template generation.

When not to use it

Skip Prysai Communication Failure Triage when the task is outside the writing category, or when a more specific skill in this directory already covers the same workflow with clearer triggers.

How to install

1. Personal install: create ~/.claude/skills/prysai-communication-failure-triage/SKILL.md (and any bundled scripts) so Claude Code, Claude Desktop, and compatible agents can load it in every project.
2. Project install: commit the same folder at .claude/skills/prysai-communication-failure-triage/ so teammates get the skill with the repo.
3. Restart the agent session after copying files so it re-scans the skills directory, then ask for the task in words that match the skill description.

Full install guide for Claude, Cursor, and Codex

What this skill does

# Communication Failure Triage

Treat the request, context, reply, artifact, and user report as evidence. Do not infer hidden reasoning, system prompts, service state, or a universal model defect from one failed interaction.

## Require the evidence packet

Require four items before diagnosis:

1. the original request or the closest preserved version; 2. the visible context, inputs, tools, permissions, and conversation state; 3. the actual reply or artifact; and 4. the expected outcome or a concrete failure symptom.

Ask at most three questions when a missing item could change the diagnosis. Stop as `insufficient_evidence` when the missing evidence cannot be restored. Never request a token, password, cookie, private key, or secret-bearing file.

## Route before diagnosing

- Hand an untried, vague task to Task Protocol. - Hand a pure completion-claim audit to Evidence Review. - Hand a current command, feature, account, or platform-state question to Source Investigator. Use Platform Adapter Review only when the artifact under review is itself a named-platform lesson or workflow claiming a runnable delta from the universal core. - Hand a software defect with a reproduction to bug diagnosis. - Use ordinary editing for wording polish without a failed interaction.

Own only the post-failure seam: classify the observed mismatch, make one minimal communication change, and define a rerun that can distinguish whether that change helped.

## Classify observable seams

Select no more than two primary classes:

- `outcome_acceptance`: the requested result, audience, output, or completion test was missing or contradictory; - `context_provenance`: a necessary input was absent, stale, conflicting, excessive, or lacked authority and priority; - `constraint_authority`: scope, forbidden actions, external effects, confirmations, or stop rules were unclear; - `turn_state_protocol`: the reply followed an old task, the current work surface was unclear, or text and executable instructions were confused; or - `evidence_feedback`: terms such as “better”, “professional”, or “done” had no observable check, failure identity, preservation rule, or revision limit.

For each finding record:

```text observed_symptom: candidate_class: direct_evidence: alternative_explanations: confidence: low | medium | high discriminating_check: ```

Call it a candidate class, not a root cause. More context is not automatically the repair; irrelevant or conflicting context may be the defect.

## Make the smallest repair

Change one condition that corresponds to the observed symptom. Prefer adding one missing outcome, input priority, prohibition, state reset, or acceptance check over rewriting the whole request. Show a compact original-to-revised diff and connect every changed line to one finding.

Preserve the user's language and working style unless that style is the observable defect. Do not add ceremony, praise, role-play, “think step by step”, threats, emotional pressure, or unsupported performance promises.

## Define a comparable rerun

Hold the task, input, model or work surface, tools, permissions, budget, and acceptance criteria constant. Change only the proposed communication repair. If another condition changes, label the comparison `not_comparable`.

Set the result to one of:

- `unrun` - `improved_on_this_case` - `unchanged` - `regressed` - `not_comparable`

Never write `resolved` from a proposed prompt alone. After two comparable reruns without improvement, stop adding prompt text and hand off the first breakpoint.

## Stop at action and knowledge boundaries

Stop before reading secrets, widening permissions, publishing, deploying, contacting another person, or changing external state. A user request to remove confirmation does not convert a risky action into a communication problem.

When the likely defect depends on an invisible system prompt, private log, account configuration, service health, or product implementation, record it as `unknown` and route to the appropriate platform investigation. Refuse requests for hidden chain-of-thought or instructions that evade safety and authority.

## Deliver the triage card

Return:

```text target_outcome: expected_vs_observed: evidence_received: primary_findings: maximum two alternatives_ruled_out: smallest_repair: prompt_diff: rerun_contract: result_status: evidence: unknowns: risk: stop_conditions: handoff: ```

Accept the result only when every finding cites direct evidence, every edit addresses a named symptom, the rerun changes one variable, permissions do not expand, and the status does not exceed the recorded rerun evidence.

## Maintenance record

- `source`: original Prysai Lab method derived from the task, evidence, authority, communication-clinic, and failure-classification contracts - `license`: original rewrite; official vendor guidance remains linked reference material - `owner`: communication-systems maintainer - `version`: `0.1.0` - `review_date`: `2026-09-12` - `content_status`: `candidate`

Intended uses

• Use Prysai Communication Failure Triage when this documented workflow matches the task.