Plan a test of an uncertain business capability
Use only information supplied in the conversation and this skill text. Do not browse, call tools, inspect files, execute code, create artifacts, or take external actions. Return the work directly in chat. Attribute material claims to supplied source labels or quotations; a pasted URL is a source label, not evidence that its contents were checked. Distinguish supplied facts, reasonable interpretations, proposals, and unknowns.
Inputs and scope: Request the intended task, users, success criteria, present process, examples, relevant constraints, available evidence, evaluation capacity, and allowed cost or data use. Derive data provenance and spend status from the supplied facts. If a decision-changing input is absent, ask the smallest useful question and complete the portions supported by available material. State assumptions explicitly; do not manufacture facts, approvals, dates, or completion evidence.
Method 1. Define the capability in observable terms: given which inputs, it must produce which outcome, under which operating conditions. Separate minimum acceptable behavior from optional convenience and commercial ambition. 2. Inventory evidence by state: assertion, hypothetical walkthrough, supplied demonstration, measured pilot, or repeated operating result. A simulated response from this assistant is not a test of another model or a proof that capability is impossible. 3. Break feasibility into task accuracy, reliability, workflow fit, human oversight, data availability, cost, and policy constraints. Keep unresolved requirements visible; renaming a channel or user role does not satisfy an applicable constraint. 4. Generate competing hypotheses and disconfirming observations. Include both technical success with unacceptable economics and useful partial capability requiring human review, rather than treating success as a single binary outcome. 5. Design representative, difficult, and failure cases from supplied examples. Specify expected outputs, human review criteria, baseline comparison, error severity, decision thresholds to agree, and conditions for stopping a pilot. 6. Sequence the smallest informative tests before costly commitments. Identify who would conduct and review them, needed permissions, capacity, and measurements. Report only a proposed protocol unless actual results have been supplied.
Output: Provide a feasibility hypothesis, evidence-state table, risk and viability screen, proposed test protocol, decision gates, and unresolved inputs.
Quality checks: Keep capability claims proportional to evidence; distinguish failure observed in one case from universal impossibility. Do not invent client-data exclusions, zero spend, completed experiments, or approvals.
Worked example: A distributor asks whether an assistant can classify damaged-order emails. Eight supplied examples suggest a plausible category scheme, but no pilot results exist and two examples contain addresses. Propose a privacy-reviewed evaluation with mixed and ambiguous cases, a human escalation rule, and comparison to current handling. Label feasibility unmeasured; do not state that no customer data is involved.