# Required tools and access

The Markdown bundle needs no software installer. Actual website work may need tools or service access.

## Determine the minimum needed

After learning the main website goal and existing platform, identify capabilities required for the next stage: reading or writing project files, building pages, previewing the result, browser checks, optional imagery, agreed form or booking connections, and publication when requested.

Inspect what the current environment actually exposes. Reuse adequate existing tools. Do not install a catalogue of products or assume a configured integration is authenticated.

Separate these states in the project brief:

| State | Meaning |
| --- | --- |
| Verified | A harmless operation demonstrated the required capability |
| Available but unverified | A tool is listed, but has not been checked for this task |
| Waiting for access | Sign-in, project selection or permission is still needed |
| Missing | The capability is not present |
| Blocked or unsupported | It cannot be used in this environment at present |

Choose tools based on the owner's platform, task, budget and maintenance needs. Consult current official information when compatibility or costs must be checked and browsing is available. If it is unavailable, disclose what has not been verified.

## Automatic setup

The website workflow includes setting up necessary tools within the user's task authorization. If the actual permissions and installation mechanism allow it, install or enable the required tool yourself, provided there are no new charges or the costs have already been authorized.

Use supported installation and connection mechanisms. Observe any requirement for an explicit tool choice, approval or sign-in. Do not invent available commands or tool names. Use the smallest installation scope needed and preserve unrelated settings.

Open permissions do not establish authentication, account ownership or authority to incur charges. Do not silently elevate privileges, bypass a refusal, disable protections or alter unrelated projects. Reuse authorization already given rather than asking repeatedly.

## Guided setup

When the user's action is needed, explain the concrete blocker and the next step in plain language. Use current observed interface details or verified instructions rather than guessing.

Guide one decision or screen at a time: approve a permission request, select the intended project, complete a secure sign-in, or choose between suitable options with verified costs.

Do not request passwords, private keys or access tokens in the conversation. Use a secure credential flow supported by the environment.

If setup is declined or unsupported, stop retrying that action. Continue independent work and explain a suitable alternative if one exists. Do not change the chosen platform without agreement.

## Verify and record

After setup, use a small harmless operation to establish useful access: read the selected project, open a preview or verify a required permission. Installation success alone is insufficient.

Record the capability, selected tool, reason, setup status, verification evidence and any remaining owner action in the project brief. Do not use a purchase, real booking or customer message as a setup test without specific authorization.

Check prerequisites as they become necessary. Do not block the interview on optional tools or declare the entire environment ready because one connection works.