Promote staging to production

docs/DESIGN.md

@@ -1,64 +1,43 @@
 # Design
 
-DocSlime has no graphical app today, but it still has a product experience: the CLI, the
-generated Markdown, the agent skills, and the way those docs later publish through
-`docmd.io`. This file is the design context that tools like `impeccable` can load from
-`docs/`.
+DocSlime has no graphical app today, but it still has a product experience: the CLI, the generated Markdown, the agent skills, and the way those docs later publish through `docmd.io`. This file is the design context that tools like `impeccable` can load from `docs/`.
 
 ## Design Principles
 
-- **Useful before decorative:** the first run should leave the user with a clear, fillable
-  docs tree and obvious next action.
-- **Opinionated, not heavy:** DocSlime should make strong defaults feel helpful, not like a
-  governance framework.
-- **Agent-readable and human-readable:** templates should guide an agent without making a
-  human feel like they are reading internal machinery.
-- **Traceable by design:** requirements, BDD scenarios, tests, architecture, and ADRs should
-  naturally point at each other.
-- **Learning continues in production:** user outcomes and system health should be observable,
-  not assumed once a release deploys.
-- **Small command surface:** CLI commands stay memorable; judgment-heavy work belongs in
-  skills.
+- **Useful before decorative:** the first run should leave the user with a clear, fillable docs tree and obvious next action.
+- **Opinionated, not heavy:** DocSlime should make strong defaults feel helpful, not like a governance framework.
+- **Agent-readable and human-readable:** templates should guide an agent without making a human feel like they are reading internal machinery.
+- **Traceable by design:** requirements, BDD scenarios, tests, architecture, and ADRs should naturally point at each other.
+- **Learning continues in production:** user outcomes and system health should be observable, not assumed once a release deploys.
+- **Small command surface:** CLI commands stay memorable; judgment-heavy work belongs in skills.
 
 ## Brand And Voice
 
 - **Product name:** use `DocSlime` for the product and `docslime` for the binary/command.
-- **Tone:** practical, direct, and lightly playful when the name earns it. The product can
-  carry the integrated "slime" idea without turning docs into a joke.
-- **Mascot:** use the blue anime slime as a product signal. It can appear in the homepage
-  hero and brand surfaces, but it should support the repo/docs artifact rather than replacing
-  developer credibility.
-- **Terminology:** use "docs tree," "product context," "design context," "requirements,"
-  "BDD," "Domain Driven Design," "ADR," "template," "skill," and "agent" consistently.
-- **Writing rules:** generated guidance should be specific and interview-driven. Prefer
-  "ask the user," "trace this to a requirement," and "record the decision" over vague advice.
+- **Tone:** practical, direct, and lightly playful when the name earns it. The product can carry the integrated "slime" idea without turning docs into a joke.
+- **Mascot:** use the blue anime slime as a product signal. It can appear in the homepage hero and brand surfaces, but it should support the repo/docs artifact rather than replacing developer credibility.
+- **Terminology:** use "docs tree," "product context," "design context," "requirements," "BDD," "Domain Driven Design," "ADR," "template," "skill," and "agent" consistently.
+- **Writing rules:** generated guidance should be specific and interview-driven. Prefer "ask the user," "trace this to a requirement," and "record the decision" over vague advice.
 
 ## Impeccable Workflow
 
-`impeccable` should treat `docs/PRODUCT.md` and `docs/DESIGN.md` as the current product and
-design context. UI work should begin by loading those files, critiquing the actual surface,
-and then changing the smallest set of docs/site files that makes the critique more true.
+`impeccable` should treat `docs/PRODUCT.md` and `docs/DESIGN.md` as the current product and design context. UI work should begin by loading those files, critiquing the actual surface, and then changing the smallest set of docs/site files that makes the critique more true.
 
 For the homepage, the desired direction is:
 
 - lead with the outcome: DocSlime turns a repo into living docs;
 - show the repo/docs tree as the credibility anchor;
 - include the blue slime mascot as a memorable brand moment;
 - keep CTAs developer-native and direct;
-- avoid pink/purple gradient text, decorative grid backgrounds, oversized cards, and claims
-  that `docslime-kiss` is a CLI command.
+- avoid pink/purple gradient text, decorative grid backgrounds, oversized cards, and claims that `docslime-kiss` is a CLI command.
 
 ## Markdown Experience
 
