rootnode-project-brieflisted

Generates a structured Project Brief — a comprehensive markdown document that extracts goals, architecture, knowledge file inventory, Custom Instructions summary, Memory contents, current state, ecosystem position, and key decisions from a Claude Project. Briefs serve as uploadable context documents: add one to any other Project for immediate deep awareness of the source Project's purpose, architecture, and progress. Use when user says "create a brief," "brief this project," "extract project context," "generate a project summary for another project," "I need to share this project's context," "prepare this project for cross-project reference," or "document this project." Also use when the user is preparing to work across Projects and needs portable context. Do NOT use for session handoffs, project audits, or Memory optimization (use rootnode-session-handoff, rootnode-project-audit, or rootnode-memory-optimization respectively, if available).
drayline/rootnode-skills · ★ 40 · Data & Documents · score 76

Install: claude install-skill drayline/rootnode-skills

# Project Brief Builder > **Calibration:** Tier 1 (Model-compatible) - runs cleanly on the current dual-primary tier (Opus 5, Sonnet 5) as well as Haiku 4.5 with extended thinking. Structured retrieval, rule evaluation, or template lookup - output shape does not depend on model class. Correct-shape output also on Opus 4.8 (fallback-graceful) and Sonnet 4.6 (legacy-graceful). See repository README for model compatibility. You generate Project Briefs — structured markdown documents that capture everything another Project needs to understand about a source Project. A brief is not a session summary or a project audit. It is a portable context artifact: upload it to any other Project and that Project immediately has deep awareness of the source Project's purpose, architecture, current state, and ecosystem position. Briefs are consumed as knowledge files in receiving Projects. Every token matters — a 5,000-token brief in a project with 60,000 tokens of knowledge files is fine, but the same brief in a small project would dominate the context budget. Target 2,000–6,000 tokens. Be dense and structured, not verbose. ## Critical: Extraction, Not Fabrication Every fact in the brief must come from an observable source — Custom Instructions, knowledge files, Memory entries, project file listings, or user-provided context. When information is not available for a section, mark it "Not available — {reason}" rather than inferring. A brief with gaps is more valuable than a brief with fabri