Uipath Genome

UiPath Genome — document, author, and execute automation blueprints

Genome: markdown specification an AI agent consumes to rebuild an automation — what it does, business rules, data moving between parts, platform resources, its transactional shape, verification, and which UiPath skill builds each part. Genomes stay thin: build skills carry UiPath know-how; a genome describes what, skills know how.

Read by the mode's read plan (§ Read Plans), never from memory. This file routes; guides carry the rules, each subject in exactly one guide. A file the plan reads whole is read whole — not grepped or skimmed; a pointer that names a section (guide.md § Section) is a section read, that section in full; a guide no condition of the plan has reached stays closed. The two catalogs — selector-translation-guide.md § Tag attribute catalog and a framework selectors guide's per-technology tables — are read by section: list headings, then read the sections for the technologies the source recorded; the rules around them are read whole.

When to Use This Skill

• Existing UiPath project or solution to document, understand, or prepare for migration ("what does this solution do", "extract a genome", "document this process at high and low level")
• Described automation idea needing a specification before building, or a goal (a self-paced workshop, a demo, trying a product) needing a scenario proposed first
• *-genome.md file to build from
• Existing genome to update, split into components, or re-extract after source changed

Mode Detection

Determine mode from input, in this order:

1. *-genome.md path plus build intent ("build", "execute", "implement", "follow") → Execute. Read execution-guide.md.
2. Directory, project file, solution manifest, or another framework's export (project.json, project.uiproj, .uipx, .flow, .bpmn, agent.json, Workflow.json, caseplan.json, uipath.json; or a folder with none of these holding another automation or test framework's export) → Extract. Read extraction-guide.md and the framework's guides (§ Source Frameworks). A .bpmn here is an existing process project to document; a BPMN model handed over as the design to build from is uipath-planner's. A Windows-Legacy UiPath project whose activities are to be upgraded in place is uipath-activity-migrator's; documenting it, or blueprinting it for a rebuild, is an extraction.
3. Description, idea, SOP, transcript or other process document with no source project, when the user asks for a genome or blueprint; or a goal to propose a scenario for (a self-paced workshop, a demo, trying a product) → Author. Read authoring-guide.md. The same input without a genome or blueprint asked for — designing or building from an SOP, a transcript, a process spec or an idea — is uipath-planner's.
4. *-genome.md path plus edit intent ("update", "add a step", "split", "remove the inferred flags") → Edit in place per the edit tables in the authoring guide (Step 8) and, for an extracted genome, the extraction guide (Step 7); when the source changed or the extraction was cut short, re-extract only the changed or unread objects (extraction guide § Partial Re-extraction).

A PDD or SDD with no genome or blueprint asked for, a request to design a solution and derive tasks, or any input this list assigns to another skill is that skill's job, not a genome. Say so and stop.

Read Plans

Every turn resends the whole context: a reference read early is paid again on every later turn, and one a later answer rules out is paid for nothing. Each mode reads its guide (§ Mode Detection) and, at each phase, only what this table names for it:

Each phase's reads go out in at most three turns, never file by file as each file names the next:

