Idea To Publish Workflow
A useful public page starts before drafting. The idea needs a reader, a purpose, a boundary, and a route through review.
This workflow explains how rough source material becomes public material without turning private working context into public copy.
When To Use It
Use this workflow when an idea should become durable public material instead of staying as a note, status update, or private planning detail.
Good candidates usually have at least one of these traits:
- the idea explains a repeatable pattern;
- the work produced a lesson worth finding again;
- the page would help a reader understand the project map;
- the material supports a section such as Work, Systems, Workflows, Skills, or the Knowledge Base;
- the idea connects to a larger content thread that should not be lost.
If the idea is only a quick update, it may not need a full page. If it exposes private operational detail, it needs shaping before it belongs in public.
Workflow
- Capture the idea. Name the point, intended reader, and likely content type before writing.
- Choose the right route. Decide whether the idea belongs as an article, KB reference, workflow, skill, project proof page, or section update.
- Shape the reader outcome. Write down what the visitor should understand or do after reading.
- Check the public boundary. Remove private hostnames, machine labels, credentials, internal-only task details, and anything that teaches the wrong lesson.
- Draft from the useful pattern. Keep the explanation focused on the reusable point, not the private scaffolding around it.
- Preview the rendered page. Check the actual page, links, cards, tags, search exposure, and mobile layout before treating the content as ready.
- Publish only after approval. Preview-ready does not mean public-approved. Publishing stays behind the launch gate.
Content Type Choices
| Type | Use when |
|---|---|
| Article | The idea needs narrative, context, opinion, or a public lesson. |
| Knowledge Base | The material should be a durable reference, definition, checklist, or method. |
| Workflow | The useful part is the path from one state to another. |
| Skill | The useful part is a repeatable capability or review habit. |
| Work page | The material proves a project, system, or build pattern through an example. |
| Section update | The change clarifies how a public area is organized. |
Feedback Loop
- Date: 2026-05-28
- Used on: RR operating-library pilot generation into the public
/workflows/idea-to-publish/page. - Did it produce the intended output? yes
- Better state noticed: generated public workflow pages need source maturity, raw Markdown download, and change-watch metadata while keeping internal review packet links out of public output.
- Current drag or opportunity: workflow source and generated page can drift when RRCP gates or public boundary rules change.
- Missing case: future sync should flag changed source dependencies before a page is treated as still current.
- Confusing instruction: none after the public/internal review cleanup.
- Right-sized improvement made or proposed: kept
change_watchon the source and manifest; generated source metadata and raw downloads; removed internal review URLs from public output. - Validation:
python3 scripts/sync-operating-library.py --check;python3 scripts/validate-content.py;bash scripts/build-preview.sh;bash scripts/build-prod.sh. - Keep / revise / reject: keep; revise if RRCP gate language changes.
Source
- Raw Markdown: /assets/files/operating-library/workflows/idea-to-publish.md
- Source maturity:
active - Change watch: workflow frontmatter schema, RRCP gates, public/internal content boundary, publishing approval policy
