ecosystem-autopsy
Orchestrate a full directory-graph autopsy across an ORGANVM workspace, then emit migration signals that unite repositories under canonical governance. Thin wrapper over organvm ecosystem + organvm irf + promotion-readiness-checklist. Triggers on auto-autopsy, map all directories, governance migration, ecosystem discovery, or "send the signal to unite" requests.
Best use case
ecosystem-autopsy is best used when you need a repeatable AI agent workflow instead of a one-off prompt.
Orchestrate a full directory-graph autopsy across an ORGANVM workspace, then emit migration signals that unite repositories under canonical governance. Thin wrapper over organvm ecosystem + organvm irf + promotion-readiness-checklist. Triggers on auto-autopsy, map all directories, governance migration, ecosystem discovery, or "send the signal to unite" requests.
Teams using ecosystem-autopsy should expect a more consistent output, faster repeated execution, less prompt rewriting.
When to use this skill
- You want a reusable workflow that can be run more than once with consistent structure.
When not to use this skill
- You only need a quick one-off answer and do not need a reusable workflow.
- You cannot install or maintain the underlying files, dependencies, or repository context.
Installation
Claude Code / Cursor / Codex
Manual Installation
- Download SKILL.md from GitHub
- Place it in
.claude/skills/ecosystem-autopsy/SKILL.mdinside your project - Restart your AI agent — it will auto-discover the skill
How ecosystem-autopsy Compares
| Feature / Agent | ecosystem-autopsy | Standard Approach |
|---|---|---|
| Platform Support | Not specified | Limited / Varies |
| Context Awareness | High | Baseline |
| Installation Complexity | Unknown | N/A |
Frequently Asked Questions
What does this skill do?
Orchestrate a full directory-graph autopsy across an ORGANVM workspace, then emit migration signals that unite repositories under canonical governance. Thin wrapper over organvm ecosystem + organvm irf + promotion-readiness-checklist. Triggers on auto-autopsy, map all directories, governance migration, ecosystem discovery, or "send the signal to unite" requests.
Where can I find the source code?
You can find the source code on GitHub using the link provided at the top of the page.
SKILL.md Source
# Ecosystem Autopsy
Open the ecosystem on the table, map every directory, classify every repository, and emit the signals that bring drifting work back under canonical governance.
## Authority boundary (read first)
This skill **orchestrates** the canonical surfaces already shipped in the ORGANVM substrate. It does not re-implement them.
- **Governance state machine** — defined in [`promotion-readiness-checklist`](../../project-management/promotion-readiness-checklist/SKILL.md). Do not restate. Invoke.
- **IRF queries** — exposed via `organvm irf {list,status,stats}`. Do not fabricate a parallel registry.
- **Ecosystem inventory + lifecycle scoring** — exposed via `organvm ecosystem {audit,list,actions,lifecycle,staleness,coverage}`. Do not duplicate.
- **Post-migration verification** — defer to [`qa-audit`](../qa-audit/SKILL.md). Do not execute remediation; stop at the signal.
If an autopsy step appears to require new state-machine definitions, IRF schema, or inventory logic, the substrate already has it. Search before authoring. See `references/integration-map.md` for the surface-by-surface mapping.
## When to use
- "Run an auto-autopsy on the workspace"
- "Map all directories under ~/Code and ~/Workspace"
- "Find every repo that's still LOCAL-only"
- "Send the signal to unite all of these under the new governance"
- "Triage what's drifting before we consolidate"
- After a long period (~30d+) without ecosystem-wide review
- Before a multi-repo consolidation, rename, or org migration
## Workflow
### Phase 1 — Discovery (registered + unregistered)
Run the canonical inventory:
```bash
organvm ecosystem --workspace ~/Workspace --workspace ~/Code audit
organvm ecosystem --workspace ~/Workspace --workspace ~/Code list
```
These cover repositories already known to the eight-organ registry.
For paths **outside** the registry (transient skill caches, `~/Documents`, scratch dirs, ad-hoc clones), supplement with:
```bash
bash scripts/discover_unregistered.sh ~/Workspace ~/Code ~/Documents
```
The helper lists git repos found on disk that are absent from `organvm ecosystem list` output. These are the autopsy's primary finds — directories the canonical inventory doesn't yet know about.
### Phase 2 — Triage (priority + IRF cross-reference)
Get the canonical prioritized next-action list:
```bash
organvm ecosystem --workspace ~/Workspace --workspace ~/Code actions --json
```
For each high-priority repo, cross-reference open IRF items by owner/domain:
```bash
organvm irf list --status open --owner <organ-or-substring> --json
organvm irf list --domain <domain-code> --status open --json
```
A repo is **truly drifting** when it appears in `ecosystem actions` AND has no open IRF row tracking the drift. That gap is the signal worth emitting.
### Phase 3 — State assessment (defer to canonical authority)
For each repo flagged in Phase 2, invoke `promotion-readiness-checklist` to assess current governance state and the evidence required to advance. Do NOT classify states from this skill. The state machine (LOCAL → CANDIDATE → PUBLIC_PROCESS → GRADUATED) and its evidence requirements (seed.yaml schema fields, LICENSE, README, CI, branch protection, etc.) live there.
```bash
organvm ecosystem --workspace ~/Workspace --workspace ~/Code lifecycle <repo>
```
`organvm ecosystem lifecycle` reports the current lifecycle stage as the ecosystem module sees it. Use it to confirm before invoking the checklist skill.
### Phase 4 — Migration signal (emit, do not execute)
For each repo with a confirmed state and a clear next-state target, emit a signal record (JSON, written to `autopsy/signals/<timestamp>.json` in the user-chosen working directory):
```json
{
"signal_type": "migration",
"repo": "<repo-name>",
"current_state": "LOCAL",
"target_state": "CANDIDATE",
"evidence_gaps": ["seed.yaml missing", "no LICENSE", "no remote"],
"invoke": "repo-onboarding-flow",
"irf_gap": true,
"emitted_at": "<ISO-8601>"
}
```
Signals route to the right downstream skill:
- LOCAL → CANDIDATE: invoke `repo-onboarding-flow`
- CANDIDATE → PUBLIC_PROCESS or PUBLIC_PROCESS → GRADUATED: invoke `promotion-readiness-checklist`
- IRF gap: emit an IRF-row proposal (do not auto-write — IRF mutations require user authorization per ORGANVM constitutional rules)
This skill **stops at signal emission**. Execution belongs to the downstream skill the signal names.
### Phase 5 — Verification (defer to qa-audit)
After downstream skills execute (in a separate session or under explicit user go), invoke `qa-audit` to verify that the claimed transitions match disk reality. The autopsy's signal file is the verification target.
## What this skill explicitly does NOT do
- Restate or redefine governance states
- Walk directory trees with bespoke Python (use `organvm ecosystem` + `discover_unregistered.sh`)
- Mutate IRF, seed.yaml, or any governance file (signals only)
- Execute git operations (push, branch, remote add) — those belong to `repo-onboarding-flow`
- Verify its own claims — that's `qa-audit`'s job
## Scripts
- `scripts/discover_unregistered.sh` — list git repos on disk that are absent from `organvm ecosystem list`
## References
- `references/integration-map.md` — phase-by-phase mapping to canonical surfaces
## Anti-patterns
- Authoring a `governance-states.md` reference in this skill (the source of truth is `promotion-readiness-checklist`)
- Writing Python that walks directories for inventory (the canonical CLI does this)
- Auto-writing IRF rows (mutations require explicit user authorization)
- Treating signals as commitments (signals are proposals; execution is a separate authorization)Related Skills
workspace-autopsy-governance
Conducts a full automated autopsy of the current workspace directory to map files, identifies structural issues, proposes a restructuring plan (the signal), and establishes unified governance using templates. Use this skill when a user asks to map, restructure, reorganize, or apply new governance to an existing messy repository.
taxonomy-modeling-design
Phase 2 of the pentaphase structural-overhaul protocol. Classifies entities, standardizes attributes, establishes relationships, and designs the access framework. Use when the user invokes phase 2 of an overhaul, asks to "design the taxonomy" or "model the structure", or has completed a landscape audit and is ready to redesign. Consumes phase-1-landscape-report.md; produces phase-2-taxonomy-model.md.
systemic-ingestion-normalization
Phase 4 of the pentaphase structural-overhaul protocol. Purges redundancies, enriches and aligns legacy entities to the new schema, executes phased ingestion into the new environment, and audits integrity. Use when the user invokes phase 4 of an overhaul, asks to "migrate the data" or "ingest into the new system", or has a configured environment ready to accept legacy entities. Consumes phase-3-environment-spec.md; produces phase-4-ingestion-report.md.
system-environment-configuration
Phase 3 of the pentaphase structural-overhaul protocol. Translates the taxonomy model into objective technical criteria, evaluates candidate mechanisms or frameworks, instantiates the chosen architecture, and programs validation rules. Use when the user invokes phase 3 of an overhaul, asks to "select a system" or "configure the environment", or has a taxonomy model and is ready to choose technology. Consumes phase-2-taxonomy-model.md; produces phase-3-environment-spec.md.
pentaphase-orchestrator
Threads the full five-phase structural-overhaul protocol — landscape discovery, taxonomy design, environment configuration, systemic ingestion, governance evolution — for any substrate the user names. Use when the user requests a structural overhaul, system redesign, or end-to-end restructuring of a documentation system, asset registry, code monorepo, knowledge base, or operational workflow; or when they explicitly invoke the pentaphase methodology. Coordinates handoffs between phase-skills and seats validation gates between phases.
landscape-discovery-audit
Phase 1 of the pentaphase structural-overhaul protocol. Inventories assets, maps current flow, identifies friction, and defines value metrics for any substrate. Use when the user invokes phase 1 of an overhaul, requests a baseline audit, asks to "discover the landscape" of a system, or wants to understand current state before redesigning. Produces phase-1-landscape-report.md.
governance-evolution-protocol
Phase 5 of the pentaphase structural-overhaul protocol. Codifies operational protocols, onboards the ecosystem of participants, programs behavior monitoring, and establishes an iteration cadence so the substrate evolves rather than calcifies. Use when the user invokes phase 5 of an overhaul, asks to "establish governance" or "lock in the protocols", or has completed ingestion and is ready to declare the substrate operational. Consumes phase-4-ingestion-report.md; produces phase-5-governance-charter.md, which closes the protocol.
dimension-surfacing
Surfaces the parallel domain dimensions implicit in a dense or minimal prompt. Use when a user prompt is small on the surface but plainly implies multiple independent domains needing different expertise; when explicitly invoked by the coliseum-orchestrator skill as Phase 1; or when the user asks "what dimensions does this prompt encode" or "what axes does this break into." Produces a named dimension set where each dimension is independently executable and not a paraphrase of another.
coliseum-dispatch
Dispatches a composed set of assignment envelopes to domain-expert subagents in parallel, in a single message with multiple Agent tool calls. Enforces the no-pingpong gate via the pingpong-detector agent before any dispatch fires. Use when invoked by the coliseum-orchestrator as Phase 3; when envelopes are already composed and the next step is parallel execution; or when the user asks to "fan out" or "dispatch in parallel." Produces a dispatch log capturing what was sent, when, and where returns land.
assignment-composition
Wraps each surfaced dimension as a self-contained 9-section autonomous-work-assignment envelope — scope, context, success criteria, allowed tools, return format, handoff — all the recipient subagent needs to execute without coming back. Use when invoked by coliseum-orchestrator as Phase 2; when dimensions are named and the next step is to make each independently dispatchable; or when the user asks "compose this as an assignment." The no-pingpong gate validates each envelope before dispatch.
workshop-presentation-design
Design engaging workshops, conference talks, and educational presentations. Covers learning objectives, activity design, slide craft, and facilitation techniques. Triggers on workshop design, presentation prep, talk structure, or training session requests.
webhook-integration-patterns
Designs reliable webhook systems with proper delivery guarantees, retry logic, signature verification, and idempotent processing for event-driven integrations.