claude-project-manifest
Creates annotated bibliography-style manifests for Claude projects, tracking files, conversation threads, and relationships with unique IDs and annotations. Use when documenting project contents, creating file inventories, tracking conversation history, or building navigable knowledge maps.
Best use case
claude-project-manifest is best used when you need a repeatable AI agent workflow instead of a one-off prompt.
Creates annotated bibliography-style manifests for Claude projects, tracking files, conversation threads, and relationships with unique IDs and annotations. Use when documenting project contents, creating file inventories, tracking conversation history, or building navigable knowledge maps.
Teams using claude-project-manifest should expect a more consistent output, faster repeated execution, less prompt rewriting.
When to use this skill
- You want a reusable workflow that can be run more than once with consistent structure.
When not to use this skill
- You only need a quick one-off answer and do not need a reusable workflow.
- You cannot install or maintain the underlying files, dependencies, or repository context.
Installation
Claude Code / Cursor / Codex
Manual Installation
- Download SKILL.md from GitHub
- Place it in
.claude/skills/claude-project-manifest/SKILL.mdinside your project - Restart your AI agent — it will auto-discover the skill
How claude-project-manifest Compares
| Feature / Agent | claude-project-manifest | Standard Approach |
|---|---|---|
| Platform Support | Not specified | Limited / Varies |
| Context Awareness | High | Baseline |
| Installation Complexity | Unknown | N/A |
Frequently Asked Questions
What does this skill do?
Creates annotated bibliography-style manifests for Claude projects, tracking files, conversation threads, and relationships with unique IDs and annotations. Use when documenting project contents, creating file inventories, tracking conversation history, or building navigable knowledge maps.
Where can I find the source code?
You can find the source code on GitHub using the link provided at the top of the page.
SKILL.md Source
# Claude Project Manifest
Create structured, annotated documentation of Claude projects that tracks files, conversation threads, and their relationships.
## When to Use
- Documenting project contents and structure
- Creating file inventories with annotations
- Tracking conversation history across sessions
- Building navigable knowledge maps
- Onboarding new collaborators to existing projects
## Core Concepts
### Manifest Structure
A manifest has four primary sections:
1. **Metadata**: Project-level information (ID, version, status)
2. **Files**: Annotated file inventory with provenance
3. **Threads**: Conversation summaries and accomplishments
4. **Relations**: Dependencies and connections between entities
### ID System
| Entity | Format | Example |
|--------|--------|---------|
| Project | `PROJ-{YEAR}-{SEQ}` | `PROJ-2024-001` |
| File | `FILE-{SEQ}` | `FILE-042` |
| Thread | `THR-{SEQ}` | `THR-017` |
| Relation | `REL-{SEQ}` | `REL-123` |
## Quick Start
### Minimal Manifest
```yaml
manifest:
id: "PROJ-2024-001"
version: "1.0.0"
created: "2024-01-15T10:30:00Z"
project:
name: "My Project"
description: "Brief description of the project"
status: active
files:
- id: "FILE-001"
path: "src/main.py"
title: "Main Entry Point"
summary: "Application entry and initialization"
```
### Full File Entry
```yaml
files:
- id: "FILE-001"
path: "src/main.py"
type: source # source | config | doc | asset | generated
thread_id: "THR-001"
title: "Main Entry Point"
summary: "One-line description of purpose"
notes: |
Extended annotation explaining:
- Design decisions made
- Why this approach was chosen
- Key implementation details
- Known limitations or TODOs
tags: [core, initialization]
depends_on: ["FILE-002", "FILE-003"]
created: "2024-01-15T10:30:00Z"
modified: "2024-01-16T14:20:00Z"
```
### Thread Entry
```yaml
threads:
- id: "THR-001"
started: "2024-01-15T10:30:00Z"
ended: "2024-01-15T12:45:00Z"
title: "Initial Project Setup"
summary: "Created core infrastructure and configuration"
accomplishments:
- "Created directory structure"
- "Implemented Config class with validation"
- "Added logging infrastructure"
files_created: ["FILE-001", "FILE-002"]
files_modified: []
decisions:
- "Chose YAML over JSON for config readability"
- "Used dataclasses instead of Pydantic for simplicity"
tags: [setup, infrastructure]
```
### Relations
```yaml
relations:
- id: "REL-001"
type: depends_on
source: "FILE-001"
target: "FILE-002"
annotation: "Main imports and uses Config class"
- id: "REL-002"
type: implements
source: "FILE-003"
target: "FILE-004"
annotation: "Repository implements StorageInterface"
```
Relation types:
- `depends_on`: Source requires target to function
- `extends`: Source builds upon target
- `implements`: Source implements interface defined in target
- `references`: Source refers to target without hard dependency
- `supersedes`: Source replaces target (for versioning)
## Writing Annotations
### File Annotations
Good annotations answer:
- **What**: What does this file do?
- **Why**: Why was this approach chosen?
- **How**: Key implementation details
- **Context**: What prompted its creation?
Example:
```yaml
notes: |
Implements rate limiting using token bucket algorithm.
Chose token bucket over sliding window for better burst handling.
Created during THR-003 when API overload issues emerged.
TODO: Add Redis backend for distributed rate limiting.
```
### Thread Annotations
Capture:
- **Goal**: What we set out to accomplish
- **Outcome**: What we actually achieved
- **Decisions**: Key choices made and rationale
- **Artifacts**: Files created or modified
## Workflow
### Starting a New Project
1. Create manifest file (`manifest.yaml`)
2. Add project metadata
3. Set initial status to `active`
### During Development
1. Log new threads as conversations happen
2. Add files with annotations when created
3. Record relations as dependencies form
4. Update thread accomplishments
### Project Handoff
1. Review all thread summaries
2. Verify file annotations are current
3. Validate all relations are documented
4. Export to markdown report if needed
## Output Formats
### YAML (Primary)
Best for editing and version control. See `assets/templates/manifest.yaml`.
### JSON (Machine-Readable)
For programmatic access. See `assets/templates/manifest.json`.
### Markdown Report
Human-readable export for documentation. See `assets/templates/manifest-report.md`.
## References
- `references/manifest-schema.md` — Full schema specification
- `references/annotation-guidelines.md` — Writing effective annotations
- `references/id-systems.md` — ID generation strategies
- `references/workflow-integration.md` — Integration patterns
## Related Skills
- **knowledge-graph-builder**: For more complex relationship modeling
- **documentation-generator**: For generating docs from manifestsRelated Skills
specstory-project-stats
Fetch project statistics from SpecStory Cloud. Run when user says "get project stats", "show SpecStory stats", "project statistics", "how many sessions", or "SpecStory metrics".
project-alchemy-orchestrator
A strategic guide for managing complex creative portfolios as a system of "organs" (Art, Commerce, Tools), diagnosing lifecycle stages (Nigredo, Albedo, Rubedo), and balancing the "Four Fields" of creative labor.
taxonomy-modeling-design
Phase 2 of the pentaphase structural-overhaul protocol. Classifies entities, standardizes attributes, establishes relationships, and designs the access framework. Use when the user invokes phase 2 of an overhaul, asks to "design the taxonomy" or "model the structure", or has completed a landscape audit and is ready to redesign. Consumes phase-1-landscape-report.md; produces phase-2-taxonomy-model.md.
systemic-ingestion-normalization
Phase 4 of the pentaphase structural-overhaul protocol. Purges redundancies, enriches and aligns legacy entities to the new schema, executes phased ingestion into the new environment, and audits integrity. Use when the user invokes phase 4 of an overhaul, asks to "migrate the data" or "ingest into the new system", or has a configured environment ready to accept legacy entities. Consumes phase-3-environment-spec.md; produces phase-4-ingestion-report.md.
system-environment-configuration
Phase 3 of the pentaphase structural-overhaul protocol. Translates the taxonomy model into objective technical criteria, evaluates candidate mechanisms or frameworks, instantiates the chosen architecture, and programs validation rules. Use when the user invokes phase 3 of an overhaul, asks to "select a system" or "configure the environment", or has a taxonomy model and is ready to choose technology. Consumes phase-2-taxonomy-model.md; produces phase-3-environment-spec.md.
pentaphase-orchestrator
Threads the full five-phase structural-overhaul protocol — landscape discovery, taxonomy design, environment configuration, systemic ingestion, governance evolution — for any substrate the user names. Use when the user requests a structural overhaul, system redesign, or end-to-end restructuring of a documentation system, asset registry, code monorepo, knowledge base, or operational workflow; or when they explicitly invoke the pentaphase methodology. Coordinates handoffs between phase-skills and seats validation gates between phases.
landscape-discovery-audit
Phase 1 of the pentaphase structural-overhaul protocol. Inventories assets, maps current flow, identifies friction, and defines value metrics for any substrate. Use when the user invokes phase 1 of an overhaul, requests a baseline audit, asks to "discover the landscape" of a system, or wants to understand current state before redesigning. Produces phase-1-landscape-report.md.
governance-evolution-protocol
Phase 5 of the pentaphase structural-overhaul protocol. Codifies operational protocols, onboards the ecosystem of participants, programs behavior monitoring, and establishes an iteration cadence so the substrate evolves rather than calcifies. Use when the user invokes phase 5 of an overhaul, asks to "establish governance" or "lock in the protocols", or has completed ingestion and is ready to declare the substrate operational. Consumes phase-4-ingestion-report.md; produces phase-5-governance-charter.md, which closes the protocol.
dimension-surfacing
Surfaces the parallel domain dimensions implicit in a dense or minimal prompt. Use when a user prompt is small on the surface but plainly implies multiple independent domains needing different expertise; when explicitly invoked by the coliseum-orchestrator skill as Phase 1; or when the user asks "what dimensions does this prompt encode" or "what axes does this break into." Produces a named dimension set where each dimension is independently executable and not a paraphrase of another.
coliseum-dispatch
Dispatches a composed set of assignment envelopes to domain-expert subagents in parallel, in a single message with multiple Agent tool calls. Enforces the no-pingpong gate via the pingpong-detector agent before any dispatch fires. Use when invoked by the coliseum-orchestrator as Phase 3; when envelopes are already composed and the next step is parallel execution; or when the user asks to "fan out" or "dispatch in parallel." Produces a dispatch log capturing what was sent, when, and where returns land.
assignment-composition
Wraps each surfaced dimension as a self-contained 9-section autonomous-work-assignment envelope — scope, context, success criteria, allowed tools, return format, handoff — all the recipient subagent needs to execute without coming back. Use when invoked by coliseum-orchestrator as Phase 2; when dimensions are named and the next step is to make each independently dispatchable; or when the user asks "compose this as an assignment." The no-pingpong gate validates each envelope before dispatch.
workspace-autopsy-governance
Conducts a full automated autopsy of the current workspace directory to map files, identifies structural issues, proposes a restructuring plan (the signal), and establishes unified governance using templates. Use this skill when a user asks to map, restructure, reorganize, or apply new governance to an existing messy repository.