-- `docs/PRODUCT.md` and `docs/DESIGN.md` are top-level context files so design and coding
-  agents can discover them from the docs directory.
-- Semantic folders separate strategy, continuous discovery, and engineering while
-  `docs/README.md` keeps the lifecycle explicit without encoding navigation into filenames.
-- Tables are useful for traceability, requirements, component lists, and ADR logs; prose
-  should stay short enough to scan.
+- `docs/PRODUCT.md` and `docs/DESIGN.md` are top-level context files so design and coding agents can discover them from the docs directory.
+- Semantic folders separate strategy, continuous discovery, and engineering while `docs/README.md` keeps the lifecycle explicit without encoding navigation into filenames.
+- Tables are useful for traceability, requirements, component lists, and ADR logs; prose should stay short enough to scan.
 - Templates may contain `<!-- LLM: ... -->` guidance, but filled docs should remove it.
-- Avoid generic motivational copy. Every paragraph should help a future human or agent make
-  a better change.
+- Avoid generic motivational copy. Every paragraph should help a future human or agent make a better change.
 
 ## CLI Experience
 
@@ -74,8 +53,7 @@ For the homepage, the desired direction is:
 - Requirements should be testable and carry stable IDs.
 - Testing docs should map requirements and experiences to Given/When/Then behavior coverage.
 - Architecture docs should describe domain concepts and boundaries when the project has them.
-- Publishing docs should distinguish built, deployed, and verified artifacts and include a
-  safe rollback path.
+- Publishing docs should distinguish built, deployed, and verified artifacts and include a safe rollback path.
 - Observability should cover user outcomes as well as logs, metrics, traces, SLOs, and alerts.
 - Significant product or technical decisions should be captured as ADRs.
 - KISS review should cut bloat, stale contradictions, generic AI prose, and weak traceability.

docs/PRODUCT.md

@@ -1,51 +1,29 @@
 # Product
 
-DocSlime is an opinionated documentation system for codebases. It gives a repo a consistent
-`docs/` tree, a `docslime` CLI, and agent skills that help teams turn product intent into
-filled-in, version-controlled Markdown.
+DocSlime is an opinionated documentation system for codebases. It gives a repo a consistent `docs/` tree, a `docslime` CLI, and agent skills that help teams turn product intent into filled-in, version-controlled Markdown.
 
-It exists so services and user-facing products can carry product context, continuous
-discovery, requirements, design guidance, architecture, tests, delivery, observability, and
-decisions next to the code. Agents working in the repo can read that context directly
-instead of guessing from implementation details alone.
+It exists so services and user-facing products can carry product context, continuous discovery, requirements, design guidance, architecture, tests, delivery, observability, and decisions next to the code. Agents working in the repo can read that context directly instead of guessing from implementation details alone.
 
 ## Problem
 
-Project knowledge usually lives away from the work: in tickets, chats, wikis, docs tools,
-and memory. That is painful for humans and worse for AI coding agents, which often see the
-code but not the intent behind it. Teams also reinvent documentation structure per repo, so
-there is no familiar shape for agents to read, fill, tighten, or publish.
+Project knowledge usually lives away from the work: in tickets, chats, wikis, docs tools, and memory. That is painful for humans and worse for AI coding agents, which often see the code but not the intent behind it. Teams also reinvent documentation structure per repo, so there is no familiar shape for agents to read, fill, tighten, or publish.
 
-The result is predictable: missing context, stale decisions, requirements that do not map to
-tests, and architecture docs that sound polished but do not guide the next change.
+The result is predictable: missing context, stale decisions, requirements that do not map to tests, and architecture docs that sound polished but do not guide the next change.
 
 ## Vision
 
-DocSlime makes the repo the product and engineering context container. A team runs
-`docslime init`, answers focused agent questions, records ADRs as decisions happen, and uses
-`docslime-kiss` to keep the tree lean and honest.
+DocSlime makes the repo the product and engineering context container. A team runs `docslime init`, answers focused agent questions, records ADRs as decisions happen, and uses `docslime-kiss` to keep the tree lean and honest.
 
-The system is playful in name but serious in method: it gathers the scattered pieces of a
-project into one integrated docs body, then gives humans and agents more power because the
-context is complete, local, and testable.
+The system is playful in name but serious in method: it gathers the scattered pieces of a project into one integrated docs body, then gives humans and agents more power because the context is complete, local, and testable.
 
 ## Product Shape
 
 - **CLI:** `docslime init`, `docslime add`, and `docslime list` manage the scaffold.
