From document-project
Create or improve project documentation. Use when the user asks to "document the project", "create docs", "improve documentation", "write a README", "add a getting started guide", or mentions that documentation is missing or outdated. Produces a minimal root README.md and a /docs directory with linked pages. All diagrams use ASCII or Mermaid.
npx claudepluginhub dan323/easier-life-skills --plugin document-projectThis skill uses the workspace's default tool permissions.
Create or improve project documentation: a minimal root `README.md` that describes the project and links to a `/docs` directory containing all detailed pages. Every file and section is cross-linked so readers can navigate naturally. All diagrams are ASCII or Mermaid — no external image dependencies.
Creates new Angular apps using Angular CLI with flags for routing, SSR, SCSS, prefixes, and AI config. Follows best practices for modern TypeScript/Angular development. Use when starting Angular projects.
Generates Angular code and provides architectural guidance for projects, components, services, reactivity with signals, forms, dependency injection, routing, SSR, ARIA accessibility, animations, Tailwind styling, testing, and CLI tooling.
Executes ctx7 CLI to fetch up-to-date library documentation, manage AI coding skills (install/search/generate/remove/suggest), and configure Context7 MCP. Useful for current API refs, skill handling, or agent setup.
Create or improve project documentation: a minimal root README.md that describes the project and links to a /docs directory containing all detailed pages. Every file and section is cross-linked so readers can navigate naturally. All diagrams are ASCII or Mermaid — no external image dependencies.
# Language / runtime / build tool
ls package.json pyproject.toml Cargo.toml go.mod pom.xml build.gradle \
Makefile CMakeLists.txt *.sln 2>/dev/null
# Entry points and structure
ls src/ app/ lib/ cmd/ internal/ main.* index.* 2>/dev/null
# Existing documentation (audit before creating anything)
find . -maxdepth 3 -name "*.md" -o -name "*.rst" -o -name "*.adoc" \
! -path "*/.git/*" ! -path "*/node_modules/*" 2>/dev/null
# Existing /docs directory
ls docs/ 2>/dev/null
# Test directories
ls test/ tests/ spec/ __tests__/ 2>/dev/null
# CI/CD
ls .github/ .gitlab-ci.yml .circleci/ 2>/dev/null
Read package.json, pyproject.toml, Cargo.toml, or equivalent to extract:
Read existing README.md fully if it exists — capture its tone, any content worth keeping, and note what is missing.
| Question | Where to look |
|---|---|
| What does this project do? | README, package manifest description, main entry file |
| Who is the audience? (end users / developers / both) | README tone, API surface, CLI vs library |
| How do you install it? | package manifest, Makefile, CI scripts |
| How do you run / use it? | scripts section, main file, existing docs |
| How do you run tests? | test config, CI workflow, Makefile |
| What are the main components? | directory structure, imports, module names |
| Are there configuration options? | env files, config schemas, CLI flags |
| Is there a deployment / release process? | CI/CD, Dockerfile, release scripts |
Before creating or editing any file, inventory what already exists:
.md / .rst / .adoc file and its first heading.Do not delete existing documentation files. If content should move from one file to another, copy the useful parts and mark the old file as superseded with a link to the new location.
If the existing README.md contains badges (e.g. [](...) or similar), evaluate each one:
Keep as-is if the badge:
.github/workflows/ or equivalent).LICENSE file or manifest).Recommend a change if the badge:
For each problematic badge, output a specific suggestion rather than silently removing it:
⚠️ Badge
buildlinks to.github/workflows/ci.ymlbut that file does not exist (foundbuild.ymlinstead). Suggested fix: update the badge URL to referencebuild.yml.
Do not remove any badge without explicit user approval. Only flag and explain.
Choose the page set based on project complexity:
README.md
docs/
getting-started.md
configuration.md (if there are config options)
README.md
docs/
getting-started.md
architecture.md
configuration.md
api.md / usage.md
contributing.md
README.md
docs/
getting-started.md
architecture.md
configuration.md
api.md
deployment.md
contributing.md
adr/ (architecture decision records, if applicable)
001-*.md
Only create pages that have real content to put in them. A placeholder page with "TBD" is worse than no page.
Present the planned structure to the user and wait for approval before writing any files if significant work already exists. For a project with no docs at all, proceed directly.
The root README.md must be minimal. Its only jobs are:
/docs pages for everything else.# <Project Name>
<One to three sentences: what it does, who it is for, what problem it solves.>
## Quick Start
\`\`\`<lang>
<install command>
<run command>
\`\`\`
## Documentation
- [Getting Started](docs/getting-started.md)
- [Architecture](docs/architecture.md)
- [Configuration](docs/configuration.md)
- [API Reference](docs/api.md)
- [Contributing](docs/contributing.md)
## License
<License name> — see [LICENSE](LICENSE).
Rules:
/docs.README.md already exists, use Edit to add or update only what is missing; preserve content that is still accurate.Cover: prerequisites → install → first run → verify it works. Use numbered steps. Include copy-paste commands. Link back to README.md and forward to configuration.md if relevant.
Explain the main components, how they relate, and the data/control flow. Always include at least one diagram.
Mermaid component diagram example:
```mermaid
graph TD
CLI[CLI / Entry Point] --> Core[Core Library]
Core --> DB[(Database)]
Core --> Cache[(Cache)]
CLI --> Config[Config Loader]
```
ASCII fallback (if Mermaid is not appropriate):
┌─────────┐ ┌──────────┐ ┌──────────┐
│ CLI │────▶│ Core │────▶│ DB │
└─────────┘ └──────────┘ └──────────┘
│
▼
┌──────────┐
│ Cache │
└──────────┘
Use Mermaid for: flowcharts, sequence diagrams, entity-relationship diagrams, state machines. Use ASCII for: simple box-and-arrow topology diagrams, directory trees, table-like layouts.
List every configuration option in a table:
| Option | Type | Default | Description |
|---|---|---|---|
PORT | int | 8080 | HTTP server port |
Group by source (env vars, config file, CLI flags) if there are multiple.
Cover: how to set up the dev environment, run tests, submit a pull request, and the code style expectations. Link to any existing .github/CONTRIBUTING.md if it exists rather than duplicating it.
Cover: environment requirements, build steps, how to deploy, environment variables required in production, rollback procedure.
Every page must be navigable without using the browser back button.
Required links in every /docs page:
[← Back to README](../README.md)In-page section links:
See [Configuration](configuration.md#database).#section-name) for deep links within the same file.README Documentation table:
/docs must appear in the README's Documentation section. If a new page is added, the README must be updated.Cross-link map to maintain:
README.md
└── links to every docs/*.md
docs/getting-started.md
└── links to: configuration.md, architecture.md (if helpful)
docs/architecture.md
└── links to: getting-started.md, api.md / usage.md
docs/configuration.md
└── links to: getting-started.md, deployment.md (if applicable)
docs/api.md / usage.md
└── links to: getting-started.md, configuration.md
docs/contributing.md
└── links to: getting-started.md, architecture.md
After all writes and edits, print:
Documentation written:
✓ README.md (updated — Quick Start section added)
✓ docs/getting-started.md (created)
✓ docs/architecture.md (created — includes Mermaid component diagram)
✓ docs/configuration.md (created — 12 options documented)
Skipped (no content available):
— docs/deployment.md (no deployment config found)
Action needed:
! docs/api.md (stub created — public API surface needs manual review)
Flag any sections that were left as stubs because the required information could not be inferred from the codebase alone.