12 Claude Skills for the Ops Your Design Team Already Runs On

What these skills are

The ops your team already has, written down and runnable. Every design team of 20 to 200 people already has DesignOps. It has a critique ritual (maybe "Thursday, whoever shows up"), a handoff standard (maybe "whatever the last engineer complained about"), a governance model for the system (maybe "ask Marta"), and an intake process (maybe "DM the lead"). The problem is not that these are missing. The problem is that they live in two heads and nobody can point at them.

One line holds through all of it: Claude designs the rituals and keeps the records, but the critique stays human.

No skill in this pack judges a design, scores a designer, or ranks anyone's work. The handoff check lists what a package lacks, never what a designer forgot. The capacity plan works at team and stream level, because per-person hour tracking is the fastest way to turn a planning tool into a performance tool. The onboarding plan is something the team keeps, not a test the joiner passes. The attention people pay each other's work is the one thing here that does not get handed to a file.

Mechanically, each skill is one folder with a SKILL.md file. Five of them write a standard once, four run per session, per feature, per change or per joiner, and three run on a cadence — the map quarterly, capacity weekly, the handbook whenever a standard moves. Each reads what the ones before it wrote, from one Claude Project per design team, so the map, the standards and the decision records stay in one findable place.

Download all 12 skills. One zip: ready-to-install skill zips and readable SKILL.md files. No templates to fill in — the skills read each other's output by file name. Free, no signup. The same 12 skills are open on GitHub: polar-bear-org/claude-skills.

The 12 skills you get

One skill writes the map, seven write the standards the team runs on, three handle the work coming in and the people doing it, and the last compiles the lot.

1 · Start with the map

1. Team Ops Mapper

Use when: You know the ops exist but nobody could write them down, or a quarter has passed since you last looked

Output: How your team works today, written as it is rather than as you wish it were: rituals, handoffs, tools, who decides what, and where it hurts. The first file in the project, and every other skill reads it. On a rerun it checks the standards written since against what is actually happening

2 · Write the standards, one at a time

2. Critique Ritual Designer

Use when: Crit is a calendar slot people dread or skip, and feedback lands as opinion

Output: The ritual on paper: cadence, format, who comes, what gets said in which order, the rules for givers and receivers, the objectives work is assessed against, and what happens to it afterwards. Claude designs the ritual; it never attends one

3. Critique Session Preparer

Use when: There is a crit on Thursday and the work needs a proper setup, or the crit just ended and nobody captured it

Output: Before: the objectives, the one question you need answered, what is out of scope today, and a walkthrough cut to three minutes. After: your raw notes turned into the reply your ritual asks for. Never an opinion on the work itself

4. Handoff Standard Writer

Use when: Engineers keep asking what the empty state looks like, and every handoff is different

Output: Your definition of ready for design-to-engineering handoff: what the package contains, every state and edge case, tokens instead of hex values, the motion spec instead of "make it feel smooth" — and the checkpoint conversation written into it, because a checklist with no checkpoint just moves the arguments later

5. Handoff Package Checker

Use when: A feature is about to go to engineering and you want to catch the gaps before they do

Output: One package walked through your standard item by item — present, missing, or unclear — as a list of what the package lacks, never what the designer forgot. It checks completeness against a standard your team wrote, not whether the design is good

6. System Governance Designer

Use when: The system drifts, people detach components, and nobody knows who decides

Output: Governance sized for your team rather than one fifty times larger: a named owner, the short written path a change takes, versioning, a deprecation rule so old things leave, the contribution path, and the decision-record format the next skill uses every time

7. System Change Recorder

Use when: Someone wants to add, change, or retire a component and the team needs a decision it can find later

Output: One proposed change run through your governance path — what exists already, who is affected, whether the coded library moves — and the decision record that outlives it, so next year's "why do we have two card patterns?" has an answer. Claude writes the record; a person makes the call, and the record says so on its first line

8. File Hygiene Standard Writer

Use when: Three files are called final and the new hire cannot find the current one

Output: How your team names, structures, marks, archives and branches its work, across the tools you actually use, on a page that fits on a wall. Every other skill that writes a file takes its names from here

3 · The work coming in, and the people doing it

9. Request Intake Designer

Use when: Requests arrive by DM and the lead decides by gut, every Monday

Output: The front door, all three parts: a brief short enough that requesters fill it in, triage rules that reach yes, not yet, or no without a meeting, and the wording that keeps the requester's goodwill when the answer is no — the part design teams lose the most on

10. Capacity Planner

Use when: The quarter looks impossible and you need to decide what moves before the team burns

Output: The arithmetic for a week, month or quarter: the design-days the team has against what the committed work and the intake log are asking for, what has to move, and the wording for the no. Team and stream level, never a per-person load report

11. Designer Onboarding Planner

Use when: Someone starts in two weeks and you want them to learn the team on purpose, not by osmosis

