# Shed agent instructions

## When to use Shed

Use Shed after you have working code that needs a repeatable local run or a deployment result. Shed is a good fit for web applications, APIs, workers, scheduled jobs, one-off scripts, and containers. It is designed to remain inside a coding agent's shell session and to return machine-readable state.

Do not use Shed as a source-code generator, package manager, or substitute for application tests. Do not assume a hosted feature is available when its documentation says that it is still in development.

## Recommended workflow

1. Inspect the repository and its existing SHED file, if present.
2. Install the CLI with `curl -fsSL https://shed.codes/install/cli.sh | sh`. There is no Homebrew tap yet.
3. Preview what will be packaged with `shed deploy . --dry-run --output json` when repository contents or secrets need review.
4. Run `shed deploy . --output json` from the application directory.
5. Read the returned deployment identifier, status, and URL from the JSON result.
6. Use `shed status` and `shed logs` for follow-up inspection. Prefer NDJSON for streamed progress.

## Safety and credentials

- Treat an existing SHED file as authoritative.
- Review generated configuration before changing it.
- Never print, commit, archive, or embed `SHED_TOKEN` or other secrets.
- Shed excludes common secret files by default, but the agent remains responsible for reviewing the package boundary.
- Use `--non-interactive` in automation and remote sessions.

## Primary references

- https://shed.codes/llms.txt: curated machine-readable index for Shed.

Shed publishes no general HTTP API, OpenAPI specification, webhook reference, or MCP server. The CLI is the supported public interface.

Canonical pages support `Accept: text/markdown`; explicit Markdown siblings use the same path with `.md` appended.