OthmanAdi/planning-with-files: README-based editorial guide

OthmanAdi/planning-with-files describes itself in the README as "Persistent file-based planning for AI coding agents and long-running tasks. Crash-proof markdown plans, session recovery after /clear and compaction, per-turn re-injection against context rot, deterministic completion gate. Manus-style.". This article keeps to facts that can be checked in the repository. Stars, forks, and promotional badges are signals of attention, not proof of quality. Under "README", the README says: Persistent file-based planning for AI coding agents and long-running agent tasks: the skill keeps taskplan.md , findings.md , and progress.md on disk and re-injects them every turn, so the plan survives context loss, /clear , crashes, and. That establishes the project's stated boundary, not a production test.

The README's "The Problem" section gives a useful starting point for deciding whether the project fits: Goal drift: after 50+ tool calls, the original goals get crowded out. If that problem is not yours, popularity is a poor reason to adopt it. Project names, commands, and component names are kept as written so a reader can return to the primary source without guessing at terminology. Another checkable README item is: Volatile memory: the TodoWrite list disappears on context reset. It can shape a first test, but it does not replace testing in the intended environment.

The operating model is spread across sections such as "Before and after /clear". The source evidence includes: > you: continue > > agent: I don't have context from an earlier session. Can you describe the task and where you left off?. This article does not turn missing architecture, performance, or security details into claims. A real deployment still needs a look at the repository layout, configuration files, and release history.