---
name: workspace-fit
description: Audit a repository without changing it to decide whether its workflow fits a rebuildable remote-agent task, needs a persistent development workspace, or lacks enough evidence. Use when choosing between GitHub Copilot CLI, Claude Code web, or persistent remote development, and when deciding whether live processes and interactive state justify a persistent shell.
license: MIT
---

# Workspace Fit

Audit only the repository evidence available locally. Do not treat the audit as permission to
install, start, migrate, build, or modify anything.

## Safety boundary

- Keep the audit read-only. Do not create, edit, delete, stage, or commit files.
- Do not run setup scripts, package managers, builds, tests, migrations, containers, databases,
  servers, watchers, or other project commands.
- Do not make network requests or invoke external services.
- Do not read secret values, `.env` files, credential stores, key files, or untracked private data.
  It is enough to note that a documented secret or service dependency exists.
- Prefer repository search and file reads. If shell inspection is necessary, use only read-only
  commands such as `pwd`, `git status --short`, `git ls-files`, `find`, `ls`, `file`, `sed`, `rg`,
  and `git grep`.
- Report uncertainty instead of inferring facts that the repository does not support.

## Audit workflow

1. Read the repository orientation and development instructions first, including `CLAUDE.md`,
   `README`, contribution guidance, and nested agent instructions when present.
2. Inspect tracked manifests, lockfiles, development scripts, container configuration, CI
   workflows, and documentation. Do not inspect dependency trees or generated build output.
3. Collect evidence for each decision factor:
   - Can a clean clone restore dependencies from committed manifests and lockfiles?
   - Are required tools and setup steps explicit, repeatable, and reasonably bounded?
   - Does useful work depend on a live database, preview server, watcher, queue, container, or
     long-running agent process?
   - Does the workflow rely on interactive shell or tmux state that cannot be reconstructed?
   - Does it require non-GitHub repositories, private-network access, SSH hops, hardware, or local
     data? Record only documented dependencies, never credentials.
   - Is frequent cross-device steering of the same live shell part of the workflow?
4. Choose exactly one outcome:
   - **Rebuildable remote task** when a clean clone plus repeatable setup restores the useful state
     and the work can proceed as an asynchronous repository task.
   - **Persistent workspace** when the useful state is a running process, interactive shell, local
     service/data set, or continuously steered session.
   - **Evidence incomplete** when the repository does not establish the deciding facts.
5. Give the smallest next step that could validate the decision without modifying the repository.

## Output

Return:

- **Recommendation:** one outcome and a one-sentence reason.
- **Repository evidence:** three to six specific file-backed observations.
- **Rebuild plan:** what a fresh session would need to restore, without executing it.
- **Persistence triggers:** the state that must remain live, or “none found.”
- **Unknowns:** only decision-relevant gaps.
- **Next test:** one safe validation step.

Keep the provider boundary explicit:

- If the rebuildable path fits, recommend using the user's existing remote-agent or cloud-task
  workflow. Do not promote additional infrastructure.
- If persistence is supported by repository evidence, describe the capabilities a persistent
  workspace would need. Do not name, rank, or link to a vendor.
- If evidence is incomplete, do not recommend buying anything.

End with: “This plugin adds no telemetry or network integration. Repository context is handled by
your installed agent client under its existing provider settings and is not sent to the plugin
author. Review the source and client permissions before use.”