You have a running app. Now make the AI build real tools in it, the same way every time. You write your knowledge and your how as small, explicit skills, and the AI produces your result reproducibly, not a stranger’s guess. Own the layer that outlives the tool.
Builds on step 1, you already have a running app: Build a local app
A running app from step 1, an editor with AI, and a task that comes up again and again that you do not want to explain from scratch each time. For example: build a screen, set up a flow, produce a recurring asset.
Set me up a folder of Markdown files that holds my knowledge about the project: what it is, who it is for, the key rules. Tell the AI to always read these files first.
The AI stops guessing plausibly and works from your context. That is the foundation for everything else.
Write me a skill file in Markdown: a repeatable process for my task, in clear steps, one named rule per step. Short and explicit, no essay.
The skill is the how behind the result: the order, the layout, the principles. That is what you own, not the one-off output.
Set me up tokens for colours and spacing and a few components. Tell the AI to always use these names, never its own values or hex codes.
Nothing can drift. The AI builds against names, your result stays on brand and the same every time.
Build me a screen or flow with this skill. Then again fresh in a new chat. Show me where the two results differ.
A real skill produces the same thing twice. If the results differ, you sharpen the skill, not the single output.
Split the work into specialised subagents, each with a narrow task and only the context it needs. Keep token use low.
Narrow tasks, little context, clear results. Cheaper and more focused, exactly the architecture from our call.
Chain the skills so the task runs from start to finish with as little manual input as possible. Tell me where I still need to confirm and why.
The process largely runs itself, you supervise and step in only at the important points.
Package my skills and my context pack so I can take them into another project or another tool. Explain how I plug them back in there.
The skill is yours, not a tool’s. It travels while the tools change. That is the layer that stays.
Explain that more simply, no jargon.
Show me a short example of such a skill file.
Check whether the AI actually followed my rules.
Summarise this as one repeatable skill.
Why the skill layer
The screen is disposable, the skill compounds. Whoever owns the how owns the process that makes the next thousand screens consistent. Whoever only ships the finished screen drops out of it, once nobody wants to do that last manual step anymore.
| Block | What for |
|---|---|
| Context pack | Your knowledge as Markdown, read by the AI first. |
| Skill | A repeatable process, the how of a task. |
| Token | A named value (colour, spacing), never a hex. |
| Component | A named building block the AI reuses. |
| Subagent | A specialist for one narrow task, little context. |
| Zero-click | Chained skills that run with almost no input. |
| Aspect | Screen (output) | Skill (the how) |
|---|---|---|
| Reusable | no, one-off | yes, again and again |
| Travels | no, sticks to the project | yes, across tools and projects |
| Value over time | decays | compounds |
| Who owns the process | nobody | you |
This is the layer that stays. That is exactly what you build with the handbook, on your real projects.