Scroll · Arrows · Space

Internal briefing · April 21 2026

Claude Skills
— how we're using them.

Skills are packaged instructions that teach Claude how Builder Prime does specific things — writing customer comms in our voice, reviewing estimates, summarizing trade reports. One well-built skill saves twenty people from re-prompting the same thing.

One toolbelt. Shared across the team.

Why now

Claude is a coworker now,
not a chat window.

Cowork, Claude Code, Claude for Excel/PowerPoint, Claude Design — all share the same skills system. A skill you write once runs wherever the team works.

1
Skill authored
∞
Times used
0
Custom tooling we build

What it actually is

A skill is a folder.

my-skill/
├── SKILL.md          ← instructions (required)
└── examples/         ← optional supporting files
    └── template.md

That's it. YAML frontmatter at the top tells Claude when to use the skill. The markdown body tells Claude how.

Example SKILL.md

---
name: estimate-reviewer
description: Reviews customer
  estimates for missing line items,
  math errors, and margin outliers.
  Use when the user asks to check,
  review, or QC an estimate.
---

# Estimate Reviewer

When given an estimate:
1. Check every line item against
   the job scope...
2. Flag items priced below 35%
   gross margin...
3. Return a punch list of issues
   with line references.

The one thing that matters most

Description makes or breaks a skill.

Claude reads only the description when deciding whether to fire a skill. Bad description → skill never triggers, no matter how good the body is.

✗ Useless

"An AI helper that assists with writing various kinds of documents."

✓ Specific

"Drafts customer-facing estimates in Builder Prime's house voice. Use when the user asks for an estimate, quote, or proposal for a home-improvement job."

  • Third person, not first. ✓ "Drafts estimates…" ✗ "I help you write estimates…"
  • Lead with when to use it. Include trigger phrases people actually say.
  • Name concrete nouns from our world. "estimate", "job scope", "change order" — not "document."
  • Keep SKILL.md under ~500 lines. Long stuff goes in linked reference files.

Naming conventions

Names tell you who owns it.

Skill names become slash commands (/estimate-reviewer) and appear in Claude's system prompt. A consistent naming rule prevents collisions and makes ownership obvious at a glance.

🏢 Company-wide (owner-provisioned)

Prefix with bp- so they're clearly firm-standard skills:

bp-estimate-reviewer
bp-customer-comms
bp-job-cost-summary
bp-weekly-ops-report

When a user sees /bp-* fire, they know it's the official version, not a personal draft.

👤 Personal / peer-shared

No prefix — use your own name or initials if you want to avoid clashes:

estimate-draft        ← personal
sam-daily-digest      ← initialed
team-sales-memos      ← team scope

Keeps personal experiments visually separate from the firm's blessed toolkit.

Four rules for every skill name, regardless of scope:
  • Lowercase, hyphenated. estimate-reviewer, not Estimate_Reviewer.
  • Gerunds where it fits. drafting-estimates, reviewing-proposals, summarizing-weekly-ops. Describes the ongoing activity the skill supports.
  • Concrete noun + verb. Avoid vague names like helper, assistant, tool.
  • No duplicate names. If someone already has estimate-reviewer, call yours estimate-reviewer-v2 or rename the concept.

How to create a skill

Ten minutes, no terminal.

  1. Open Claude Desktop → Cowork tab
  2. Click Customize → Skills in the left sidebar
  3. Install skill-creator via + → Browse skills
  4. In any session, say: "Use skill-creator to help me build a skill for [thing you keep doing]"
  5. Claude interviews you, drafts the SKILL.md, iterates
  6. Test it on 2–3 real prompts
  7. Share it (next slide)

What to build first

Pick a workflow you've already pasted into Claude more than three times. That's skill candidate #1.

Any repeated prompt = a skill.

Not sure what qualifies? Estimate review, customer-comm drafting, job-costing spot checks, weekly ops summaries, trade-partner scorecards — anything that has a pattern.

How to share

Three buttons. No git.

Anthropic ships three native sharing paths directly in Cowork. Pick based on blast radius.

Peer-to-peer in practice

From built to shared in 30 seconds.

  1. Open your skill in Customize → Skills
  2. Click Share on the skill page
  3. Pick Specific people → type a name or email
  4. Recipient sees it in their "Shared with you" section, grayed out until they enable it
The magic part: if you update the skill later, recipients automatically get the new version on their next session. No re-sending, no version pinging.

Recipient experience

  • Skill appears in Shared with you
  • Toggle on to enable · toggle off anytime · delete to remove from their list
  • View-only — they can't edit yours
  • If they want to customize, they download a copy and upload it as their own

Fork = download + reupload. Simple.

