When Opsy cannot continue, first identify what failed: the local environment, the required business input, the store permission or verification of a previous write. Preserve any known object IDs and completed work. Then use the smallest relevant check. Reinstalling the Skill or repeating authorization is not a reliable answer to every failure.
The error category matters because the corrective actions differ. A missing product fact needs a business response. An unavailable command may indicate a different installed version. An interrupted write needs a result check before another create operation is attempted.
What should you capture first?
Record the task you were trying to perform, the last completed step and the error text with secrets removed. Identify the expected store or local output. Keep any returned product, article or task ID, even if the final report was incomplete.
Do not share raw tokens, cookies, authorization headers or credential files as debugging material. A useful diagnostic record describes the operation and failure while preserving only the non-sensitive context needed to investigate it.
Which kind of problem is it?
Symptom |
Likely category to check |
First useful action |
|---|---|---|
A documented command is unavailable |
Installed version or path |
Check the actual installed copy and its help output |
A product or blog task lists missing business fields |
Input or context |
Confirm the named business facts or voice rules |
A Blog task has neither usable data nor a qualified FAQ route |
Topic evidence |
Obtain the required data or review applicable FAQ questions |
The intended operation lacks permission |
Store access |
Verify the store and actual granted capability |
A write timed out or its result was not checked |
Pending verification |
Read the known object or inspect its intended identity |
Some batch items succeeded and others failed |
Item-level result |
Preserve successful IDs and review failures separately |
These are starting checks, not diagnoses from the wording alone. Read the actual result and use current evidence. A network failure, rate limit and permission denial should not all be described as an expired login.
How should you ask Opsy to diagnose the task?
Use $opsy to inspect this interrupted task. Read the latest result and known object IDs first. Explain whether the blocker is environment, business input, permissions or pending verification. Check the relevant current state, retain successful work, and show the smallest next step. Do not repeat a create operation until you have checked whether its object already exists.
If the task stopped during local preparation, make that clear. There may be no remote object to recover. If it stopped after a store operation, preserve that uncertainty rather than treating the whole task as a local failure.
What if the connection needs attention?
Verify the intended store and the capability required for the actual task. Follow the supported connection workflow when login or consent is needed. A person may still need to complete Shopify's browser flow. Once that step finishes, check the actual granted state again before continuing.
Do not broaden the operation merely to make a warning disappear. A profile gap is not an OAuth issue, and a permission grant does not confirm the product facts that will appear in a draft. Keep the business and access checks separate.
What if a previous write may have succeeded?
Use a known object ID when available. When no ID was returned, inspect the store using the agreed handle or source identity before retrying. A second create request can make a duplicate if the first request completed but its response was lost.
When the check confirms partial success, report it precisely. Name the saved objects and fields, the failed operation and the next verification needed. Retain the earlier evidence and create a new continuation record rather than erasing the failed run from the history.
When should you hand the issue to a provider?
Escalate with a focused packet: task goal, source and installed version where known, sanitized error, completed checks, known IDs and the exact remaining blocker. This helps the provider investigate without asking you to repeat unrelated setup work.
The Opsy repository is the reference for current supported behavior. For assistance with the project or operating workflow, review GRC's services and Discuss your project, including the failed task and its non-sensitive evidence.
Use the contact page if you prefer to describe the task and available materials in a form.
