Skip to main content

doc-coauthoring

A structured workflow for co-authoring high-signal docs (PRD, RFC, design docs, proposals, decision records). Use when the user needs to turn messy context into a readable artifact with clear goals, tradeoffs, and next steps. Emphasizes context capture, outline-first drafting, and context-free reader testing to catch blind spots.

Source facts

Repository
shareAI-lab/Kode-CLI
Last source activity
January 21, 2026 at 19:44
Detected SKILL.md language
English
Stars
5,226
Forks
777

Install options

The review-first prompt is selected by default. You can switch to a direct command or download a local copy.

Review the source files

Read SKILL.md and any companion files shown by SkillsMP before deciding whether to install.

File Explorer
3 files

Showing SKILL.md

SKILL.md
Source instructions · Read-only preview
name
doc-coauthoring
description
A structured workflow for co-authoring high-signal docs (PRD, RFC, design docs, proposals, decision records). Use when the user needs to turn messy context into a readable artifact with clear goals, tradeoffs, and next steps. Emphasizes context capture, outline-first drafting, and context-free reader testing to catch blind spots.
license
Complete terms in LICENSE.txt
# Doc Co-Authoring Turn partial context into a clear document by following a staged workflow. Keep the user in control of decisions, and optimize for a doc that works for readers who do **not** share the author’s context. ## Triggers Use this workflow when the user asks to: - write or refine documentation, proposals, RFCs, PRDs, decision docs, specs - “summarize our discussion into a doc” - “make this readable for others” / “share with the team” - create a template or standard for recurring documents If the user explicitly wants freeform writing, keep the workflow lightweight (ask fewer questions; draft faster). --- ## The Workflow (3 stages) ### Stage 1 — Context Capture (close the gap) Goal: collect the minimum context required to write a doc that is correct, scoped, and actionable. Ask for: 1. **Doc type + goal**: what is this document for, and what decision/action should it unlock? 2. **Audience**: who will read it, and what do they already know? 3. **Constraints**: deadlines, non-goals, dependencies, security/compliance, platform limits. 4. **Current state**: what exists today? what’s broken? what’s missing? 5. **Options considered**: at least 1–2 alternatives and why they may/ may not work. 6. **Success criteria**: how we know it worked (metrics, user outcomes, acceptance tests). 7. **Open questions**: unknowns that block writing certain sections. Output of Stage 1: - a short “context snapshot” - a list of open questions (ranked by importance) - a proposed doc outline (1 screen) ### Stage 2 — Outline-First Drafting (iterate by section) Goal: draft a document in layers without losing coherence. Rules: - **Outline before prose**. Do not write full paragraphs until the outline is agreed. - **One section at a time**. Draft → review → revise, then move on. - **Maintain a decision log** (small bullet list) so changes are explicit. - **Keep unknowns visible**: unresolved items stay in an “Open Questions / Risks” section, not hidden. Recommended iteration loop per section: 1. Write a 3–7 bullet “section intent” (what this section must answer). 2. Draft the section (short, concrete). 3. Ask the user for a quick pass: “What’s wrong / missing / too detailed?” 4. Revise and update the decision log. ### Stage 3 — Reader Testing (catch blind spots) Goal: validate readability and completeness for a reader without the author’s context. Method: - Prepare a **clean-context review prompt**: “You are a reviewer with no prior context. Read this doc and identify: missing context, unclear terms, ambiguous decisions, hidden assumptions, and where you’d ask questions.” - If sub-agents are available, run the review in a fresh agent session. Otherwise, run the review yourself by explicitly pretending you have _no access_ to prior conversation. Output of Stage 3: - a short list of fixes (highest leverage first) - revised doc with clarified assumptions, terms, and decisions --- ## Default Section Templates Load `references/templates.md` and pick the closest template: - Decision record (ADR-lite) - Product requirements (PRD-lite) - Technical design / RFC - Proposal / pitch ## Quality Bar (what to optimize for) The doc should make it easy for a reader to answer: - What problem are we solving, for whom, and why now? - What are we proposing, and what are we not doing? - What options did we consider, and what tradeoffs drive the choice? - What are the risks, unknowns, and mitigations? - What are the next steps and owners?
View on GitHub