wtf-p 0.1.0

package/commands/wtfp/write-section.md

@@ -0,0 +1,273 @@
+---
+name: wtfp:write-section
+description: Execute a PLAN.md to write section content
+argument-hint: "[path-to-PLAN.md]"
+allowed-tools:
+  - Read
+  - Bash
+  - Write
+  - Edit
+  - Glob
+  - Grep
+  - AskUserQuestion
+  - Task
+---
+
+<objective>
+Execute a PLAN.md file to write section content.
+
+Takes the path to a PLAN.md file and executes its tasks sequentially, writing the actual paper content.
+
+Creates SUMMARY.md documenting what was written and updates STATE.md with progress.
+</objective>
+
+<execution_context>
+@~/.claude/write-the-f-paper/workflows/execute-section.md
+@~/.claude/write-the-f-paper/templates/summary.md
+@~/.claude/write-the-f-paper/references/git-integration.md
+</execution_context>
+
+<process>
+
+<step name="verify">
+**Verify plan exists:**
+
+```bash
+[ ! -f "$ARGUMENTS" ] && echo "ERROR: Plan not found at $ARGUMENTS" && exit 1
+```
+
+Check plan hasn't already been executed (SUMMARY.md exists):
+```bash
+SUMMARY_PATH="${ARGUMENTS/PLAN.md/SUMMARY.md}"
+[ -f "$SUMMARY_PATH" ] && echo "WARNING: This plan already has a SUMMARY.md. Re-executing will overwrite."
+```
+
+</step>
+
+<step name="load">
+**Load plan and all context:**
+
+1. Read the PLAN.md file specified in $ARGUMENTS
+2. Parse the frontmatter (section, plan, mode, word_target)
+3. Load all @context files referenced in the plan
+4. Read PROJECT.md for core argument
+5. Read argument-map.md for relevant claims
+6. Read any prior section content for continuity
+</step>
+
+<step name="mode_setup">
+**Configure for writing mode:**
+
+Based on `mode` from plan frontmatter:
+
+**Co-Author Mode:**
+- Claude writes draft prose
+- User refines afterward
+- Output: Full draft text
+
+**Scaffold Mode:**
+- Claude creates detailed outline with key points
+- User fills in actual prose
+- Output: Structured outline for each paragraph
+
+**Reviewer Mode:**
+- Prompt user to write section
+- Claude provides feedback after each chunk
+- Output: User's text + Claude's comments
+
+</step>
+
+<step name="execute_tasks">
+**Execute each task in the plan:**
+
+For each `<task>` in `<tasks>`:
+
+1. Read the task requirements (action, target, verify)
+2. Based on mode:
+   - **Co-Author:** Write the draft content
+   - **Scaffold:** Create detailed outline
+   - **Reviewer:** Prompt user to write, then critique
+3. Verify the output meets task criteria
+4. Track word count
+5. Commit after each task (if substantive)
+
+**Per-task commit:**
+```bash
+git add paper/[section].md  # or wherever content lives
+git commit -m "$(cat <<'EOF'
+write(XX-YY): [task description]
+
+[Word count] words for [section]
+EOF
+)"
+```
+
+</step>
+
+<step name="deviation_rules">
+**Handle deviations during writing:**
+
+| Type | Action |
+|------|--------|
+| Citation needed but not in sources | Flag, continue, note in SUMMARY |
+| Argument weak | Note in SUMMARY for revision |
+| Word count significantly off | Note in SUMMARY, suggest adjustment |
+| Logical gap discovered | Note in SUMMARY, may need ISSUES.md |
+| Better structure found | Implement if minor, note if major |
+
+**Auto-fix:**
+- Minor prose improvements
+- Citation format fixes
+- Paragraph flow improvements
+
+**Log for later:**
+- Missing citations (add to sources/literature.md gap list)
+- Argument weaknesses (ISSUES.md)
+- Structure suggestions beyond plan scope
+</step>
+
+<step name="output_content">
+**Write output content:**
+
+Content goes to `paper/` directory:
+- `paper/[section-name].md` - Markdown section content
+- Or appended to `paper/paper.md` if single-file format
+
+Include proper markdown structure:
+```markdown
+## [Section Title]
+
+[Content from tasks...]
+
+### [Subsection if applicable]
+
+[More content...]
+```
+
+Track all files created/modified for SUMMARY.
+</step>
+
+<step name="summary">
+**Create SUMMARY.md:**
+
+```markdown
+---
+section: XX-name
+plan: YY
+mode: [co-author/scaffold/reviewer]
+word_count: [actual]
+word_target: [target]
+---
+
+# Section [XX]-[YY] Summary
+
+## What Was Written
+- [Task 1]: [what was accomplished]
+- [Task 2]: [what was accomplished]
+- [...]
+
+## Word Count
+- Target: [X] words
+- Actual: [Y] words
+- Variance: [+/- Z]%
+
+## Files Created/Modified
+- paper/[section].md: [description]
+
+## Key Points Made
+- [Argument 1]
+- [Argument 2]
+- [...]
+
+## Citations Used
+- [citation-key]: [where used]
+- [...]
+
+## Decisions Made
+| Decision | Rationale |
+|----------|-----------|
+| [choice] | [why] |
+
+## Issues Noted
+- [Any problems discovered during writing]
+- [Gaps that need addressing]
+
+## Next Steps
+- [What should happen next]
+
+---
+*Written: [timestamp]*
+```
+
+</step>
+
+<step name="update_state">
+**Update STATE.md:**
+
+- Update current position
+- Add word count to progress
+- Note any decisions made
+- Log any issues discovered
+- Update argument strength assessment
+</step>
+
+<step name="final_commit">
+**Final commit:**
+
+```bash
+git add .planning/sections/XX-name/XX-YY-SUMMARY.md .planning/STATE.md paper/
+git commit -m "$(cat <<'EOF'
+docs(XX-YY): complete [section name] writing
+
+[Word count] words written
+Mode: [mode]
+EOF
+)"
+```
+
+</step>
+
+<step name="done">
+**Present completion:**
+
+```
+Section written:
+
+- Content: paper/[section].md ([Y] words)
+- Summary: .planning/sections/XX-name/XX-YY-SUMMARY.md
+- Progress: [current]/[total] words ([%]%)
+
+## Written
+
+[Brief summary of what was written]
+
+## Issues Noted
+
+[Any issues discovered, or "None"]
+
+---
+
+## ▶ Next Up
+
+[Based on STATE.md - next plan, next section, or review]
+
+`/wtfp:[appropriate-command]`
+
+<sub>`/clear` first → fresh context window</sub>
+
+---
+```
+
+</step>
+
+</process>
+
+<success_criteria>
+- [ ] All tasks in PLAN.md executed
+- [ ] Content written to paper/ directory
+- [ ] Word count tracked and within tolerance
+- [ ] SUMMARY.md created with full documentation
+- [ ] STATE.md updated with progress
+- [ ] All changes committed to git
+- [ ] Next action clearly identified
+</success_criteria>

