Vision and Why
The one-sentence (or two) answer to: why does this project exist for someone other than the repo?
What it is
Section titled “What it is”Vision is not a slogan on a slide. It is the progress a real person hires this software to make — or the maintainer mission that keeps the lights on. Without it, every skill is a hammer looking for nails, and “done” means “the agent stopped typing.”
Signals live in README, PRODUCT.md, DocSlime docs/, ProductFeeling feeling notes, landing copy, and recent commit themes. If none exist, vision is unclear — say so; don’t invent a corporate poem.
Why it works
Section titled “Why it works”Goals that aren’t tied to vision optimise for local relief (close the tab, quiet CI) and accumulate product debt. Vision-tied goals survive the coffee test: they put out a fire that matters to the dish, not just rearrange smoke.
- Write vision in one or two sentences; rate confidence
- Prefer user/outcome language over feature laundry lists
- Update docs when vision changes (DocSlime /
document-it)
- Confuse “we use React” with why the product exists
- Block all work forever on perfect vision — name a provisional vision and proceed
Agent skill
Section titled “Agent skill”idk-now vision · DocSlime init/fill · ProductFeeling init · document-it