Our security posture

One toggle. Set it and move on.

✓ ON  ·  Skill sharing

Peer-to-peer. One author → one recipient at a time. Low blast radius. This is how 95% of Builder Prime skill sharing happens.

✗ OFF  ·  Share with organization

One-click publish to the whole team with zero review gate. Anthropic's own docs recommend keeping this off if you work with sensitive data. We do. So it stays off.

Why this matters. Snyk's Feb 2026 ToxicSkills study audited ~4,000 real-world skills and found 36.8% had at least one security flaw, 13.4% critical. Our team isn't malicious, but well-intentioned people paste API keys into SKILL.md files all the time. Peer-to-peer contains the blowup. Org-wide doesn't.

To push a skill to the whole team, route it through an owner (or eventually the marketplace — see appendix). That's the review gate.

Four habits, everyone

Don't ship these mistakes.

🚫 No credentials in SKILL.md

API keys, tokens, passwords — never paste them in. They land in context windows and (if you ever commit the skill) in git history. Use env vars.

🚫 No real customer data in examples

Skill examples get shared. Abstract customer names, addresses, PII, financial specifics. Synthetic data only.

✓ Review before enabling

When a colleague shares a skill with you, open it. Read the SKILL.md. Look at referenced files. If it fetches URLs, runs scripts, or calls external services, understand why before turning it on.

✓ Assume Claude will do what it says

If the skill says "read every file in ~/Documents and summarize", it will. Write like you mean it; read others' skills like your permissions depend on it.

Anthropic's phrasing, verbatim: "Treat skill installation with the same rigor as installing software on production systems."

Versioning practices

The native system doesn't version.
We do it by hand.

Cowork doesn't track versions, doesn't let recipients pin to an old copy, and auto-pushes your latest to everyone you've shared with. Live with that. Lean on these four practices so changes don't surprise anyone.

1. Changelog block at the top of SKILL.md

<!-- Version: 1.2.0 · 2026-04-21
     Owner: @sam
     Changelog:
       1.2.0 — tighter tone for estimates
       1.1.0 — added trade-specific flavor
       1.0.0 — initial -->

First thing a reviewer sees. Owner + version + what changed, in plain sight.

2. SemVer by discipline, not by tooling

  • Patch (1.1.0 → 1.1.1) — typo, tighter phrasing, no behavior change
  • Minor (1.1.x → 1.2.0) — new capability, old behavior still works
  • Major (1.x → 2.0.0) — output format changed, trigger changed, not backward-compatible

3. Announce majors before you merge

Any 2.0-scale change — drop a note in the team channel first. Everyone who has the skill gets it auto-pushed on their next session; don't ambush them.

4. Owner per skill, quarterly review

Every firm-wide skill has a named owner in the changelog. Once a quarter the owner confirms the skill still works, still makes sense, and either bumps the version or retires it.

Deprecation: when a skill is being retired, rename it DEPRECATED-<name> and strip the description so Claude stops firing it. Delete after 30 days once you're sure nothing depends on it.

For anything where rollback matters or multiple authors edit the same skill, use the marketplace (appendix) — git gives real history, PR review, and one-click revert.

Scheduled tasks

Any skill can run on a schedule.

/schedule is itself a built-in skill in Cowork. Type it in any session, describe the task, and Claude runs it on the cadence you pick — daily, weekly, cron-style. Each run spins up its own Cowork session with full access to your connectors, skills, and plugins.

What it's good for

  • Monday-morning weekly ops reports
  • Daily pipeline digest before standup
  • End-of-week sub scorecard
  • Monthly margin review against plan
  • Nightly review-response drafts

Anything that pairs well with “I want this already done when I sit down.”

How to set one up

  1. In any Cowork session, type /schedule
  2. Describe what you want done and when
  3. Claude confirms cadence + saves the task
  4. Review results under Scheduled in the left sidebar

Desktop must be open when the task is scheduled to run. No laptop = no task.

Naming convention for skills that are designed to be scheduled: prefix with bp-daily-, bp-weekly-, or bp-monthly-. Signals to teammates “this one's meant for /schedule, not ad-hoc use.” 
bp-daily-pipeline-digest        ← runs 7am weekdays
bp-weekly-ops-report            ← runs monday 6am
bp-weekly-sub-scorecard         ← runs friday 5pm
bp-monthly-margin-review        ← runs 1st of the month

You can still run scheduled-style skills ad-hoc any time — the prefix is about intent, not enforcement. It just helps authors and teammates reach for the right skill in the right context.

Company-wide skill list · TBD — draft candidates

What should every Builder Prime
session have on day one?