package/package.json

@@ -0,0 +1,40 @@
+{
+  "name": "wtf-p",
+  "version": "0.1.0",
+  "description": "The G.O.A.T. meta-prompting system for 10x researchers who need to submit papers and projects and proposals YESTERDAY.",
+  "bin": {
+    "wtfp": "bin/install.js",
+    "wtf-p": "bin/install.js",
+    "wtf-p-uninstall": "bin/uninstall.js"
+  },
+  "scripts": {
+    "test": "node test/sanity.js",
+    "preflight": "node scripts/preflight.js",
+    "release": "node scripts/release.js"
+  },
+  "files": [
+    "bin",
+    "commands",
+    "write-the-f-paper"
+  ],
+  "keywords": [
+    "claude",
+    "claude-code",
+    "ai",
+    "meta-prompting",
+    "context-engineering",
+    "academic-writing",
+    "research",
+    "latex",
+    "bibtex"
+  ],
+  "author": "akougkas",
+  "license": "MIT",
+  "repository": {
+    "type": "git",
+    "url": "git+https://github.com/akougkas/wtfp.git"
+  },
+  "engines": {
+    "node": ">=16.7.0"
+  }
+}

package/write-the-f-paper/references/checkpoints.md

@@ -0,0 +1,213 @@
+<overview>
+Writing plans execute with Claude as partner. Checkpoints formalize interaction points where human verification or decisions are needed.
+
+**Core principle:** Claude assists with writing. Checkpoints are for verification and decisions about content direction.
+</overview>
+
+<checkpoint_types>
+
+## checkpoint:human-verify (90% of checkpoints)
+
+**When:** Claude completed a writing task, human confirms it captures their intent.
+
+**Use for:** Argument accuracy, voice consistency, factual correctness, citation appropriateness, logical flow.
+
+**Structure:**
+```xml
+<task type="checkpoint:human-verify" gate="blocking">
+  <what-written>[What Claude drafted]</what-written>
+  <how-to-verify>[What to check - argument, tone, accuracy]</how-to-verify>
+  <resume-signal>[How to continue - "approved" or describe issues]</resume-signal>
+</task>
+```
+
+**Example:**
+```xml
+<task type="auto" mode="co-author">
+  <name>Draft introduction hook</name>
+  <action>Write opening paragraph establishing the problem</action>
+  <verify>~150 words, establishes tension</verify>
+</task>
+
+<task type="checkpoint:human-verify" gate="blocking">
+  <what-written>Introduction opening paragraph (~150 words)</what-written>
+  <how-to-verify>
+    Review and confirm:
+    1. Captures the problem accurately
+    2. Tone matches your voice
+    3. Hook is compelling
+  </how-to-verify>
+  <resume-signal>Type "approved" or describe what to change</resume-signal>
+</task>
+```
+
+## checkpoint:decision (9% of checkpoints)
+
+**When:** Human must make choice that affects content direction.
+
+**Use for:** Argument framing, evidence selection, structure choices, emphasis decisions.
+
+**Structure:**
+```xml
+<task type="checkpoint:decision" gate="blocking">
+  <decision>[What's being decided]</decision>
+  <context>[Why this matters for the paper]</context>
+  <options>
+    <option id="option-a"><name>[Name]</name><pros>[Benefits]</pros><cons>[Tradeoffs]</cons></option>
+    <option id="option-b"><name>[Name]</name><pros>[Benefits]</pros><cons>[Tradeoffs]</cons></option>
+  </options>
+  <resume-signal>[How to indicate choice]</resume-signal>
+</task>
+```
+
+**Example:**
+```xml
+<task type="checkpoint:decision" gate="blocking">
+  <decision>Framing of methodology section</decision>
+  <context>Two valid ways to present your method. Choice affects reader perception.</context>
+  <options>
+    <option id="novel"><name>Emphasize novelty</name><pros>Highlights contribution</pros><cons>May invite more scrutiny</cons></option>
+    <option id="extension"><name>Frame as extension</name><pros>Builds on established work</pros><cons>Contribution may seem incremental</cons></option>
+  </options>
+  <resume-signal>Select: novel or extension</resume-signal>
+</task>
+```
+
+## checkpoint:human-action (1% - rare)
+
+**When:** Action requires human input that Claude cannot provide.
+
+**Use ONLY for:** Providing specific data points, recalling personal observations, supplying unpublished results, clarifying domain-specific terminology.
+
+**Do NOT use for:** Writing tasks Claude can draft, formatting, citation formatting.
+
+**Example:**
+```xml
+<task type="checkpoint:human-action" gate="blocking">
+  <action>Provide specific experimental result</action>
+  <instructions>
+    I need the exact p-value and effect size from your analysis
+    to complete this sentence accurately.
+  </instructions>
+  <resume-signal>Provide: p-value and effect size</resume-signal>
+</task>
+```
+
+</checkpoint_types>
+
+<execution_protocol>
+
+When Claude encounters `type="checkpoint:*"`:
+
+1. **Stop immediately** - do not proceed to next task
+2. **Display checkpoint clearly:**
+
+```
+════════════════════════════════════════
+CHECKPOINT: [Type]
+════════════════════════════════════════
+
+Task [X] of [Y]: [Name]
+
+[Checkpoint-specific content]
+
+[Resume signal instruction]
+════════════════════════════════════════
+```
+
+3. **Wait for user response** - do not hallucinate completion
+4. **Incorporate feedback** - adjust content as directed
+5. **Resume execution** - continue only after confirmation
+
+</execution_protocol>
+
+<writing_mode_checkpoints>
+
+Different writing modes have different checkpoint patterns:
+
+**Co-Author Mode:**
+- Checkpoint after significant drafts
+- Verify voice, accuracy, intent
+- Fewer checkpoints (Claude has more latitude)
+
+**Scaffold Mode:**
+- Checkpoint after outline creation
+- User fills in prose between checkpoints
+- Checkpoint to review user's additions
+
+**Reviewer Mode:**
+- User writes first
+- Claude's critique IS the checkpoint content
+- User decides what feedback to incorporate
+
+</writing_mode_checkpoints>
+
+<guidelines>
+
+**DO:**
+- Use checkpoints after substantive content (not after every paragraph)
+- Be specific about what to verify
+- Give clear options for decisions
+- Make feedback incorporation easy
+
+**DON'T:**
+- Checkpoint every task (checkpoint fatigue)
+- Make vague verification requests
+- Force binary yes/no when nuance exists
+- Checkpoint mechanical tasks (formatting, citations)
+
+**Placement:**
+- After completing a logical unit (subsection, argument)
+- Before dependent content (need decision to continue)
+- At voice-critical moments (abstract, intro hook)
+- After significant revisions
+
+</guidelines>
+
+<anti_patterns>
+
+**BAD: Too many checkpoints**
+```xml
+<task type="auto">Write sentence 1</task>
+<task type="checkpoint:human-verify">Check sentence 1</task>
+<task type="auto">Write sentence 2</task>
+<task type="checkpoint:human-verify">Check sentence 2</task>
+```
+Why bad: Disrupts flow. Combine into one checkpoint after a paragraph/section.
+
+**BAD: Vague verification**
+```xml
+<task type="checkpoint:human-verify">
+  <what-written>Methods section</what-written>
+  <how-to-verify>Check if it's good</how-to-verify>
+</task>
+```
+Why bad: "Good" is meaningless. Specify: accuracy, completeness, tone.
+
+**GOOD: Substantive checkpoint**
+```xml
+<task type="checkpoint:human-verify">
+  <what-written>Methods section draft (800 words)</what-written>
+  <how-to-verify>
+    1. Procedure accurately described?
+    2. Enough detail to replicate?
+    3. Analysis approach clear?
+  </how-to-verify>
+</task>
+```
+
+</anti_patterns>
+
+<summary>
+
+**Checkpoint priority:**
+1. **checkpoint:human-verify** (90%) - Claude wrote, human confirms intent captured
+2. **checkpoint:decision** (9%) - Human chooses content direction
+3. **checkpoint:human-action** (1%) - Human provides information Claude can't know
+
+**When NOT to use checkpoints:**
+- Mechanical tasks (formatting, citations)
+- Every paragraph (consolidate)
+- When Claude can verify programmatically (word count, structure)
+
+</summary>