Run the repo check
Paste this prompt into a coding agent that can read the repository you want reviewed:
Check this repository's architecture with Cachely Repo Check.
Read and follow the public skill at:
https://cachely.dev/.well-known/agent-skills/cachely-repo-check/SKILL.md
Perform a read-only review. Map and distinguish the project/package dependency graph, deployment graph, and task graph. Include declared and observed edges, actual consumers, dependency direction, cycles, hidden cross-boundary dependencies, and unknowns. Decide whether this repository should stay single-project, become or remain a monorepo, or be split. Recommend the right build or monorepo framework - including no new framework when that is best. Identify code that should move between apps, internal modules, shared libraries, and independently deployable services. Flag libraries that should be folded back when their consumers, ownership, release lifecycle, and coupling show the boundary adds ceremony without useful isolation. Triage cache readiness.
Base every recommendation on repository evidence, state uncertainty and tradeoffs, and do not modify files or run project scripts.
Return an executive recommendation, dependency graphs, current repository map, per-project verdicts, prioritized framework and boundary findings, target architecture, phased migration plan, validation plan, and the single best next Cachely skill.The canonical skill is published at https://cachely.dev/.well-known/agent-skills/cachely-repo-check/SKILL.md. The prompt stays stable while the public skill improves.
What it decides
- Keep a single-project repo, use a modular repo, adopt or preserve a monorepo, or split along a real isolation boundary.
- Keep the current build setup or choose package-manager workspaces, Turborepo, Nx, Gradle, Bazel, or a better language-native tool.
- Extract code into a shared library only when real consumers and ownership justify it.
- Fold a library back when one-consumer status combines with pass-through APIs, lockstep changes, or other evidence that it adds no useful isolation.
- Create a service only when independent deployment, scaling, data, security, failure, or team ownership requires one.
- Improve task boundaries, affected execution, and caching when repeated work is visible in the build graph.
"No new framework" and "keep the current architecture" are valid outcomes. The check is designed to remove unnecessary boundaries as readily as it proposes useful ones.
What you get
The report maps three related views: the project and package dependency graph, the deployment graph, and the task graph. It distinguishes declared dependencies from observed edges, identifies actual consumers, and calls out dependency direction, cycles, hidden cross-boundary dependencies, and unknowns.
It then maps deployables, packages, modules, and ownership, and gives each material project a verdict: well-bounded, extract, fold back, wrong boundary kind, cyclic or tangled, or insufficient evidence.
Every proposed change includes repository evidence, the benefit, migration cost, risk, confidence, a concrete smallest first move, and the signal that would make the opposite decision correct.
It finishes with a target architecture, a reversible phased plan, a validation plan, and the single most useful follow-up. It does not produce an arbitrary architecture score or invent team size, traffic, cache hit rate, or savings.
One entry skill, focused follow-ups
Repo Check is the front door. It performs enough cache and monorepo triage to choose the next step, then points to one focused Cachely skill when a deeper audit or migration plan is justified. This keeps the initial prompt useful without turning one skill into an encyclopedia.
If the repository already has an Nx or Turborepo task graph, you can also run the dedicated build-cache audit.
Privacy
The skill is read-only. It does not execute project scripts, read secret values, or send repository files or the generated report to Cachely. Your coding-agent provider may process repository data under its own privacy terms.
Cachely may count aggregate requests for the public SKILL.md file through ordinary edge analytics. A fetch does not prove a review was completed, and the skill does not send repository identifiers, paths, source, or findings.