wantsong
/
writing-workbench
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity
writing-workbench/docs/operating-playbook.md

5.8 KiB
Raw Blame History

Writing Workbench Operating Playbook

This playbook explains how to run an article project inside Writing Workbench.

It is the operational layer between the workspace principles in WORKBENCH.md and the concrete project files under projects/active/.

1. When To Start A Project

Start a Writing Workbench project only after the user has decided that an idea should enter article production.

Do not use this workspace for:

  • raw diary capture
  • open-ended viewpoint exploration
  • generic source archiving
  • canonical CCPE asset creation
  • video production planning

Those belong in Knowledge Vault, CCPE System, or the future Video Workbench.

2. Project ID

Use this folder pattern:

projects/active/YYYY-MM-DD-aNNN-temp-slug/

Rules:

  • YYYY-MM-DD is the project creation date.
  • aNNN is a local article counter for that day.
  • temp-slug is a stable working slug, not the final title.
  • Do not rename the folder when the article title changes.
  • Store title changes in project.md.

3. Creating A New Project

  1. Copy the skeleton:
Copy-Item -Recurse templates\article-project\skeleton projects\active\YYYY-MM-DD-aNNN-temp-slug
  1. Fill these files first:
  • project.md
  • source-map.md
  • status.md
  • 00-creation-plan/creative-brief.md

  1. Update indexes/active-projects.md.

  2. If CCPE assets are used, update:

  • indexes/ccpe-consumption-map.md
  • ccpe-consumption/runtime-links.md when a new reusable asset relationship is discovered

4. Minimum Viable Project State

A project is ready for article work when these files are no longer blank:

  • project.md: identity, intent, target article type, decision gates
  • source-map.md: source locations and source policy
  • status.md: current phase, open decisions, next actions
  • 00-creation-plan/context-pack.md: the smallest useful pack for the first writer or reviewer

Do not dispatch writer or reviewer sessions before these files exist.

5. Phase Flow

Use this default sequence:

00-creation-plan
01-positioning
02-outline
03-drafting
04-draft-review
05-appendix
06-metadata
07-tribunal
08-model-writing
publish

The user may skip optional stages, but record the decision in status.md.

Required before drafting:

  • positioning is stable enough to write
  • outline has passed review or the user has explicitly accepted the risk
  • required sources are listed in source-map.md
  • the active context pack is available

Required before publish:

  • final article exists in publish/final.md
  • unresolved review issues are either fixed or explicitly waived
  • metadata is complete when needed
  • archive destinations are recorded

6. Context Packs

Use the smallest pack that can support the task.

  • lite: article goal, current artifact, core claims, constraints
  • standard: lite pack plus source summaries and selected evidence
  • deep: standard pack plus long excerpts, historical essays, or research material

Do not paste every source file into a context pack. Reference source paths unless selected excerpts are necessary.

7. Sessions And Reports

For each writer, reviewer, tribunal member, or modeling session, preserve both:

  • session.md: process record
  • report.md: final result or decision-ready output

The orchestrator should read reports, syntheses, and repair requests before reading full session records.

Use full sessions only when:

  • the report is ambiguous
  • a decision depends on reasoning history
  • the user asks to inspect the process
  • the next agent needs exact prior discussion details

8. Review Rounds

Each review round should preserve:

  • review-brief.md
  • one folder per reviewer
  • each reviewer folder with session.md and report.md
  • synthesis.md
  • repair-request.md

The repair request should be addressed to the next writer or reviser. It should not be a generic list of review comments.

9. Index Synchronization

Update indexes as project state changes.

Use indexes/active-projects.md when:

  • a project is created
  • current phase changes
  • next action changes
  • lead writer or project status changes

Use indexes/completed-projects.md when:

  • a project moves to projects/completed/
  • final archive paths are known
  • extracted model documents or CCPE improvement requests are known

Use indexes/ccpe-consumption-map.md when:

  • a CCPE asset is used in a project
  • an asset produces an output
  • an issue or improvement request should be sent back to CCPE System

Use indexes/extracted-models.md when:

  • the article produces a human-facing model document
  • the model should be archived in Knowledge Vault
  • the model has possible AI-facing Model Card potential

10. CCPE Boundary

Writing Workbench consumes CCPE assets. It does not redefine them.

Allowed here:

  • canonical path references
  • task-specific usage notes
  • context packs for using an asset
  • reports about asset issues
  • improvement requests for CCPE System

Not allowed here:

  • copied canonical Agent Specs
  • copied canonical Model Cards
  • copied canonical Skill definitions
  • permanent forks of CCPE runtime protocols

Trial article runs should wait until the required CCPE agents or Lite prompts are available in CCPE System, unless the user explicitly chooses a manual placeholder workflow.

11. Completion And Archiving

When an article is complete:

  1. Move the project folder from projects/active/ to projects/completed/.
  2. Keep all process records inside the completed project folder.
  3. Archive the final essay to Knowledge Vault sayings/.
  4. Archive human-facing model documents to Knowledge Vault rules/.
  5. Promote AI-facing model assets only through CCPE System.
  6. Update all relevant indexes.

When a project is abandoned:

  1. Record the reason in status.md.
  2. Move the project folder to projects/abandoned/.
  3. Keep the process trail unless the user explicitly asks to remove it.