SKILLS · ARCHITECTURE · v2 · MOBILE · v2.0

opchain skills ecosystem

Checkpoint-driven pipeline · 36 skills · 6 phases · 11 tri-agent · 3 audit gates · spine ordinals · v1.7 Seams & Signals · v1.8 quality-gate rail · v1.9 assurance rail · v2.0 learning rail

Foundation · cross-cutting

PROTOCOLoc-checkpoint-protocol

JSON schema written by every skill: phase · progress · blockers · next_actions · wire 1.1: cost · eval_scores · telemetry_handle. Single source of truth — no database, no vendor lock-in.

ORCHoc-orchestrator

/oc-ops · routing · cross-project status · gate enforcement.

RAILInstrumentation rail · v1.6

oc-cost-ops + oc-telemetry-ops · NEW · gated · tap every band ↓

1DiscoverPhase 1 of 6

Reverse-engineer existing codebases into structured spec documents. The output feeds oc-app-architect as a Phase 2 baseline so the oc-orchestrator never starts from a cold context. Optional — greenfield projects skip this band entirely.

CPphase · codebase_scan · spec_output

2PlanPhase 2 of 6

oc-app-architect anchors the spine, auto-invoking oc-stack-forge for platform decisions, taking advisory input from oc-scale-ops on capacity, and routing oc-migration-ops when a live system needs a schema, framework, or platform change. The plan checkpoint is the master record downstream skills consume. In v1.5, /oc-discover gained an “AI app?” branch that routes to the new AI phase.

CPphase · stack_decision · capacity · migration_plan

Pack fabricv1.5 · 36

oc-stack-forge owns the registry; 6 skills consume it. Source: skills/oc-stack-forge/packs/<id>/pack.yml

LANGUAGES13

buncsharpdenoelixirgojavakotlinphppythonrubyrustswifttypescript

FRAMEWORKS9

dotnet-aspnetlaravel-phpphoenixremixsolidspring-javaspring-kotlinsveltekitswiftui

MOBILE4

kotlin-androidflutterios-swiftuireact-native-expo

DEPLOY6

app-storeaws-amplifyplay-storeherokunetlifyrailway

VECTOR-DB · NEW v1.54

pgvectorpineconesupabase-vectorsturbopuffer

consumed by oc-stack-forge · oc-app-architect · oc-migration-ops · oc-api-dev · oc-deploy-ops · oc-rag-forgeView /coverage →

3AIPhase 3 of 6 · NEW

v1.5 adds an AI-native phase. When /oc-discover flags an AI app, oc-app-architect chains to four new skills — oc-claude-api (model routing · caching · tool use · migration), the tri-agent pair oc-rag-forge (vector DB · embeddings · hybrid search · retrieval eval) and oc-agent-forge (Agent SDK · subagents · tool budgets · agent eval), and oc-prompt-ops (prompt versioning · eval datasets · regression). All four ship gated behind skills.registry.<id>.enabled and return checkpoints to oc-app-architect; oc-rag-forge consumes the vector-db packs.

CPphase · model_routing · retrieval · agent_topology · prompt_versions

4BuildPhase 4 of 6

Three tri-agent loops (oc-ux-engineer · oc-api-dev · oc-integrations-engineer) plus the dense-UI specialist (oc-dash-forge) work in parallel. oc-ux-engineer hands data-heavy screens to oc-dash-forge; oc-api-dev produces an OpenAPI/GraphQL contract that the deploy-time drift gate later enforces. All four feed checkpoints back to oc-app-architect.

CPphase · ux_specs · api_surface · integrations · dashboards

5ShipPhase 5 of 6

Three audit gates (oc-bug-check pre-commit, oc-code-auditor for code-level findings, oc-security-auditor for STRIDE/OWASP/infra) all must pass before oc-deploy-ops will run the production sequence. At release boundaries the spine threads oc-git-ops → oc-release-ops → oc-deploy-ops; oc-release-ops produces the changelog · version bump · release ticket · announcement, then hands off (it is not itself a deployer). v1.5 taught oc-code-auditor prompt-injection and tool-use safety rules for AI apps.

