菜单
Use when analyzing an existing codebase for architecture, tech stack, conventions, and infrastructure. Covers project structure mapping, data model discovery, integration point cataloging, and constraint identification. Do not use for schema changes (use schema-design) or API contract definition (use api-design).
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
| name | codebase-context |
| department | architect |
| description | Use when analyzing an existing codebase for architecture, tech stack, conventions, and infrastructure. Covers project structure mapping, data model discovery, integration point cataloging, and constraint identification. Do not use for schema changes (use schema-design) or API contract definition (use api-design). |
| version | 1 |
| triggers | ["codebase","context","architecture","infrastructure","tech stack","project structure"] |
Analyze the existing codebase and produce a comprehensive context briefing covering architecture, data model, patterns, and constraints. This output becomes shared context for ALL council agents — it is the foundation every other skill builds on.
No user-provided values are used in commands or file paths. All inputs are treated as read-only analysis targets.
Read CLAUDE.md, package.json (or equivalent), tsconfig, and any config files at the project root. Extract framework, language version, key dependencies, and build tooling.
List top-level directories and identify their purposes. Recurse one level into key directories (src/, app/, lib/, components/, etc.) to understand the organizational pattern.
Determine the routing approach (file-based, config-based), data fetching strategy (SSR, SSG, CSR, RSC), state management solution, and component patterns (atomic, feature-based, etc.).
Read database schema files, migration history, or ORM models. List tables, their relationships, key entities, and access control policies (e.g., RLS policies for Supabase).
Identify naming conventions (camelCase vs snake_case, file naming), file structure patterns, import conventions (barrel exports, path aliases), and error handling patterns used throughout the codebase.
Document hosting platform, database type and version, auth provider, CDN configuration, edge function usage, environment variable patterns, and deployment pipeline.
Catalog external APIs, webhooks, third-party services, and any inter-service communication patterns. Note authentication methods for each integration.
Compaction resilience: If context was lost during a long session, re-read the Inputs section to reconstruct what system is being analyzed, check the Progress Checklist for completed steps, then resume from the earliest incomplete step.
# Context Briefing
## Tech Stack
- **Framework**: [name + version]
- **Language**: [name + version]
- **Database**: [type + provider]
- **Auth**: [provider + method]
- **Hosting**: [platform]
- **Key Dependencies**: [list with versions]
## Directory Structure
[tree output with annotations]
## Architectural Patterns
- **Routing**: [approach]
- **Data Fetching**: [strategy]
- **State Management**: [solution]
- **Component Pattern**: [style]
## Data Model
| Entity | Key Fields | Relationships |
|--------|-----------|---------------|
| ... | ... | ... |
[ASCII relationship diagram if complex]
## Conventions
1. [Convention with example]
2. [Convention with example]
3. [Convention with example]
## Infrastructure Constraints
- [Constraint and implication]
- [Constraint and implication]
## Integration Points
| Service | Purpose | Auth Method |
|---------|---------|-------------|
| ... | ... | ... |
## Warnings / Tech Debt
- [Known issue or constraint that affects design decisions]
Use when designing component interaction specs with visual states, transitions, and accessibility requirements. Covers state matrices, responsive behavior, ARIA compliance, and content constraints. Do not use for multi-step user journey mapping (use journey-mapping).
Use when mapping complete user journeys through multi-step flows, onboarding sequences, or feature workflows. Covers entry points, happy paths, alternate paths, error states, friction analysis, and delight opportunities. Do not use for individual component interaction specs (use interaction-design).
Use when designing documentation architecture for a project or team. Covers audience mapping, Diataxis framework classification, onboarding path design, format and location decisions, documentation testing, and maintenance scheduling. Do not use for recording individual architecture decisions (use adr-template) or creating versioned changelogs (use changelog-design).
Use when auditing codebase patterns or evaluating proposed changes for convention consistency. Covers file naming, component patterns, data fetching, state management, and type conventions. Do not use for test plan design or coverage targets (use testing-strategy).
Use when classifying data elements by sensitivity tier and defining per-tier handling requirements. Covers data inventory, sensitivity classification, PII flow mapping, encryption and masking specifications, and cross-boundary transfer documentation. Do not use for regulatory gap analysis (use compliance-review) or audit logging design (use audit-trail-design).
Use when designing, evaluating, or versioning system prompts for LLM-powered features. Covers instruction structure, chain-of-thought patterns, output format constraints, few-shot example selection, and prompt versioning strategy. Do not use for RAG pipeline design (use rag-architecture) or AI evaluation frameworks (use ai-evaluation).