# Claude Immigration Attorney and a skill set for petition drafting > claude_immigration_attorney is a set of Claude Code skills for immigration lawyers and self-petitioning candidates, covering evidence indexing, O-1A and EB-1A narrative drafting, NIW research, expert letters, an audit pass and RFE responses, backed by a knowledge base of adjudication practice. It is a workflow for professionals, not an automated legal answer, and the readme is explicit that an attorney reviews and signs. **juntoku9/claude_immigration_attorney** — Claude code environment for laywers - Repository: https://github.com/juntoku9/claude_immigration_attorney - Stars: 696 · Forks: 80 - Language: Shell - License: MIT - Published: 2026-10-21 · Updated: 2026-10-21 · Language: en - Canonical page: https://hysenlabs.com/projects/juntoku9-claude-immigration-attorney ## Two audiences, one set of skills, and a hard stop at the signature The project describes itself as Claude Code skills for immigration attorneys and self-petitioning candidates, covering O-1A, EB-1A and EB-2 NIW petitions with the stated promise that every claim is backed by evidence. The audience split is explicit, and it matters for how the tool is used. For attorneys, the skills are for the mechanical work: organizing 100+ client documents into a structured evidence index, drafting petition letters with proper legal structure and exhibit references, auditing drafts for factual errors and unsupported claims, and drafting expert and recommendation letters with strategic criteria assignment. For self-petitioning candidates, the framing is more careful: understand what evidence you need, research government sources that support a national importance argument, generate a first draft of the self-petition letter to review with your attorney, and identify evidence gaps before filing. The workflow diagram in the readme ends with a line that settles the scope question. The chain runs from source documents through document-summary-arrangement to a document index, then through the knowledge base into the narrative skills, then into petition-audit for an audit report, and finally to the last step, which is Attorney reviews and signs. So the deliverable is a package the attorney then owns. The readme also says that before the 1.0 release you can expect to potentially encounter some issues or bugs, and asks people to raise them, which is a candid framing for a tool that touches high stakes filings. One thing worth noting: the project is written in Shell as its primary language, which is a sign that it is a set of instructions and scripts for a coding agent rather than an application with a UI of its own. ## The pipeline runs documents, index, drafting, audit The workflow diagram is the best description of the mechanism in the repository, and it is worth reading line by line. ``` Source documents ↓ document-summary-arrangement → document index (arranged by criterion) ↓ knowledge/ (read best practices) ↓ o1-petition-narrative → O-1A petition package ─┐ eb1a-petition-narrative → EB-1A petition package ─┤ niw-national-importance-research → research document │ → niw-petition-narrative → NIW petition package ──┤ expert-letter-drafter → expert letter drafts │ ↓ petition-audit → audit report ↓ Attorney reviews & signs ``` The key structural decision is that everything downstream depends on the index. The document-summary-arrangement skill ingests source documents, which the table describes as PDFs, images and scans, triages them by importance, summarizes the key ones, and produces a structured index arranged by evidentiary criterion. That index is then what the drafting skills read, and the knowledge base is read before drafting. So the pipeline is sequential, and the first stage is where the work is. If the triage misplaces a document, every later stage inherits that mistake, and the narrative skill will not know the difference between a document it was never shown and a document that was shown and found to be irrelevant. The three narrative skills are separate because the legal standards differ. `o1-petition-narrative` drafts O-1A and O-1B support letters with criterion-by-criterion arguments. `eb1a-petition-narrative` uses the same criteria as O-1A but with stricter scrutiny, and adds a sustained acclaim totality argument, intent to continue work, and a substantial US benefit. `niw-petition-narrative` drafts EB-2 NIW letters using the Dhanasar three-prong framework, and it is fed by `niw-national-importance-research`, which researches authoritative government sources, national plans and federal funding to produce a quotable research document matched to the petitioner's background. The final stage, `petition-audit`, is the one that matters most for trust. It audits any petition letter, verifies every factual claim against source documents, flags legal errors, checks internal consistency, and produces a severity-rated report. That is the stage where the system is arguing with itself rather than with the facts, and it is the closest thing here to a check on the drafting. ## The knowledge base is the real asset, and it is a snapshot The `knowledge/` directory contains best practices distilled from real cases and USCIS adjudication patterns, and the skills read these files before drafting. The structure is the substance. There are two overview files, one for the O-1A and EB-1A standard and the Kazarian framework, and one for the NIW standard and the Dhanasar framework. Then a `criteria/` directory with one numbered file per extraordinary ability criterion, from awards through judging, a `prongs/` directory with one file per NIW prong, and three standalone files: The per-criterion files are the useful part. An attorney working an extraordinary ability case is working against eight numbered criteria, and having a file per criterion means the drafting skill can be told to check the evidence against that criterion rather than against a general notion of what makes a strong case. The `evidence-hierarchy.md` file, described as how USCIS weighs evidence in four tiers, does something similar for documents. That is a different kind of guidance from a template, because it tells the model which evidence to prefer when the index contains several candidates for the same point. The `uscis-policy-alerts.md` file is the fragile part. It is a short list of key citations, and it names a specific policy memorandum, PA-2022-03, alongside the Kazarian and Dhanasar frameworks. Any snapshot of policy has a shelf life, and the repository's last push was on 2026-04-25, with no GitHub releases to indicate a versioned cadence. For a tool whose value is knowing the current state of adjudication, that is the first thing to check and the first thing that will go stale. The `argument-patterns.md` file holds reusable argument structures, which is the most reusable content in the repository, because it is the part that is not tied to a specific criterion. ## What you actually clone, and where the installation steps are The repository is mostly skill directories, and the top level listing shows each one as a sibling folder: `document-summary-arrangement/`, `case-strength-assessor/`, `publication-citation-table/`, `o1-petition-narrative/`, `eb1a-petition-narrative/`, `niw-national-importance-research/`, `niw-petition-narrative/`, `expert-letter-drafter/`, `petition-audit/` and `rfe-response-drafter/`, plus the `knowledge/` directory, an `assets/` folder for the images, an `AGENT.md`, and the usual `LICENSE`, `README.md` and `.gitignore`. There is no build step, no package manifest and no dependency file in that listing, which is consistent with the primary language being Shell. These are instruction directories for a coding agent, not a library to compile, and the interesting file in each one is the skill definition itself. The installation steps are not fully in the repository. The Quick Start section of the readme is cut off mid-sentence in the version available here, at the line introducing the attorney workflow, so the exact command to register the skills with Claude Code is not something you can read from this repository. The readme does tell you where the guidance is: the project points at the Claude Code documentation at docs.anthropic.com, and the skills themselves are documented per directory with a link from each row of the skills table. What the readme does establish is the order of work. The attorney path begins with the document index, the candidate path is about understanding the evidence, and the two optional skills sit after the index exists. The knowledge base is read before drafting. One other pointer is worth noting for anyone planning to extend this. The readme mentions a separate repository, Cyberbro MCP, for building custom reports with an LLM through the Model Context Protocol, so the MCP surface of the project is not in this tree. ## Expert letters and RFE responses are where the workflow is most specialised Two of the ten skills address situations that are not drafting a first petition, and they are worth separating because they are the most distinctive parts of the set. `expert-letter-drafter` drafts expert, reference and recommendation letters, and the table describes the mechanism in unusually concrete terms: it assigns criteria to experts by credential, ensures no two letters overlap, and produces ready-to-customize drafts. The overlap constraint is the interesting bit. A support letter that repeats another expert's argument dilutes both, and a case where several experts are writing letters needs a division of labour across criteria that is tedious to do by hand. Having the tool assign criteria by credential and check for overlap is a concrete piece of case assembly that a general purpose model would not do reliably on its own. `rfe-response-drafter` handles the other common situation. It analyzes a USCIS Request for Evidence, diagnoses what went wrong in the original petition, maps each deficiency to a fix, and drafts the point-by-point response with a new evidence strategy. An RFE is a list of specific deficiencies, and the natural structure of a good response is one section per deficiency, each stating the gap, the fix and the new evidence. That mapping is a natural fit for a document-in, structured-document-out process, and it is the second place where the tool is doing case work rather than prose generation. Two optional skills round this out, and the readme is careful to mark them as optional and to place them at a specific point in the timeline: any time after the index exists, often before or during narrative drafting. `case-strength-assessor` reads the document index and produces a frank pre-draft assessment of which criteria or prongs are strong, moderate, weak or unsupported. `publication-citation-table` produces a summary table and a TSV, with lead picks for Criterion 5 and a Criterion 3 side list, and tags Criterion 5 versus press under Criterion 3, along with a `NEEDS VERIFICATION` marker for publication-heavy cases. The author says neither is required and that you should skip them if you do not need them. The `NEEDS VERIFICATION` tag is a small design decision with a good instinct behind it: rather than pretending a publication citation is confirmed, the tool marks it as needing a human check. ## What a petition package actually contains The readme describes the output format, and it is the part that tells you what a user actually receives. Each petition package is a single file containing the full support letter draft, a source registry where every fact is traced to a document or URL, the web sources the attorney needs to print for filing, and evidence gaps with a strength assessment. The source registry is the most valuable artefact in that list. A petition letter is the part that gets filed, but the registry is what lets a lawyer check the work, and the readme's screenshots show the same idea in the intermediate outputs: a sample source registry showing verified facts from client documents and web research, and a sample web sources page with URLs, quotes and an attorney verification checklist. The sample petition draft is described as using only sourced facts, with every number carrying a citation, which is the checkable claim behind the project's tagline about every claim being backed by evidence. Whether the skill actually holds that line on a hundred document set is a question you would answer by running it, and the readme is honest that this is a real test run rather than a marketing mock-up. The research step is worth singling out because it involves the open web rather than the client file. Every entity is researched with facts traced to source documents and verified web URLs, and web sources are compiled with exact quotes, retrieval dates and attorney action checkboxes. Retrieval dates and exact quotes are the two things that make a web citation usable in a filing, and the checkbox model is the right one, because it puts the verification step on a human explicitly rather than assuming the model did it. ## Where an agent drafting a legal filing is the wrong approach There are three limits, and they are structural rather than fixable by configuration. The first is jurisdiction and visa class coverage. The knowledge base is specific to O-1A, EB-1A, EB-1B and NIW, with criteria files for the extraordinary ability criteria and prong files for the Dhanasar framework. A project like this is not a general immigration assistant, it is a set of case playbooks for four specific pathways. Anything outside those four is out of scope, and the readme does not claim otherwise. The second is that the drafting quality ceiling is set by the knowledge base, not by the model. The skills are described as reading the best practices before drafting, which means the guidance in those markdown files is the actual input. If a file is thin on a criterion, the output on that criterion is thin, and no amount of model capability compensates. This is also why the per-criterion and per-prong structure matters so much: the quality of the file for criteria 03 and 05 determines the quality of those sections of the letter. The third is the pre-1.0 state, and the readme says it plainly. The author expects bugs before 1.0 and asks for issue reports. For a tool that produces a document which may be filed with a government agency, that is a fair thing to weigh, and it is worth asking how the outputs are verified before anything leaves the office. The audit skill is a partial answer, since it checks claims against source documents, but the tools cannot check whether the legal reasoning is right. There is also a dependency worth naming. These are Claude Code skills, so the workflow is coupled to one agent environment and to how that agent handles long document sets and multi-step instructions. The repository does not describe a fallback, and the primary language being Shell rather than Python or TypeScript says the scripts are glue around the agent rather than a self-contained pipeline. ## Conclusion The skills fit an immigration attorney with a large document pile and a deadline, who wants the evidence index, the first draft and the audit pass produced consistently across cases, and who treats the output as a starting draft they rewrite. It is the wrong tool for someone who wants a filing-ready letter without a lawyer, and the wrong tool for a jurisdiction or visa class the skills do not cover, since the knowledge base is specific to O-1A, EB-1A, EB-1B and NIW. Before adopting, verify three things: that the document triage handles the formats your clients actually send, since it claims PDFs, images and scans, that the knowledge base matches current USCIS policy, because the policy alerts file is a snapshot that the repository's last push on 2026-04-25 may predate, and how much of the final letter is rewritten by hand. The code is MIT licensed and the repository publishes no releases. ## FAQ ### What is Claude Immigration Attorney and what does it produce? It is a set of Claude Code skills for immigration attorneys and self-petitioning candidates, covering O-1A, EB-1A, EB-1B and EB-2 NIW. Each petition package is a single file containing the full support letter draft, a source registry tracing every fact to a document or URL, the web sources the attorney needs to print for filing, and evidence gaps with a strength assessment. ### What is the workflow the Claude Immigration Attorney skills follow? Source documents are ingested and triaged into a document index arranged by evidentiary criterion, the knowledge base best practices are read, then a narrative skill drafts the petition package for the relevant pathway, followed by `petition-audit` producing a severity-rated audit report, and finally the attorney reviews and signs. ### What is in the knowledge directory of Claude Immigration Attorney? The `knowledge/` directory holds best practices distilled from real cases and USCIS adjudication patterns: an O-1A/EB-1A overview for the Kazarian framework, an NIW overview for the Dhanasar framework, per-criterion files for the eight extraordinary ability criteria, per-prong files for the three NIW prongs, an evidence hierarchy, reusable argument patterns and a policy alerts file with key citations. ### Which Claude Immigration Attorney skills are optional? Two. The `case-strength-assessor` gives a pre-draft assessment of which criteria or prongs are strong, moderate, weak or unsupported, and the `publication-citation-table` builds a publication and citation table for research-heavy cases with lead picks for Criterion 5 and a Criterion 3 side list. Both can be run any time after the document index exists, and the readme says to skip them if you do not need them. ### Does Claude Immigration Attorney replace an immigration attorney? No. The workflow diagram ends with Attorney reviews and signs, the candidate use case is to generate a first draft of the self-petition letter to review with your attorney, and the readme states that before the 1.0 release you can expect to potentially encounter some issues or bugs. ## Sources - [Issues](https://github.com/juntoku9/claude_immigration_attorney/issues) - [juntoku9/claude_immigration_attorney on GitHub](https://github.com/juntoku9/claude_immigration_attorney) - [License: MIT](https://github.com/juntoku9/claude_immigration_attorney/blob/main/LICENSE) - [README](https://github.com/juntoku9/claude_immigration_attorney/blob/main/README.md) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/juntoku9-claude-immigration-attorney