Phase 1 / Ep 05: Physical Plugin planning-with-files

If the previous episodes were about improving the Agent's "persona" and "discipline", then this episode is about the core technology that truly breaks through the theoretical ceiling of all current Large Language Models (LLMs) — memory capacity and context collapse.

When our T-Block calendar management system becomes so complex that it involves 50 files and hundreds of API communications, even the most powerful models will inevitably forget a key constraint you mentioned in the 1st round by the 50th round of conversation.

This pattern is born out of the top-tier star product Manus: the palest ink is better than the best memory. It uses persistent text files to replace token-based conversations.

1. Principle: Using the File System as the LLM's Hippocampus

Context Window = Computer RAM — cleared at any time, extremely limited capacity.
Filesystem = Computer Hard Drive (Disk) — persistently exists, retrievable by name at any time.

We need to inject a mandatory, black-and-white logical concept into the Agent: "Any important decision, finding, or plan must be written to the hard drive."

2. Establishing the Skill Planning Rules

In .agents/skills/planning-with-files/SKILL.md, create the following extremely pure methodological core:

name: planning-with-files
description: Use when facing any complex task, R&D phenomenon, or long-term build to prevent core steps from being lost in the context.

## Core Mechanism (The Manus Way)
Before you face a multi-step task, do not start searching for code immediately. Force the creation or reading of the following three files:

1. **`docs/task_plan.md`**: Records the high-level step plan, the completion status of each goal (`[ ]` `[/]` `[x]`), and key decisions.
2. **`docs/findings.md`**: Acts as an external knowledge base. Every time you analyze an API structure or encounter a special mechanism/phenomenon, never just stop at answering the user in the chat box; immediately solidify it and write it into this document!
3. **`docs/progress.md`**: An archive diary used for retaining the current conversation/session. Explains what errors were resolved today.

**[Two-Step Action Rule]:** Never perform more than three consecutive file lookups or browsing operations without summarizing! After checking a couple of times, you must return to findings.md to record your discoveries.
**[No Repeated Mistakes Principle]:** If a step fails, before making a second attempt at plan_task, you must record in the progress document: "Using method A produced error B, therefore I must change tools to find a way out."

3. Why are the Three Musketeers (Three Core MD Files) Indestructible?

• task_plan.md: Your task board (similar to an internal Jira). When the conversation exceeds 8000 tokens or even after restarting the environment, the Agent only needs to take one look at it to know: "So we are waiting for the Google API debugging, and the prerequisite configurations are already done."
• findings.md: The scientific research notebook. When integrating Google Calendar, we will inevitably encounter various timezone pitfalls and permission pitfalls. The Agent must write down the pitfalls it has fallen into, so that subsequent refactoring will never repeat the same mistakes.
• progress.md: The daily handover board. If tomorrow you switch to another computer and connect with another model, you can seamlessly continue today's progress.

With these "Physical Three Musketeers", even for a super project spanning 30 episodes, or even if you take a month-long break before opening it again, you only need to give the newly awakened Agent one instruction: "Please read the plan and findings in the docs directory", and it can recall tens of thousands of words of past context in 1 second!

The next step, which is also the finale of Phase 1: We will connect these isolated rules into a truly operational production assembly line (Workflows).