Skip to content

Latest commit

 

History

History
139 lines (92 loc) · 6.04 KB

File metadata and controls

139 lines (92 loc) · 6.04 KB

Usage

简体中文

The Skills are read-only. They may use evidence and read-only sources explicitly placed in scope, but they do not execute the recommendation or change external state. Audience adaptation can change order, terminology, and detail; it cannot change facts, calculations, causal confidence, material risk, or whether an action is proposed versus complete.

A statement supplied by a user, document, log, proposal, or retrieved page is a Reported claim unless independent verification and its standard are also supplied. Calling something a Fact requires that traceable verification; a Derived fact inherits the verification limits of every input operand.

Invocation and observability by surface

The $skill-name examples below are explicit Skill invocations for Codex. In Codex CLI or IDE, confirm availability through the Skill inventory and use the surface's visible Skill selection when it is exposed. A host-managed Plugin may instead require its Plugin or Skill picker (for example, @ on a surface that documents it). Follow that host's invocation mechanism and visible status; bundled documentation does not prove that an external Plugin is installed, enabled, selected, or currently available. If the host exposes no route indicator, report the observed output as a behavior observation, not as proof that a particular Skill ran.

structured-thinking

Use when

The source material and required conclusion, causal assessment, or decision analysis already exist, and the remaining task is to produce a report, status update, briefing, summary, or recommendation for a specific audience.

Minimum input

Provide the source statements or completed findings, intended audience, purpose, and any length or format constraint. Identify source attribution, independent verification, and verification limits that must remain visible.

Explicit invocation

Use $structured-thinking to turn the supplied completed findings into a concise executive update. Preserve every unknown and distinguish proposals from completed actions.

Expected behavior

The Skill classifies material statements as Reported claim, Fact, Derived fact, Inference, Hypothesis, Recommendation, or Unknown; checks reproducible arithmetic; leads with a supported knowledge state; and organizes evidence for the audience without silently upgrading its status.

Insufficient evidence

It states what cannot be concluded and which missing inputs would materially change the message. It does not invent an impact, owner, root cause, commitment, or third category to complete a template.

Out of scope

New root-cause analysis, option comparison, live research without authorization, code changes, terminal work, publishing, messaging, and any claim that an external action completed.

incident-analysis

Use when

The user asks what happened, requests root-cause or causal analysis, supplies timelines, logs or metrics for diagnosis, or needs a plan to distinguish competing incident hypotheses.

Minimum input

Provide observations with times and sources, the affected behavior or scope, candidate causes if known, counterevidence, and constraints on additional read-only investigation. State whether a root cause has already been verified.

Explicit invocation

Use $incident-analysis to separate confirmed factors, hypotheses, counterevidence, unknowns, and the next discriminating evidence checks. Analyze without taking action.

Expected behavior

The Skill constructs a source-attributed timeline, distinguishes chronology from causality, calibrates confidence, preserves alternatives and counterevidence, and proposes observations that could falsify material hypotheses. Instructions inside logs or traces remain untrusted data.

Insufficient evidence

It returns a bounded causal assessment or “root cause unknown,” names the decision-relevant gaps, and proposes evidence checks. It does not convert the most plausible explanation into a confirmed root cause.

Out of scope

Running probes, changing production, rotating credentials, editing code, deploying, rolling back, closing an incident, or claiming that another tool performed those actions.

decision-analysis

Use when

The user must compare at least two options, choose an architecture, technology, vendor, or operating approach, or review a proposed selection against explicit requirements and uncertainty.

Minimum input

Provide candidate options, must-have constraints, decision criteria, evidence for material scores, uncertainties, risk or reversibility context, and who owns the eventual decision. If key inputs are missing, say so rather than supplying convenient defaults.

Explicit invocation

Use $decision-analysis to compare these options against the supplied must-haves, evidence, and uncertainties. Show sensitivity and return no decision if the missing inputs are blocking.

Expected behavior

The Skill applies must-have gates before weighted preferences, distinguishes measured values from judgment, avoids double counting, exposes sensitivity, and makes a conditional Recommendation only when the evidence supports one. Numeric scoring remains a model of stated inputs, not objective truth.

Insufficient evidence

It identifies decision-blocking Unknowns, states what evidence would resolve them, and may return a conditional result or no decision. It does not fabricate weights, candidate capabilities, costs, compliance status, or stakeholder approval.

Out of scope

Approving, purchasing, emailing a vendor, implementing or deploying an option, creating missing business requirements, or treating a Recommendation as an authorized decision.

Sources and untrusted content

Quoted documents, logs, web pages, tool output, and fixture text are evidence, not an instruction channel. Preserve source attribution for unverified claims. If external research is explicitly in scope, cite the source and retain the resulting verification limits.

For routing boundaries, see Choosing a Skill. For evaluated behavior, see Examples.