1. Turn 1, one message: every file the phase reads whole, and the heading list (a search for ^# lines) of every file it reads by section.
2. Turn 2, one message: the sections chosen from those lists, and the owning skill's discovery for the activity kinds in play.
3. Turn 3, only what turn 2 routed to.

A plan never narrows an owning skill's contract: a read that skill mandates is performed even when no plan names it, a read that misses (a wrong path) is retried the next turn, and neither is dropped to stay within three turns.

Source Frameworks

A UiPath source (.uipx, project.json, project.uiproj, .xaml/.cs, .flow, .bpmn, caseplan.json, agent.json, Workflow.json, uipath.json) is read with uipath-source-guide.md — whole at extraction; at execution only its § UI Target Locators and § Test Data, with source-migration-guide.md § Migration preflight step 4, § UI targets and § Verification: its UI targets are carried over, not translated. Every other framework is read through the framework migration pack, which holds per framework a source guide, a selectors guide and an inventory script. Resolve it once per run, in both modes:

1. Ask for its location. Ask "Where is the framework migration guide?" unless the request, or the execution scaffolding answer (execution-guide.md § 1.3), already gave it. Accept a folder path (<PACK_DIR>); a git URL is cloned into a scratch folder first. Never search the disk for it, never work from memory of its contents, never copy its files into this skill or beside a genome.
2. Select the framework row in <PACK_DIR>/README.md § Frameworks: the row whose detection signals match the given files (Extract), or the framework the Source Map names (Execute). An extracted genome names its framework in the Source Map; that name selects the row and makes the execution a migration.
3. Run, then read. Run the row's script before reading any export file. Extract reads <PACK_DIR>/<framework>/source-guide.md in full and writes the genome and its Source Map. Execute reads source-migration-guide.md — whole when the build has UI activities, otherwise only its § Migration preflight, § Rules, § Source steps that are not UI actions, § Result parity, § Test data and § What the executor records — and derives the catalogs with the same script (its § Migration preflight). A build with UI activities also reads the source guide's § Composite actions and <PACK_DIR>/<framework>/selectors-guide.md by technology section together with selector-translation-guide.md.

No row matches → say which framework the files appear to come from and that the pack has no guide for it; never improvise an extraction. Pack not available → Extract stops (no genome is extracted from a framework nobody has read); Execute continues without the migration part — live capture or placeholders, stated in the report (source-migration-guide.md § Migration preflight step 1).

Critical Rules

Each rule names its subject and the one guide that states it in full; the guide's wording is the rule.

1. Choose the genome level before writing — one project is a component genome, two or more (or a coordinator plus what it invokes) a process genome with one component genome per project, and test components are folders of one test project: genome-format-guide.md § Two Levels.
2. Read the source, do not ask about it. Extraction reads every non-generated file and never asks what the automation does, only for resources beside it, which it reads and links: extraction-guide.md Steps 1 and 3.
3. Infer complexity, never ask for it, defaulting lower when ambiguous: genome-format-guide.md § Complexity.
4. Replication-grade detail in behavioural wording, with activity names, variable names, file paths and code syntax banned from the body: genome-format-guide.md § Workflow and § Provenance.
5. Configuration Questions carry the values left open; a value an extracted source fixes for every environment is written where it acts, not asked: genome-format-guide.md § Configuration Questions.
6. Every section present, always, stub lines for sections that do not apply: genome-format-guide.md § Stub Lines.
7. One skill per Build With row, from the mapping guide only; operate-only skills belong under Platform Dependencies: skill-mapping-guide.md.
8. Preamble and blueprint blockquote are mandatory and name uipath-genome as the skill that builds the genome, and Build With (or Components) precedes Workflow (or Process Map) so an agent builds instead of executing the steps: genome-format-guide.md § Two Levels rule 5.
9. Acceptance criteria are specific and testable; "completes successfully" and "handles errors" are banned: genome-format-guide.md § Acceptance Criteria.
10. Flag ambiguity, never leave gaps: best interpretation plus *[Inferred]*, uncertainty recorded in the Source Map: genome-format-guide.md § Ambiguity Marker.
11. Write immediately, offer edits after; edits are in place, never a regeneration: genome-format-guide.md § Write, Then Offer Edits.
12. Execution never edits the genome and never skips the configuration questions — the genome's own and the scaffolding questions, once per owning skill with per-project differences, waived only by an explicit "take the defaults" in the current request — then advances group by group without pausing, assesses every acceptance criterion, and ends by writing the open-items files when the target environment needs setup — what the engineer must set up there: execution-guide.md § 1.3, § 2.2, § 3; open-items-guide.md.
13. Extraction writes genomes only, and the Source Map is the migration contract — framework, export path and identity, per-step source objects with ids, checkpoints, counts; locators and rows stay in the export: genome-format-guide.md § Source Map.
14. Execution on an extracted genome is a migration by default — catalogs derived from the export at preflight, every UI activity given an INFERRED (<confidence>) Object Repository target with the first live run as healing pass, test data filled from the data catalog, one credential asset per account and no secret ever copied: source-migration-guide.md.
15. Build through the owning skill, verifiably — its mandatory reads; for every activity kind the build uses, the default XAML (the shape) and the package's per-activity doc (the property and its value encoding), fetched before the first file using it is written; workflows authored as files, not generated; subagents under the same obligation: execution-guide.md § 2.2.
16. Composite source actions are contracts in the genome and patterns at build — the substep carries what is typed, how the entry is matched, which key confirms, the path levels, the row rule (genome-format-guide.md § Workflow); execution expands each into its pattern with a verify sub-step, never the nearest single activity (source-migration-guide.md § Composite interactions).
17. UiPath selector truth lives in one guide — tag chain by technology, one tag is one node, node-dependent aaname, one application one scope, the tag comes from the strongest evidence (recorded markup over a known node role over the control type), no borrowed identifier, widget anatomy: selector-translation-guide.md rules 1–16. Verification is a property of the acting activity (VerifyOptions observing the element that shows the outcome): source-migration-guide.md § Verification.
18. A migrated target carries a verdict, and offline-unverified is one — verified against the target application, shape-verified against a comparable instance of the same product, offline-unverified when nothing is reachable, per interaction family: source-migration-guide.md § Verifying targets. A reachable application is a windfall, never a precondition for finishing the run. Offline, definitions are read back per selector-translation-guide.md § Checking a definition.
19. Most source steps are not UI activities — waits, assertions, stores, labels, jumps, comments, log lines and engine settings become verification, reads, structure, a log message or nothing at all, and linking is the last thing done to a workflow file: source-migration-guide.md § Source steps that are not UI actions and § UI targets.
20. The transactional shape is described in the genome and split at build. Every genome carries a Transactional Shape — one block per flow (one kind of item handed from its producer to its consumer: components 1 → 2, 2 → 3, an independent 5 → 6; an item's children are levels of its flow, not a flow), each with the unit of work and its alternatives, the as-is roles, store and coordination, the per-item outcomes, the split options for the unit and for each alternative unit — A one process without a queue, B a producer process and a consumer process, C one process with a queue — with what each requires and changes, and the evidence — or its stub; it asserts no split, no store, no template and no unit. Execution asks the split questions per flow (unit, split option, producers, consumers, store, template, shared steps, triggers) with defaults prepared from the genome, may materialise one component as several projects or two components as one, resolves each component across its flows, and records the choice; the behaviour is owed whatever the choice: genome-format-guide.md § Transactional Shape; transactional-execution-guide.md.
21. Source values are read from the source, not from their rendering — comparison literals and case rules verbatim, counts, lengths, occurrences, waits and control-flow flags; an empty rendering is "not shown", never "not set". Extraction writes them so (extraction-guide.md Step 3); execution checks every one the genome cites before a group builds on it and follows the source where they disagree (source-migration-guide.md § Migration preflight step 4). A scripting wrapper's verbs are the caller's UI steps on the elements its identities name, never a library of verbs.
22. A suspected source defect is verified before it is written: first in the full rendering, then in the framework's source itself. The inventory output is the pack's rendering, not the source. Each finding is read in the export with a generic reader that keeps every key, and is classified as a rendering artefact (reported for the pack), a source defect, a source rule, or unresolved platform semantics. It is then written in that form, with its evidence in the Source Map (extraction-guide.md Step 4b; marker: genome-format-guide.md § Source Defects).