Most people fail at building AI skills because they expect perfection on the first try. They spend hours crafting a detailed skill file, run it once, and when the output isn’t right, they give up. That approach assumes skills are static — write once, deploy forever. That assumption is wrong.
AI skills are not software. They’re more like teaching a child to ride a bike. You don’t hand them the bike, let go, and walk away. You run alongside, give feedback, and let them wobble until they get it. Then you keep adjusting. The bicycle method treats every skill as a work in progress that gets better every time you use it.
Your skill is never finished.
Why the “Build It Once” Mentality Fails
The foundational misunderstanding is that you can anticipate every edge case in advance. You can’t. A skill file might describe the task perfectly, but when the agent encounters a novel situation — a conflicting source, an unexpected file format — it guesses. The guess is often wrong, and you blame the skill.
So you try to write a longer skill with more rules. The file grows; the agent slows down. And it still fails on the next unique case. This cycle ends in frustration, and the skill sits unused.
The bicycle method flips this entirely.
What the Bicycle Method Actually Means
Nate, a developer who builds AI agents daily, explains it simply: “Your skill is never finished.” Every time you run a skill, you give feedback. That feedback updates the skill file. Next run, the agent already knows what went wrong last time.
The process has three repeating steps:
- Run the skill and get an output.
- Review the output — note what worked and what didn’t.
- Update the skill file with specific instructions from that review.
Then repeat. Each cycle removes one failure mode. Over a dozen runs, the skill tightens into something reliable.
The Pitfalls Section Is the Engine
Inside every well-built skill file is a section called “pitfalls.” This is where you document every mistake you’ve watched the agent make. The source material stresses this: “the pitfalls section is where you put the mistakes you’ve already watched it make, and it stops making them once they’re written down.”
Instead of starting from scratch, the agent now has a reference of what not to do. That’s the core of the bicycle method — you build a memory of failures so the agent avoids them automatically.
How to Apply It: A Real Example
Take the skill that turns a YouTube video into a long-form X article. The first version might say: “Transcribe the video, pull key quotes, and format them into a thread.” Simple.
Run it on a video. The output comes back with quotes in the wrong order and no screenshots. Now you give feedback: “Quotes should appear in the order they appear in the video. Take four screenshots at key moments and insert them after the relevant quote.”
Update the skill file with that instruction. Run it again. This time the order is right, but the screenshots are poorly cropped. Add to pitfalls: “Crop screenshots to remove irrelevant UI elements.”
After eight or nine runs, the skill knows exactly how to handle video length, quote selection, image placement, and even which parts of a transcript to skip. That consistent output didn’t come from a perfect first draft. It came from iteration.
Verification Cycles: Let the Agent Help
You don’t have to be the only reviewer. The bicycle method works even better when you add a verification step. After the agent produces the output, have it check its own work against the skill’s own criteria.
From the source: “Each skill I build works in some sort of verification cycle. The agent that creates the thing delivers the result, and then we have the same agent or different subagents check that result and provide feedback.”
This verification loop can run multiple times per session. The agent examines its own output, flags anything that violates the skill’s instructions, and fixes it before you ever see it. That’s the training wheels coming off — the agent learns to correct itself during a single run, not just across runs.
The Danger of “Set It and Forget It”
The bicycle method directly counters the belief that a skill is finished once written. AI agents are probabilistic — they can drift. A skill that worked perfectly three weeks ago might start making mistakes after a model update or a change in your data.
The only way to maintain consistent quality is to treat every output as a feedback opportunity. Each time you run a skill, you spend two minutes reviewing and one minute updating the file. That small investment compounds into a skill that handles 95% of cases on its own.
Beyond Individual Skills: The System Evolves Too
One nuance that extends the bicycle method: your agent’s entire identity works the same way. The soul.md file — which defines the agent’s personality and working style — also benefits from iterative feedback. As you update both the soul and the skills together, the agent becomes more aligned with your specific preferences. That’s when automation stops feeling like a fragile hack and starts feeling like a true extension of your workflow.
The bicycle method turns a static file into a living process. That’s the difference between a skill that works once and a skill that works forever.
- What is the bicycle method?The bicycle method treats AI skills as living processes that improve with each use through iterative feedback.
- Why does the build-it-once mentality fail?It fails because you cannot anticipate every edge case in advance, leading to frustration and unused skills.
- How do you apply the bicycle method?Run the skill, review the output, update the skill file with specific instructions, and repeat.
- What is the role of the pitfalls section?The pitfalls section documents mistakes the agent has made, so it stops making them once they are written down.