-- **Skills:** `docslime-install`, `docslime-init`, `docslime-fill`, `docslime-adr`, and
-  `docslime-kiss` drive the human-in-the-loop documentation lifecycle.
-- **Impeccable integration:** `docs/PRODUCT.md` and `docs/DESIGN.md` are discoverable product
-  and design context files without needing root-level duplicates, so `impeccable` can critique
-  and polish product surfaces from the same docs tree agents use.
-- **Lifecycle:** discovery evidence becomes requirements, architecture and tests implement
-  the contract, publishing carries verified artifacts to users, and observability closes the
-  learning loop.
-- **Publishing path:** the docs stay plain Markdown and can publish through `docmd.io`; the
-  engineering publishing template also covers software artifacts, promotion, deployment,
-  verification, and rollback.
-- **Quality stance:** requirements should trace to BDD scenarios and tests, architecture
-  should use Domain Driven Design language where it clarifies the system, and significant
-  choices should become ADRs.
+- **Skills:** `docslime-install`, `docslime-init`, `docslime-fill`, `docslime-adr`, and `docslime-kiss` drive the human-in-the-loop documentation lifecycle.
+- **Impeccable integration:** `docs/PRODUCT.md` and `docs/DESIGN.md` are discoverable product and design context files without needing root-level duplicates, so `impeccable` can critique and polish product surfaces from the same docs tree agents use.
+- **Lifecycle:** discovery evidence becomes requirements, architecture and tests implement the contract, publishing carries verified artifacts to users, and observability closes the learning loop.
+- **Publishing path:** the docs stay plain Markdown and can publish through `docmd.io`; the engineering publishing template also covers software artifacts, promotion, deployment, verification, and rollback.
+- **Quality stance:** requirements should trace to BDD scenarios and tests, architecture should use Domain Driven Design language where it clarifies the system, and significant choices should become ADRs.
 
 ## Quality Method
 
