---
name: team-scan
description: Scan a project to detect its stack, conventions, and available skills/agents, then write a reusable `.council/project-profile.md` consumed by team-council, team-council-plan, and team-kickoff. Use before running the council for the first time in a project, or to refresh the profile after the stack or tooling changes.
---

# team-scan

Produces the project profile that every council skill reads. Run it once per project (and again whenever the stack, conventions, or available skills change). Re-running overwrites `.council/project-profile.md`; git tracks history.

## What to detect

1. **Tech stack** — languages, frameworks, package manager, build tools, test runner. Read `package.json` / `pyproject.toml` / `Cargo.toml` / `go.mod` etc., lockfiles, and config files (`vite.config`, `tsconfig`, `vitest.config`, CI files).
2. **Conventions** — `CLAUDE.md`, `AGENTS.md`, lint/format config (eslint, prettier, biome, ruff), architecture patterns, directory layout, naming conventions.
3. **Available specialists by domain** — take the skills, agent types and MCP servers your session lists (that covers personal, project and plugin installs alike), and map each to a team-role domain by what its description says it does:
   - **UX domain**: interface design, visual critique or audit, accessibility, UX copy, motion
   - **Technical domain**: testing, debugging, code search and exploration, language or framework best practices, plus the project's lint/typecheck/test commands
   - **Process domain**: brainstorming, planning, executing plans, reviews
   - **Project-specific**: agents, MCP servers and skills that only make sense for this project (a database MCP, a deploy skill)

   Leave out what fits no domain (document formats, config helpers). The `team-*` skills themselves are not specialists.
4. **Project phase** — git history depth, existing plans under `docs/plans/`, maturity signals.
5. **Team preferences** — memory files, feedback patterns, design docs, existing decisions under `.council/decisions/`.

## Procedure

1. Confirm the target directory (default: cwd).
2. Gather the signals above with read-only tools. Prefer batched, non-interactive commands; do not modify project files other than the profile.
3. Write `.council/project-profile.md` using the output format below. Create `.council/` if absent.
4. Report a one-line summary and the profile path.

## Output: `.council/project-profile.md`

```markdown
# Project Profile — {project name}
_Generated by team-scan on {date}_

## Stack
- Language(s), framework(s), package manager, build, test runner

## Conventions
- Quality gates (lint/typecheck commands), architecture patterns, naming, key CLAUDE.md rules

## Available Specialists (by domain)
One line each: `<name> — what it is for` (e.g. "writes plans", "executes plans", "TDD", "code exploration"), so a caller can pick the one it needs.
- UX: <mapped skills/agents>
- Technical: <mapped skills/agents + lint/typecheck commands>
- Process: <mapped skills/agents>
- Project-specific: <custom agents, MCP tools>

## Project Phase
- Maturity, git depth, existing plans/decisions

## Team Preferences
- Memory/feedback/design-doc signals worth carrying into council debates
```

## Notes
- Keep the profile concise and factual — it is injected into every council agent's context, so bloat costs tokens on every run.
- If no specialists are found for a domain, say so explicitly (the council still runs; roles simply have fewer tools to invoke).