Output: A 30/60/90 plan for one named joiner, built from the standards you have already written: the buddy, their first critique as a participant before their first as a presenter, their first handoff checked by a peer, their first system contribution as a decision record. No measure of how the person is doing

4 · Put it in one place

12. Ways of Working Handbook Writer

Use when: You have most of the standards and want the whole thing in one readable place

Output: Everything the team has written, compiled into one document a joiner, a client or an engineer reads in twenty minutes, in the order a person meets the team's work. It carries the version of every standard it compiled, and where two standards disagree it flags the disagreement instead of picking a winner

How the standards get written

One DesignOps Studio project carries the whole thing. team-ops-mapper runs first and writes the map every other skill reads. Then the standards, in whatever order hurts most: critique-ritual-designer, handoff-standard-writer, system-governance-designer, file-hygiene-standard-writer and request-intake-designer each write one page, once, and each reads the map.

Four skills run per instance rather than once, and each reads the standard its partner wrote: critique-session-preparer the day before a session and again within 48 hours after, handoff-package-checker per feature before it goes to engineering, system-change-recorder per proposed change before anyone touches the library, and designer-onboarding-planner per joiner, two weeks out. Run one of them before its standard exists and it still works, from a default — and says so.

capacity-planner reads the intake log and does the arithmetic for the period, weekly in twenty minutes and properly once a quarter. ways-of-working-handbook-writer runs once at least four of the standards exist and compiles them into one readable document. Then team-ops-mapper comes back a quarter later, reads what has been written since, and checks it against what is actually happening.

Nothing else ships with the pack: no templates, no blank canvases. The skills find each other by file name inside your project — critique-ritual.md, handoff-check-checkout-flow.md, capacity-plan-2026-q4.md — and what accumulates over a quarter is the team's operating manual in the team's own words, with a record of every decision that shaped it.

The pack writes down how the team works; it does not do the design work. No skill here designs screens, runs research, or builds components — that work lives in the Design Thinking Pack. It does not hire or manage performance, and it stops at the handoff line: it defines what design hands over and how that conversation goes, not how engineering plans, builds, or releases.

Setup guide

1. Download the pack. One zip: an install folder with 12 ready-to-upload skill zips, and a skills folder with the same skills as readable files. There is nothing else to fill in — this pack ships no templates, because the skills read each other's output by file name.
2. Install your skills. In Claude Code, add the marketplace and install designops-pack, and all 12 load at once. In Claude, turn on code execution in Settings, Capabilities, then go to Customize, Skills and upload one zip per skill from the install folder. Prefer working from files? Add the SKILL.md files to your Project knowledge instead; it works, just less cleanly.
3. Create your DesignOps Studio. Make one Project per design team and call it DesignOps Studio. Keep one pinned chat per standard or ritual — Ops map, Critique, Handoff, Design system, Files, Intake and capacity, Onboarding, Handbook — so the crit prep does not fill up with capacity arithmetic. Every skill saves its output as a markdown file named for its artifact (critique-ritual.md, handoff-check-checkout-flow.md, capacity-plan-2026-q4.md), and later skills read the earlier files by those names. Then open the Ops map chat and write "run team-ops-mapper". Everything else reads the map it produces.

Where to start

The quality bar

Every skill in the pack holds the same standard, the one we hold when we write down how a team works:

• Claude designs the rituals and keeps the records; the critique stays human — no skill judges a design, scores a designer, or ranks anyone's work
• The map is written as the team works today, not as you wish it worked: you cannot redesign a ritual you have never seen on paper
• A standard describes what the team will actually do, not what an ideal team would do, which is what keeps it true a quarter later
• The handoff check produces a to-do list, never blame: gaps are what the package lacks, not what the designer forgot
• Governance is sized for your team, not copied from a company fifty times larger: a named owner and a short written path beat a review board nobody uses
• Every system decision leaves a record, and the record says on its first line that a person made the call
• Capacity is planned at team and stream level, never as a per-person load report: hour tracking is the fastest way to turn a planning tool into a performance tool
• Onboarding is a plan for the team to keep, not a test for the joiner to pass
• Where two standards disagree, the handbook flags it rather than picking a winner: the disagreement is a decision the team has not made yet

Who made this

Polar Bear is a people ops consultancy for human-size teams (20 to 200 people). Built by ex-McKinsey founders with a dream to make AI work for People, not instead of them. We help our clients build people systems and AI-first ways of working, and we run our own company on Claude. This pack is the free, self-serve version of how we work.

The pack writes down one team's ways of working. When you want your whole company working this way, AI carrying the overhead so people do the thinking, across design ops, hiring, and everyday work, that's what we build with clients.

Meet Pauline. Your team's ops live in two heads? Bring the crit nobody enjoys, the handoff that keeps slipping, or the design system nobody owns. Book a 30-minute call · Pauline on LinkedIn