These are candidate owner-provisioned skills — things we'd flip on for everyone by default. None of these exist yet. The goal of the meeting is to confirm what belongs on this list, name owners, and pick the first 2–3 we actually build.

📝 bp-estimate-reviewer

Reviews customer estimates for missing line items, math errors, and sub-35% gross margin outliers. Fires on “check this estimate” / “review my quote”.

Owner: TBD

✍️ bp-customer-comms

Drafts customer emails and texts in Builder Prime's house voice — warm, direct, trade-savvy, no corporate mush. Fires on “draft a response” / “write a reply to”.

Owner: TBD

💰 bp-job-cost-summary

Summarizes a completed job's cost structure — labor, materials, subs, overhead, net margin — and flags outliers vs. estimate. Fires on “close out this job” / “job cost review”.

Owner: TBD

📊 bp-weekly-ops-report ⏰

Pulls jobs-in-progress, gross margin, pipeline stage, and subcontractor spend into the standard Monday-morning ops format. Designed for /schedule weekly. Fires on “weekly report” / “monday update”.

Owner: TBD

🧰 bp-change-order

Drafts change orders with scope delta, cost delta, and customer-friendly plain-English explanation in the Builder Prime template. Fires on “change order” / “scope change”.

Owner: TBD

👷 bp-subcontractor-scorecard

Generates a trade-partner scorecard from recent job data — on-time %, defect rate, callbacks, margin impact. Fires on “scorecard” / “how is [sub] performing”.

Owner: TBD

⏰ = recommended to run on /schedule. Stretch candidates for v2 — not day-one: bp-lead-qualifier (inbound lead triage), bp-marketing-copy (offer pages, landing pages), bp-daily-review-responder ⏰ (nightly Google/Yelp replies), bp-daily-safety-toolbox-talk ⏰ (morning job-site safety briefs).

What we're asking you to do

This week.

1 · Pick a workflow

Something you've pasted into Claude three or more times. That's your first skill.

2 · Use skill-creator

Open Cowork. Install skill-creator. Ask it to build your skill. ~10 minutes.

3 · Share with one person

Use the Share button. Pick a colleague. See if it works for them too.

If 3+ people want it, bring it to me — we'll promote it to a team-wide skill through an owner.

Roundup

Questions to answer in the room.

Build something. Share it with one person. Go.

Appendix · Optional implementation

The GitHub-synced marketplace route.

Everything above uses Cowork's native sharing. If you want CI validation, review gates, rollback, and cross-surface distribution (Cowork + Claude Code on the same skills), you layer a GitHub marketplace underneath. Skip this for now — it's optional, and for a later phase.

When to use the marketplace vs. native sharing
How to promote a Cowork skill to the marketplace

Requires a maintainer (engineering help available).

  1. Skill folder lives at ~/Library/Application Support/Claude/skills/<name>/ on macOS (or %APPDATA%\Claude\skills\<name>\ on Windows)
  2. Clone the marketplace repo (one-time): gh repo clone [private-repo]/builder-prime-skill-marketplace
  3. Copy the plugin template: cp -r plugins/_template plugins/<plugin-name>
  4. Drop your skill in: cp -r [skill-folder] plugins/<plugin-name>/skills/<skill-name>
  5. Fill in plugin.json and register in marketplace.json
  6. Run claude plugin validate . — must pass
  7. Open a PR, reviewer merges, Cowork auto-syncs within minutes
Non-developer shortcut: drop the skill folder path in the internal #skill-marketplace channel. A maintainer will PR it in about 5 minutes.
What the marketplace gives you that native sharing doesn't
  • Git history on every change — who wrote it, why, when
  • CI that validates the skill against Anthropic's schema before it ships
  • Required reviewer on sensitive paths (CODEOWNERS)
  • One-click rollback (revert the PR → next sync undoes it)
  • Per-plugin distribution control in Cowork admin UI (default-on / available / required / hidden)
  • Per-group overrides (ops-only skill, finance-only skill, etc.)
  • Cross-surface: Claude Code users install via /plugin marketplace add, same source of truth
Why we're not doing this on day one
  • Marketplace adds real overhead: maintainer review on every PR, git literacy for authors (or handoff to a maintainer)
  • At Builder Prime's current scale (<5 skills/month expected), admin review is cheaper than infrastructure
  • Anthropic is shipping weekly — anything custom we build on top risks drift within 90 days
  • Native sharing gives us 90% of the value with zero ops burden
  • Revisit when: we have 10+ skills, 5+ regular authors, or cross-surface need emerges

End of deck

Build one skill. Share it with one person. This week.

Internal — Builder Prime · access restricted to @onblueprint.com and @builderprime.com