Skip to content
cccskills
FreePublished on GitHub

brd

Draft a Business Requirements Document (BRD) for cross-functional or stakeholder-heavy work that needs more structure than an intake. Use after `/intake` when the request spans multiple systems/teams, carries regulatory weight, or needs formal sign-off. Output lives at `docs/brd/<slug>.md`.

The English summary is being prepared. Showing the original description.

See how to install

Files included (2)

  • SKILL.md3.0 KB
  • template.md2.3 KB

SKILL.md (original)

Review the instructions the agent will receive before you install.

BRD — Business Requirements Document

You are drafting a BRD. BRDs are heavier than intakes — they exist when a request needs explicit sign-off from named business stakeholders, and when the why and the what must survive independently of the how (the spec).

Use a BRD when:

  • Multiple teams or external stakeholders need to align.
  • Regulatory, legal, or compliance concerns shape the requirements.
  • Business milestones or contractual dates are tied to the work.
  • Budget or headcount implications warrant an approved scope.

Don't use a BRD for: single-team feature work, quickfixes, or internal refactors. Those need an intake + spec, nothing more.

Prerequisite

Either /intake has completed (there's a corresponding docs/intake/<slug>.md), OR the user is starting directly at BRD because the intake exists upstream (e.g., in Linear/Jira) and they want to formalize it here.

Inputs

  • The intake document (if any) — it supplies Problem and Goal.
  • The user's additional context about stakeholders, timelines, and compliance.
  • template.md in this skill directory.

Steps

  1. If a corresponding intake exists at docs/intake/<slug>.md, read it. Map Problem → Business objective and Goal → Executive summary.
  2. Read template.md. Every heading must appear in the output.
  3. For each section, write content that answers the questions in the template comments. If unknown, list the gap under Open questions — never fabricate stakeholder names, dates, or dollar amounts.
  4. Name every requirement with an ID: BR-001, BR-002, … for business reqs; FR-001, … for functional; NFR-001, … for non-functional. Downstream spec AC will reference these IDs.
  5. Write to docs/brd/<slug>.md (same slug as the intake, if one exists).
  6. Tell the user: "BRD drafted at docs/brd/<slug>.md. Sign-offs required from: <list>. Open questions: N. Next: /scout (or get sign-offs first if you want to freeze scope)."

Drafting rules

  • Requirements are testable, not aspirational. "The system shall support peak traffic" is aspirational. "The system shall sustain 500 RPS with P95 < 200ms" is testable.
  • Separate business from functional from non-functional. A mixed list becomes unactionable.
  • Risks must have owners. "Risk: the vendor API could change" with no owner is noise. Either name who monitors it or delete it.
  • Sign-offs are names, not titles. "Head of Compliance" can't sign — their replacement, who is a specific person, can.
  • Do not write the solution. The BRD says what must be true; the spec says how. If you catch yourself writing "we'll use Kafka", stop — that belongs in /spec.

Reviews

No reviews yet. Tell others what you thought.

Comments

No login needed. Share how it worked for you, ask a question, or note where it did not run.

No comments yet. Be the first to write one.

Comments are published right away. Do not include personal information such as email addresses or phone numbers. Up to 2 URLs.

0 / 1,000 characters

This form is protected by reCAPTCHA, and the Google Privacy Policy and Terms of Service apply.

More skills from this repository

Phase 10.5 — move the slug's workflow artifacts (intake, scout, research, spec, approvals, swarm state, security reports, rendered diagrams) to docs/archive/<YYYY-MM-DD>/<slug>/. Runs before /commit so the committed tree is clean of work-in-flight files. workflow.json stays live and gets archived as the first step of /commit.

The English summary is being prepared. Showing the original description.

friedbotstudio/baseline14Updated Oct 13, 2026

Drift check between the baseline implementation on disk and the claims in `docs/init/seed.md` + cross-references in CLAUDE.md, README.md, and the rendered docs site. Verifies hook/agent/skill/command names + counts, settings.json wiring, project.json key presence, .mcp.json servers, vendored license files, and helper script presence. Exit 0 PASS / 1 FAIL — suitable for CI. Read-only; safe to invoke any time.

The English summary is being prepared. Showing the original description.

friedbotstudio/baseline14Updated Oct 13, 2026

PM-mode brainstorm helper. Captures the requirement via Socratic dialogue before any entry phase (`/intake`, `/spec`, `/tdd`) drafts its artifact. Stage 0 skip-check, Stage 1 gap-analysis, Stage 2 probe-loop, Stage 3 confirm-and-persist. Output lives at `docs/brief/<slug>.md`. Never proposes solutions — Stage 2 dialogue discipline is structurally enforced via `discipline.mjs`.

The English summary is being prepared. Showing the original description.

friedbotstudio/baseline14Updated Oct 13, 2026

chore

Free

Workflow track for tasks that need no TDD — documentation edits, governance count bumps, vendored-skill content updates, configuration tweaks, formatting, typo fixes, dependency bumps where no project code changes. Skips `/scenario` and `/implement` (no failing test to drive) and runs the work directly. `archive`, `memory-sync`, `/grant-commit`, and `/commit` remain mandatory. `verify`, `simplify`, `integrate`, and `document` are conditional — required when the diff hits one of the listed triggers, optional otherwise. `verify` is skipped only when the diff is pure-docs/prose AND `project.json → test.kind` is `behavior` (absent/invalid `test.kind` → `structural` → verify runs). Chore is a stripped-down pipeline, not a bypass; never silently skip a conditional phase whose triggers apply.

The English summary is being prepared. Showing the original description.

friedbotstudio/baseline14Updated Oct 13, 2026

Analyze a codebase and recommend Claude Code automations (hooks, subagents, skills, plugins, MCP servers). Use when user asks for automation recommendations, wants to optimize their Claude Code setup, mentions improving Claude Code workflows, asks how to first set up Claude Code for a project, or wants to know what Claude Code features they should use.

The English summary is being prepared. Showing the original description.

friedbotstudio/baseline14Updated Oct 13, 2026

Dev-only review of user-facing CLI interface copy in `src/cli/tui/*.js`, `src/cli/*.js` error paths, and `bin/cli.js` help/usage text. Surfaces three failure modes — copy/behavior mismatch, jargon, missing next-action — as a punch list the maintainer addresses before `/grant-commit`. Read-only; no writes to source. Conditionally seeded by `/triage` between `/memory-sync` and `/grant-commit` when the request will touch CLI surfaces.

The English summary is being prepared. Showing the original description.

friedbotstudio/baseline14Updated Oct 13, 2026

See all skills by friedbotstudio

Report a problem with this skill