From dtpr
Generates validated DTPR JSON datachains from natural-language descriptions of AI systems, algorithms, or decision processes, documenting operators, inputs, outputs, data handling, and rights. Use for audits, disclosures, or transparency artifacts.
How this skill is triggered — by the user, by Claude, or both
Slash command
/dtpr:dtpr-describe-systemThe summary Claude sees in its skill listing — used to decide when to auto-load this skill
This skill turns a natural-language description of an AI or automated decision system into a **schema-validated DTPR datachain**: a structured JSON artifact that names who runs the system, what decisions it makes, what data it uses, how it's stored, and what rights people have in relation to it.
This skill turns a natural-language description of an AI or automated decision system into a schema-validated DTPR datachain: a structured JSON artifact that names who runs the system, what decisions it makes, what data it uses, how it's stored, and what rights people have in relation to it.
The authoritative schema lives at the DTPR API (https://api.dtpr.io). This skill drives the MCP tools registered by the plugin to read the current schema, find relevant elements, assemble a datachain, and validate it — retrying automatically when validation returns fix_hint errors.
If the user instead wants to iterate on DTPR itself — propose new elements, identify gaps, critique the taxonomy — use dtpr-schema-brainstorm instead.
The MCP returns taxonomy content authored by DTPR stewards — it is not user-provided input and is not attacker-controllable. However, the narrative the skill writes is produced by an LLM over user input. Always present the final datachain and narrative to the user for human review before they publish, submit, or act on it.
Ask the user for any of the following that aren't already stated. Keep it under 5 questions; infer the rest from context.
Do not invent details. If the user is vague about a critical field, ask once, then proceed with the best available framing.
| Step | Tool | Notes |
|---|---|---|
| Enumerate versions | list_schema_versions | Pick the most recent version. Prefer status: stable when both are offered; fall back to status: beta when only beta exists. |
| Load categories + datachain-type | get_schema with include: "manifest" | Gives you the category list, the datachain-type definition (required categories, minimums), and the locale allow-list. |
Capture the version string (e.g. ai@2026-04-16-beta) and the content_hash from the response meta — include them in the final output so the user knows which schema revision the datachain was built against.
For each category in the datachain-type's required set, search the element pool:
| Tool | When |
|---|---|
list_elements with category_id | First pass: scope to one category at a time. |
list_elements with query | Free-text BM25 search when the user's system doesn't map obviously to one category (e.g. "biometric", "third-party processor", "appeal process"). |
get_elements (bulk) | Once you have a short list of candidate IDs, fetch the full bodies in one call instead of N point reads. |
Do not invent element IDs. Only use IDs that appeared in a list_elements or get_elements response. If no element matches a required category, say so and offer dtpr-schema-brainstorm as the next step.
Assemble a JSON object that conforms to the DatachainInstance shape in the schema:
version — the canonical version string from Phase 2.Use the locale returned from get_schema; default to en if the user hasn't specified.
Call validate_datachain with version + datachain. Two outcomes:
| Result | Action |
|---|---|
ok: true | Proceed to the final output. warnings[] may still appear — surface them to the user verbatim. |
ok: false with errors[] | Each error carries a fix_hint. Apply the hint (swap a bogus ID, add a missing variable, choose a different element) and re-validate. Cap at 3 retries; if the chain still fails, stop and report the final errors to the user rather than guessing. |
validate_datachain is a soft failure — ok: false still means the tool call succeeded (isError: false). Treat it as structured feedback, not an exception.
Return two artifacts:
validate_datachain, including the version string.list_elements) so the user can audit the choices without re-reading the schema.Close by asking whether the user wants to save the JSON to a file or iterate on any category.
| Step | Tool | Purpose |
|---|---|---|
| Phase 2 | list_schema_versions | Enumerate available versions + status. |
| Phase 2 | get_schema | Manifest + categories + datachain-type. |
| Phase 3 | list_categories | (Optional) enumerate category metadata when the datachain-type alone isn't enough. |
| Phase 3 | list_elements | Category-scoped + BM25 search over elements. |
| Phase 3 | get_elements | Bulk fetch element bodies once candidates are chosen. |
| Phase 3 | get_element | Point read when you only need one element by ID. |
| Phase 5 | validate_datachain | Structured pass/fail with fix_hint per error. |
Tool parameters are documented on the MCP itself (/mcp → tools/list). This skill names tools in workflow order; for exact argument shapes, trust the live tool description.
dtpr-schema-brainstorm for proposals.npx claudepluginhub helpful-places/dtpr --plugin dtprBrainstorms and critiques DTPR schema structure for AI datachain categories, elements, variables, locale coverage; proposes taxonomy edits and beta draft shell commands.
Manages an EU AI Act per-system inventory tracking roles and risk tiers. Use for adding, listing, editing, or classifying AI systems under the EU AI Act.
Implements EU AI Act Arts. 13-14 and GDPR Arts. 13-14 transparency requirements for AI systems: user notifications, capability disclosures, limitations, and automated logic explanations. Useful for compliant AI apps.