Manage a WTF-P Project
Keep project state honest, resumable, and useful for routing the next academic action.
Select the action
- Use
progress to reconcile artifacts and recommend the next step.
- Use
pause-writing or resume-writing to create and consume a session handoff.
- Use
checkpoint to save, list, or restore named snapshots.
- Use
settings to inspect and edit project policy.
- Use
add-todo or check-todos to capture and triage non-blocking work.
Read references/actions.md for the selected action before mutating project state.
Apply the state contract
- Treat schema-valid v1 records and verified authored artifacts as the source of truth. Reconcile
project://state with project://structure/outline, section records, linked plans, summaries, reviews, handoffs, manuscript artifacts, source/evidence records, validations, and checkpoints before reporting progress.
- Keep durable state factual and concise: position, completed work, decisions, blockers, pending work, word counts, and exact next action.
- Preserve Markdown handoffs, validation records, and human-action checkpoints after every decision that must survive a new session.
- Show a proposed settings diff and validate its schema before writing it.
- Require explicit confirmation before restoring a snapshot or taking any destructive or version-control action.
- Do not contact a package registry, external service, or version-control remote merely to display local progress.
- Update multiple state artifacts only after their primary operation succeeds; avoid advertising work as complete prematurely.
- Report what changed, what remains pending, and the safest next action.
Keep operations reversible
- Save snapshot metadata and verify it can be read before declaring a checkpoint successful.
- Never discard an active handoff until the author has actually resumed or explicitly closed it.
- Resolve, waive, or expire completed checkpoints without deleting their audit history.
- Reject unknown configuration keys under the closed v1 schema; do not silently carry legacy settings into the portable record.
- Keep all paths relative to the project. Never embed client home directories or machine-specific state.
- Treat VCS operations as separate actions, never implicit project bookkeeping. A checkpoint restore remains an explicit gated state effect.
If project state is inconsistent, present the discrepancy and a repair proposal before routing onward.
1---2name: wtfp-manage-project3description: This skill coordinates the durable state of a research-writing project. It activates when an agent needs to report progress, pause or resume work, save or restore a checkpoint, edit project settings, capture or review todos, choose the next workflow, or perform the WTF-P progress, pause-writing, resume-writing, checkpoint, settings, add-todo, or check-todos actions.4---56# Manage a WTF-P Project78Keep project state honest, resumable, and useful for routing the next academic action.910## Select the action1112- Use `progress` to reconcile artifacts and recommend the next step.13- Use `pause-writing` or `resume-writing` to create and consume a session handoff.14- Use `checkpoint` to save, list, or restore named snapshots.15- Use `settings` to inspect and edit project policy.16- Use `add-todo` or `check-todos` to capture and triage non-blocking work.1718Read [references/actions.md](references/actions.md) for the selected action before mutating project state.1920## Apply the state contract21221. Treat schema-valid v1 records and verified authored artifacts as the source of truth. Reconcile `project://state` with `project://structure/outline`, section records, linked plans, summaries, reviews, handoffs, manuscript artifacts, source/evidence records, validations, and checkpoints before reporting progress.232. Keep durable state factual and concise: position, completed work, decisions, blockers, pending work, word counts, and exact next action.243. Preserve Markdown handoffs, validation records, and human-action checkpoints after every decision that must survive a new session.254. Show a proposed settings diff and validate its schema before writing it.265. Require explicit confirmation before restoring a snapshot or taking any destructive or version-control action.276. Do not contact a package registry, external service, or version-control remote merely to display local progress.287. Update multiple state artifacts only after their primary operation succeeds; avoid advertising work as complete prematurely.298. Report what changed, what remains pending, and the safest next action.3031## Keep operations reversible3233- Save snapshot metadata and verify it can be read before declaring a checkpoint successful.34- Never discard an active handoff until the author has actually resumed or explicitly closed it.35- Resolve, waive, or expire completed checkpoints without deleting their audit history.36- Reject unknown configuration keys under the closed v1 schema; do not silently carry legacy settings into the portable record.37- Keep all paths relative to the project. Never embed client home directories or machine-specific state.38- Treat VCS operations as separate actions, never implicit project bookkeeping. A checkpoint restore remains an explicit gated state effect.3940If project state is inconsistent, present the discrepancy and a repair proposal before routing onward.
akougkas