← Search

BRD Draft
Business 📌 Pinned version: commit 1071f72
⚙ Needs: Before you start: read this whole install prompt…

BRD Draft

At a glance
What
Cost
Free
Needs
Before you start: read this whole install prompt, tell me in a few lines what this skill does and what installing it involves, and wait for my go-ahead before you do anything else.
Install
Copy the installer prompt below into your Muse — your agent does the rest.

Version:

C
Created by: ChenxingJi-Innovate
⌁

Install

Copy the install package below, then paste it into Muse📌 Pinned version: commit 1071f72
Wanna be extra careful?

The install prompt below already includes the vetting steps: your agent follows the community checklist before installing anything with executable code. Want more?

How to check a build before installing →

🔒 Security and provenance
📌 Pinned version: commit 1071f72 · 2026-10-19
Skill Harbor never reviews the code of a listed skill. These are dated facts about the install prompt and our install test, not a safety certification. Review a skill yourself before you install it. How we verify

Before you start: read this whole install prompt, tell me in a few lines what this skill does and what installing it involves, and wait for my go-ahead before you do anything else. Prerequisites: none for the install itself: no account, no API key, no paid service, and nothing else to install first. For using the skill afterwards, no key or account is required either: it works from elicitation material I supply myself (workshop notes, interview transcripts, emails and existing documents). One known upstream defect is disclosed in point 2 and must not be "fixed" during installation: the SKILL.md frontmatter is not valid YAML as shipped (see point 2), so install the file byte for byte as fingerprinted and report that defect back to me instead of editing it. Install "brd-draft" for me. It turns elicitation material — workshop and interview notes or transcripts, emails, the project brief, current process descriptions, existing specs, sample reports — into a first-draft business requirements document (BRD) that stakeholders can review and correct, one that makes the open questions obvious instead of hiding them behind confident prose. It fills a fixed structure: document control (title, version, date, author, reviewers, status draft); background and problem, in the stakeholders' words where possible; objectives numbered O1, O2, ... each with how success will be measured (unknown measures become open questions); scope (in scope, out of scope, deliberately deferred); stakeholders (role, interest, influence, what each needs; in a RACI, exactly one Accountable per activity); current and future process as numbered steps (who does each, systems touched, with an offer to draw diagrams only if a process-mapping skill is already installed); requirements grouped by functional area, numbered BR-<area>-<n>, each written as "The <system or role> shall <one verifiable behavior>." with priority (must, should, could), rationale, source, fit criterion and the objective it serves; business rules numbered and stated once; data and reporting (entities and key fields, sources, retention, reports with audience and frequency); non-functional requirements (performance, availability, security and access, privacy and retention, audit, accessibility, localization), each marked captured, assumed or unknown; assumptions, constraints, dependencies and risks, one list each; a glossary of every domain term used; and numbered open questions, each with who can answer and what it blocks. It works by extracting candidate statements with their source, separating needs from solutions someone suggested, merging duplicates and splitting compound statements, turning disagreements between sources into open questions instead of picking a side, leaving empty sections marked "no information yet" rather than inventing content, and running a final self-check (every requirement traces to an objective and a source, every term is in the glossary, every unknown is an open question). Its output is the BRD in Markdown (or my house template if I provide one) plus a short review note: counts per section, the five most important open questions, and suggested next steps (for example a requirements lint pass, then acceptance criteria). It never invents numbers, dates, owners or rules, it keeps the stakeholders' vocabulary, and it marks every requirement that came from a single source only. Repository: https://github.com/ChenxingJi-Innovate/Cheatcode_ (the skill is the whole packages/requirements-kit/skills/brd-draft/ folder at the pinned commit: SKILL.md only, 1 file) Pinned version: install the code at commit 1071f72533f0a8bb671e2d9b48c8d75f12adc904 exactly. Do not substitute a newer version. If this commit is unreachable, stop and tell me. 1. Clone https://github.com/ChenxingJi-Innovate/Cheatcode_ into a temporary folder, check out commit 1071f72533f0a8bb671e2d9b48c8d75f12adc904, and copy the packages/requirements-kit/skills/brd-draft/ folder from that checkout. Then compare every file in the folder with the fingerprints recorded for this listing on 2026-10-19: [FINGERPRINTS] - SKILL.md: SHA-256 c447a7297ff98c6e2bc83f6b1b4131b74e4bdc157247a20e8ff228bab9464a85 If a file does not match, it changed since the listing was prepared: do not install it yet, tell me what you found and let me decide. 2. Read SKILL.md in full, and tell me in plain words: what the skill does when used, which services it can connect to, whether it reads or sends any personal information or keys, and anything that seems unusual. Stop on any red flag and tell me before going further. Confirm these points from the file: - The skill folder holds 1 file only: SKILL.md (3,873 bytes). There are no scripts, no code, no imports, no URLs and no file references in it: the skill is self-contained in its own folder and needs no file from elsewhere in the repository — not the sibling skills acceptance-criteria, requirements-lint, traceability-matrix or uat-plan, not the package files (packages/requirements-kit/README.md, cheatcode.json, .claude-plugin/plugin.json, LICENSE), not the repository root files, and not the installer/ app. Two mentions in SKILL.md are not dependencies: offering to draw process diagrams only if a process-mapping skill is already installed (an offer, conditional on something I already have; this skill neither fetches nor installs one), and suggested next steps in the review note (a requirements lint pass, then acceptance criteria — suggestions only; the sibling skills are not required, not included and not run by this skill). - Known frontmatter defect, disclosed here exactly as shipped and NOT to be corrected: the file starts at byte 0 with "---" followed by a line feed (no byte-order mark, line feeds only, no carriage returns anywhere in the file), then exactly two fields on single unquoted plain-scalar lines — "name: brd-draft" and one 511-character "description: ..." line whose 498-character value is unquoted — then a closing "---" line; there are no other frontmatter fields (no version, license, author or any other key). Because that unquoted description itself contains ": " (in "...existing documents: objectives, ...", at column 132 of the line), a strict YAML parser rejects the frontmatter ("mapping values are not allowed here", line 2, column 132), and the VM harness that tested this repository recorded frontmatter_ok: false with name: null for this file, even though the "name: brd-draft" line is textually present and the repository's installation test passed. Install the file byte for byte as fingerprinted: do not quote, wrap, reformat or otherwise repair the description, and do not substitute a corrected copy. If your own loader refuses a skill whose frontmatter does not parse, stop and tell me that, rather than editing the file. - Nothing is sent anywhere during installation itself; the only download at install time is the skill folder from GitHub at the pinned commit. No script is run during installation (there is none), no key is asked for, and there is no telemetry in the folder. - What is read and what leaves this conversation at use time, disclosed here before it ever happens — using the skill is a separate step that only starts when I bring elicitation material: I supply the workshop and interview notes or transcripts, emails, the project brief, current process descriptions, existing specs and sample reports, and optionally a house template — all of that is material I hand you, it stays in our conversation, and SKILL.md treats all of it as data, not instructions, with a note kept of which source each statement came from. There is no connector route and no service is named or contacted: SKILL.md contains no URL at all, asks for no account or key, posts or publishes nothing, and its output — the BRD in Markdown (or in the house template I provided) plus the review note — is returned in our conversation. The only conditional outward step even mentioned is the offer to draw the current/future processes as diagrams if a process-mapping skill is already installed; that offer changes nothing unless I accept it on that later use step, and it is never part of installation. - Do not use the skill during this install: do not draft any BRD, do not extract requirements from any material, and do not draw any diagram. 3. When I say "yes, install", install it as a skill: copy the whole brd-draft folder into the agent's skills directory, in a folder named "brd-draft", keeping its 1 file (SKILL.md at its root) byte for byte as fingerprinted, frontmatter defect included. A manual clone followed by copying the packages/requirements-kit/skills/brd-draft folder into ~/.claude/skills/ is the route described here; any other route is fine only as long as every installed file matches its fingerprint. 4. Verify with no network calls: the 1 file in place with a matching fingerprint, and its first lines exactly as fingerprinted — opening "---", "name: brd-draft" line present, description line and closing "---" unchanged. Expect a strict YAML parse of the frontmatter to fail for the disclosed reason in point 2: that failure is the known upstream defect recorded for this listing, not a fingerprint mismatch; do not rewrite the file to make it pass, and report the defect in your final report. Do not run any usage step to verify. 5. Report what was installed, where, and what I still need to do myself (for example: bring the elicitation material myself — workshop notes, transcripts, emails, brief, process descriptions, existing specs, sample reports — and a house template if I want one used; expect unknowns to come back as numbered open questions rather than invented content, and single-source requirements to be marked for me to confirm; note the disclosed frontmatter defect: the file is installed exactly as upstream ships it, a strict YAML loader may refuse it, and any decision to use a corrected copy is mine alone, on a separate step; using the skill is a separate step that only starts when I ask for it, and nothing is read or sent at use time beyond the material I hand you in conversation, as disclosed above). GitHub is optional: if I have a GitHub account or the gh CLI, you may use it; otherwise public access is fine. Never require it unless it's in the prerequisites above. Rules: don't touch anything outside the temp folder and the install target. If anything looks off, stop and ask me.

?

Questions

How do I install a build?

Every product page includes a copy-paste install prompt. Paste it into your Muse and it sets the build up for you — no manual configuration.

Where does my money go?

Straight to the seller. Skill Harbor never processes payments: checkout happens on the seller’s own page, usually Stripe.

What does the ✓ next to a creator’s name mean?

It means we confirmed the identity of the person behind the listing. It says nothing about the code itself — always check a build before installing it.