Stop Writing Skills from Memory

Skills are having a moment. Every agent platform is shipping them, every team is starting a folder for them, and they’re being treated like the next abstraction layer in the AI engineering stack. I think that’s right. I also think most of the skills being written this week were written the same way prompts were a year ago: from memory, by hand, by someone who is pretty sure they remember what worked.

If skills are going to become part of the stack, they need provenance. Otherwise we are just rebuilding prompt libraries with nicer names.

A skill is not something you write and hope works. It should be a pattern extracted from agent sessions that already did. If your team is hand-authoring skills without session history, you are not systematizing what worked. You are guessing with better formatting.

Skills written from memory are lossy exports

This is the core of it. Most teams are writing skills from what they think they learned, not from what actually happened.

A March 2026 research paper on institutional knowledge in AI development describes the problem precisely: each commit captures a code diff but discards the reasoning behind it: the constraints, the rejected alternatives, and the forward-looking context that shaped the decision. They call that discarded reasoning the “Decision Shadow.”

Skills files have the same shadow. You write what you remember. You leave out what you forgot you knew. The session that actually worked had the real signal in it: the specific error, the config that finally took, the edge case you only hit because you were there. You just didn’t keep it. What you wrote down a week later is the 80% version, confident and incomplete, missing exactly the part that would have saved the next person.

That’s what a lossy export is. It looks like the original. It is missing the data you can’t get back.

The silo is now between sessions

Every engineering team already knows the knowledge-silo problem: the one person who understands the flaky deploy, the fix that lives only in someone’s head or a Slack thread that scrolled out of view. The 2024 Stack Overflow Developer Survey found that 45% of developers say knowledge silos hurt their productivity three or more times a week, and that was before most teams were running agents.

Agents add a new kind of silo. Research on AI coding teams found that when AI tools mediate problem-solving, organizations face real risks of knowledge silos and diminished interpersonal trust. The problem-solving used to happen between people, where at least someone could overhear it. Now it happens between one engineer and an agent, in a session nobody else sees. So the silo isn’t just between engineers anymore. It’s between sessions. Every run your agent does without capture is institutional knowledge that evaporates before it reaches anyone, including the person who ran it.

The fix isn’t more documentation discipline bolted onto more tools. It’s treating the work as something worth keeping. An initiative at Code Climate to promote intentional knowledge sharing (logging key decisions, documenting new tracks of work) helped boost throughput almost 70%.

What capturing sessions actually gives you

Capture is the thing that turns the silo back into shared knowledge. Once the session is a durable record instead of a scrollback buffer, the rest follows:

• —You can see what worked and why. Not the summary. The actual path.
• —Skills come from sessions that succeeded, not from reconstruction after the fact.
• —Your team inherits the actual pattern, not your approximation of it.
• —The knowledge doesn’t live in one person’s terminal history, one closed tab away from gone.

This isn’t a fringe position anymore. Researchers studying the shift to agentic software engineering emphasize that maintaining repositories of requirements, agent instructions, and design rationale alongside implementations is essential for maintaining organizational knowledge and reducing cognitive debt. Session history is that repository. You don’t have to author it twice. You just have to capture it once and keep improving it.

Brian did this end to end. He hit the same bug across two repos, then pulled the fix out of his recorded sessions instead of debugging it from scratch a second time. He wrote up the whole story, including the troubleshooting table the skill captured automatically because he actually ran into every row of it.

The mistake we’re about to repeat

We shipped skills on our paper console platform not because skills are a nice feature to have, but because the industry is about to make the same mistake with skills that it made with prompts: treating them like clever text instead of operational artifacts.

A prompt library felt like progress. It was really just a drawer full of things that worked once for someone, with no record of when, where, or why. Skills inherit that flaw the moment you write them from memory. The format got better. The provenance didn’t.

That’s the mistake paper console is built to avoid. You point it at sessions you’ve already run, and it generates the skill from what actually happened: the real commands, the real errors, the fix that worked. The skill doesn’t stay buried in your terminal. It’s surfaced in the console for your whole team to see, run, and build on. The debugging session one engineer did alone on a Tuesday becomes a skill anyone can pull up on Wednesday. That’s the part that closes the silo: the knowledge stops living in one person’s history and starts living where the team already looks.

Generation is one step in a loop that keeps tightening every time you run it:

• 01.Run the agent.
• 02.Capture the session.
• 03.Inspect what actually happened.
• 04.Extract the repeated pattern.
• 05.Generate the skill.
• 06.Review it.
• 07.Reuse it.
• 08.Improve it, then the next session starts the loop again.

Every step after the first depends on having kept the first. You can’t inspect a session you didn’t capture, and you can’t extract a pattern you can’t inspect. The skill is the output of that loop, not the input to it.

Start with evidence

Install the paper CLI:

curl -fsSL https://download.papercompute.com/install | sh

Then run paper start claude and start capturing. The first session you keep is the first one your team can actually learn from, and the first skill you generate from it in paper console will be the first one that started with evidence instead of a guess.

Stop writing skills from memory. Your memory is a lossy export. The session isn’t.