[Bug] writing-plans generates 4,000–5,000-line code-heavy plans instead of implementation

Summary

The bundled writing-plans workflow can turn implementation work into extremely large Markdown documents containing substantial test and production code. Instead of moving from an approved design into implementation, the agent repeatedly wrote code-like content inside implementation plans.

The planning output grew to approximately 4,000–5,000 lines during the session, according to the user-visible state, and the user had to stop the session and explicitly instruct Codex to return to a normal implementation flow.

Uploaded thread: 019f78cf-a24c-7f30-80ac-c32b3ccfc887

Root Cause in the Planning Workflow

The writing-plans skill explicitly requires:

• Every action to be decomposed into 2–5 minute steps.
• Actual test code in each test step.
• Complete implementation code in each implementation step.
• Code to be repeated rather than referenced when tasks may be read independently.
• Exact commands and expected output for every small task.

For a multi-module TypeScript application, those requirements cause the plan to become a second implementation written in Markdown before the real implementation begins.

Evidence

• The surviving docs/superpowers/plans/2026-07-19-locator-workbench-release-2.md is 745 lines.
• That one retained plan contains 52 Markdown fence markers and 210 lines of embedded code.
• The later 2026-07-21-devtools-product-reset.md adds another 634 lines.
• The thread contains repeated announcements that the agent was invoking writing-plans before touching runtime code, even after plans and requirements already existed.
• Some larger/transient planning output was later cleaned or replaced, so the current repository no longer preserves the full 4,000–5,000-line state observed by the user.
• The user had to stop the session and explicitly redirect the agent to use existing tasks/progress tracking and perform normal implementation.

Steps to Reproduce

1. Provide a specification for a multi-module TypeScript application.
2. Invoke the bundled writing-plans skill.
3. Follow its requirement to include complete code for every test and implementation step.
4. Decompose each change into 2–5 minute steps across many files and tasks.
5. Observe the implementation plan grow into hundreds or thousands of lines of duplicated code-like Markdown.
6. Observe that actual source implementation does not begin until the oversized plan is finished and separately approved.

Actual Result

• Planning becomes a substitute for implementation.
• Test and production code are authored inside Markdown instead of source files.
• Code is duplicated between the plan and eventual implementation.
• Plans become expensive to generate, review, maintain, and keep consistent with source.
• Existing approved plans do not reliably prevent another planning cycle.
• The user must interrupt and explicitly request a normal implementation workflow.

Expected Result

An implementation plan should be a concise execution map:

• Requirements and acceptance criteria.
• Task boundaries and dependencies.
• Exact files or modules involved.
• Short pseudocode or interface examples only where necessary.
• Commands and verification gates without full expected source implementations.

Once a plan is approved, Codex should begin implementation and should not invoke another full planning workflow unless requirements materially change.

Impact

• Significant token and time consumption before source implementation starts.
• False appearance of coding progress because code exists only inside Markdown.
• Increased risk that planned code and real code diverge.
• Repeated approval and planning loops.
• Users must manually interrupt autonomous sessions to force execution.

Environment

• Codex CLI: 0.144.6
• Platform: macOS
• Repository: selectorChromePlugin
• Language: TypeScript
• Bundled workflow: writing-plans
• Multi-agent persistent-goal session

Suggested Fix

• Remove the requirement for complete production and test code in every plan step.
• Replace it with concise contracts, pseudocode, and acceptance criteria.
• Add a configurable plan-size budget and warn or stop when it is exceeded.
• Detect an already-approved plan and transition directly to implementation.
• Track whether generated content changes source files or only planning documents.
• Warn when multiple consecutive turns produce only plans/specifications.
• Require explicit user approval before regenerating or substantially expanding an existing implementation plan.

Related persistent-goal planning-loop report: #34657.