Automatically document completed work in journal entries and usage manuals. Use this skill after completing any significant piece of work — a feature, bugfix, configuration change, infrastructure setup, or investigation. Also use when the user asks to document something, write a journal entry, create a manual, or says "write this up." If work involved commands, config files, services, or multi-step setup, a manual is needed too.
From project-documentationnpx claudepluginhub mottlio/project-documentation --plugin project-documentationThis skill uses the workspace's default tool permissions.
Fetches up-to-date documentation from Context7 for libraries and frameworks like React, Next.js, Prisma. Use for setup questions, API references, and code examples.
Retrieves current documentation, API references, and code examples for libraries, frameworks, SDKs, CLIs, and services via Context7 CLI. Ideal for API syntax, configs, migrations, and setup queries.
Uses ctx7 CLI to fetch current library docs, manage AI coding skills (install/search/generate), and configure Context7 MCP for AI editors.
Good projects have a paper trail. This skill ensures that completed work gets documented in two complementary ways:
Not every piece of work needs both. A quick bugfix might only need a journal entry. A new service deployment needs both. The skill helps you decide.
Announce at start: "Using project-documentation to write up this work."
┌─────────────────────────┐
│ Significant work done? │
└────────┬────────────────┘
│
┌──────▼──────┐
│ Journal │ ← Always, for any non-trivial work
│ entry │
└──────┬──────┘
│
┌────────────▼────────────────┐
│ Does the work involve: │
│ • Commands to run? │
│ • Config files to edit? │
│ • Services to start/stop? │
│ • Multi-step setup? │
│ • Things someone would │
│ forget in 3 months? │
└─────────┬──────────┬────────┘
Yes │ │ No
┌────────▼──┐ │
│ Manual │ │
│ too │ │
└────────────┘ │
│
Done ◄─┘
Look for a docs/ directory in the project root. Within it, look for journal/ and manuals/ subdirectories. If they don't exist, create them.
If the project has no docs/ directory, look for journal/ and manuals/ at the root. Use whatever structure the project already has — don't reorganize without asking.
Before creating a new file, scan existing journal entries for one that covers the same topic. The work you just did might be a continuation of earlier work — if so, append to the existing file under a new section header with today's date.
Filename pattern: YYYY-MM-DD-short-description.md
Structure:
# Title
**Date:** YYYY-MM-DD
## Objective
One or two sentences: what were we trying to accomplish and why?
## What was done
Describe the work in logical sections. Include:
- Decisions made and the reasoning behind them
- What was tried and didn't work (if relevant)
- Key files changed or created
- Commands run (if notable)
## What's NOT included (and why)
Optional — useful when something was deliberately excluded or deferred.
## Outcome
Brief statement of the result. Link to any PRs, issues, or follow-up work.
Keep it factual and concise. The journal is for someone (including future-you) trying to understand what happened and why. Don't pad it — if the work was simple, the entry should be short.
When appending to an existing journal file, add a new date-stamped section:
## YYYY-MM-DD — Follow-up title
Description of what was done in this session...
A manual is needed when the work produced something that someone will need to operate in the future — not just understand (that's the journal's job).
Ask yourself: "If the server rebooted tomorrow, or if I came back to this in 3 months, would I know what commands to run?" If the answer is no, write a manual.
Needs a manual:
Doesn't need a manual:
Scan manuals/ (or docs/manuals/) for an existing manual covering the same system or tool. Update it rather than creating a duplicate.
Filename pattern: descriptive-name.md (not date-prefixed — manuals are living documents)
Structure:
# System/Tool Name
## Overview
What is this, what does it do, and where does it run?
## Prerequisites
What needs to be installed or configured first?
## Configuration
Key config files and their locations. What each setting does.
Don't include actual secrets — reference where they're stored.
## Common operations
### Starting / stopping
Commands to start, stop, restart the service.
### Checking status
How to verify it's running correctly.
### Viewing logs
Where logs are and how to tail them.
## Troubleshooting
Common issues and how to fix them.
Not every section applies to every manual. Use what's relevant, skip what isn't. The goal is practical — someone should be able to follow the manual to get things working without having to reverse-engineer anything.
When updating, preserve the existing structure. Add new sections, update outdated commands or paths, and note what changed at the top:
> **Updated YYYY-MM-DD:** Added section on X, updated Y command.
Journal entries are honest and specific. They record what actually happened, not an idealized version. Include things that went wrong or took longer than expected — that context is valuable.
Manuals are practical and scannable. Someone should be able to find the command they need in under 30 seconds. Use code blocks generously. Keep explanatory text short — the reader is trying to do something, not learn the theory.
Both should be written for someone who has context about the project but wasn't in the room when the work was done.
Writing a journal entry that's really a manual — If your journal entry is mostly commands and config snippets, you probably need a manual instead (or in addition).
Creating a new file when you should append — Check existing files first. A single coherent document about "email integration" is better than three separate dated entries.
Including secrets in documentation — Reference where secrets are stored (BWS, .env, vault), never include the actual values.
Writing for today instead of tomorrow — The documentation is for future-you who has forgotten everything. Be explicit about paths, versions, and context that seems obvious right now.