CPphase · audit_score · posture · branch · pr · release_tag · deploy_status

6MonitorPhase 6 of 6

oc-deploy-ops hands off to oc-monitoring-ops once production is green. oc-monitoring-ops also receives oc-api-dev's SLO + drift manifest so contract violations alert the same way uptime errors do. Incident response runbooks and postmortems live here.

CPphase · slo_status · alert_rules · incident_log

Quality-gate railv1.8 · PR gate

v1.8 reframes every gate onto one boundary timeline. The new piece is the PR rail: oc-git-ops chains to oc-docs-forge (writes the docs packet — README, changelog, ADR, PR body) then oc-repo-ops (repo hygiene + generated-file/catalog drift), which fails closed when the repo is not ready. It is a sequence oc-git-ops follows — unlike the commit gate, no hook enforces it. The commit gate (oc-bug-check) and the two deploy gates (oc-code-auditor, oc-security-auditor) are unchanged — they also appear in the Ship band above.

CPdocs-forge + repo-ops write phase · pr_docs · readiness · drift

Assurance railv1.9 · 4 new

v1.9 lands four skills as one cross-cutting rail rather than four more boxes in the phase bands. oc-qa-ops decides which tests exist — split out of oc-bug-check, which still executes them at the commit gate — and writes .opchain/qa.yaml; a coverage-budget miss warns by default, and only coverage.enforce: fail makes it block. oc-data-ops is the 9th tri-agent (Designer / Builder / Contract-Verifier), invoked by oc-app-architect when discovery surfaces a data-heavy backend; the warehouse and queue choice still comes from oc-stack-forge. oc-compliance-ops keeps a standing control register and is inert until a project adds .opchain/compliance.yaml. oc-security-hardening is the execution half of a pair — oc-security-auditor assesses, this one executes. The last two each attach a conditional row to oc-deploy-ops' existing audit gate, so the ecosystem still has three gates, not five.

