Agentic Dev preset · Visual walkthrough

Onboarding, Flow & Data

Three pictures of the project graph in motion: how a new project is stood up, how one feature travels through the methodology, and what the data model looks like.

Companion to the design discussion · the agentic-dev solution pack
1 onboarding 2 example flow 3 the ontology
Diagram 1

New-project onboarding

Standing up a project is five steps — and an init agent runs the first four, so a team lead points it at a repo and gets a governed, decision-aware workspace back.

1 Create the workspace one per project — an isolated tenant (graph · vectors · policies) 2 Install the agentic-dev preset POST ontology · rules · actions (· rbac · lifecycle) — data, not core code 3 Seed the Role nodes manager · architect · developer · integrator · devop · production-engineer 4 Backfill (optional) ingest discussions/PRDs · feed Module/API from a structural index (tree-sitter) 5 Agents connect over MCP — ready each role gets exactly its query · emit · governed-action tools INIT AGENT
The init agent owns steps 1–4 (purple rail); step 5 is the handoff to the working agents. Every step after install runs through the graph, so onboarding is itself recorded.
◆ Single-agent shortcut
A solo project skips steps 3–5 entirely: create a workspace, install the ontology, done. No roles, no RBAC — the layers are opt-in, so simple stays simple.
Diagram 2

One feature, end to end

Follow a single feature across the six roles. The governed steps pass through a gate before anything happens, and every step leaves an audit edge — so the flow is also its own record.

Architect Manager Developer Developer Integrator Prod-Eng Discussion →Decisionaccepted Create CR→ spawns Tasks ProposeAPIreuse-checked Implement→ Commit closes Task AdvanceTask(done) Ship Featuremerge to main ⛨ gate — sim() vs existing APIsno duplicate → PASS ⛨ gate — RBAC + lifecycleintegrator? active→done legal? AUDIT TRAIL every step writes an edge — who · why · evidence · outcome — so the next agent inherits the reasoning for free
Two of the six steps are governed (amber & teal gates). A duplicate API would FLAG at step 3; a non-integrator, or an illegal state jump, would be blocked at step 5 — before any side effect.
◆ Where the layers show up
Step 3 is the rules gate + precedent search (reuse). Step 5 is RBAC + the lifecycle guard. Every box is an action writing a decision edge. Nothing here is bespoke — it's the generic layers, configured.
Diagram 3

The ontology — the data model

Ten object types in four families, wired by fourteen link types. Colour marks the family; every edge carries a RelationContext (the who/why). This is the validated agentic-dev ontology, drawn.

produces motivates motivates supersedes spawns requires closed_by touches reuses exposes depends_on owns has_skill applies_to assigned_to Discussion Decision ChangeRequest Feature Task Commit Module API Role Skill
Intent — Discussion · Feature · ChangeRequest Decision (the crown jewel) Work — Task · Commit Structure — Module · API Actors — Role · Skill
Read it left-to-right as delivery (Discussion → Decision → Feature → Task → Commit), with the structure the work touches on the right and the actors along the bottom. The bold edges — reuses, exposes, owns — power the reuse check and ownership-based access.
◆ Three deliberate choices
States are properties (Task.state, Decision.status) — the seams the lifecycle layer drives. Relationships over strings — Task —assigned_to→ Role and Role —owns→ Module are edges, so "who owns this?" and access checks are graph queries. Module/API are declared, not parsed — the slot a structural code index feeds. Full source: the ontology section · presets/agentic-dev/ontology.json.
↑ Top