← ClaudeAtlas

scan-projectlisted

Once per project, discover its manifest — where the project's ground truth lives and which domains (experts) it has — by scanning it, then propose a manifest for the human to accept or adjust. Use when a project has no .servo/manifest.yaml yet, or to refresh a stale one.
t1djani/servo · ★ 0 · AI & Automation · score 72
Install: claude install-skill t1djani/servo
# scan-project Give servo a project's `.servo/manifest.yaml` without hand-writing it. This skill discovers the project's sources of truth and its domains, then proposes a manifest. It is what makes one generic plugin work on any project — the manifest is the only project-specific adapter, and this builds it. ## Discover, do not ingest The goal is a **map of pointers**, not a copy of the project. Sample enough signal to infer where truth lives and which domains exist; do not read everything. The output is the manifest, not an index. ## Procedure 1. **Enumerate candidate sources, tool-agnostic.** Look for: - local directories and files (codebase, `docs/`, notes, ADRs), - connected MCP servers (a tracker, a notes store, a database), - any declared memory or knowledge base. The source forms that end up in the manifest are generic (`path/...`, `git:main`, `issue:{id}`, `vault:...`) — see `docs/manifest.md`. 2. **Infer the experts (domains) — from the code, not from the tooling.** Read the project's actual structure (its domain folders, its docs) and infer the domains *it* has. Do **not** just mirror the existing skills, agents, or tools: those are *sources*, not the list of domains. A project's core domain often has no skill of its own — infer it anyway from the code (a `domain/coaching/` folder is a coaching expert whether or not a coaching skill exists). For each domain, a seat is a **role plus pointers to where its knowledge lives** — its depth comes from the