Appropriate use
Use for customer-reported device, browser, content, network, account, or environment problems.
Scope and intent
A controlled workflow specification
This page defines the behaviour, controls, evidence, and outputs required from the skill. It does not claim that a language model can enforce security or correctness by wording alone.
Non-goals
Do not use to access a customer tenant, data, device, or network beyond explicit authorisation or to dismiss a report simply because the laboratory cannot reproduce it.
- 8
- versioned workflow phases
- 4
- explicit approval gates
- 6
- defined result states
- 10
- versioned output artifacts
Material changes to the source, environment, identity, approved actions, or expected behaviour invalidate dependent approvals and require revalidation.
Workflow
The 8 phases
Each phase has explicit inputs and outputs. Approval gates are hard stops bound to exact versions and hashes.
Phase 1: Case and consent preflight Gate 1 · approve case boundary
Resolve the support case revision, authorised data access, customer consent, privacy restrictions, affected account, device, content, and communication owner.
case ID · consent · data boundary · support owner
Phase 2: Environment normalisation
Capture model, OS, firmware, app or player version, account state, role, region, network, proxy, DNS, content type, schedule, orientation, resolution, and recent changes.
customer matrix · unknowns · confidence
Phase 3: Failure signature extraction
Describe the observable symptom, timing, frequency, recovery, last-known-good state, error messages, screenshots, logs, and customer actions without inferring cause.
symptom · trigger · frequency · duration · recovery
Phase 4: Reproduction matrix design Gate 2 · approve tests
Create the smallest set of comparisons that isolates customer-specific variables from product, platform, network, content, and account effects.
same content · same device · known-good content · alternate network · alternate account
Phase 5: Laboratory and approved remote execution
Run controlled comparisons, preserve all attempts, avoid destructive account changes, and clearly separate laboratory evidence from customer-provided evidence.
attempts · differences · evidence · data cleanup
Phase 6: Isolation analysis
Classify whether the signal follows content, device, firmware, network, account, version, configuration, time, or remains unknown.
variable correlation · counterexample · confidence
Phase 7: Outcome and support guidance Gate 3 · confirm response
Prepare a customer-safe conclusion, next diagnostic request, workaround when verified, and product defect proposal when evidence supports it.
reproduced · environment-specific · not reproduced · insufficient information
Phase 8: Publish and preserve case package Gate 4 · publish
Update the support case idempotently, link restricted evidence appropriately, and hand product defects or incidents into the correct workflow.
customer wording · internal detail · handoff · retention
Approval contract
Every gate approves an exact decision object
An approval cannot be reused after its environment, source, action plan, or approved document changes.
| Gate | Decision | Required binding |
|---|---|---|
| 1 | Gate 1 · approve case boundary | Approval stores approver, role, timestamp, context hash, approved document hash, expiry, and invalidation state. |
| 2 | Gate 2 · approve tests | Approval stores approver, role, timestamp, context hash, approved document hash, expiry, and invalidation state. |
| 3 | Gate 3 · confirm response | Approval stores approver, role, timestamp, context hash, approved document hash, expiry, and invalidation state. |
| 4 | Gate 4 · publish | Approval stores approver, role, timestamp, context hash, approved document hash, expiry, and invalidation state. |
Result model
Defined states prevent vague conclusions
Attempt outcomes remain separate from these workflow results. Errors, cancellations, and invalid context are never silently converted into a pass.
REPRODUCED
The customer failure signature was reproduced under matching controlled conditions.
PARTIALLY REPRODUCED
A related symptom was reproduced, but one or more customer-specific aspects remain different.
ENVIRONMENT-SPECIFIC
Evidence links the issue to device, firmware, network, account, content, or configuration conditions.
NOT REPRODUCED
The tested matrix did not reproduce the issue; this is not proof the report is invalid.
INSUFFICIENT INFORMATION
Critical environment or failure details are missing.
THIRD-PARTY RELATED
Evidence points to an external service or dependency.
Evidence contract
Evidence must directly support the claim
Evidence has provenance, capture context, privacy classification, retention, and integrity metadata. A convenient artifact is not automatically sufficient proof.
| Claim | Primary evidence | Required validation |
|---|---|---|
| Customer symptom | Approved screenshots, video, logs, or case text | Privacy and provenance are recorded. |
| Environment | Device and configuration inventory | Unknown values remain unknown rather than guessed. |
| Comparison | Controlled matrix results | Only one or a justified set of variables changes per comparison. |
| Network | Approved connectivity and request evidence | Customer secrets and internal addresses are protected. |
| Content | Source, format, and known-good comparison | Customer content is handled according to consent and retention rules. |
| Outcome | Attempt and isolation summary | Confidence and unreproduced differences are explicit. |
Trust and safety
Controls that must be enforced outside the prompt
These controls belong in the runtime, connector permissions, sandbox, renderer, storage layer, and review process.
Runtime control
Consent boundary
No customer data or tenant access is used outside the recorded authorisation.
Runtime control
Laboratory distinction
A lab success cannot erase a credible customer failure.
Runtime control
Privacy-safe reproduction
Prefer synthetic or customer-supplied minimal content over copying full production data.
Runtime control
No destructive support steps
Clear cache, reset, re-pair, or factory reset require impact-aware approval.
Runtime control
Customer-safe wording
External responses avoid internal speculation, raw secrets, and blame.
Runtime control
Escalation routing
Widespread or severe signals move to incident or security handling promptly.
Decision policy
Ordered outcomes, not averaged pass counts
The first applicable high-severity outcome takes precedence. A manual override is recorded separately and never rewrites the calculated result.
INSUFFICIENT INFORMATION
Request specific missing evidence or environment details.
REPRODUCED
Proceed to bug triage or incident flow based on impact.
ENVIRONMENT-SPECIFIC
Provide verified isolation steps and route to the correct owner.
PARTIALLY REPRODUCED
Continue targeted isolation or file a qualified finding.
NOT REPRODUCED
Report tested scope and next diagnostic option without dismissing the customer.
Known limitations
Uncertainty and coverage limits remain visible
The workflow documents what it cannot prove and what further evidence would change confidence.
- Limit 1. Customer networks and devices may not be reproducible in the laboratory.
- Limit 2. Remote troubleshooting steps can remove useful evidence or worsen downtime.
- Limit 3. Support case summaries may omit timing and configuration details.
- Limit 4. Customer content may have legal or privacy restrictions.
- Limit 5. Intermittent issues may require telemetry rather than repeated manual testing.
- Limit 6. A workaround can reduce impact without identifying the product cause.
Outputs
Versioned records for review and continuation
Human summaries are generated from validated structured records. They are not maintained as separate, drifting sources of truth.
case-context.jsonVersioned output produced by the workflow.
consent-record.mdVersioned output produced by the workflow.
environment-matrix.yamlVersioned output produced by the workflow.
failure-signature.mdVersioned output produced by the workflow.
reproduction-plan.mdVersioned output produced by the workflow.
attempt-ledger.jsonlVersioned output produced by the workflow.
isolation-analysis.mdVersioned output produced by the workflow.
customer-response.mdVersioned output produced by the workflow.
internal-handoff.mdVersioned output produced by the workflow.
customer-repro-report.htmlVersioned output produced by the workflow.
artifacts/qa/customer-issue-repro/<run-id>/ ├── case-context.json ├── consent-record.md ├── environment-matrix.yaml ├── failure-signature.md ├── reproduction-plan.md ├── attempt-ledger.jsonl ├── isolation-analysis.md ├── customer-response.md ├── internal-handoff.md └── customer-repro-report.html
Example
Example request and controlled output
Input
Reproduce a customer report where Ethernet works but Wi-Fi does not on one SCOS device. Do not ask them to reset or clear cache yet.
Output excerpt
Outcome: ENVIRONMENT-SPECIFIC Evidence: - Same device and content work over Ethernet. - Wi-Fi obtains an IP address but TLS requests fail. - A laboratory device on another Wi-Fi network works. - No cache or pairing reset was performed. Next customer-safe step: Test the affected device on a mobile hotspot and collect the exact time of the attempt. Internal direction: Investigate customer Wi-Fi proxy, firewall, DNS, or TLS interception before treating this as a player defect.
Production readiness
Required before operational use
The written skill is only one layer. The repository, runtime, connectors, evidence storage, and publication path must implement these requirements.
- Required. Tool, filesystem, repository, command, secret, and network permissions are enforced outside the model.
- Required. Every source, environment, build, plan, and approval has a version or content hash.
- Required. Untrusted values are escaped, length-bounded, path-safe, and separated from executable instructions.
- Required. Attempt outcomes, scenario verdicts, workflow decisions, and publication status remain separate.
- Required. Raw evidence, publishable evidence, access control, retention, redaction, and deletion are defined.
- Required. Concurrent runs use unique IDs, locks, idempotency keys, and conflict-aware updates.
- Required. Material changes invalidate dependent approvals and outcomes.
- Required. The repository validator passes before the skill is considered production-ready.
In one line
/customer-issue-repro
Transforms a support case into a privacy-safe, controlled reproduction plan that compares customer conditions with known-good conditions and returns a clear confidence-based outcome.