CPall four write phase · qa.yaml · data-contracts/*.yaml · compliance.yaml · hardening.yaml

Learning railv2.0

Learn from completed work. Opchain 2.0 contains 36 skills, including oc-update, Hindsight and Evolve. The shared runtime stores scored outcomes in .opchain/learning/, checks recurring weak results and returns approved lessons as advisory context. Evolve uses recorded task runs and an externally trusted reviewer signature. Your team configures provider access, reviewer keys and separate evaluator sessions. Context is delivered through explicit commands.

CPshared runtime · scored history · task evidence · external review

Appendix A · Cross-cutting

Checkpoint Protocol — sync topology

Skills use a shared checkpoint protocol to save progress. The updater preserves existing checkpoints. The oc-orchestrator both reads from and writes to each — bidirectional sync. Diagram below shows 6 representative connections; the same topology extends to all 36 skills.

{
  "skill": "oc-app-architect",
  "phase": "build",
  "progress_table": { "discover": "complete" },
  "context_primer": "2-sentence summary...",
  "blockers": ["waiting on API key"],
  "next_actions": ["/oc-git-sync"],
  "cost": { "total_usd": 1.81 },
  "eval_scores": [{ "rubric": "oc-bug-check" }],
  "telemetry_handle": { "enabled": false }
}

Appendix B · Cross-cutting

Orchestrator — routing decision flow

When a request enters /oc-ops, the oc-orchestrator reads source-skill checkpoint state, decides the next skill, and dispatches. All three states shown together (desktop version animates each in sequence).

Legend

Connections · markers · skill types

Spine ordinal

Numbered mint pill on the 6 primary-spine skills marks handoff position. Replaces directional arrows between bands — vertical reading order is the sequence.

1 oc-reverse-spec → 2 oc-app-architect → 3 oc-git-ops → 4 oc-release-ops → 5 oc-deploy-ops → 6 oc-monitoring-ops

Chains to

A documented handoff: the calling skill's own instructions bring the next one in while it runs, so you don't invoke it separately. A convention the assistant follows — not a background trigger.

e.g. oc-app-architect → oc-stack-forge · oc-app-architect → oc-ux-engineer

Advisory

Non-blocking recommendations passed via checkpoint. The receiver can accept or override. No hard dependency.

e.g. oc-scale-ops → oc-app-architect · oc-migration-ops ↔ oc-app-architect

Audit gate

Pipeline blocks until the gate writes a passing result. Three gates in this ecosystem: oc-bug-check (pre-commit), oc-code-auditor (code-level), oc-security-auditor (posture).

score ≥ 7/10 · STRIDE clean · zero critical CVEs

CP · checkpoint indicator

Solid ember dot in each skill's top-right corner indicates the skill writes a checkpoint. The CP badge marks checkpoint participation — desktop version shows full CP badge on each rect; mobile uses the dot for legibility.

.checkpoints/<skill>.checkpoint.json · phase · progress · blockers · next_actions

ORC · oc-orchestrator indicator

Faded ember dot adjacent to the CP dot indicates the skill participates in /oc-ops routing. All 36 skills carry ORC — every skill is route-addressable by the oc-orchestrator.

/oc-ops · cross-project routing · gate enforcement · "what should I do next"

Skill types

Tri-agent

Skills running an internal Planner / Generator / Evaluator loop. The Evaluator scores output (≥ 7/10 to advance); failure triggers Generator retry until threshold or max iterations.

oc-app-architect · oc-ux-engineer · oc-api-dev · oc-integrations-engineer · oc-code-auditor · oc-rag-forge · oc-agent-forge · oc-signal-forge · oc-data-ops (v1.9)

Advisor

Non-orchestrating skills that return recommendations or analysis. No tri-agent loop. Results fed back via checkpoint; caller can override.

oc-stack-forge · oc-scale-ops

Standalone specialist

Single-purpose skills that produce a concrete artifact and hand it off. No internal loop, no orchestration of others.

oc-reverse-spec · oc-dash-forge · oc-git-ops · oc-release-ops · oc-migration-ops · oc-monitoring-ops · oc-cost-ops · oc-telemetry-ops (v1.6) · oc-qa-ops (v1.9)

Workflow / oc-orchestrator

Skills that drive structured, sequential pipelines. oc-app-architect orchestrates the build; oc-deploy-ops orchestrates the ship; oc-orchestrator routes across projects.

oc-app-architect · oc-deploy-ops · oc-orchestrator

Audit gate

Quality enforcement skills that block pipeline progression until thresholds are met. Three in this ecosystem cover three layers: pre-commit, code-level (also tri-agent — see yellow stroke on oc-code-auditor), security posture.

oc-bug-check · oc-code-auditor · oc-security-auditor

v1.9 assurance rail

Gold rail chrome marks the four skills added in v1.9. The accent is chrome only — every panel inside the rail keeps its own archetype colour (specialist mint · tri-agent gold · gate rose). Two clusters: plan/build strategy, and two conditional rows on the existing deploy gate.

oc-qa-ops · oc-data-ops · oc-compliance-ops · oc-security-hardening

v2.0 learning rail

Opchain 2.0 has 36 skills. Its shared runtime records scores, returns approved lessons and tests proposed rules. The star marks an external review requirement.

oc-hindsight · oc-evolve · Outcome Scorecard · shared runtime

Reference

Pipeline patterns at a glance

Spine Ordinals

Mint pills on the 6 spine skills mark the handoff sequence
1 oc-reverse-spec → 2 oc-app-architect → 3 oc-git-ops → 4 oc-release-ops → 5 oc-deploy-ops → 6 oc-monitoring-ops
Direction is implicit from vertical reading order
Branch handoffs noted inline as captions:
oc-ux-engineer → oc-dash-forge
oc-api-dev / integ-eng → oc-code-auditor
oc-code-auditor → oc-security-auditor

Tri-Agent Patterns

oc-app-architect: Generator / Evaluator
oc-ux-engineer: Planner / Generator / Evaluator
oc-api-dev: Designer / Builder / Conformance
oc-integrations-engineer: Planner / Builder / Tester
oc-code-auditor: Auditor / Fixer / Verifier
oc-rag-forge: Designer / Builder / Evaluator (v1.5)
oc-agent-forge: Planner / Builder / Evaluator (v1.5)
oc-signal-forge: Designer / Builder / Evaluator (v1.7)
oc-data-ops: Designer / Builder / Contract-Verifier (v1.9)
oc-hindsight: Curator / Lesson Gen / Retrieval Eval (v2.0)
oc-evolve: Reflector / Rule Gen / Adversarial Eval (v2.0)

Audit Gates (3)

oc-bug-check — pre-commit type/lint/secret scan
oc-code-auditor — code-level Auditor/Fixer/Verifier
oc-security-auditor — STRIDE / OWASP / posture assessment
All three must pass before oc-deploy-ops ships
v1.9 adds 2 conditional rows to the deploy gate — oc-compliance-ops evidence, oc-security-hardening manifest-verify. Still 3 gates.
v2.0 adds ★ human gates on promote and adopt — not audit gates. Still 3.

Checkpoint Protocol

JSON files at .checkpoints/<skill>.checkpoint.json
Keys: phase · progress_table · context_primer · blockers · next_actions
All 36 skills share checkpoint access (no ACL)
2.0 · shared history and task evidence · checkpoint wire 1.1
Resume order: own → upstream → novice mode
Framework-agnostic — no platform lock-in

Routing Key

Bus pattern: 1 trunk + N branches for fan-outs/fan-ins
Width: spine 2px · secondary 1.8px · advisory 1.5px · gate 2px
Style: solid for spine handoffs · dashed for chains-to / advisory / gate
Bidirectional: paired arrows when the receiver also sends back (advisor pattern)
Mobile note: vertical reading order replaces left-right gutter routing from desktop

PROTOCOLoc-checkpoint-protocolJSON schema · phase · progress · blockers · next_actions

ORCHoc-orchestrator/oc-ops · routing · cross-project status · gate enforcement

Every skill writes a JSON checkpoint after each state change. Single source of truth — any skill can read any other's to rebuild context. Plain JSON on disk · no database · no vendor lock-in.

{
  "skill": "oc-app-architect",
  "phase": "build",
  "progress_table": { "discover": "complete", "spec": "in_progress" },
  "context_primer": "2-sentence summary...",
  "blockers": ["waiting on API key"],
  "next_actions": ["/oc-git-sync"],
  "cost": { "total_usd": 1.81 },
  "eval_scores": [{ "rubric": "oc-bug-check", "score": 0.86 }],
  "telemetry_handle": { "enabled": false } // v1.6 wire 1.1 (additive)
}

The oc-orchestrator routes every skill invocation across projects. Tracks which checkpoint is current, enforces audit gates before deploys, and answers /oc-ops queries. Reads all 33 checkpoints; writes its own pipeline state.

DISCOVER

skills

oc-reverse-spec

checkpt

CP phase · codebase_scan · spec_output

links

↓ handoff to plan

Phase 1 of 6

Discover

PLAN

skills

oc-app-architectoc-stack-forgeoc-scale-opsoc-migration-opsoc-modularize-ops

checkpt

CP phase · stack_decision · capacity · migration_plan

links

↑ from discover↓ to build

Phase 2 of 6

Plan

oc-app-architect anchors the spine, auto-invoking oc-stack-forge for platform decisions, taking advisory input from oc-scale-ops on capacity, and routing oc-migration-ops when a live system needs a schema, framework, or platform change. The plan checkpoint is the master record downstream skills consume. v1.7 adds oc-modularize-ops here — it decides whether to split a live monolith, captures golden fixtures from real data, proves zero functionality/data loss, then hands the bulk move to oc-migration-ops (the Seams chain → oc-fleet-ops).

PACK FABRIC

v1.5 · cross-cutting · oc-stack-forge owns

Pack fabric — language · framework · mobile · deploy · vector-db

Declared in skills/oc-stack-forge/packs/<id>/pack.yml · consumed by oc-stack-forge · oc-app-architect · oc-migration-ops · oc-api-dev · oc-deploy-ops · oc-rag-forge · emits the reserved skills.coverage.<id>.enabled

v1.5 · 36 packs→

LANGUAGES13

buncsharpdenoelixirgojavakotlinphppythonrubyrustswifttypescript

FRAMEWORKS9

dotnet-aspnetlaravel-phpphoenixremixsolidspring-javaspring-kotlinsveltekitswiftui

MOBILE4

kotlin-androidflutterios-swiftuireact-native-expo

DEPLOY6

app-storeaws-amplifyplay-storeherokunetlifyrailway

VECTOR-DB4

pgvectorpineconesupabase-vectorsturbopuffer

skills

oc-claude-apioc-rag-forgeoc-agent-forgeoc-prompt-ops

checkpt

CP phase · model_routing · retrieval · agent_topology · prompt_versions

links

↑ invoked from oc-app-architect · “AI app?” branch↓ checkpoints back to oc-app-architect

Phase 3 of 6 · NEW v1.5

v1.5 adds an AI-native phase. When /oc-discover detects an AI app, oc-app-architect routes to four new skills: oc-claude-api (model routing, prompt caching, tool use, version migration), the tri-agent pair oc-rag-forge (vector-DB choice, embeddings, hybrid search, retrieval eval) and oc-agent-forge (Agent SDK, subagent topology, tool budgets, agent eval), and oc-prompt-ops (prompts as versioned, eval-gated artifacts). All four ship gated behind skills.registry.<id>.enabled and feed checkpoints back to oc-app-architect; oc-rag-forge consumes the vector-db packs.

BUILD

skills

oc-ux-engineeroc-dash-forgeoc-api-devintegrations-engoc-signal-forge

checkpt

CP phase · ux_specs · api_surface · integrations · dashboards

links

↑ invoked from oc-app-architect↓ to ship gates

Phase 4 of 6

Build

Three tri-agent loops (oc-ux-engineer · oc-api-dev · oc-integrations-engineer) plus the dense-UI specialist (oc-dash-forge) work in parallel. oc-ux-engineer hands data-heavy screens to oc-dash-forge; oc-api-dev produces an OpenAPI/GraphQL contract that the deploy-time drift gate later enforces. All four feed checkpoints back to oc-app-architect. v1.7 adds oc-signal-forge — invoked from oc-app-architect's 08-analytics plan, it builds and adversarially proves a metric answers its question before wiring it to oc-dash-forge (render) and a freshness SLA in oc-monitoring-ops (the Signals chain).

SHIP

skills

oc-bug-checkoc-git-opsoc-release-opsoc-code-auditoroc-security-auditoroc-deploy-opsoc-fleet-ops

checkpt

CP phase · audit_score · posture · branch · pr · release_tag · deploy_status

links

3 audit gates block prodoc-release-ops at release boundaries↓ handoff to monitor

Phase 5 of 6

Ship

Three audit gates (oc-bug-check pre-commit, oc-code-auditor for code-level findings, oc-security-auditor for STRIDE/OWASP/infra) all must pass before oc-deploy-ops will run the production sequence. At release boundaries the spine threads oc-git-ops → oc-release-ops → oc-deploy-ops; oc-release-ops produces changelog · version bump · release ticket · announcement, then hands off (it is not itself a deployer). The gate cluster sits below and writes blocker status into shared checkpoints. v1.5 taught oc-code-auditor prompt-injection and tool-use safety rules for AI apps. v1.7 adds oc-fleet-ops as oc-deploy-ops' peer: managed PaaS → oc-deploy-ops; self-managed multi-container fleets (k8s/Nomad/Compose/VMs, IaC) → oc-fleet-ops, which lands the modules oc-modularize-ops carves out and reports fleet health to oc-monitoring-ops.

MONITOR

skills

oc-monitoring-ops

checkpt

CP phase · slo_status · alert_rules · incident_log

links

↑ handoff from oc-deploy-opsoc-api-dev SLO + drift manifest

Phase 6 of 6

Monitor

oc-deploy-ops hands off to oc-monitoring-ops once production is green. oc-monitoring-ops also receives oc-api-dev's SLO + drift manifest so contract violations alert the same way uptime errors do. Incident response runbooks and postmortems live here.

v1.6 · cross-cutting · instrument railInstrumentation — per-phase cost + opt-in usage telemetry

oc-cost-opsSpecialist · /oc-cost$ attribution · budget gates · tier routingCPORCNEW v1.6 · gated oc-telemetry-opsSpecialist · /oc-telemetry · default OFFopt-in local usage metering · anonymizedCPORCNEW v1.6 · gated

↑ taps every phase · illustrative sample run · CP wire 1.1: cost · eval_scores · telemetry_handle

v1.8 · cross-cutting · quality-gate railQuality gates — a gate at every boundary: commit · PR · deploy

oc-docs-forgeSpecialist · /oc-docs · pre-PR & releasedocs packet · README · changelog · ADR · PR bodyCPORCNEW v1.8 oc-repo-opsSpecialist · /oc-repo · PR-readiness gaterepo hygiene · generated-file & catalog drift · .gitignoreCPORCNEW v1.8

↑ the PR boundary is new in v1.8 · oc-git-ops chains to oc-docs-forge → oc-repo-ops before a PR opens · commit + deploy gates unchanged

v1.9 · cross-cutting · assurance railAssurance — four declared manifests: tests · data contracts · controls · hardening

oc-qa-opsSpecialist · /oc-qa · plan + buildtest pyramid · coverage budgets · contract matrix · load plans → .opchain/qa.yamlCPORCNEW v1.9 oc-data-opsTri-agent · /oc-data-ops · Designer / Builder / Contract-Verifieringestion · transform layers · dbt · data contracts (freshness · volume · schema)CPORCNEW v1.9 oc-compliance-opsStanding operator · /oc-comply · inert without .opchain/compliance.yamlcontrol register · evidence bundles · policy scaffolds · readiness, not certificationCPORCNEW v1.9 oc-security-hardeningRemediation operator · /oc-harden · executes what oc-security-auditor assessesheaders · staged CSP · TLS/WAF/rate limits · .opchain/hardening.yaml + per-deploy verifyCPORCNEW v1.9

↑ all four are new in v1.9 · each declares a manifest under .opchain/ that a gate or another skill reads · oc-compliance-ops and oc-security-hardening add conditional rows to oc-deploy-ops' existing audit gate — still 3 gates

v2.0 · learning railLearn from past work. Test a change. Ask a reviewer before using it.

oc-hindsightTri-agent · /oc-hindsight · in the v2.0review recorded outcomes → source cited lessons → external approval → retrievalNEW v2.0 oc-evolveTri-agent · /oc-evolve · in the v2.0reflect on recurring failures → candidate rules → held-out + full-suite regress → ★ human adoptNEW v2.0

Outcome ScorecardShared runtime · learning scorecardreads recorded scores and shows recurring weak resultsv2.0 · KIT, NOT A SKILL

2.0 · 36 skills · approved context is advisory and never overrides project policy

2.0 · governed workflows (layer 3)

oc-hindsightoc-evolvehuman gateadvisory data

connections

spine ordinal

Spine Ordinal

The 6 primary-spine skills wear numbered mint chips showing handoff position. Each chip carries ↑prev·↓next indicators. Replaces the cross-band handoff lines that previously connected them; the three in-band mint arrows in Ship remain. Branch handoffs use inline mint → target pills inside source rects.

1 rev-spec → 2 app-arch → 3 oc-git-ops → 4 oc-release-ops → 5 oc-deploy-ops → 6 oc-monitoring-ops

chains-toadvisoryaudit gatePR-readiness gate v1.8CP · checkpoint

Checkpoint Protocol

Skills save progress as JSON in .checkpoints/. The updater preserves existing checkpoints. Single source of truth — any skill can read any other's checkpoint to rebuild context after a reset. CP badge sits centered on the top edge of each skill, paired just to the left of ORC. Hover the oc-checkpoint-protocol pill top-left of the diagram to see 6 representative connections — the same topology extends to all 36 skills.

.checkpoints/oc-app-architect.checkpoint.json · phase · progress_table · blockers · next_actions

ORC · oc-orchestrator

Orchestrator

Ask /oc-ops and the oc-orchestrator reads every checkpoint and recommends the next skill — you still invoke it. The ORC badge sits centered on the top-right corner of each skill (straddling the right edge), with CP paired immediately to its left. Marks every skill that appears in those routing recommendations.

/oc-ops · cross-project routing · gate enforcement · "what should I do next" recommendations

skill types

tri-agentadvisorspecialistworkflow / orchestratoraudit gateAI-native · v1.5

AI-native phase (v1.5)

The four AI skills added in v1.5, invoked from oc-app-architect's "AI app?" branch in /oc-discover and gated behind skills.registry.<id>.enabled. Two are tri-agent (oc-rag-forge, oc-agent-forge).

oc-claude-api · oc-rag-forge · oc-agent-forge · oc-prompt-ops

instrument · v1.6

Instrument rail (v1.6)

The two cross-cutting v1.6 skills that meter the pipeline — per-phase cost attribution and opt-in usage telemetry. Not on the spine; they tap every phase. Both gated behind skills.registry.<id>.enabled; checkpoint wire 1.1 adds cost · eval_scores · telemetry_handle. Rail meters show an illustrative sample, not live spend.

oc-cost-ops · oc-telemetry-ops

Seams & Signals · v1.7

Seams & Signals (v1.7)

The three v1.7 skills, gated behind skills.registry.<id>.enabled. Two new throughlines. Signals: oc-app-architect's 08-analytics chains to oc-signal-forge (build + adversarially prove a metric), which feeds oc-dash-forge (render) and a freshness SLA to oc-monitoring-ops. Seams: oc-modularize-ops decomposes a live monolith with golden-fixture proof, hands the move to oc-migration-ops, and the modules deploy via oc-fleet-ops — oc-deploy-ops' self-managed peer.

oc-signal-forge · oc-modularize-ops · oc-fleet-ops

assurance rail · v1.9

Assurance rail (v1.9)

The four v1.9 skills — cross-cutting, not a new phase. Each declares a manifest under .opchain/ that a gate or another skill reads. oc-qa-ops decides which tests should exist and writes .opchain/qa.yaml; oc-bug-check still runs them at the commit gate. oc-data-ops — the ninth tri-agent (Designer / Builder / Contract-Verifier) — designs pipelines and guards .opchain/data-contracts/*.yaml with freshness · volume · schema SLAs. oc-compliance-ops keeps a standing control register and builds audit-ready evidence bundles — readiness and evidence, not certification and not legal advice — and stays inert until a project adds .opchain/compliance.yaml. The security pair splits assess from execute: oc-security-auditor assesses (/oc-hardening), oc-security-hardening executes (/oc-harden) and stands the per-deploy check of its own .opchain/hardening.yaml. Those last two add conditional rows to oc-deploy-ops' existing audit gate — still three gates.

oc-qa-ops · oc-data-ops · oc-compliance-ops · oc-security-hardening

learning rail · v2.0

Spine Ordinals

· Mint chips on the 6 spine skills mark the handoff sequence
· 1 oc-reverse-spec → 2 oc-app-architect → 3 oc-git-ops → 4 oc-release-ops → 5 oc-deploy-ops → 6 oc-monitoring-ops
· Each chip carries ↑prev·↓next for direction
· Branch handoffs as inline mint pills inside source rects:
oc-ux-engineer → oc-dash-forge
oc-api-dev / integ-eng → oc-code-auditor
oc-code-auditor → oc-security-auditor

Tri-Agent Patterns

· oc-app-architect: Generator / Evaluator
· oc-ux-engineer: Planner / Generator / Evaluator
· oc-api-dev: Designer / Builder / Conformance
· oc-integrations-engineer: Planner / Builder / Tester
· oc-code-auditor: Auditor / Fixer / Verifier
· oc-rag-forge: Designer / Builder / Evaluator
· oc-agent-forge: Planner / Builder / Evaluator
· oc-signal-forge: Designer / Builder / Evaluator
· oc-data-ops: Designer / Builder / Contract-Verifier
· oc-hindsight: Curator / Lesson Gen / Retrieval Eval
· oc-evolve: Reflector / Rule Gen / Adversarial Eval
· 11 tri-agent skills

Audit Gates (3)

· oc-bug-check — pre-commit type/lint/secret scan
· oc-code-auditor — code-level Auditor/Fixer/Verifier
· oc-security-auditor — STRIDE / OWASP / infra hardening
· All three must pass before oc-deploy-ops ships
· v2.0's ★ promote / adopt gates are human gates, not audit gates — the count stays 3

AI Phase (v1.5)

· Phase 3 of 6 — chained in via oc-app-architect's "AI app?" branch
· oc-claude-api — model routing · prompt caching · tool use · migration
· oc-rag-forge — tri-agent; vector DB · embeddings · retrieval eval
· oc-agent-forge — tri-agent; Agent SDK · subagents · tool budgets
· oc-prompt-ops — prompt versioning · eval datasets · regression
· All four gated behind skills.registry.<id>.enabled

Checkpoint Protocol

· JSON files at .checkpoints/<skill>.checkpoint.json
· Keys: phase · progress_table · context_primer · blockers · next_actions
· All 36 skills share checkpoint access (no ACL)
· 2.0 · shared history and task evidence · checkpoint wire 1.1
· Resume: own → upstream → novice mode
· Framework-agnostic — no platform lock-in

Routing Key

· Bus pattern: 1 trunk + N branches for fan-outs/fan-ins
· Lane offsets: handoff −10, chains-to −3, advisory +4, gate +11
· Width: spine 1.8 · secondary 1.2 · advisory 1.0 · gate 1.4
· Opacity: spine .95 · secondary .78 · advisory .55
· Long-jumps: route via left/right gutter (safeX 32)
· Edge centers only: top receives, bottom sends
· Bidirectional: single line, both arrowheads (e.g. oc-deploy-ops ↔ oc-fleet-ops)

opchain skills ecosystem

1Discover$0.00 · 0Phase 1 of 6

2Plan$0.00 · 0Phase 2 of 6

3AIPhase 3 of 6 · NEW

4Build$0.00 · 0Phase 4 of 6

5Ship$0.00 · 0Phase 5 of 6

6Monitor$0.00 · 0Phase 6 of 6

Checkpoint Protocol — sync topology

Orchestrator — routing decision flow

Legend

Reference

Spine Ordinals

Tri-Agent Patterns

Audit Gates (3)

Checkpoint Protocol

Routing Key

opchain skills ecosystem

Spine Ordinals

Tri-Agent Patterns

Audit Gates (3)

AI Phase (v1.5)

Checkpoint Protocol

Routing Key

1DiscoverPhase 1 of 6

2PlanPhase 2 of 6

4BuildPhase 4 of 6

5ShipPhase 5 of 6

6MonitorPhase 6 of 6