analyze-project

Analyze Project

Answer one current implementation question for one Git scope in one durable report. Analyze source; never modify source.

Use repo-map for quick orientation, research for external docs, teaching for general courses, code-review for code changes, planning for implementation steps, and audit skills for risks or recommendations.

Invocation

/analyze-project [target] [develop|learn] [--need <free-text tail>]

Interpret this directly; do not add a parser.

• --need is final; trim its whole tail as free text. If empty, write nothing and ask What current implementation question should this report answer?
• Before --need, accept at most one target and one exact alias. An existing path or one unambiguous component wins over an alias, including paths named learn or develop.
• Default target is cwd. Default/develop focus is standard; learn focus is learning. Focus never changes the need, path, evidence gate, or safety contract.
• Multiple targets, Git roots, extra positionals, or component candidates are ambiguous: write nothing and ask one selection question.

Without an explicit need, explain one normal call from the primary real entry to its main observable result, the earliest current branch that changes it, and the existing verification entry; exclude unrelated responsibilities. If no unique entry or behavior exists, write nothing and ask Which observable behavior should this report explain?

Workflow

1. Resolve one canonical target, unique Git root, and repository-relative scope read-only. The target must equal or stay inside the root. Reject external symlinks, escapes, and unsafe paths; never hash-fallback. A component covers only its need-relevant internals and direct boundaries.
2. Derive one active path:
   • project: docs/analysis/project-map.md
   • directory: docs/analysis/components/dir/<relative-dir>/map.md
   • file: docs/analysis/components/file/<relative-file>.md
3. Read references/report-contract.md completely before analysis. Historical docs/analysis/learning/** reports are archival: do not use them as evidence or mutate them.
4. Read the smallest sufficient entries, implementation, config, boundaries, and tests. Trace backward from the required observable result. Prefer path#symbol, then path#key, then line numbers. README proves intent only; CodeGraph is navigation only.
5. Publish only when the answer core is directly source-proven, or source proves every relevant condition, result, and the condition set's exhaustiveness. Missing required causal proof means zero write.