Skills for turning scattered, uncited paperwork into a structured case file: ingest documents, normalize records, store evidence, retrieve deterministically, validate citations, and export a human-reviewed packet.
Read this page like a triage menu. Find the skill that removes a repeated explanation, a fragile manual step, or a quality bar the agent keeps missing. Then copy the setup prompt and let your agent adapt it to your tools, files, accounts, and standards.
Install the primitive only when you can name the workflow it will improve.
9 skills
How to use this category.
If you are building this lane from scratch, start with PDF / Document Ingestion. Otherwise, skip directly to the skill that matches today's bottleneck. The prompt is the starting point; the installed skill should reflect your real workflow.
PDF / Document Ingestion
Converts PDFs, scans, forms, CSVs, and loose source files into lightweight markdown or tabular artifacts with stable source anchors. The skill treats ingestion as a chain-of-custody step: every paragraph, row, or form field needs a path back to the original file, page, heading, row, or box.
Why build it
Most bureaucratic workflows fail before reasoning starts because the evidence is trapped in documents the agent cannot cite cleanly. Ingestion makes the file system usable: the original stays intact, the converted text is greppable, and every later draft can point back to the source instead of hand-waving.
What you need
A local folder of source documents · PDF/text conversion tools available to the agent · A chosen output folder convention such as work/<case-id>/ingested
Show the full setup prompt
<prompt>
<task>Create a new skill called "pdf-document-ingestion".</task>
<job>Turn heavy or messy documents into lightweight artifacts with stable source anchors before analysis begins.</job>
<requirements>
<requirement>Preserve original files unchanged.</requirement>
<requirement>Convert PDFs and forms into markdown or structured text.</requirement>
<requirement>Attach source anchors for page, heading path, row, box, or file location.</requirement>
<requirement>Write an index listing each converted artifact, source path, document type, and conversion confidence.</requirement>
<requirement>Never analyze the original heavy file directly when an ingested artifact exists.</requirement>
</requirements>
<verification>Run the skill on one sample document and prove that a converted paragraph can be traced back to its source anchor.</verification>
</prompt>
Document Chunking and Tagging
Splits ingested documents into addressable sections and tags each chunk with document type, normalized section label, domain relevance, source anchor, effective date, and content. The skill favors structure-first tagging over vector similarity when the source documents have known sections.
Why build it
A good chunk is reusable by any model. A bad chunk is a landmine. Chunking and tagging is the seam that lets healthcare appeals, tax prep, contract review, and grant packets all share the same retrieval discipline while keeping their domain labels separate.
What you need
Ingested markdown/text artifacts · A domain-specific section-label map · A target store such as SQLite or Open Brain
Show the full setup prompt
<prompt>
<task>Create a new skill called "document-chunking-tagging".</task>
<job>Split ingested documents into addressable chunks and apply normalized metadata.</job>
<schema>
<field>chunk_id</field>
<field>case_id or plan_id</field>
<field>document_type</field>
<field>section_label</field>
<field>domain_tags</field>
<field>source_anchor</field>
<field>effective_date</field>
<field>content</field>
</schema>
<requirements>
<requirement>Use headings, form boxes, table rows, and known document structure before semantic guessing.</requirement>
<requirement>Keep chunks small enough to retrieve directly, but large enough to preserve the clause or table meaning.</requirement>
<requirement>Flag unclassified sections for review instead of inventing labels.</requirement>
</requirements>
<verification>Show a query that pulls one chunk by section_label and returns its source_anchor.</verification>
</prompt>
Case Data Normalization
Turns messy facts into a normalized case ledger: dates, parties, amounts, codes, categories, document links, confidence, and review status. It separates extracted facts from inferred classifications so a human can see which fields came from the page and which fields need judgment.
Why build it
Scattered facts are how institutions keep the advantage. Once the facts become a ledger, the agent can compare, query, audit, and draft against them. Normalization is the move from a pile of paperwork to a case file.
What you need
A target case type · Source artifacts with anchors · A schema for records and review flags
Show the full setup prompt
<prompt>
<task>Create a new skill called "case-data-normalization".</task>
<job>Extract messy document facts into a structured, reviewable ledger.</job>
<requirements>
<requirement>Define the minimum schema for the current domain before extraction.</requirement>
<requirement>Store source-backed facts separately from agent classifications.</requirement>
<requirement>Track confidence and review_status for every normalized record.</requirement>
<requirement>Preserve evidence links to source chunks, pages, rows, boxes, or files.</requirement>
<requirement>Produce unresolved_questions when required fields are missing or contradictory.</requirement>
</requirements>
<verification>Normalize one sample case and show which fields came directly from source evidence.</verification>
</prompt>
SQLite Case Store
Creates a local SQLite database for source documents, chunks, normalized records, retrieval mappings, run outputs, and validation results. It is the default starter backend because it is local, inspectable, portable, and enough for one person's case file.
Why build it
A case file needs durable structure, not another chat transcript. SQLite gives the workflow a real query surface without creating infrastructure theater. You can inspect it with standard tools, copy it with the repo, and swap it later when the system earns more complexity.
What you need
SQLite available locally · A schema migration folder · A convention for case IDs and generated work folders
Show the full setup prompt
<prompt>
<task>Create a new skill called "sqlite-case-store".</task>
<job>Stand up a local SQLite store for document-grounded case workflows.</job>
<requirements>
<requirement>Create tables for source_documents, chunks, normalized_records, retrieval_mappings, run_outputs, and validation_results.</requirement>
<requirement>Keep original document paths and source anchors in the database.</requirement>
<requirement>Provide scripts for migrate, inspect, query-by-section, and export-case.</requirement>
<requirement>Do not store secrets or real private data in committed fixtures.</requirement>
</requirements>
<verification>Run a migration, insert sample chunks, and demonstrate a WHERE section_label query.</verification>
</prompt>
Open Brain Case Store
Adapts the same case-file schema to Open Brain for OB1 users who want the normalized records, chunks, and source anchors inside their durable personal context layer instead of a local SQLite file.
Why build it
SQLite is the right starter path. Open Brain is the upgrade path for people already running OB1: the same primitives become part of a larger memory and retrieval system instead of staying trapped in one folder.
What you need
An existing Open Brain / OB1 setup · A project or case namespace · A mapping from starter schema fields to Open Brain primitives
Show the full setup prompt
<prompt>
<task>Create a new skill called "open-brain-case-store".</task>
<job>Map document-grounded case workflows onto Open Brain instead of SQLite.</job>
<requirements>
<requirement>Start from the same logical schema used by the SQLite case store.</requirement>
<requirement>Define where source documents, chunks, normalized records, retrieval mappings, and run outputs live in Open Brain.</requirement>
<requirement>Preserve source anchors and provenance.</requirement>
<requirement>Include a migration note for moving a local SQLite starter case into Open Brain.</requirement>
<requirement>Do not imply Open Brain is required for the beginner path.</requirement>
</requirements>
<verification>Write one sample case record and show how it would be queried back by case_id and section_label.</verification>
</prompt>
Deterministic Retrieval Map
Builds explicit lookup tables that map a case type to the document sections or record categories that matter. It retrieves by known structure first, then lets the agent reason over a small, cited packet.
Why build it
Vector search is not the first move when the documents already have known structure. Deterministic retrieval keeps v1 boring in the best way: denial type to plan sections, expense type to tax categories, clause type to contract sections. The strong model gets the right evidence instead of a haystack.
What you need
Chunked/tagged documents · A domain mapping table · A query path for the selected store
Show the full setup prompt
<prompt>
<task>Create a new skill called "deterministic-retrieval-map".</task>
<job>Retrieve evidence by explicit case-type to section/category mappings.</job>
<requirements>
<requirement>Define the domain case types and the section labels each type requires.</requirement>
<requirement>Implement retrieval with ordinary queries against tags and labels.</requirement>
<requirement>Return a compact evidence packet with chunk IDs, source anchors, and content.</requirement>
<requirement>Flag missing expected sections before drafting starts.</requirement>
<requirement>Use semantic search only as a later fallback, never as the v1 foundation.</requirement>
</requirements>
<verification>Run all case types through the mapping and show the retrieved chunk IDs.</verification>
</prompt>
Citation Guard
Checks generated drafts for substantive claims and verifies that each one cites evidence that actually supports it — the cited chunk or record must exist in the case store AND match the claimed amount, date, or language. A citation that resolves but does not support its claim fails. Verdicts are three-state: pass, needs_review, fail.
Why build it
The whole promise of context ownership collapses if the final artifact invents around gaps. Citation Guard is the trust layer: claims either point to evidence, ask for confirmation, or get cut.
What you need
A generated draft · A citation map or source registry · A validation command that can fail the run
Show the full setup prompt
<prompt>
<task>Create a new skill called "citation-guard".</task>
<job>Validate that substantive draft claims are grounded in known evidence.</job>
<requirements>
<requirement>Define what counts as a substantive claim for the current domain: amounts, dates, deadlines, coverage or rule statements, and counts.</requirement>
<requirement>Prescribe ONE machine-checkable citation syntax and show a worked example, e.g. a claim line ending with [record:case-42:expense:adobe_feb] or [chunk:eoc-017].</requirement>
<requirement>Resolve every citation against the case store; a citation that does not resolve is a fail.</requirement>
<requirement>Verify support, not just existence: compare the claimed amount, date, or quoted language against the cited record's stored values; a resolvable citation that does not support the claim is a fail.</requirement>
<requirement>Use three verdicts — pass, needs_review, fail — and write a validation report listing every claim under its verdict. needs_review is for claims whose underlying record is itself flagged for review, not a soft pass for unsupported claims.</requirement>
<requirement>Exit nonzero when any claim fails, so the guard can gate downstream steps.</requirement>
<requirement>Allow general disclaimers and process labels without citations only when they are boilerplate from the runbook.</requirement>
</requirements>
<verification>Two-sided test: run the guard on a fully-cited draft and prove it PASSES (exit 0); then run it on a copy with one seeded fabricated-but-well-formed citation (a plausible record ID that does not exist) and prove it FAILS (nonzero exit). Save both reports as evidence.</verification>
</prompt>
Packet Export
Packages the reviewed outputs into an editable folder and PDF: draft letter or summary, citation map, checklist, supporting documents list, source manifest, and any unresolved questions. It keeps editable markdown as the source of truth and treats PDF as the delivery artifact.
Why build it
The work is not done when the agent writes a decent draft. The human needs a packet they can inspect, edit, send to a professional, or file manually. Packet export turns agent output into something operational.
What you need
Validated markdown outputs · A source manifest · A local PDF export path
Show the full setup prompt
<prompt>
<task>Create a new skill called "packet-export".</task>
<job>Turn validated case outputs into an editable packet folder and PDF.</job>
<requirements>
<requirement>Refuse to export while the citation guard reports any failing claim; a packet ships only when every claim is pass or needs_review, and the guard's verdict summary appears in the packet README.</requirement>
<requirement>Keep markdown, JSON, and CSV outputs editable in the packet folder.</requirement>
<requirement>Create a source manifest with original files and citation anchors.</requirement>
<requirement>Export a PDF for review or professional handoff.</requirement>
<requirement>Include unresolved questions and missing documents instead of hiding them.</requirement>
<requirement>Never transmit, submit, sign, file, or send the packet.</requirement>
</requirements>
<verification>Export a sample packet and open the PDF to confirm the sections render.</verification>
</prompt>
Human Gate
Defines the stop line for high-stakes workflows: the agent may organize, draft, validate, and export, but a human reviews, signs, sends, files, or submits. The skill writes this boundary into the workflow instead of relying on vibes.
Why build it
Healthcare, taxes, legal, finance, and identity workflows all have a point where agency matters. The human gate is not a missing automation feature. It is the product boundary that keeps the person in charge and prevents the agent from taking irreversible action with sensitive data.
What you need
A list of allowed actions · A list of forbidden actions · A review checklist for the handoff
Show the full setup prompt
<prompt>
<task>Create a new skill called "human-gate".</task>
<job>Enforce the review-and-submit boundary in high-stakes agent workflows.</job>
<requirements>
<requirement>List what the agent may do: organize, draft, validate, summarize, export.</requirement>
<requirement>List what the agent must not do: sign, send, file, submit, authorize, pay, or transmit sensitive data.</requirement>
<requirement>Add an explicit review checklist to every packet.</requirement>
<requirement>Stop the workflow at export unless the human starts a separate approved sending workflow.</requirement>
<requirement>Use domain-specific disclaimers without burying the actual next step.</requirement>
</requirements>
<verification>Run the skill against a sample packet and show where the workflow stops.</verification>
</prompt>