Experience
This folder is DocSlime’s continuous-discovery and experience-design workspace. It connects observed user needs to requirements without turning research notes into an untraceable feature backlog.
Discovery practice
DocSlime is maintainer-led today. Product learning comes from direct maintainer and user feedback, issues and pull requests, real repositories using the scaffold and skills, CLI behavior observed during development, and whether agents can act accurately from the generated docs. Claims that lack evidence remain hypotheses rather than being written as validated user facts.
A finding becomes a requirement when it identifies an observable behavior or measurable quality the product must provide. A requirement remains solution-neutral; implementation choices belong in architecture or an ADR.
Primary participants
- Team developer: wants a familiar in-repo documentation system without inventing one for every project.
- Product or design collaborator: needs concise product and design context that tools can discover without maintaining duplicate files.
- AI coding agent: needs evidence, requirements, boundaries, and decisions close to the code so it can ask focused questions instead of fabricating context.
Core journeys
| Journey | Desired outcome | Requirements |
|---|---|---|
| Scaffold a repo | One safe command creates the complete lifecycle-oriented docs tree. | FR-1, FR-2, FR-7 |
| Add one missing document | A partial tree can gain one known template without overwriting work. | FR-2, FR-3, FR-8 |
| Record a decision | The next collision-free ADR is created with a normalized memorable slug. | FR-4, FR-5 |
| Fill docs with an agent | The agent interviews the team, follows inline guidance, and removes scaffolding. | FR-9, FR-16 |
| Tighten docs | Review cuts bloat, contradictions, weak requirements, and invented certainty. | FR-10, FR-12 |
| Load design context | impeccable resolves canonical docs/PRODUCT.md and docs/DESIGN.md. |
FR-11 |
| Trace intent through production | Discovery, requirements, architecture, tests, delivery, and observability point to one another. | FR-13–FR-18 |
Experience principles
- Non-destructive by default: existing user-authored files are never overwritten or migrated implicitly.
- Evidence before assertion: agents ask rather than inventing users, systems, metrics, or decisions.
- Opinionated, not ceremonial: the lifecycle is complete, but documents stay as small as the project permits.
- Traceable quality: a user need can be followed to a requirement, test, decision, release, and production signal.
- Fast and local: the CLI works offline against the current repository.
- Discoverable context: standard names and a semantic tree make important context easy for humans, agents, and publishing tools to find.
Continuous-discovery artifact shape
Create one focused lowercase-kebab-case file when an opportunity, study, journey, or product slice needs more evidence than this index can hold. Use only the sections the evidence earns:
# Opportunity or experience
## Observed need and evidence
## Desired user and business outcome
## Users and context
## Current journey
## Opportunity and hypothesis
## Intended behavior
## Given / When / Then scenarios
## Constraints and domain language
## Success signals and telemetry
## Open questions
## Related requirements, tests, architecture, and ADRs
Learning loop
Index
No separate discovery artifacts exist yet. Add them when evidence for a meaningful opportunity or journey should outlive the issue or conversation where it surfaced.
