Use this guide after a useful first workflow is understood. It contains instructions, not installation software.
Determine what the host can do
| Actual capability | Suitable path |
|---|---|
| Conversation only | Use pasted instructions and data; return Markdown and manual steps |
| File reading | Inspect the selected skill and supplied inputs |
| File writing | Save context and outputs in the agreed workspace when authorized |
| Local execution | Use an existing suitable calculator or runtime; set up selected dependencies within authorization |
| Plugin or connector tools | Check the supported operations, account scope and the user's authorization before acting |
A model name does not establish these capabilities. If they cannot be inspected, ask one focused question about the capability needed next.
Identify actual requirements
Read the selected skill and distinguish inputs, computation, output formatting, host features and optional live integrations.
The basic route uses supplied text and local files. A live account is not required merely because the source data came from a business application.
Use a tool or plugin's real name when necessary to identify it reliably. Avoid substituting a generic label for an exact component during an actual installation. These names are functional requirements, not business examples or endorsements.
Reuse existing tools. A new application is not a remedy for an unclear process or missing decision owner.
Prepare the concrete plan
For each new component specify its functional purpose, existing alternatives, target workspace, required permissions, cost status, supported setup route, success test and recovery approach.
Verify current instructions, versions, package identity and paid-plan details against official information available to the host or supplied by the owner. If this cannot be checked, label the unknown and provide a bounded manual outline; do not invent commands, prices or interface labels.
Use the setup record template. A free software license does not eliminate setup, hardware, maintenance or review costs.
Guided setup
Explain the next meaningful step and what success looks like. Continue dependent steps after completion evidence is available.
Keep authentication in the normal provider or application interface. Do not ask for secrets in chat.
If the host cannot verify a completed step, record it as user-reported and use a suitable next test. Do not relabel a user report as independently verified.
Automatic setup within authorization
Proceed without another permission question when the user has authorized the selected scope, the host supports the operation, active permissions permit it, and cost and destination fit the existing authorization.
Inspect existing state first, preserve unrelated settings and use supported mechanisms. Record enough state to recover from a failed change.
Technical access or an open-permissions setting does not independently authorize subscriptions, account connections or business actions. Resolve only the missing authority that affects the next concrete step. A real host approval boundary still applies.
If part of the work requires user login, consent or administrator action, complete independent authorized work and hand off that step clearly. Do not bypass a denied operation through another interface.
Verify the actual result
Track states separately:
- Available: the capability is exposed.
- Installed: the intended component is present.
- Configured: the required settings and destination are correct.
- Authenticated: the intended account and role are active, if relevant.
- Read-tested: an authorized read produces the expected data.
- Action-tested: a separately authorized action completes and its result is verified.
A file-only workflow may need none of the account states. Do not force installation or authentication to fill a checklist.
For calculations, check a small case whose answer can be verified independently. Starting a program is not proof that the calculation is correct.
Prefer a read test, dry run or controlled test record. Setup permission does not by itself authorize sending messages, paying bills, running payroll or changing customer records.
Handoff
Return a receipt describing completed actions, evidence, user-reported states, untested limits, pending steps and recovery. Preserve a workable text or file route if integration is unavailable.
Only arrange future monitoring or scheduled work if the user requests it and the host supports it. Do not promise to continue after the session without an actual supported mechanism.