
Write Project Document
- 2 installs
- 56 repo stars
- Updated August 4, 2026
- seed-hypermedia/seed
Draft a concise Markdown project brief with fixed sections: Problem, Solution, Scope, Rabbit Holes, and No Gos.
About
Creates project documents in Markdown following a fixed Shipit-style structure of Problem, Solution, Scope, Rabbit Holes, and No Gos. A developer uses it to draft or refine a project brief, feature spec, or planning note.
- Fixed five-section template written to ./docs/projects/
- Drafts a useful first version with labeled assumptions when inputs are sparse
Write Project Document by the numbers
- 2 all-time installs (skills.sh)
- Ranked #1,294 of 1,879 Documentation skills by installs in the Skillselion catalog
- Data as of Aug 5, 2026 (Skillselion catalog sync)
npx skills add https://github.com/seed-hypermedia/seed --skill write-project-documentAdd your badge
Show developers this skill is listed on Skillselion. Paste this into your README.
| Installs | 2 |
|---|---|
| repo stars | ★ 56 |
| Last updated | August 4, 2026 |
| Repository | seed-hypermedia/seed ↗ |
What it does
Draft a concise Markdown project brief with fixed sections: Problem, Solution, Scope, Rabbit Holes, and No Gos.
Files
Write Project Document
Create comprehensive project document in Markdown with the sections Problem, Solution, Scope, Rabbit Holes, and No Gos based on the current context, draft, solution and scope in this specific session. write the document in the ./docs/projects/ folder (create the folder if not present).
<support-material>
Output format
Always produce these sections in this order:
# <Project title>
## Problem
## Solution
## Scope
## Rabbit Holes
## No GosUse bullets when the content is easier to scan. Use paragraphs only where narrative explanation is clearer.
Section guidance
- Problem: State the user pain, product gap, or operational issue. Explain why it matters now. Avoid solution details unless needed for context.
- Solution: Describe the proposed approach in concrete terms. Include the user-facing behavior and the system changes only at the level needed for planning. Define what will be included. Prefer crisp bullets that can later become implementation tasks or acceptance criteria. if you can also add user stories to it the better.
- Scope: the timeframe it will require to implement the solution. if the plan is multi-phase or multi-step, you can define the timeframe for each one and also dependencies of each phase/section
- Rabbit Holes: List tempting investigations, extensions, or refactors that could consume time but are not required for the first useful version.
- No Gos: List explicit non-goals, constraints, and things the project should not do.
Working style
If inputs are sparse, draft a useful first version with clearly labeled assumptions instead of blocking. Ask clarifying questions only when a missing decision would materially change the project direction.
Keep the document practical and opinionated. Favor specific statements over generic product-planning language.
</support-material>
interface:
display_name: "Write Project Document"
short_description: "Draft project docs with clear scope"
default_prompt: "Use $write-project-document to draft a markdown project document for this idea."