A friendly assistant for Claude that interviews you and writes a professional Product Requirements Document (PRD), the plan behind a product or feature, without ever making up facts.
You talk, it asks smart questions, and a complete, well-structured document comes out the other end. No template wrangling. No blank-page paralysis. And above all, no invented numbers, names, or evidence.
- What is this, in plain words?
- Who is it for?
- Why people use it
- How it works
- A quick example
- Installation
- How to use it
- What's inside a PRD
- Diagrams
- Smart research features
- The honesty guarantee
- Quality score
- Where your files go
- Does it use the internet?
- For the technically curious
- Customize it for your team
- Glossary
- FAQ
- License
A PRD (Product Requirements Document) is the single document a team agrees on before building something. It answers: What are we building? Who is it for? Why now? How will we know it worked? What's in scope, and what isn't?
Writing a good one is hard. It's easy to leave gaps or describe a solution before you've explained the problem. And when you're in a hurry, it's easy to write down a number you think is right but never actually measured.
PRD Maker is a "skill" (an add-on) for Claude that fixes this. It:
- Interviews you one question at a time, in plain language.
- Writes the document for you as you answer, following a proven structure.
- Refuses to invent things. If you don't know a number, it writes a clearly-marked "to be determined" placeholder instead of guessing.
- Checks its own work and gives the finished document a score out of 100, with a list of anything still missing.
You end up with a document that looks like it came from an experienced product manager, because the rules of an experienced product manager are baked in.
- Product managers who want a faster path to a rigorous PRD.
- Founders and solo builders who've never written a PRD and want guardrails.
- Engineers, designers, and analysts asked to "write up" a feature.
- Anyone in a regulated industry (finance, health, anything touching personal data) who needs the compliance angle handled carefully.
You do not need to be technical. If you can have a conversation, you can use this.
| What you might struggle with | How PRD Maker helps |
|---|---|
| Staring at a blank page | It asks you questions instead, so you just answer |
| Forgetting important sections | It walks through every required section in order |
| Vague requirements | It turns each one into a clear "user story" with testable conditions |
| Made-up or fuzzy numbers | It never fabricates; unknowns become visible [TBD] markers |
| "Is this good enough to share?" | It scores the document 0 to 100 and lists what's missing |
| Regulations you're unsure about | It looks up likely rules, shows you the official source, and asks you to confirm |
| Claims with no backing | Every sourced fact is quoted and linked, never paraphrased from memory |
PRD Maker has three modes. You don't pick them; Claude figures out which one you want from how you ask.
| Mode | You say something like… | What happens |
|---|---|---|
| Generate | "I want a PRD for…" | A short intake, then a guided section-by-section interview, then a finished document |
| Review | "Review my PRD" | It reads an existing document, scores it, and tells you what to fix |
| Update | "Update the hypothesis" | It edits just one section and re-checks it |
In Generate mode there's a deliberate two-step rhythm:
- Intake first. Before writing anything, it asks a handful of orienting questions: what kind of product, which platforms, how many teams, whether any sensitive data is involved, how far along the idea is. This is so it never has to guess later.
- Then the interview. It works through each section in order, validates your answer, shows you the finished section, and moves on.
Two nice touches happen automatically: the document's version number ticks up as it changes (v0.1 → v0.2 → … → v1.0 when approved), and the "last updated" date is always kept current.
Here's the flavor of a Generate session (shortened):
You: I want a PRD for letting customers pay with a QR code.
PRD Maker: Great. A few quick questions before we start the document.
1. What's a working name for this?
2. In one sentence: what is it trying to do, and for whom?
You: "QR Pay." It lets shoppers pay merchants by scanning a code.
PRD Maker: You mentioned payments, so some financial regulations probably
apply. Based on your market (Indonesia), these likely matter:
PCI-DSS, Bank Indonesia's SNAP open-payment standard, and the
personal-data law UU PDP. This is a starting point, not legal
advice. Does that look right, or should I add/remove any?
You: That's right.
PRD Maker: Noted. I'll carry those into Background, Scope, and Risks.
Now, what problem are we solving, and who feels it today?
...
Notice what it did: it gathered context first, flagged the compliance angle, showed you its sources for you to confirm, and only then started writing.
- Claude. Either Claude Code (an app that runs on your computer and works directly with your project's files) or the Claude app (claude.ai on the web, or the desktop app).
- That's it. There's nothing else to install. In the Claude app, the skill's helper scripts run on Claude's side. In Claude Code they use Python 3 if your computer has it, and are skipped gracefully if not (Claude still scores the document itself either way).
If you're comfortable with a terminal:
git clone https://github.com/anatasof/NatPRD.git ~/.claude/skills/natprdRestart Claude Code (or just start a new session) and the skill loads automatically.
If you'd rather not use a terminal:
- Go to github.com/anatasof/NatPRD.
- Click the green Code button → Download ZIP.
- Unzip it, and rename the folder to
natprd(all lowercase). - Move that folder into your Claude skills folder, creating the folder first if it doesn't exist yet:
- Mac: in Finder, press
⌘ Shift G, paste~/.claude/skills, press Enter, and drop the folder in. If Finder says the folder can't be found, go to~/.claudeinstead, make a new folder there namedskills(⌘ Shift N), and dropnatprdinside it. - Windows: go to
C:\Users\[your name]\.claude\, create a folder namedskillsif there isn't one, and dropnatprdinside it.
- Mac: in Finder, press
- Restart Claude Code (or just start a new session).
Check it worked: type /natprd (it should autocomplete) or ask Claude "What skills are available?" and look for natprd in the answer. Then just say what you need; Claude handles the rest.
Upgrading from an old install? If you previously had it at
~/.claude/skills/NatPRD/(capital letters), rename it to lowercasenatprd. On Mac/Linux:mv ~/.claude/skills/NatPRD ~/.claude/skills/natprd.
Installing for a whole team? Put the same folder inside your project's repository at
.claude/skills/natprdand commit it. Everyone who opens that project in Claude Code then gets the skill automatically.
The Claude app installs skills as a ZIP upload. It's a one-time setup that takes about two minutes.
- Turn on the capability (once). In the app, open Settings → Capabilities and enable Code execution and file creation. Skills don't run without it.
- Get the ZIP into the right shape. Download the repo ZIP (green Code button → Download ZIP), unzip it, rename the folder to
natprd(all lowercase), then compress that folder back into a ZIP (right-click → Compress on Mac, Send to → Compressed (zipped) folder on Windows).- Why the re-zip? The app requires the folder inside the ZIP to match the skill's lowercase name, and GitHub's download is named
NatPRD-main, so uploading it as-is will fail.
- Why the re-zip? The app requires the folder inside the ZIP to match the skill's lowercase name, and GitHub's download is named
- Upload it. In the app's settings, find Skills (under Capabilities or Customize, depending on version), choose Upload skill, and pick your
natprdZIP. The app readsSKILL.mdand shows a summary; make sure the skill's toggle is on.
That's the whole install. Everything rides along in the ZIP: templates, rules, the regulation list, and even the helper scripts (they run on Claude's side). So scoring and regulation lookup work just like in Claude Code.
One difference from Claude Code: the app can't write into a folder on your computer. The finished PRD arrives as a downloadable file instead; save it wherever you like (e.g. as
docs/prd.mdin your project).
Can't enable code execution? Some workplaces switch it off. The older Project-based setup still works: create a Project, paste the entire contents of
SKILL.mdinto the project instructions, and uploadprompts/interview-questions.md,prompts/section-rules.md,prompts/validation-rules.md,templates/prd-template.md, andtemplates/prd-summary-template.md(plusreferences/api-docs.mdif your PRDs name outside vendors) as project knowledge. Scoring uses the rubric in those files, regulation lookup falls back to the built-in table ininterview-questions.md, and you copy the finished PRD out of the chat.
Once installed, just talk to Claude naturally:
Create a new PRD
"I want a PRD for adding two-factor authentication"
"Help me write a PRD for the merchant onboarding flow"
"Create a PRD for our loyalty points system"
Review an existing PRD
"Review my PRD"
"Validate the PRD at docs/prd.md"
Change one part
"Update the hypothesis in the PRD"
"Add a new user story to the requirements section"
Make a short version for stakeholders
"Generate a one-page summary of the PRD"
In Claude Code you can also invoke it directly by typing /natprd.
Every PRD has 12 core sections (always included) and up to 4 optional sections (added only when they're relevant; for example, the Risks section appears automatically when sensitive data is involved).
| # | Section | In plain words |
|---|---|---|
| 1 | Initiative Name | A short, clear name for the thing you're building |
| 2 | Document Status | Who wrote it, who owns it, who reviews/approves it, and which version this is |
| 3 | Background | The problem, who it hurts, and proof it's real (plus any regulations and benchmarks) |
| 4 | Objective | The single business outcome you want, with measurable targets |
| 5 | Scope & Boundaries | What's included, what's deliberately left out, and why |
| 6 | Hypothesis | Your bet, written so it can be proven right or wrong |
| 7 | Success Metrics | The numbers that tell you it worked (and the ones that must not get worse) |
| 8 | Requirements | Each need written as a "user story" with testable pass/fail conditions |
| 9 | Solution | How it works for the user, with links to designs and the alternatives you rejected |
| 10 | Metric Monitoring | Who watches the dashboards after launch, and when to pull the plug |
| 11 | Event & Data Tracking | Exactly what gets measured, so the metrics in §7 actually have data |
| 12 | FAQ | Questions people have asked, with answers and owners for the open ones |
| # | Section | Added when… |
|---|---|---|
| 13 | Risks & Mitigations | Payments, regulated data, or multiple teams are involved |
| 14 | Dependencies | You rely on another team or an outside vendor |
| 15 | Launch Plan | The rollout is staged, phased, or needs sign-offs |
| 16 | Stakeholder Map | Several teams or external parties need to be kept in the loop |
A wall of text is hard to picture. At a few natural points the skill can add a small diagram right next to the part it illustrates, so reviewers can see a flow at a glance. Two kinds are supported:
- A flowchart of a user flow (in the Requirements and Solution sections), built from the pass/fail scenarios you already described.
- A sequence diagram of how an event travels (in the Solution and Tracking sections), built from the event you already mapped (who triggers it, whether it is client or server side, and where it lands).
Three things matter about how this works:
- It asks first. The skill offers a diagram, shows you the diagram text, and adds it only after you say yes. Nothing is drawn behind your back.
- It only draws what you confirmed. A diagram is a picture of facts already in the PRD, never
a source of new ones. It will not invent a step, a branch, or a system you did not mention; if
something is unknown it labels it
[TBD], the same as everywhere else. - It is just text. Diagrams are written in Mermaid, a plain-text format that renders as a real picture on GitHub and in most Markdown viewers. There is nothing to install, and the diagram stays readable even where it is not rendered.
Diagrams are an optional extra. They do not change your quality score; the checker only flags a diagram that is malformed (for example, an unfinished placeholder), as a gentle warning.
PRD Maker can pull in real, verifiable facts, but only from sources you point it to or from a small built-in list of official references. It never goes searching the web on its own, because that's how AI tools end up citing things that don't exist.
When your idea touches money, identity, health, or personal data, the skill consults a built-in, dated list of regulations (references/regulations.json) and suggests the ones likely to apply, each with a link to the official source. It covers common rules across regions, including:
GDPR, PCI-DSS, HIPAA, PSD2, CCPA/CPRA, Singapore's PDPA & MAS Notice 626, Thailand's PDPA, Indonesia's UU PDP & OJK rules & Bank Indonesia SNAP, China's PIPL, Illinois BIPA, COPPA, India's RBI rules, and the FATF anti-money-laundering standards.
It then asks you to confirm the list (it's a starting point, not legal advice), and can optionally fetch the official page to quote the exact obligation. If you're unsure, it writes [TBD — legal/compliance to confirm] rather than inventing requirements.
If you want to ground a target in an industry or competitor number ("top apps in our space convert at X%"), it records it with the source, the date, and a comparability note (because a benchmark from a different market or definition can mislead). It will never invent a benchmark figure.
If your feature relies on an outside service (a payment processor, an identity checker, a cloud vendor), the skill can read that vendor's official documentation and pull real limits (rate limits, quotas, uptime promises) straight into the relevant sections. If the docs don't say, it writes [TBD — confirm with vendor docs].
Every fact that comes from a source is quoted directly (never paraphrased from memory) and tagged inline like [source: …, retrieved: 2026-06-03]. All sources are also collected into a single References / Sources list at the bottom, so a reviewer can audit where every claim came from.
This is the feature people care about most, so it's worth stating plainly:
PRD Maker will not make things up.
If you don't have a number, a name, a date, a design link, or evidence, it writes a visible placeholder (like [TBD — baseline needed] or [No design link — status: Draft]) instead of inventing something plausible. Those placeholders are deliberately ugly so they're easy to spot and fix, and they pull the document's score down until they're resolved.
It also pushes back gently when you're vague, and it never paraphrases a source; it quotes the exact words or number. The result is a document you can trust: anything stated as fact is either something you confirmed or something clearly marked as still-open.
When the document is done (or when you ask it to review one), PRD Maker scores it out of 100 and tells you the band:
| Score | Band | What it means |
|---|---|---|
| 90 to 100 | Excellent | Ready to circulate for review |
| 75 to 89 | Good | Solid; fix the flagged warnings first |
| 60 to 74 | Needs Work | Several sections are incomplete |
| Below 60 | Not Ready | Major gaps; don't share yet |
The report separates hard problems (violations: things that must be fixed) from softer ones (warnings: things you should look at), and lists exactly where each one is.
- Your PRD:
docs/prd.md(or any path you ask for, e.g. "save it toprds/2026-q3-auth.md"). - The quality report: shown right in the chat after it's written.
- Optional one-page summary:
docs/prd-summary.md, for stakeholders who won't read the full thing.
(In the Claude app, the PRD arrives as a downloadable file instead, and the quality report still appears in the chat.)
Yes, because Claude does. The skill is just a set of instructions that Claude follows, and Claude runs by talking to Anthropic's servers over the internet (in both Claude Code and the Claude app). So this isn't an offline tool: you need a connection for it to work at all, and your conversation (including any files or text you share) is sent to Claude exactly like in a normal chat.
What the skill itself won't do is wander off and browse the web on its own. That part is deliberately locked down:
- It only opens a web page you named (or an official source it suggested and you confirmed), and it shows you every fetched fact before using it.
- It never runs open-ended web searches. If you didn't name a source, the skill treats it as not existing and writes a
[TBD]instead. - Reading files on your computer and the built-in reference lists pulls nothing extra from the web. Their contents are still processed by Claude like everything else in the chat.
- Private/locked pages (Confluence, Jira, internal wikis) can't be fetched, so it'll ask you to paste the relevant text instead.
Want to tighten that further? In Claude Code, removing WebFetch from the allowed-tools line at the top of SKILL.md means Claude must ask your permission before each fetch; to block fetching outright, add a disallowed-tools: WebFetch line below it. The skill keeps working either way; it just asks you to paste anything it would otherwise fetch. In the Claude app, web access is controlled by the app's own settings instead. (None of this makes Claude itself run offline.)
Everything below is optional; the skill works without you ever opening these files.
natprd/
├── SKILL.md ← The skill's brain: instructions Claude reads
├── README.md ← This file
├── templates/
│ ├── prd-template.md ← The blank PRD structure
│ └── prd-summary-template.md ← The one-page summary structure
├── prompts/
│ ├── interview-questions.md ← The questions asked for each section
│ ├── section-rules.md ← The pass/fail rules for each section
│ ├── validation-rules.md ← How the 0 to 100 score is calculated
│ └── diagram-rules.md ← How Mermaid diagrams are proposed and drawn
├── references/
│ ├── regulations.json ← The dated regulation list (rules → official URLs)
│ └── api-docs.md ← Official documentation links for common vendors
└── scripts/
├── validate.py ← Scores a PRD automatically (Python 3, no extra installs)
└── lookup_regulation.py ← Suggests regulations from the list (Python 3, no extra installs)
The folder follows Anthropic's open Agent Skills format, so the same unchanged folder also works beyond the two install options above. For example, you can upload it via the Skills API for use in agents you build on the Claude API.
Score any PRD file (prints a detailed JSON report: per-section scores, violations, warnings):
python3 scripts/validate.py docs/prd.mdSee which regulations the built-in list suggests for a given situation:
# signals: payments, ekyc, pii, credit, insurance, biometric, healthcare, cross_border, children
# geo: a country code such as ID, SG, EU, US, US-CA
python3 scripts/lookup_regulation.py --signals payments,pii --geo IDBoth scripts use only Python's standard library, so there's nothing to install. The automated score is the structural baseline; Claude layers human-judgment checks (is the problem really stated before the solution? is the owner a real person, not a team?) on top.
The validator checks structure deterministically (valid status, named reviewers, two test scenarios per requirement, events that map to metrics, monitoring fields filled in, open FAQ items having owners, regulation rows naming a specific regulation, citations carrying a date, and so on). Anything that needs judgment is left to Claude. The total is always out of 100; optional sections are checked but don't change the number.
PRD Maker ships with sensible, opinionated defaults, but every team has its own house style, its own definition of "done," and its own regulations. The skill is built to be molded to your workflow. There are two ways in: ask Claude to make the change for you, or fork the project to get your own copy that you fully control. A fork lets you change whatever you like and still pull in future improvements from the original.
Everything that drives the skill is a plain text file, and no programming is required for most changes. If you can edit a document, you can customize the skill. If you'd rather not touch a file at all, the first route below is for you.
The skill's files are instructions written in plain English, and Claude is good at editing its own instructions. Describe the change you want in Claude Code, in your own words:
"In the natprd skill, add an accessibility question to the Requirements
interview, and make the score check for it."
"Change the PRD template so Document Status sits in a table at the top."
"Add Brazil's LGPD to the skill's regulation list, with its official URL."
Claude finds the right file (or files), makes the edit, and keeps the scoring files in sync (see the chain below). Claude Code picks up skill edits immediately, so the very next PRD follows your new rules.
Using the Claude app? Uploaded skills are a snapshot; they don't update themselves. Make your changes to the
natprdfolder on your computer first (ask Claude for help, or use any text editor), then re-zip the folder and upload it again under Skills in the app's settings, replacing the old copy.
The steps below are the edit-it-yourself route. It's also the better setup for teams, because a fork gives everyone one shared, versioned copy.
A "fork" is your personal copy of this project on GitHub. You own it, you can change anything in it, and it stays linked to the original so you can pull updates later.
- Go to github.com/anatasof/NatPRD and click Fork (top-right). You now have your own
github.com/your-username/NatPRD. - Install your fork instead of the original, using the same steps as Installation, just with your URL:
No terminal? Download your fork's ZIP and drop it into
git clone https://github.com/your-username/NatPRD.git ~/.claude/skills/natprd~/.claude/skills/exactly as in the install steps. - Edit the files and save. Claude Code picks up skill edits right away, with no reinstall needed. (In the Claude app, re-zip and re-upload the folder, as in the note above.)
Just trying things out? You can also edit the installed files in
~/.claude/skills/natprd/directly, without forking. Forking is the better long-term choice if you want to keep your changes safe, share them with teammates, or pull in future updates.
You don't need any special software. Every file except scripts/validate.py is plain text, so any editor works (TextEdit on Mac, Notepad on Windows). If you forked, you can even edit on the GitHub website itself: open a file and click the pencil icon. For validate.py (the one Python file), describe the check you want and let Claude write it.
Here's everything you can tailor, along with what you gain by doing it:
| File | What it controls | A change you might make | What you gain |
|---|---|---|---|
templates/prd-template.md |
The shape of the final document: sections, headings, tables | Add a "Localization" section, add your company header, or drop a section you never use | Output matches your house style, with no reformatting after the fact |
templates/prd-summary-template.md |
The one-page stakeholder summary | Add the three numbers your execs always ask for | Leadership gets exactly what they scan for |
prompts/interview-questions.md |
The questions Claude asks for each section | Add probes your team always forgets (accessibility, fraud, data retention) | Those gaps get captured every time instead of slipping through |
prompts/section-rules.md |
The pass/fail rules per section | Tighten or relax a standard; require a field you care about | The skill enforces your definition of "done" |
prompts/validation-rules.md |
How the 0 to 100 score is weighted | Make Requirements worth more; add a rule for a section you added | The score reflects your priorities, not the defaults |
references/regulations.json |
The built-in regulation list | Add your country's rules, fix a source URL, update last_reviewed |
Compliance suggestions fit your market and stay current |
references/api-docs.md |
Official documentation links for vendors | Add the payment / identity / cloud vendors you actually use | Real API limits get pulled from your real stack |
scripts/validate.py |
The automated structural checker | Add a check for a mistake your team keeps making | Recurring errors get caught automatically, before human review |
SKILL.md |
The skill's overall behavior and trigger phrases | Change the default save path, the tone, or how it's activated | The workflow fits how your team already talks and works |
Each of these works word for word as a request to Claude, or as a map of what to edit by hand (the files involved are named in each one).
- "We're a fintech in Indonesia." Ask Claude to add OJK and Bank Indonesia entries to
regulations.json, make Indonesia the default geography, and add interview probes about duplicate charges and settlement timing tointerview-questions.md. → The compliance and edge cases you care about are handled by default. - "We don't use Gherkin." Ask Claude to replace the Given/When/Then block in
prd-template.mdwith your scenario format, and update the matching rules insection-rules.mdand the check invalidate.py. → Requirements come out in your preferred format. - "Our execs only read summaries." Ask Claude to expand
prd-summary-template.mdwith your KPIs and a one-line risk callout. → One-pagers land without extra editing. - "We always forget accessibility." Ask Claude to add an accessibility question to the Requirements interview and a matching rule. → Every PRD now covers it.
- "We live in Jira / Linear." Ask Claude to add ticket-link fields to the template and a question that prompts for them. → Traceability to your tracker is built in.
If you add, rename, or remove a section, update these four together so the score stays correct. They form a chain:
templates/prd-template.md (defines the section) → prompts/section-rules.md (defines pass/fail) → prompts/validation-rules.md (sets the points) → scripts/validate.py (does the automatic check)
This chain is exactly what Claude maintains for you on the no-edit route, which is why that route is the safest one for structural changes.
After any change, run a quick self-test to make sure the checker still works:
python3 scripts/validate.py docs/prd.mdNot comfortable with a terminal? Ask Claude instead: "re-score the PRD and check that the four scoring files still agree."
Because you forked, you can keep your copy fresh without losing your edits:
git remote add upstream https://github.com/anatasof/NatPRD.git # one time only
git fetch upstream
git merge upstream/main # bring in new features; resolve any overlap with your changesNo terminal? On your fork's GitHub page, click Sync fork to pull in the latest changes, then reinstall the same way you installed the first time: re-download the ZIP and replace your installed folder (Claude Code), or re-zip and re-upload it (Claude app).
And if you build something broadly useful, consider opening a pull request back to the original, so other teams benefit and your change rides along with future releases.
New to product-doc jargon? Here's what the terms mean.
| Term | Plain meaning |
|---|---|
| PRD | Product Requirements Document: the plan for what you're building and why |
| User story | A requirement written as "As a [type of user], I want to [do something], so that [benefit]" |
| Gherkin / acceptance criteria | A simple "Given / When / Then" recipe describing exactly what counts as the feature working |
| NFR | Non-Functional Requirement: qualities like speed, security, or uptime (not a feature itself) |
| Leading vs. lagging metric | Leading moves early and predicts success; lagging confirms it later |
| Guardrail metric | A number that must not get worse as a side effect of your change |
| MoSCoW | Priority labels: Must-have / Should-have / Could-have / Won't-have-this-time |
| Baseline / target | Where a metric is today vs. where you want it to be |
| Hypothesis | Your testable bet about what will happen and why |
| Scope | What's included; out of scope is what you're deliberately leaving out |
| PII | Personally Identifiable Information: data that can identify a person |
| eKYC | Electronic "Know Your Customer": verifying someone's identity online |
| DRI | Directly Responsible Individual: the one named person on the hook |
[TBD] |
"To be determined": a visible placeholder for something not yet known |
Do I need to be technical to use this? No. You answer plain questions in a chat. The technical files run behind the scenes: on your computer in Claude Code, or on Claude's side in the Claude app.
Does it work in the regular Claude app, not just Claude Code?
Yes. The app installs skills directly now: upload the natprd folder as a ZIP (see Installation, Option 2). Scoring and regulation lookup work fully there, because the helper scripts run on Claude's side. The one difference: the finished PRD arrives as a downloadable file rather than being saved into your project folder.
Why does it ask so many questions before it starts writing? So it never has to guess. A few minutes of context up front is what lets it avoid invented metrics, fake design links, and made-up evidence later.
Will it ever invent a number or a name to fill a gap?
No. That's the core promise. Gaps become visible [TBD] markers that lower the score until you fill them.
Can I change the template or rules to match my company's standards? Yes, that's encouraged. See Customize it for your team for the full list of what you can change (and the upside of each). The easiest way is to ask Claude to make the change for you; forking the repo is the sturdier setup for teams.
Is the regulation list legal advice? No. It's a helpful, dated starting point that always asks you to confirm and points to official sources. Treat it as a prompt to check with legal/compliance, not a substitute for them.
Is my data sent anywhere? Your conversation is processed by Claude over the internet, just like any other Claude chat; that's how Claude works at all. Beyond that, the skill fetches only the pages you explicitly name (or confirm), shows you every fetched fact before using it, and never runs background web searches. See Does it use the internet?.
BSD 3-Clause: free to use and redistribute, with attribution. Don't use the author's name to endorse derived works.