doc-coauthoring

Guide structured documentation creation through context gathering, drafting, and reader testing.

Updated Dec 4, 2025
One-click install
npx skills add https://github.com/jokken79/KobetsuV1.0 --skill doc-coauthoring-jokken79
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: doc-coauthoring
Source: https://github.com/jokken79/KobetsuV1.0/tree/main/.claude/skills/doc-coauthoring
Command: npx skills add https://github.com/jokken79/KobetsuV1.0 --skill doc-coauthoring-jokken79

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve?

This Skill solves the challenge of writing clear, effective, and reader-ready documentation by providing a structured, three-stage workflow that ensures no context is lost and all blind spots are addressed.

Core Features & Use Cases

  • Structured Workflow: Guides you through Context Gathering, Refinement & Structure, and Reader Testing stages.
  • Context Capture: Efficiently pulls in all relevant background from you, your team channels, and documents.
  • Blind Spot Testing: Uses a "fresh" AI to test the final document, catching assumptions and ambiguities before you share it.
  • Use Case: You need to write a Product Requirements Document (PRD) for a new feature. This Skill will help you gather all technical and business context, structure the document section-by-section, and then test it to ensure a new engineer can understand it perfectly.

Quick Start

I need to write a technical spec for a new API. Let's use the doc-coauthoring workflow.

Frequently Asked Questions about doc-coauthoring

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I write documentation that's clear and complete without missing key context?

Structured documentation workflows capture all relevant context upfront through guided questions, then organize it into sections, ensuring blind spots are caught before readers encounter them. This Skill guides you through context gathering, refinement, and testing stages.

What's the best way to write a technical spec or PRD that engineers will actually understand?

Break the writing into stages: gather all technical and business context, structure the document section-by-section with clarifying guidance, then test readability with fresh eyes to catch assumptions and ambiguities before sharing.

How can I test my documentation for accessibility and unclear assumptions?

Use a reader-testing stage where a separate reviewer evaluates the document against your original intent, checking for missing context, unclear terminology, and accessibility gaps like missing image alt-text.

Can I use this workflow for proposals and decision documents, or only technical specs?

This three-stage workflow applies to any documentation type—technical specs, PRDs, proposals, RFCs, and decision documents—wherever clarity, completeness, and reader understanding matter.

Do I need a template to use this structured documentation workflow?

Templates are optional and provided as guidance, but the core value comes from the structured three-stage process: context gathering, refinement with iterative section drafting, and reader testing.