Collaboration pattern

Collaboration Pattern

Overview

Use this pattern when missing or contradictory information could change an important decision. It helps an AI collaborator distinguish what must be checked now from what can be handled with a small reversible choice.

Do not turn every ambiguity into an investigation. The question is whether the unknown can materially change scope, architecture, data shape, validation, cost, safety, or reversibility.

Decision Loop

Understand the current decision
  -> identify unknowns that could change it
  -> decide whether a factual probe is required
  -> choose an appropriate specialist capability
  -> act under that capability's rules
  -> verify material claims
  -> reconsider when evidence changes

Map Only Decision-Relevant Uncertainty

• Known knowns: confirmed goals, evidence, constraints, and decisions.
• Known unknowns: open questions already recognized.
• Unknown knowns: tacit preferences, standards, workflow knowledge, or customer language that examples, observation, prototypes, or interviews can reveal.
• Unknown unknowns: hidden constraints, unenumerated behavior, alternatives, edge cases, and blind spots.

This map is a thinking aid, not a mandatory report. Show only distinctions that change the next step.

Apply the Probe Gate

REQUIRED REFERENCE: Read references/probe-protocol.md when a probe triggers.

Probe before relying on a claim when:

• a decision depends on an unverified file set, schema, API contract, source set, runtime behavior, or customer workflow;
• an error could materially change scope, architecture, data shape, validation, cost, safety, or reversibility;
• an acceptance criterion needs exact values that have not been observed;
• new evidence contradicts a load-bearing premise; or
• a material blind spot can be checked cheaply against reality.

Use a labeled conservative default when the unknown is small, reversible, and isolated. Do not probe when checking would cost more than making and clearly labeling that choice.

A load-bearing claim without enough evidence remains UNKNOWN. Do not choose, recommend, provisionally select, or claim completion when that choice depends on the unresolved claim. Define only a reversible information-gathering step that does not commit the decision.

Route by Capability

Situation	Portable capability
Tacit or unclear needs	Discovery or design exploration
Unknown customer workflow or demand	Interviews, observation, and purchasing evidence
Agreed direction	Implementation planning
Unexpected failure	Systematic diagnosis
Substantial work appears complete	Independent review and verification
Claims depend on external facts	Research and source verification

Read references/specialist-routing.md for small fallbacks and optional client mappings.

If the needed specialist workflow is available, use it under its own rules. If it is absent, name the missing capability and use the documented minimum fallback. Stop when the missing capability makes a defensible decision impossible. Never claim that an unavailable workflow ran.

Do not reproduce complete planning, debugging, research, interviewing, or review systems inside this Skill.

Reconsider Existing Decisions

Approval does not make a contradicted premise true. When evidence changes:

1. name the premise that changed;
2. identify the requirements, tests, plans, or decisions that depend on it;
3. preserve unaffected work;
4. return affected work to probing or design;
5. verify the revised decision before continuing.

When customer workflow, buyer, budget, alternatives, or willingness-to-pay evidence is load-bearing and absent, keep the product definition unresolved. A neutral problem hypothesis and discovery plan are allowed; a settled feature set or roadmap is not.

For all, none, complete, or similar set-wide claims, enumerate the claimed set and check every relevant member. If a wider set is unknown, report exactly the enumerated or observed members and leave the wider status unresolved. A bounded completion claim is allowed only for an explicitly identified subset whose every member was verified. Do not claim the wider set complete or invent after-the-fact labels such as agreed or in-scope to manufacture a subset.

Output Contract

Default to a short decision-focused result:

Current decision:
Material unknowns:
Probe required: yes/no — why
Clarify now:
Handle conservatively:
Recommended capability:

Omit fields that do not help the next decision. Use the full uncertainty map only when it improves the choice.

Common Mistakes

Mistake	Correction
Investigating every small ambiguity	Choose and label a reversible default
Designing from a plausible schema	Inspect a real instance first
Turning an idea into an MVP without customer evidence	Keep a problem hypothesis and gather workflow/purchasing evidence
Preserving a plan after its premise fails	Reopen only the affected decisions
Naming a specialist that is not installed	Use a documented fallback or stop
Claiming completion from samples	Enumerate the claimed set; bound completion to fully verified members

References

• references/probe-protocol.md — enumerate-and-verify procedure.
• references/specialist-routing.md — portable fallbacks and optional client mappings.
• references/example-prompts.md — concise prompts for common decision boundaries.