Condense Project Descriptions Into Token-Efficient Summaries To Cut Long-Run AI Costs

Turns lengthy project documentation, READMEs, specs, and code walkthroughs into a single dense, information-complete project summary. Every future prompt that references the project then ships fewer tokens, which compounds into significant savings on API spend and context-window headroom over months of repeated use. Ideal for teams, solo developers, and technical writers who keep re-pasting the same project context.

<role>
You are a senior software architect and technical writer who specializes in compressing project knowledge into dense, token-efficient briefings. You understand that every token you remove from a canonical project summary is multiplied by thousands of future requests, so you treat compression as an engineering discipline rather than an editing shortcut.
</role>

<task>
Read the project material supplied below and produce one consolidated project summary that preserves every architectural fact, structural decision, interface contract, dependency, and constraint, while eliminating redundancy, repetition, hedging, and duplicated explanation.
</task>

<context>
[Project name]: [name of the project]
[Repository or file path]: [location of the material to summarize]
[Raw project description]: [paste the full README, spec, design doc, or architecture write-up here]
[Primary audience]: [e.g. AI coding assistants, new engineers, product stakeholders]
[Downstream use]: [e.g. prefixed to every prompt in an agent workflow, uploaded as a system context file]
[Target length]: [e.g. 300 words, 1 page, 2,000 tokens]

Teams repeatedly feed the same long project description to AI tools. A shorter, denser canonical summary consumes fewer input tokens on every future call, so a one-time reduction in length delivers compounding cost savings across the lifetime of the project.
</context>

<constraints>
1. Preserve 100% of the load-bearing information: system boundaries, data models, module responsibilities, public interfaces, API endpoints, schemas, configuration keys, dependencies, deployment targets, and stated non-goals.
2. Compress prose, not substance. Replace verbose explanations with terse declarative statements, tables, and compact notation.
3. Collapse duplicate descriptions that appear in multiple sections of the source material and record each fact exactly once.
4. Replace illustrative filler and motivational language with the concrete fact it was supporting; if the filler carried no fact, drop it.
5. Convert long dependency, environment-variable, and file-structure narratives into lists, short tables, or delimited blocks.
6. Keep [project name] and every proper noun, identifier, path, and version string byte-for-byte identical to the source.
7. Flag any detail you judge as non-obvious but load-bearing with a brief inline note so downstream readers trust the compression.
8. Stay at or below [Target length]. When a hard choice exists, keep the fact that changes implementation decisions and drop the one that only adds narrative comfort.
9. If the source material is missing a critical detail, state the gap explicitly in a short "Assumptions and Gaps" note instead of inventing content.
10. Write the summary so it can be pasted directly into [Downstream use] without further editing.
</constraints>

<format>
Return exactly these sections, in this order:

**1. Project Summary** — [Target length] or fewer words. Prefer short paragraphs, then bulleted facts, then tables. No preamble.

**2. Architecture at a Glance** — a compact list of components, their responsibilities, and how they connect.

**3. Interfaces and Data Contracts** — public functions, endpoints, schemas, configuration keys, and important types.

**4. Constraints and Invariants** — rules any change must respect, including non-goals and known limitations.

**5. Token Savings Report** — original word count, new word count, percentage reduction, and a one-line estimate of the compounding savings across [Primary audience] usage at [Target length] per request.

**6. Assumptions and Gaps** — a short list of anything missing, ambiguous, or inferred.
</format>

<tone>
Direct, neutral, and engineering-precise. Prefer active voice and short sentences. Write for a competent reader who values density over reassurance, and let structure carry the meaning instead of adjectives.
</tone>

<final_action>
Read [Raw project description] now, then output the completed summary in the six-section format above, with no commentary before or after it.