Skills

A skill is a short written playbook — how your team builds a particular kind of thing. It is injected into an agent's briefing whenever the router matches it to the work.

Organization → Skills.

Teach your agents how you build. Each skill is a short written playbook — your conventions for React, your review checklist, your migration rules. Take one, cut it down to what is true here, and activate it: every matching agent is briefed with it automatically.

Two tabs

Marketplace — Madebook's shared shelf, plus 34 starter templates. Installed — your organization's own. The page opens on Installed if you have any, otherwise on the Marketplace: land where the work is.

Nine categories: backend, frontend, data, security, testing, infrastructure, process, documentation, integration.

What a skill holds

Field	Notes
Name
Category	One of the nine.
Description	One line, shown on every marketplace card.
Instructions	20 to 60,000 characters. This exact text is injected.
Technologies	What the router matches on.
Path patterns	Globs — **/auth/** routes to an Authentication skill.
Tags	Matched against the work's intent.
Examples	Up to 10, each marked do this or not this.

Technologies, tags and path patterns each hold up to 100 entries of at most 120 characters.

The form's own guidance on length: keep instructions under roughly 1,500 words, and remember that six skills at 2,000 tokens each is a fifth of a context budget.

Scope

Scope	Who sees it
platform	Every organization's marketplace. Written by Madebook staff.
organization	One organization.
workspace	One workspace.

A skill's scope can never change. Widening one is refused:

A skill's scope cannot be changed. Create a new platform skill written generically, so the widening is a deliberate, reviewed act.

The skill detail page repeats it:

This skill is only ever loaded for {organization}. It cannot become platform-wide by editing it — a platform skill is authored fresh and approved, so nothing organization-specific is carried across.

Status and versions

A skill is draft, published or archived. Only a published skill is ever injected.

Versions are immutable once published:

A published version is immutable. Runs record the version they injected, so an old plan stays explicable.

Editing a published skill creates a new version with a changelog. The old one is superseded, never deleted — the runs that used it still refer to it.

Who can do what

Action	Capability	Roles
Read	skill.read	all four
Write a draft, copy a built-in	skill.propose	owner, admin, member
Publish or archive an organization or workspace skill	skill.publish	owner, admin
Write, publish or promote a platform skill	skill.publish_platform	platform admin only
Choose which approved skills apply to one workspace	workspace.update	owner, admin, member (plus write on that workspace)

Proposing is open; publishing is not. Publishing is what puts your text into other people's agent briefs.

Choosing which of the organization's approved skills apply to a workspace is configuring the workspace, not authoring a skill — so it asks for the same capability as the per-workspace policy toggle beside it, and not for anything in the skill.* family.

State badges

Badge	Meaning
active	Published and in use.
draft — not injected	Written, not published. Nothing reads it.
workspaces can use this	Offered; each workspace still opts in.
off here	Switched off for this organization or workspace.
already taken	A template you have already used.
available	A template you have not.

Taking a template

Use this on a marketplace template copies it into your organization as a draft:

{name} added as a draft — read it, cut it down, then activate

A built-in platform skill can also be copied with the copy icon, titled "Make an editable copy owned by this organization". It arrives as {name} (ours).

The marketplace footer makes the flow explicit:

Skills you take arrive as drafts under Installed — read them, cut them down to what is true here, then activate.

Switching one off

An organization can switch a platform skill off for itself. Its own skills are controlled by publishing and archiving them instead, so there is exactly one switch per skill:

This is your own skill — publish it to activate it, archive it to switch it off.

The router honours an organization's opt-out before anything else.

Which skills a workspace uses

Workspace → Skills.

A master switch, Use everything the organization approves:

• On: "On — all {n} approved skills apply here, and new approvals join automatically."
• Off: "Off — this workspace chooses skill by skill below. {n} of {m} currently apply."

With the switch on, per-skill choices are dormant but preserved. With it off, the organization's own skills default on and platform skills default off.

A workspace cannot switch off a skill it wrote itself: "This workspace wrote this skill. Archive it to switch it off."

The router

Deterministic scoring. No model.

What matches	Points
A technology the workspace uses	+3 each
A path pattern against a changed file	+4 each, at most 3 hits
The category matches the work	+2
Scope proximity — nearer wins	0 to +3
A tag matching the intent	+1 each

Threshold 3, cap 8. A skill scoring 3 or more is selected, up to eight of them, highest first.

Workspace technologies come from the context's confirmed technology list plus every dependency in every connected repository — a package.json that says react is a workspace that uses React.

Scores are a deterministic total with the contributing reasons attached. They are not probabilities, and the interface says so:

{n} skills selected (score ≥ 3, at most 8) — about {n} tokens of the context budget. Scores are deterministic and every point has a reason; they are not probabilities. Anything switched off under "In use" never reaches this list at all.

Trying it

Workspace → Skills → What gets injected lets you route a hypothetical piece of work:

The router scores skills against the workspace's stack, the files touched, and what the work is about.

Give an intent — Add password reset endpoint — and some files, and it shows every skill it considered, its score, its reasons, and whether it would be injected or not injected. A skill with no match says so: "Nothing about this workspace or this work matched it."

In the brief

Skills get 18% of the context budget — about 28,800 characters. Each one renders with its name, version, its instructions, and up to three examples.

The section's instruction sets the precedence:

Follow them unless the constitution, a decision or a security rule contradicts one, in which case the workspace wins and you should say so.

Skills above the threshold are injected. The rest are named in the manifest as available and not injected.

Promotion to the platform

The one place knowledge crosses a tenant boundary, and it is gated.

A platform admin writes the platform version from scratch:

Write the platform version from scratch. The original is never carried across — the scanner checks what you write for anything that identifies the customer.

The original is shown for reference behind a collapsed disclosure labelled "do not paste it".

The leak scanner

The rewrite is scanned before a draft is created. Findings come in two severities.

Blocked — promotion is refused:

• Credential patterns: a populated password, accountkey or secret=; a private key block; an API key with a recognised prefix; a long bearer token; a JWT.
• The organization's full name and slug.
• Workspace names.
• Repository names and owners.

Flagged — allowed, but a reviewer must look:

• A single word from a multi-word organization name.
• GUIDs.
• Internal hostnames — .internal, .local, .corp, .intranet, .lan.
• Cloud resource names.
• Email addresses.
• Database schema references.
• Identifiers that appear in this organization's file paths and no other's.

Terms shorter than four characters are never matched, and about sixty generic words — insurance, logistics, systems, solutions, global, partners — are excluded outright.

A scan never echoes a secret: credentials are redacted to their first six characters plus dots.

Blocked:

The rewritten text still identifies the organization. Fix the findings and try again.

Clean or flagged, a draft is created on the platform shelf, with a changelog recording the scan result. Publishing it is still a separate act.

The customer-name check uses the SSO organization directory. If the directory or the local list of customer IDs is unavailable, promotion is blocked until the scan can be completed; missing directory data is not treated as a clean scan.

What the scanner is not

A guarantee. It cannot detect a paraphrased proprietary algorithm or a business rule described in generic words. The human approval stays mandatory.

The platform shelf

Admin → Skills, for platform administrators.

A draft lives only on this page. Promote to platform puts it in every organization's marketplace — but nothing here is ever injected on its own. A workspace has to switch the skill on under its own Skills page before any agent is briefed with it.

Platform skills must be generic — they land in every organization's marketplace, so nothing in them can assume one customer's systems.

Take down archives a platform skill: "Takes it off every marketplace — archived, versions kept for the runs that used them."

Related

• The brief
• Governance overview
• The platform admin area