# Process Creator

> Documents cross-repo business processes as PROCESS.md files. Trigger on: "document process", "write PROCESS.md", "process audit", "map the pipeline", "process definition", any request to create or update a process document. Also trigger when processes.ts flags a PROCESS.md as MISSING. Reads existing code, DB schemas, and pipeline definitions to produce a doctrine-compliant process document that maps the full IMO, ID chain, ERD, and migration status.

- Skill: `djb258/process-creator` (Agent Skill, multi-file: 2 files)
- Install (CLI): `npx skillmds@latest add djb258/process-creator`
- Raw SKILL.md: https://api.skillmd.com/api/skills/djb258/process-creator/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: DevOps & Infra
- Author: djb258 (https://skillmd.com/u/djb258)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/djb258/process-creator

---


# process-creator — Process Documentation Skill

**Authority**: imo-creator (CC-01 Sovereign)
**Output**: `docs/processes/PROCESS-{SHORTNAME}.md`

Document a cross-repo business process. Read code and data, confirm the chain, write the document.

## IMO — Ingress / Middle / Egress

**Ingress (Trigger):** User requests a process document, or processes.ts flags PROCESS.md as MISSING.

**Middle (Processing):**
- Identify the process from processes.ts or user description
- Read all pipeline code, DB schemas, and adapter implementations
- Map the full execution chain: trigger → ingress → middle steps → egress
- Map the ID addressing chain (forward and reverse)
- Map the ERD (tables, access patterns, cross-repo joins)
- Identify wired vs unwired components
- Write the PROCESS.md

**Egress (Output):** A validated PROCESS-{SHORTNAME}.md at `docs/processes/`.

**Go/No-Go Gate:** Every section filled. No unfilled placeholder values. ID chain verified bidirectionally. ERD matches actual DB schema.

---

## Constants — What Is Fixed About Every Process Document

1. Every PROCESS.md has exactly these sections in this order:
   - Header (process ID, name, version, status, date)
   - Summary (1-3 sentences)
   - IMO (Ingress / Middle / Egress)
   - ID Addressing Chain (forward + reverse)
   - Phase Breakdown (numbered phases with gates)
   - ERD (tables, schemas, access patterns)
   - Services and Infrastructure
   - ORBT Status
   - Migration Status (what's wired, what's not)
   - Document Control
2. The ID Addressing Chain section is mandatory. Every process has at least one ID that flows through it.
3. The Phase Breakdown must match actual code — not aspirational design.
4. The ERD must match actual database tables — query the DB if needed.
5. Migration Status is honest: WIRED means deployed and tested, PARTIAL means code exists but not deployed, PLANNED means no code.
6. A PROCESS.md documents what IS, not what SHOULD BE. Aspirational items go in Migration Status only.
7. No prose filler. Every line states a fact or a constraint.
8. The process document is independent of any single repo — it spans repos.

---

## Variables — What Changes Per Process

| Variable | What It Is | Who Sets It |
|----------|-----------|-------------|
| `process_id` | PROC-{SHORTNAME} identifier | From processes.ts or user |
| `source_repos` | Which repos contain the process code | Discovered during audit |
| `pipeline_files` | Specific files implementing each phase | Discovered during audit |
| `db_tables` | Tables read/written by the process | Discovered from code + DB |
| `id_chain` | The specific IDs that flow through | Discovered from code |
| `services` | Infrastructure the process depends on | Discovered from code + config |
| `migration_status` | Per-component wired/partial/planned | Assessed during audit |

---

## Hub-and-Spoke Configuration

| Spoke | Input | Output | Interface to Hub |
|-------|-------|--------|-----------------|
| Identify | processes.ts + user request | Process scope confirmed | Go/No-Go: process_id is unambiguous |
| Audit Code | Pipeline source files | Phase-by-phase execution map | Go/No-Go: every phase traced to code |
| Audit Data | DB schemas + queries | ERD with actual tables | Go/No-Go: tables confirmed in live DB |
| Map IDs | Code + DB | Bidirectional ID chain | Go/No-Go: forward + reverse paths documented |
| Assess Status | All findings | Migration status per component | Go/No-Go: honest assessment, no guessing |
| Write | All spoke outputs | PROCESS-{SHORTNAME}.md | Go/No-Go: all sections filled, no placeholders |

---

## Rules — What This Skill Never Does

- Never document a process that doesn't exist in code. If the code isn't written, it's PLANNED in Migration Status.
- Never invent ID chains. Trace them from actual code — mintCommunicationId(), mintMessageRunId(), etc.
- Never assume table schemas. Query the database or read migration files.
- Never mix what IS with what SHOULD BE in the main sections. Aspirational items go in Migration Status only.
- Never skip the ID Addressing Chain section. If you can't find IDs, the process isn't understood yet.
- Never create a PROCESS.md with unfilled placeholder values. Every field filled or explicitly marked N/A.
- Never duplicate content from PRD, OSAM, or SCHEMA docs. Reference them, don't copy.

---

## Workflow

### Phase 1 — Identify Process

**Constants for this phase:**
- The process must exist in processes.ts or be describable as a concrete pipeline.

**Variables for this phase:**
- The specific process_id and its scope.

**Execute:**
Read `dashboard/src/data/processes.ts`. Find the process by ID or match the user's description. Extract: repos, sub-hubs, services, current IMO definition, ERD tables.

**Go/No-Go:** Can you name the process, its repos, and its entry point? If yes, proceed. If no, ask.

### Phase 2 — Audit Code

**Constants for this phase:**
- Every middle step must trace to a function in a source file.
- Gates must trace to actual gate functions.

**Execute:**
For each repo in the process:
1. Read all pipeline files (orchestrators, workers, engines, adapters)
2. Map each function to a phase: what triggers it, what it reads, what it writes, what it calls next
3. Map gate functions: what they check, what they return (PASS/BLOCK/DOWNGRADE)
4. Map adapter implementations: what channels, what APIs, what's deprecated

Record: file path, function name, reads (tables/views), writes (tables), calls (other functions).

**Go/No-Go:** Every pipeline step accounted for? Every gate identified? If yes, proceed. If no, read more files.

### Phase 3 — Audit Data

**Constants for this phase:**
- ERD must reflect actual database state, not just code references.

**Execute:**
1. Query the live database (via Hyperdrive or direct) for schema introspection
2. Confirm every table referenced in code actually exists
3. Note any tables in the DB that the code doesn't reference (orphans)
4. Map cross-repo table access (which process writes, which reads)

**Go/No-Go:** Table list confirmed against live DB? Access patterns documented? If yes, proceed.

### Phase 4 — Map ID Chain

**Constants for this phase:**
- Every process has at least one ID that flows through it.
- The chain must work in both directions (forward: trigger→output, reverse: output→trigger).

**Execute:**
1. Find all ID minting functions (mintCommunicationId, mintMessageRunId, etc.)
2. Trace forward: signal → CID → SID → MID → delivery (or equivalent)
3. Trace reverse: delivery record → MID → SID → CID → original signal
4. Document the join keys between each phase
5. Document the ID format (prefix, structure, uniqueness guarantee)

**Go/No-Go:** Can you trace any output record back to its original trigger? If yes, proceed. If no, there's a gap.

### Phase 5 — Assess Migration Status

**Constants for this phase:**
- Three statuses only: WIRED (deployed + tested), PARTIAL (code exists, not deployed), PLANNED (no code).
- Be honest. PARTIAL is not WIRED.

**Execute:**
For each component (phases, adapters, gates, infrastructure):
1. Code exists? → at least PARTIAL
2. Deployed to production? → at least PARTIAL
3. Smoke tested / confirmed working? → WIRED
4. No code at all? → PLANNED

Flag any component that routes through deprecated infrastructure (e.g., Lovable, Supabase edge functions) as needing migration.

**Go/No-Go:** Every component has a status? No guessing? If yes, proceed.

### Phase 6 — Write PROCESS.md

**Constants for this phase:**
- Use the template structure defined in Constants section 1.
- File goes to `docs/processes/PROCESS-{SHORTNAME}.md`.

**Load:** `references/process-template.md` (the section-by-section template)

**Execute:**
Write the document using all outputs from Phases 1-5. Fill every section. No placeholders.

**Go/No-Go:** All sections filled? ID chain verified? ERD matches DB? Migration status honest? If yes, deliver. If no, fix.

---

## Reference Files

| File | Contains | Load When |
|------|----------|-----------|
| `references/process-template.md` | Section-by-section PROCESS.md template with field definitions | Phase 6 — when writing the document |

---

## Document Control

| Field | Value |
|-------|-------|
| Version | 1.0.0 |
| Created | 2026-03-10 |
| Authority | imo-creator (Sovereign) |