Skills
Playbooks injected into the builder's system prompt on every build. Users never see them; they only see better builds.
A skill is a markdown playbook given to the builder as part of its instructions, before it reads a single word of the user's prompt. Skills are how the platform teaches the builder to build well: project conventions, design taste, responsive discipline, how to handle state, and when to stop and check the build compiles.
/admin/skills:
The playbooks injected into the builder's system prompt, in this order. Users never see them — they just see better builds. Deactivate to test without one; reset restores a built-in template.
How a skill reaches a build
At the start of every run, Bookbag reads the active skills in order and appends them to the system prompt under a heading:
## Playbooks
Follow the relevant ones. Each says when it applies.
### <skill name>
_Use when: <when to use>_
<the playbook body>
They are read fresh on every run, so deactivating one takes effect on the next build with no restart.
They sit after the chosen design, which is deliberate: where a design and a skill disagree about a visual decision, the user's chosen design should win.
The five that ship
A fresh installation is seeded with these, in this order, only while the skills table is empty. A template you delete stays deleted — that is treated as a decision.
1. Project conventions
Use when: Every build. How the generated app is laid out and run.
The project is a Next.js app router project with Tailwind, JavaScript only. Pages go in app/<route>/page.jsx, shared pieces in components/. app/layout.jsx owns the html and body shell and there is never a second layout with its own <html>. "use client" for anything interactive. No new dependency unless the job is impossible without one. The dev server is already running with hot reload. Never write outside the project directory.
2. Design quality
Use when: Every build. What "looks good" means here.
Ship something a designer would sign off on, not a wireframe. A deliberate palette — one primary, one neutral scale, one accent. Consistent vertical rhythm, container width and radii. A real type hierarchy, never more than two font families. Real content rather than lorem ipsum. Hover and focus states with 150–200ms transitions. Readable contrast on dark backgrounds.
3. Responsive layout
Use when: Every build with any layout work.
Mobile first, then widen. Base styles target small screens; md: and lg: add to them. A real mobile navigation with a working hamburger. No fixed pixel widths — max-w-* with mx-auto and padding. max-w-full on media.
4. State and data
Use when: Apps with interactivity: forms, carts, dashboards, todo lists.
useState or useReducer, lifted only as far as it is shared. localStorage behind a hydration guard. Inline form validation with field-level errors and a disabled pending button. Designed empty states. Fake data in one module so it is easy to replace.
5. Fix before finishing
Use when: The end of every run, and any time an edit might have broken the build.
A build that does not compile is not done. Check the dev server log after meaningful edits. Unresolved imports, a missing "use client" and JSX slips are the usual suspects. Before finishing: every page renders, every link points at a real route, the log is clean. Say plainly what could not be completed.
That last one does a lot of work. It is why the builder often reads its own error log before reporting success.
Editing a skill
Click its name. A panel opens on the right:
Edit skill Markdown. The builder reads this under a "Playbooks" heading in its system prompt.
Three fields:
- Name — required.
- When to use (one line) — shown to the builder as
Use when: …, so it knows when the playbook applies. Example given: "e.g. Every build with any layout work." - Playbook — the body, in markdown, in a monospace box.
Press Save skill. Toast: Skill saved.
Template, Custom, Edited template
Each card carries a badge:
- Template — exactly as shipped.
- Custom — written by an administrator.
- Edited template — it came from a built-in but its text has been changed.
Editing the name, the "when to use" line or the body of a built-in flips it to Edited template. Toggling it active or moving it does not.
Reset
The circular-arrow button, on skills that came from a template, restores the built-in text.
Reset "
<name>" to its template? Your edits to this playbook are replaced by the built-in version.
Toast: Restored the template.
Reset restores only the name, the when-to-use line and the body. Whether the skill is active, and where it sits in the order, are left alone.
There is nothing to reset an administrator-written skill to, and the button does not appear on one.
Order
The up and down arrows swap a skill with its neighbour. Order is injection order in the prompt, so put general rules before specific ones.
Active and inactive
The switch on each card. An inactive skill is greyed out and is not injected. This is the safe way to test whether a playbook is helping: turn it off, run a build, compare.
Installing a built-in you deleted
Install template appears in the header whenever at least one built-in is not installed. Its menu lists the missing ones by name. Installing one adds it at the end of the order.
You cannot install the same template twice: That template is already installed.
Deleting
Delete "
<name>"? The builder stops using this playbook immediately.
Permanent. A built-in can be reinstalled from Install template; an administrator-written skill cannot be recovered.
Writing a good skill
The five built-ins are the model to copy.
- Be specific. "Make it look good" achieves nothing; "one primary, one neutral scale, one accent, 150–200ms hover transitions" changes output.
- Say when it applies, in the when-to-use line. The builder uses it to decide whether the playbook is relevant.
- Prefer rules to prose. A short list of rules reads better to a model than a paragraph.
- Keep them short. Every skill is in every prompt on every build, and that costs tokens on every run.
- One subject each. Separate skills can be turned off separately.