@@ -63,54 +41,39 @@ flowchart LR
     Observe --> Strategy
 ```
 
-- **TDD+BDD:** requirements get stable IDs, behavior is written in Given/When/Then language,
-  and tests prove observable behavior before the docs call it done.
-- **Domain Driven Design:** architecture docs name the domain concepts, boundaries, and
-  language that matter for the project; small projects can stay light, but they should still
-  know their core nouns and responsibilities.
-- **ADRs:** durable choices live in `engineering/adrs/` so future humans and agents can see
-  why the current shape exists.
-- **Observability:** production health and user-outcome signals trace back to requirements
-  and discovery, so learning continues after release.
+- **TDD+BDD:** requirements get stable IDs, behavior is written in Given/When/Then language, and tests prove observable behavior before the docs call it done.
+- **Domain Driven Design:** architecture docs name the domain concepts, boundaries, and language that matter for the project; small projects can stay light, but they should still know their core nouns and responsibilities.
+- **ADRs:** durable choices live in `engineering/adrs/` so future humans and agents can see why the current shape exists.
+- **Observability:** production health and user-outcome signals trace back to requirements and discovery, so learning continues after release.
 
 ## Goals
 
 - Give every repo a consistent, agent-readable documentation structure.
 - Make first-run value fast: `docslime init` should create useful next steps immediately.
-- Keep product, design, discovery, requirements, engineering, delivery, observability, and
-  ADR context local and version-controlled.
+- Keep product, design, discovery, requirements, engineering, delivery, observability, and ADR context local and version-controlled.
 - Support both services and user-facing products without splitting into separate doc systems.
 - Make docs easier to fill, review, tighten, and publish than to let drift.
 
 ## Non-goals
 
-- DocSlime does not replace the human conversation. Agents fill docs by interviewing the
-  team, not by inventing facts.
+- DocSlime does not replace the human conversation. Agents fill docs by interviewing the team, not by inventing facts.
 - DocSlime does not add a runtime service or database to the target project.
-- DocSlime does not turn the CLI into a publishing host; publication belongs to the
-  `docmd.io` system.
-- DocSlime does not make `kiss` a CLI command. KISS review is an agent skill because it
-  depends on judgment over filled docs.
+- DocSlime does not turn the CLI into a publishing host; publication belongs to the `docmd.io` system.
+- DocSlime does not make `kiss` a CLI command. KISS review is an agent skill because it depends on judgment over filled docs.
 
 ## Success Metrics
 
 - **Docs get filled:** scaffolded documents are completed, with no leftover `LLM:` guidance.
-- **Traceability improves:** requirements, behavior scenarios, tests, and ADRs point to each
-  other clearly enough for a future agent to act.
-- **The loop closes:** published artifacts carry verification steps, and observability links
-  production signals back to product outcomes and experience hypotheses.
-- **Design context improves:** `impeccable` resolves `docs/PRODUCT.md` and `docs/DESIGN.md`
-  as the current product/design source without bridge files that can drift.
+- **Traceability improves:** requirements, behavior scenarios, tests, and ADRs point to each other clearly enough for a future agent to act.
+- **The loop closes:** published artifacts carry verification steps, and observability links production signals back to product outcomes and experience hypotheses.
+- **Design context improves:** `impeccable` resolves `docs/PRODUCT.md` and `docs/DESIGN.md` as the current product/design source without bridge files that can drift.
 - **Low friction:** short time from `docslime init` to a useful first filled document.
 - **Adoption:** installs through Homebrew, shell installer, source builds, and skill-pack use.
 - **Publication readiness:** docs remain clean Markdown that can flow into `docmd.io`.
 
 ## Stakeholders
 
-- **Maintainer (DecisionNerd):** owns DocSlime's direction, release process, templates, and
-  skill pack.
+- **Maintainer (DecisionNerd):** owns DocSlime's direction, release process, templates, and skill pack.
 - **Engineering teams:** adopt the tree across repos to keep intent close to code.
-- **Product and design collaborators:** use `PRODUCT.md` and `DESIGN.md` as compact context
-  for shaping user-facing work.
-- **AI coding agents:** fill, consume, critique, and maintain the docs while working in the
-  repo.
+- **Product and design collaborators:** use `PRODUCT.md` and `DESIGN.md` as compact context for shaping user-facing work.
+- **AI coding agents:** fill, consume, critique, and maintain the docs while working in the repo.

docs/README.md

@@ -1,29 +1,19 @@
 # Documentation
 
-DocSlime dogfoods the documentation lifecycle it scaffolds. Product and design context feed
-continuous discovery, requirements translate that evidence into a build contract, and the
-engineering docs carry the contract through architecture, testing, publishing, and
-production observability.
+DocSlime dogfoods the documentation lifecycle it scaffolds. Product and design context feed continuous discovery, requirements translate that evidence into a build contract, and the engineering docs carry the contract through architecture, testing, publishing, and production observability.
 
-Start with the [lifecycle guide](lifecycle.md) for the full UX → DDD → TDD+BDD trace and
-day-to-day tool usage.
+Start with the [lifecycle guide](lifecycle.md) for the full UX → DDD → TDD+BDD trace and day-to-day tool usage.
 
 ## Adapt the scaffold
 
-The generated tree is a starting template, not a requirement to keep every file. Projects
-should retain only the docs that help their humans or agents make better decisions, link to
-authoritative organization-level context, and update the index when files are removed or
-merged.
+The generated tree is a starting template, not a requirement to keep every file. Projects should retain only the docs that help their humans or agents make better decisions, link to authoritative organization-level context, and update the index when files are removed or merged.
 
-For example, a backend API service in a large organization may omit local product strategy
-and visual design docs when those concerns are owned elsewhere. It can still keep
-`experience/` for developer experience (DX), operator and integration journeys, and agent
-experience for coding agents or automated consumers of the API.
+For example, a backend API service in a large organization may omit local product strategy and visual design docs when those concerns are owned elsewhere. It can still keep `experience/` for developer experience (DX), operator and integration journeys, and agent experience for coding agents or automated consumers of the API.
 
 ## Lifecycle
 
 | Document | Question it answers |
-|---|---|
+| --- | --- |
 | [`PRODUCT.md`](PRODUCT.md) | What is DocSlime, who is it for, and why does it exist? |
 | [`DESIGN.md`](DESIGN.md) | What should stay consistent across its CLI, templates, skills, and site? |
 | [`experience/`](experience/) | What user evidence, journeys, and behaviors inform the product? |
@@ -36,7 +26,7 @@ experience for coding agents or automated consumers of the API.
 Supporting detail lives in:
 
 | Folder | Contents |
-|---|---|
+| --- | --- |
 | [`strategy/`](strategy/) | Market, positioning, roadmap, and strategic bets beyond `PRODUCT.md`. |
 | [`experience/`](experience/) | Continuous-discovery practice and user-centered evidence. |
 | [`engineering/`](engineering/) | Technical lifecycle and operational documentation. |