A practical companion to my learning-in-public article about building EthoPipe.
I made these files because I kept getting lost between ideas, generated code, unfinished tasks, and new conversations. They were not a system I designed perfectly at the beginning. They grew as I worked out what would make the next session easier.
This guide shows what each part does and what you might borrow. You do not need all of it, and you do not need my project’s limits. Start with one problem you want to make easier.
You can explore the EthoPipe repository. The file names below come from the working collection behind the article; older copies and local agent instructions may differ from what is currently public.
1. Pick the problem—not the whole setup
- The agent keeps adding too much: start with
solo-maintainer.md.
- Ideas become code before you decide what you want: try
idea-to-code.md.
- You forget where you stopped: borrow the structure in
project-state.md.
- Every new conversation needs the same explanation: look at
agent-handoff.md.
- You want to understand a completed task: use
walkthrough-and-tasks.md.
- You want a longer record of decisions: start a journal like
JOURNEY.md.
For me, rules carry the project’s boundaries, procedures describe a recurring task, and scripts handle repetitive work. A plain note can be useful before you automate anything.
2. Project rules: what should the agent leave alone?
My files: solo-maintainer.md, solo-maintainer-audit.md, and AGENTS.MD.
My solo-maintainer rules keep EthoPipe within what I can follow and maintain. They include a Python-focused application, a direct-dependency budget, and limits on unnecessary infrastructure. Those are choices for my project, not requirements for yours.
Here is a starter template to adapt, not a verbatim copy of my rule:
Project: [What I am building]
Stack: [Languages and tools I have chosen]
Before adding a dependency:
Explain why the existing tools are not enough.
Before changing the architecture:
Describe the change and ask whether it belongs to this task.
Leave unrelated files and unfinished ideas alone.
If instructions conflict, ask instead of guessing.
I can change these boundaries when I choose another direction. They guide the agent’s actions without turning my current setup into a limit on what I can imagine.
3. A task procedure: what am I asking for now?
My files: idea-to-code.md, walkthrough-and-tasks.md, and manage_ideas.py.
My idea-to-code procedure slows me down between brainstorming and implementation. I want to know why the task matters, what can change, and what result I am looking for. I also ask for a short walkthrough afterward so I can follow what happened.
This adapted template is enough to start:
Objective: [One change I want]
Allowed files: [Existing files involved, including tests]
Leave alone: [Dependencies, configuration, unrelated features]
Before editing:
Read the relevant files and explain the plan.
Check:
[What should happen, and how to try or test it]
If the task needs to grow:
Tell me before making unrelated changes.
When finished:
Summarize changes, checks, blockers, and the next action.
I use numbered idea cards and an idea board when I have more to track. You can begin with a checklist in one file. A checked box is a reminder of work, not a replacement for looking at the result.
4. A checkpoint: where did I stop?
My files: project-state.md, PROJECT_STATE.md, and manage_project_state.py.
This is the part I would most happily recommend to someone who keeps reopening a project and wondering what happened last time. Before finishing, leave a note precise enough for your future self.
Current focus: [The task I am working on]
Completed:
[What changed this session]
Still in progress:
[The file, function, question, or failing check]
Next action:
[One concrete thing to do when I return]
Watch out for:
[Uncommitted changes, blockers, or assumptions]
My script writes an active state file and dated copies, but the format is useful without a script. “Keep working on the API” is less useful to me than “open this test and check this failing case.”
5. A handoff: what does a new session need?
My files: agent-handoff.md, generate_agent_handoff.py, and compile_snapshot.py.
A handoff is a checkpoint with enough context for another conversation. My generator collects Git information and can run tests and refresh a snapshot when requested. The snapshot groups selected files; it is not automatically every file in the repository.
Project context: [What I am building and its current boundaries]
Immediate objective: [The next task]
Relevant files: [Only the context needed for this task]
Recent changes: [What the previous session changed]
Checks: [Observed results, or explicitly not run]
Blockers: [What remains unclear]
Next action: [Where to begin]
Fresh conversations help me avoid mixing several tasks. The handoff helps me keep the continuity I actually need.
6. A journal: why did I make that choice?
My files: JOURNEY.md, manage_journey.py, and CHANGELOG.md.
The checkpoint says where to resume. The journal gives me a longer view: what confused me, what I tried, what changed, and what I learned. A changelog has a different job—summarizing project changes for people using or following it.
Date and task:
Problem I was trying to solve:
What I tried:
What I changed or decided:
What helped, and what did not:
What I want to try next:
I do not need a grand milestone for every entry. A small discovery, an unsuccessful experiment, or a decision not to add something can be worth remembering.
7. The supporting files: useful when you need them
You can add automation later. These are the other parts of my collection, grouped by what they help me do:
- Quality checks:
code-quality-and-standards.md, audit_maintainer_guardrails.py, verify_open_source_standards.py, OPEN_SOURCE_STANDARDS.md, and OPEN_SOURCE_COMPLIANCE.md.
- Release steps:
release-governance.md.
- Bounded companion tasks:
code-companion.md and jules.md.
- Environment and session context:
sync-node.md and AGENTS.MD.
- Finding the documentation:
SUMMARY.md and the checkpoint-archive README.md.
The scripts are tied to my repository and environment. Read them before running them, and adapt paths, commands, and assumptions to your own project. You do not have to introduce a script just to use its underlying idea.
8. The older files show how the setup grew
My July material includes implementation_plan.md, walkthrough.md, walkthrough1.md, task-project.md, update.md, github_actions_audit.md, github_actions_audit2.md, technical_audit_report_1.md, technical_audit_report3.md, project_technical_report.md, and agent-handoff-report.md.
The October records include IDEAS_BOARD.md, PROJECT_STATE.md, STATE_20261012_152433.md, SOLO_MAINTAINER_AUDIT_20261012_151845.md, SOLO_MAINTAINER_AUDIT_20261012_160520.md, OPEN_SOURCE_COMPLIANCE.md, and LLM_SNAPSHOT.MD.
For the bigger narrative, I kept JOURNEY.md, CHANGELOG.md, gemini-code-phase.md, gemini-code-telemetry-sync.md, project-timeline.md, and antigravity-system-directive.md. The earlier Adobe Firefly.docx article and comment screenshot are the creative starting point, rather than files to install.
I would browse these for examples rather than copy their historical status into a current project. The July files show individual plans and findings; the October collection shows more repeatable record-keeping. The paperwork grew because I was learning what I needed—not because every project needs that many documents.
In Antigravity, rules are persistent project instructions, while skills package reusable task procedures. The current documentation explains the supported locations and activation behavior. My older workflow files can supply the content, but their old packaging may need changing.
If you use another tool, look for its project-instruction and reusable-task features. Ask for help adapting the content, then check the documentation and try a small task. A file is useful only if the tool actually finds it.
10. Leave room for experiments
You might ask for a few approaches without authorizing edits, try one in a separate experiment, and write down what you learned. That can be worthwhile even when nothing gets merged or published.
These files are meant to make exploration easier—not turn learning into another set of hurdles. Keep what helps. Change what does not. Your project can be a place to play.
AI assistance: I used Gemini and Microsoft Copilot to discuss, organize, and edit this guide. The project files and experience are mine.
