mcpField
W
writing-plan-documents

writing-plan-documents

github.com/borkwebDocuments859 installsUpdated 2d ago
Repository

About writing-plan-documents

writing-plan-documents is a prose skill for producing clear planning documents within an existing workflow. It helps writers organize goals, decisions, dependencies, risks, milestones, and acceptance criteria without inventing commitments or padding the text.

Key features

  1. 01Lead with goals and decisions
  2. 02Use plain language and concrete actions
  3. 03Include sections relevant to execution
  4. 04Describe unresolved choices and trade-offs
  5. 05Order milestones by dependencies

Use cases

  1. 01Draft a project plan for readers new to the discussion
  2. 02Document risks and dependencies for a task
  3. 03Compare options for an unresolved decision
  4. 04Sequence milestones and acceptance criteria

Install

Copy the command and run it in a terminal.

$npx skills add https://github.com/borkweb/skills --skill writing-plan-documents

After installing, type/writing-plan-documentsin Claude Code to confirm it loaded.

Details

From the project README

Writing Plan Documents

Apply this prose layer within the task's chosen planning workflow. Inherit the active model and reasoning effort.

  • Write for someone who has not seen the conversation. Lead with the goal and decisions; follow with the rationale needed to assess them.
  • Use plain language, concrete actions and accurate uncertainty. Remove filler, inflated adjectives, theatrical reveals, contrastive setups and summaries that repeat the preceding text.
  • Include only sections that help the reader act: scope, approach, dependencies, risks, unresolved decisions and acceptance criteria as relevant. Preserve another workflow's required structure.
  • For an unresolved decision, name the choice, viable options and tradeoffs, then recommend an option when evidence supports it. Do not invent alternatives for settled or trivial choices.
  • Sequence milestones by dependencies and outputs. Preserve real deadlines or a requested schedule; label uncertain estimates and separate coding time from review or rollout elapsed time. Do not fabricate calendar commitments.
  • Keep lists for parallel items and prose for relationships. A heading or paragraph must add information.
  • For a long document, write a skeleton first, then add or edit one section per write so no single response approaches the output limit.

Examples: “To” replaces “In order to facilitate.” “The content is the problem” replaces “This isn't a checkout problem. It's a content problem.” Preserve technical terms and domain-specific constraints that matter.

Comments

Markdown supported