One source of truth for agent rules.

A skill is one of the first-class node kinds in Bcontext. Its body must start with YAML frontmatter: name (required, becomes the section heading) and description (optional, short one-liner). The markdown below the frontmatter is the rule itself.

---
name: prefer-server-components
description: When and why to lean on RSC in this codebase.
---

# Prefer Server Components

- Default to server components. Client components are an opt-in via "use client".
- Never fetch data in a client component — pass it as a prop from a server parent.
- For shared state, use URL search params first, React state second.
- Use the suspense boundary nearest the data fetch, not the route root.

From any workspace you can export the curated skill set to four target formats. The same set of skill nodes drives:

• AGENTS.md— universal "cursor for agents" format, drop at repo root.
• CLAUDE.md — picked up by Claude Code at session start.
• .cursor/rules — Cursor reads each rule file at project open.
• .clinerules — Cline picks up rule blocks inline.

The generator is a pure function (src/lib/skills/generate.ts) — same skills in, same bytes out. Wire it into your CI to commit regenerated rules whenever the underlying nodes change.

# AGENTS.md

Agent skills curated in the **acme** Bcontext workspace.

_Generated. Do not edit by hand — change the underlying skill node and re-export._

## prefer-server-components

When and why to lean on RSC in this codebase.

# Prefer Server Components
...

Skills aren't just about style. Use them to encode review procedures, deployment runbooks, or post-incident lessons. The agent reads the same checklist a human would.

---
name: pr-review-checklist
description: How an agent should review a pull request in this repo.
---

# PR review checklist

1. **Scope.** One concern per PR. Flag bundles of unrelated changes.
2. **Tests.** New behavior needs a vitest test in src/**/*.test.ts.
3. **Types.** No `any` in new code; prefer `unknown` + narrowing.
4. **Migrations.** Schema changes require a numbered file under supabase/migrations/.
5. **Docs.** If the public API changed, /docs needs an update.

A skill node can also be a typed prompt template you invoke with structured input. The MCP tool run_skill and the REST endpoint POST /api/skills/[id]/run both consume the same frontmatter shape: declare your input fields, write the body with {{var}} placeholders, and the runtime validates, renders, and forwards to the AI Gateway.

---
title: Weekly review
model: anthropic/claude-sonnet-4-6
input_schema:
  fields:
    - name: activity_summary
      type: string
      required: true
system: |
  You produce terse weekly recaps. Markdown only. Under 200 words.
---

Generate the weekly review from the activity summary below.

Activity:

{{activity_summary}}

curl -X POST https://bcontext.es/api/skills/<node_id>/run \
  -H "Authorization: Bearer bctx_live_..." \
  -H "Content-Type: application/json" \
  -d '{
    "workspace": "bcontext",
    "input": { "activity_summary": "..." }
  }'

Every workspace template seeds three canonical starters: triage_inbox, weekly_review, and extract_decisions_from_meeting. They live under the Skills folder of any workspace created from the indie-hacker / ai-agency / startup-founder templates.

• Keep each skill short (under 30 lines). Long skills get ignored by the model.
• Name skills with kebab-case verbs (prefer-server-components, review-prs).
• Edit in the Bcontext web app. The MCP server exposes skills as resources, so agents see updates without a re-sync.
• For executable skills, the frontmatter system: block sets the system prompt at run time; model: pins the LLM (falls back to CHAT_MODEL env).