Epic: Expose OpenAI Skills as Ouroboros Superpower Commands

[shaun0927]

Summary

Build an Ouroboros-native Superpowers plugin layer that exposes every skill from openai/skills as an auditable Ouroboros command while preserving the existing Codex Skill user experience as closely as possible.

The goal is not to copy skills into this repository as a marketplace. The goal is to assimilate the OpenAI Agent Skills catalog into the Ouroboros UserLevel plugin contract so users can invoke the same reusable workflows through Ouroboros commands, with Seed / Ledger / State / Provenance / Permission / Audit / Handoff semantics preserved.

This is intended to move Ouroboros toward a true agentOS: an operating layer where external agent capabilities, OSS workflows, and domain-specific superpowers can be discovered, trusted, invoked, audited, and composed without becoming unbounded core code.

Motivation

OpenAI Skills already provide a strong authoring format for reusable agent workflows:

• SKILL.md frontmatter and instructions
• optional scripts/
• optional references/
• optional assets/
• optional agents/openai.yaml
• progressive-disclosure activation based on skill name and description
• explicit invocation through $skill-name
• implicit invocation when the user task matches the skill description

Ouroboros plugins provide a stronger execution boundary:

• manifest-backed command declarations
• core capability declarations
• external permission declarations
• risk taxonomy: read_only, write, destructive
• lifecycle and trust states
• firewall-mediated invocation
• audit and provenance events
• Seed / handoff / workflow integration

This epic connects both worlds:

OpenAI / Agent Skill
  ↓
Skill ingestion + command synthesis
  ↓
Ouroboros plugin contract
  ↓
permissioned command invocation
  ↓
Seed / Ledger / State / Provenance / Audit / Handoff
  ↓
agentOS superpower execution

Current inventory to support

As of the latest inspected openai/skills main tree, the repository contains 43 skills:

• 38 curated skills under skills/.curated/
• 5 system skills under skills/.system/

Observed skills:

.curated:
- aspnet-core
- chatgpt-apps
- cli-creator
- cloudflare-deploy
- figma-code-connect-components
- figma-create-design-system-rules
- figma-create-new-file
- figma-generate-design
- figma-generate-library
- figma-implement-design
- figma-use
- figma
- gh-address-comments
- gh-fix-ci
- hatch-pet
- jupyter-notebook
- linear
- migrate-to-codex
- netlify-deploy
- notion-knowledge-capture
- notion-meeting-intelligence
- notion-research-documentation
- notion-spec-to-implementation
- openai-docs
- pdf
- playwright-interactive
- playwright
- render-deploy
- screenshot
- security-best-practices
- security-ownership-map
- security-threat-model
- sentry
- speech
- transcribe
- vercel-deploy
- winui-app
- yeet

.system:
- imagegen
- openai-docs
- plugin-creator
- skill-creator
- skill-installer

Many skills include scripts, references, assets, and agent metadata. The adapter must preserve those resources as part of the execution context or handoff, not flatten them into a single prompt string.

Product goal

A user should be able to take a workflow that currently feels like this in Codex:

$openai-docs explain the current Apps SDK plugin packaging model
$gh-fix-ci inspect the failing checks on this PR
$playwright reproduce the login bug
$cloudflare-deploy deploy this Worker

And invoke the same superpower through Ouroboros with a command-shaped UX, for example:

ooo superpower run openai-docs -- "explain the current Apps SDK plugin packaging model"
ooo superpower run gh-fix-ci -- "inspect the failing checks on this PR"
ooo superpower run playwright -- "reproduce the login bug"
ooo superpower run cloudflare-deploy -- "deploy this Worker"

Future direct aliases may be supported when namespace ownership is safe:

ooo openai-docs "explain the current Apps SDK plugin packaging model"
ooo gh-fix-ci "inspect the failing checks on this PR"
ooo playwright "reproduce the login bug"

The command execution must still pass through the Ouroboros plugin firewall. A skill is not considered “run by Ouroboros” merely because a subprocess or prompt was launched. It is run by Ouroboros only when discovery, manifest resolution, trust checks, permission checks, risk classification, audit emission, and result/handoff semantics are applied.

Proposed reference plugin

Add a reference plugin:

plugins/superpowers/

Alternative names:

• plugins/codex-skill-superpowers/
• plugins/agent-skill-adapter/
• plugins/openai-skills-adapter/

Recommended name: superpowers because the user-facing intent is broader than OpenAI-specific packaging, while the first catalog source is openai/skills.

Proposed command surface

MVP commands:

ooo superpower catalog refresh --source openai/skills --ref main
ooo superpower catalog list
ooo superpower inspect <skill-name>
ooo superpower run <skill-name> -- <task>
ooo superpower handoff <skill-name> --task <task> --out <path>
ooo superpower trust-plan <skill-name>
ooo superpower doctor

Optional later commands:

ooo superpower install <skill-name>
ooo superpower pin <skill-name> --ref <sha-or-tag>
ooo superpower update <skill-name>
ooo superpower aliases enable
ooo <skill-name> <task>

Required behavior

1. Catalog ingestion

The plugin should ingest openai/skills from a pinned GitHub ref and build a local catalog projection.

For each skill, record:

• skill name
• source bucket: .curated or .system
• source path
• source repository
• source ref / commit SHA
• description
• license file presence and license text path
• resource inventory:
  • SKILL.md
  • scripts/
  • references/
  • assets/
  • agents/openai.yaml
• inferred permission requirements
• inferred risk tier
• supported command exposure mode

2. Command synthesis

Every skill should become an invocable Ouroboros command target.

Minimum stable UX:

ooo superpower run <skill-name> -- <task>

The command wrapper should:

1. resolve <skill-name> against the catalog,
2. load SKILL.md using progressive-disclosure semantics,
3. attach relevant references/scripts/assets to execution context only when needed,
4. classify required permissions,
5. perform trust/firewall checks,
6. run or hand off the skill workflow,
7. emit audit/provenance events,
8. produce a human-readable result and machine-readable handoff.

3. UX preservation

The adapter should preserve the Codex Skill experience as much as possible:

• $skill-name maps conceptually to ooo superpower run <skill-name>.
• Skill descriptions remain the activation surface.
• Skill names remain stable.
• SKILL.md remains the authoritative workflow instruction source.
• references/ are loaded progressively rather than eagerly.
• scripts/ are reused rather than reimplemented.
• assets/ remain available to the workflow.
• agents/openai.yaml is preserved as metadata, even if not fully executable in MVP.
• Existing skill-specific setup notes should surface in inspect and doctor.

The user should not feel that using a skill through Ouroboros is a degraded wrapper. The command should feel like the same superpower with stronger OS-level safety, provenance, and composability.

4. Permission and risk mapping

The adapter must infer and/or declare permissions for each skill.

Examples:

Skill type	Example skills	Likely risk
Documentation / planning	openai-docs, aspnet-core, security-threat-model	read_only or write if handoff is written
Local file generation	jupyter-notebook, migrate-to-codex, hatch-pet	write
Browser automation	playwright, playwright-interactive, screenshot	read_only / write, depending on action
GitHub operations	gh-address-comments, gh-fix-ci, yeet	read_only, write, or destructive depending on command
SaaS integrations	linear, notion-*, sentry, figma-*	read_only / write with external auth
Deployments	cloudflare-deploy, netlify-deploy, render-deploy, vercel-deploy	often write or destructive
Media/API generation	imagegen, speech, transcribe	write, network:write, provider-specific scopes

Required principle:

The adapter must not hide destructive or external-write behavior inside a generic “run skill” command.

If the selected skill may mutate external systems, the generated invocation must either be blocked until trusted or require explicit confirmation according to the Ouroboros permission model.

5. Audit and provenance

Every invocation should answer:

• Which skill ran?
• Which repository/ref/path supplied the skill?
• Which version or commit was used?
• Which command exposed it?
• What task text was supplied?
• Which references/scripts/assets were loaded?
• Which permissions were required?
• Which permissions were actually used?
• Was the run blocked, failed, cancelled, or completed?
• What handoff or artifact was produced?
• What should a human or harness do next?

Expected event vocabulary should align with the existing plugin audit model:

• plugin.invoked
• plugin.permission_used
• plugin.completed
• plugin.failed

Future extension may add more specific events such as:

• superpower.catalog_refreshed
• superpower.skill_resolved
• superpower.reference_loaded
• superpower.script_executed

Only add new audit events if the existing schema cannot represent the required evidence.

6. Handoff artifacts

ooo superpower handoff <skill-name> should create an Ouroboros-readable handoff artifact that can be consumed by ooo auto, Seed generation, or future Workflow IR / Run-Step-Artifact projections.

Suggested handoff shape:

{
  "schema_version": "0.1",
  "kind": "superpower_handoff",
  "source": {
    "repository": "openai/skills",
    "ref": "<commit-sha>",
    "path": "skills/.curated/<skill-name>"
  },
  "skill": {
    "name": "<skill-name>",
    "description": "...",
    "components": {
      "skill_md": true,
      "scripts": true,
      "references": true,
      "assets": true,
      "agents": true
    }
  },
  "task": "...",
  "permissions": {
    "required": [],
    "optional": [],
    "risk": "read_only|write|destructive"
  },
  "outputs": {
    "human_summary": "...",
    "next_steps": [],
    "artifacts": []
  },
  "provenance": {
    "catalog_commit": "...",
    "loaded_files": [],
    "executed_scripts": []
  }
}

Proposed plugin manifest sketch

{
  "schema_version": "0.1",
  "name": "superpowers",
  "version": "0.1.0",
  "description": "Expose OpenAI/Agent Skills as Ouroboros-native command superpowers with permission, audit, provenance, and handoff semantics.",
  "source": {
    "type": "local_path",
    "path": "plugins/superpowers"
  },
  "commands": [
    {
      "namespace": "superpower",
      "name": "run",
      "summary": "Run a cataloged Agent Skill through the Ouroboros plugin firewall.",
      "usage": "ooo superpower run <skill-name> -- <task>",
      "risk": "write",
      "requires_confirmation": false
    },
    {
      "namespace": "superpower",
      "name": "inspect",
      "summary": "Inspect a cataloged skill and show its inferred permissions, resources, and command exposure.",
      "usage": "ooo superpower inspect <skill-name>",
      "risk": "read_only",
      "requires_confirmation": false
    },
    {
      "namespace": "superpower",
      "name": "handoff",
      "summary": "Generate an Ouroboros-readable handoff artifact for a skill invocation.",
      "usage": "ooo superpower handoff <skill-name> --task <task> --out <path>",
      "risk": "write",
      "requires_confirmation": false
    }
  ],
  "capabilities": [
    {
      "name": "handoff",
      "access": "attach",
      "reason": "Attach superpower invocation outputs to Ouroboros workflows."
    },
    {
      "name": "provenance",
      "access": "write",
      "reason": "Record skill source, ref, loaded files, and execution evidence."
    },
    {
      "name": "ledger",
      "access": "write",
      "reason": "Record superpower invocation and trust decisions."
    },
    {
      "name": "state",
      "access": "write",
      "reason": "Cache the skill catalog and pinned refs."
    }
  ],
  "permissions": [
    {
      "scope": "filesystem:read",
      "risk": "read_only",
      "required": true,
      "reason": "Read cached skill files and local resources."
    },
    {
      "scope": "filesystem:write",
      "risk": "write",
      "required": false,
      "reason": "Write catalog cache and handoff artifacts."
    },
    {
      "scope": "network:read",
      "risk": "read_only",
      "required": false,
      "reason": "Fetch or refresh skills from GitHub."
    },
    {
      "scope": "shell:execute",
      "risk": "write",
      "required": false,
      "reason": "Run bundled skill scripts when a trusted skill requires them."
    }
  ],
  "entrypoint": {
    "type": "command",
    "command": "python -m superpowers"
  }
}

Note: command-level risk may need a dynamic risk overlay because run can dispatch both read-only and mutating skills. If the current manifest contract cannot express dynamic per-skill risk precisely, the MVP should keep superpower run conservative and perform runtime subcommand risk checks inside the firewall.

Implementation phases

Phase 0 — Contract alignment

• Confirm this epic is compatible with SSOT: UserLevel plugin authoring and capability assimilation #27’s plugin authoring / capability assimilation RFC direction.
• Decide whether the reference plugin name is superpowers, codex-skill-superpowers, or agent-skill-adapter.
• Document that this is not a marketplace and not a bulk import of third-party plugins.

Phase 1 — Catalog reader

• Fetch or read a pinned openai/skills tree.
• Parse every SKILL.md frontmatter.
• Detect optional directories: scripts, references, assets, agents.
• Record license/provenance data.
• Produce a local machine-readable catalog.
• Add ooo superpower catalog list and ooo superpower inspect.

Phase 2 — Handoff-first invocation

• Implement ooo superpower handoff <skill-name>.
• Preserve skill instructions and resource references.
• Generate a structured handoff artifact.
• Emit audit/provenance events.
• Do not execute external writes yet.

Phase 3 — Read-only superpower execution

• Enable ooo superpower run for read-only skills.
• Start with low-risk skills such as:
  • openai-docs
  • security-best-practices
  • security-threat-model
  • aspnet-core
  • pdf in read-only mode
• Verify progressive resource loading.
• Verify audit events.

Phase 4 — Write-capable and script-backed skills

• Support trusted execution for skills with bundled scripts.
• Require shell:execute only when a selected skill path actually needs it.
• Add exact provenance for executed scripts.
• Support local artifact writes with repo-relative bounds.

Phase 5 — External service and deployment skills

• Add explicit scope models for GitHub, Figma, Linear, Notion, Sentry, Cloudflare, Netlify, Render, Vercel, etc.
• Block untrusted external-write and destructive actions.
• Preserve existing Ouroboros trust semantics.
• Add command-level confirmation where required.

Phase 6 — Direct aliases and agentOS polish

• Explore safe direct aliases:
  • ooo openai-docs ...
  • ooo gh-fix-ci ...
  • ooo playwright ...
• Reject aliases that collide with existing namespaces.
• Make alias ownership auditable.
• Improve ooo auto handoff consumption without putting skill-specific branches inside ooo auto.

Acceptance criteria

This epic is complete when:

• A superpowers reference plugin exists under plugins/.
• The plugin validates against the current Ouroboros plugin schema.
• The plugin can ingest the full openai/skills catalog from a pinned ref.
• All 43 currently observed skills are represented in the local catalog.
• Each skill has an inspectable command projection.
• Each skill has inferred or declared resource inventory:
  • SKILL.md
  • scripts/
  • references/
  • assets/
  • agents/openai.yaml
• Each skill has an inferred permission/risk profile.
• ooo superpower inspect <skill-name> works for every skill.
• ooo superpower handoff <skill-name> generates an Ouroboros-readable handoff artifact.
• At least three read-only skills can be invoked through ooo superpower run.
• At least one script-backed skill can be invoked after explicit trust.
• External-write and destructive skills are blocked until trusted.
• Every invocation emits standard plugin audit/provenance events.
• UX docs explain the mapping from $skill-name to ooo superpower run <skill-name>.
• README links to the superpowers plugin and explains that this is capability assimilation, not a marketplace.
• The implementation preserves the ooo auto boundary: ooo auto may consume superpower handoffs, but does not become a skill-specific router.

Non-goals

• Do not bulk-copy every openai/skills skill as a separate plugin under plugins/.
• Do not turn Q00/ouroboros-plugins into a central marketplace.
• Do not bypass the plugin firewall for convenience.
• Do not grant destructive permissions implicitly.
• Do not execute bundled scripts without explicit permission modeling.
• Do not hide external SaaS writes behind a generic read-only command.
• Do not add new manifest fields until a reference implementation proves the existing contract cannot represent the need.
• Do not put every skill-specific branch into ooo auto.

Open design questions

1. Should .system skills be exposed by default, or should they require a separate --include-system flag?
2. Should direct aliases (ooo <skill-name>) be generated in v0, or deferred until namespace collision policy is stronger?
3. How should duplicate skill names be handled? Example: openai-docs exists under both .curated and .system.
4. Should dynamic per-skill risk be represented only at runtime, or does the manifest schema need an optional command-risk projection model later?
5. Should skill resources be cached in ~/.ouroboros/plugins/superpowers/, ~/.ouroboros/cache/, or plugin state?
6. What is the minimum handoff artifact shape needed for ooo auto and future Workflow IR / Run-Step-Artifact integration?
7. How much of agents/openai.yaml can be preserved as metadata versus executed behavior in Ouroboros?

Relationship to #27

This epic is a concrete reference implementation of the #27 thesis:

Ouroboros plugins are not merely command wrappers. They are the capability assimilation layer that turns external tools, open-source libraries, and domain workflows into structured, auditable, permissioned, Seed-compatible Ouroboros capabilities.

openai/skills is a strong test case because it is already a rich external capability catalog. The superpowers plugin should prove that Ouroboros can assimilate that catalog without collapsing into a marketplace or weakening safety boundaries.

Success statement

When this epic is done, Ouroboros users should be able to run Codex-style skills as first-class Ouroboros superpowers:

ooo superpower run openai-docs -- "explain how to build a plugin"
ooo superpower run gh-fix-ci -- "inspect this PR's failing checks"
ooo superpower run playwright -- "reproduce this UI bug"
ooo superpower handoff security-threat-model --task "model this repo's trust boundaries" --out .ouroboros/handoffs/security-threat-model.json

The experience should feel like the same skill-based workflow, but upgraded with OS-level permissioning, auditability, provenance, lifecycle, handoff, and composition.

[shaun0927]

Post-merge AgentOS 실검증 계획 / evidence collection guide

PR #67 merged the OpenAI Skills adapter as plugins/openai-skills-superpowers. To prove it works as an Ouroboros AgentOS capability, validate it in layers. The goal is not just “the Python module runs”; the evidence should show manifest discovery → permission/trust decision → firewall behavior → audit/provenance → handoff → downstream AgentOS consumption.

0. Baseline: current main and contract validation

git checkout main
git pull --ff-only origin main
python3 scripts/validate_contract.py
python3 -m unittest discover -s tests -q

Evidence to save:

• commit SHA of main
• validator output
• unit-test output

This proves the plugin is schema-compatible with the current ouroboros-plugins contract.

1. Catalog ingestion evidence

Use the pinned OpenAI Skills ref from the PR:

PYTHONPATH=plugins/openai-skills-superpowers python3 -m ouroboros_superpowers catalog refresh \
  --source openai/skills \
  --ref 590b49edc158611a2b2ed715ae73f27eb70d251a \
  --out .omx/evidence/issue39/catalog.json

PYTHONPATH=plugins/openai-skills-superpowers python3 -m ouroboros_superpowers \
  --catalog .omx/evidence/issue39/catalog.json doctor

PYTHONPATH=plugins/openai-skills-superpowers python3 -m ouroboros_superpowers \
  --catalog .omx/evidence/issue39/catalog.json catalog list --include-system \
  > .omx/evidence/issue39/catalog-list.json

Expected evidence:

• catalog.json exists and records source repository/ref/path.
• doctor reports skill_count: 43, curated_count: 38, system_count: 5.
• duplicate handling shows openai-docs and allows system/openai-docs as the qualified system target.

2. Inspect / risk projection evidence

PYTHONPATH=plugins/openai-skills-superpowers python3 -m ouroboros_superpowers \
  --catalog .omx/evidence/issue39/catalog.json inspect openai-docs \
  > .omx/evidence/issue39/inspect-openai-docs.json

PYTHONPATH=plugins/openai-skills-superpowers python3 -m ouroboros_superpowers \
  --catalog .omx/evidence/issue39/catalog.json inspect pdf \
  > .omx/evidence/issue39/inspect-pdf.json

PYTHONPATH=plugins/openai-skills-superpowers python3 -m ouroboros_superpowers \
  --catalog .omx/evidence/issue39/catalog.json inspect yeet \
  > .omx/evidence/issue39/inspect-yeet.json

Expected evidence:

• openai-docs is read-only guidance.
• pdf remains write in catalog because it can create artifacts; only read/review tasks get runtime read-only treatment.
• yeet / external-write style skills are not silently treated as read-only.

3. Firewall / blocked-path audit evidence

Blocked paths are first-class AgentOS evidence. They should not emit plugin.invoked; they should emit plugin.failed with trust_state: blocked.

PYTHONPATH=plugins/openai-skills-superpowers python3 -m ouroboros_superpowers \
  --catalog .omx/evidence/issue39/catalog.json \
  --audit-log .omx/evidence/issue39/audit-blocked.jsonl \
  run yeet -- "open a PR"

PYTHONPATH=plugins/openai-skills-superpowers python3 -m ouroboros_superpowers \
  --catalog .omx/evidence/issue39/catalog.json \
  --audit-log .omx/evidence/issue39/audit-self-trust.jsonl \
  run hatch-pet --trusted --allow-shell -- "validate pet"

PYTHONPATH=plugins/openai-skills-superpowers python3 -m ouroboros_superpowers \
  --catalog .omx/evidence/issue39/catalog.json \
  --audit-log .omx/evidence/issue39/audit-pdf-write.jsonl \
  run pdf -- "create a PDF artifact"

Expected evidence:

• each command returns blocked/non-zero;
• audit files contain plugin.failed only;
• no plugin.invoked event is emitted for missing-trust blocked execution;
• --trusted is documented as not being an authority source; future trusted execution must come from plugin-manager-provided granted scopes.

4. Read-only run projection evidence

PYTHONPATH=plugins/openai-skills-superpowers python3 -m ouroboros_superpowers \
  --catalog .omx/evidence/issue39/catalog.json \
  --audit-log .omx/evidence/issue39/audit-readonly.jsonl \
  run openai-docs -- "explain how to build an Ouroboros plugin" \
  > .omx/evidence/issue39/run-openai-docs.json

PYTHONPATH=plugins/openai-skills-superpowers python3 -m ouroboros_superpowers \
  --catalog .omx/evidence/issue39/catalog.json \
  --audit-log .omx/evidence/issue39/audit-pdf-read.jsonl \
  run pdf -- "read and summarize this PDF" \
  > .omx/evidence/issue39/run-pdf-read.json

Expected evidence:

• status is success;
• output kind is superpower_run_projection;
• audit includes plugin.invoked, plugin.permission_used, plugin.completed;
• loaded files/provenance name the selected skill source/ref/path.

5. Handoff artifact evidence

PYTHONPATH=plugins/openai-skills-superpowers python3 -m ouroboros_superpowers \
  --catalog .omx/evidence/issue39/catalog.json \
  --audit-log .omx/evidence/issue39/audit-handoff.jsonl \
  handoff security-threat-model \
  --task "model this repo's plugin trust boundaries" \
  --out .omx/evidence/issue39/security-threat-model-handoff.json

Expected evidence:

• handoff JSON has kind: superpower_handoff;
• includes source.repository, pinned source.ref, skill.name, permissions.risk, instructions.skill_md_path, and provenance.loaded_files;
• audit records successful handoff creation;
• the artifact can be attached to a Seed / ooo auto brief without adding skill-specific branches to ooo auto.

6. Full AgentOS pipeline smoke test

After installing from the repository root:

ouroboros plugin add . --plugin openai-skills-superpowers
ouroboros plugin inspect openai-skills-superpowers

Then exercise the dispatcher surface, if available:

ooo superpower catalog refresh --source openai/skills --ref 590b49edc158611a2b2ed715ae73f27eb70d251a
ooo superpower inspect openai-docs
ooo superpower handoff security-threat-model --task "model this repo's plugin trust boundaries" --out .omx/evidence/issue39/handoff-from-ooo.json
ooo superpower run openai-docs -- "explain how this plugin should be used safely"

Finally feed the handoff into the normal AgentOS continuation path, for example:

ooo auto "$(cat .omx/evidence/issue39/handoff-from-ooo.json)"

Evidence to collect from the full pipeline:

• plugin install/inspect output showing manifest identity and granted/blocked scopes;
• .omx/evidence/issue39/* artifacts listed above;
• plugin audit JSONL events;
• any Ouroboros ledger/provenance/state entries created by plugin manager / ooo auto;
• the downstream ooo auto Seed or run ledger referencing the superpower_handoff artifact;
• screenshots or command transcript showing blocked destructive/script paths remain blocked.

Success criteria for “AgentOS에서 제대로 동작”

The integration is proven when these are all true:

1. Plugin manifest is discoverable and validates.
2. Catalog ingestion represents all 43 pinned OpenAI Skills.
3. Inspect/list expose skill resources and risk without loading everything eagerly.
4. Read-only run produces a run projection and emits standard audit events.
5. Handoff creates an Ouroboros-readable artifact with source/ref/provenance.
6. Script/write/external/destructive skills are blocked until real plugin-manager trust exists.
7. Blocked paths emit plugin.failed only, not plugin.invoked.
8. ooo auto can consume the handoff artifact as input without becoming a skill-specific router.

If any of these fail, the failure evidence should be attached as:

.omx/evidence/issue39/<step>-stdout.txt
.omx/evidence/issue39/<step>-stderr.txt
.omx/evidence/issue39/<artifact>.json
.omx/evidence/issue39/<audit>.jsonl

That evidence set is enough to debug whether the problem is catalog ingestion, plugin-manager dispatch, firewall/trust, audit/provenance, or downstream AgentOS handoff consumption.

[shaun0927]

Reopening because full AgentOS real-world validation/evidence collection is not complete yet. Keep this epic open until end-to-end validation evidence is attached.

[shaun0927]

현재 세션 검증 결과 (2026-05-21)

PR #67 merge 후 origin/main 기준으로, 이 세션에서 실제 실행 가능한 범위까지 검증했습니다.

• 검증 worktree: /Users/jh0927/ouroboros-plugins-issue39
• 브랜치/HEAD: issue39-validation / 67f776d96060219422e3ba1846834682e3837680
• origin/main: 67f776d96060219422e3ba1846834682e3837680
• 증거 디렉터리: .omx/evidence/issue39/
• 요약 파일: .omx/evidence/issue39/summary.json

1. 저장소/계약/테스트 검증

항목	결과	증거
manifest contract validation	PASS	.omx/evidence/issue39/validate-contract.stdout.txt → contract validation passed (23 plugin manifest(s) validated)
full unittest discovery	PASS	.omx/evidence/issue39/unittest.stderr.txt → Ran 191 tests in 209.244s, OK
Python compile smoke	PASS	python3 -m py_compile plugins/openai-skills-superpowers/ouroboros_superpowers/__main__.py completed
audit JSONL schema validation	PASS	.omx/evidence/issue39/summary.json의 모든 audit schema check 통과

2. OpenAI/Agent Skills catalog 검증

고정 ref 590b49edc158611a2b2ed715ae73f27eb70d251a에서 실제 catalog refresh를 수행했습니다.

항목	결과	증거
catalog refresh	PASS	.omx/evidence/issue39/catalog-refresh.stdout.json
doctor	PASS	.omx/evidence/issue39/doctor.stdout.json
총 skill 수	43	skill_count: 43
curated skill 수	38	curated_count: 38
system skill 수	5	system_count: 5
duplicate policy	확인됨	duplicate: openai-docs; curated 우선, system은 bucket-qualified lookup

3. permission/risk projection 검증

inspect 결과로 risk projection을 확인했습니다.

skill	risk	required	optional	증거
openai-docs	read_only	filesystem:read	shell:execute	.omx/evidence/issue39/inspect-openai-docs.json
pdf	destructive	filesystem:read	filesystem:write, render:write	.omx/evidence/issue39/inspect-pdf.json
yeet	destructive	filesystem:read	github:write	.omx/evidence/issue39/inspect-yeet.json

4. runtime firewall / audit 검증

현재 세션에서 adapter entrypoint를 직접 실행해 허용/차단 경로를 검증했습니다.

실행	결과	audit sequence	증거
run openai-docs -- "explain how to build an Ouroboros plugin"	PASS / status: success, risk: read_only	plugin.invoked → plugin.permission_used → plugin.completed	.omx/evidence/issue39/run-openai-docs.json, .omx/evidence/issue39/audit-readonly.jsonl
run pdf -- "read and summarize this PDF"	BLOCKED	only plugin.failed, trust_state: blocked	.omx/evidence/issue39/run-pdf-read.json, .omx/evidence/issue39/audit-pdf-read.jsonl
run pdf -- "create a PDF artifact"	BLOCKED, exit code 3	only plugin.failed, trust_state: blocked	.omx/evidence/issue39/run-pdf-write-blocked.json, .omx/evidence/issue39/audit-pdf-write.jsonl
run yeet -- "open a PR"	BLOCKED, exit code 3	only plugin.failed, trust_state: blocked	.omx/evidence/issue39/run-yeet-blocked.json, .omx/evidence/issue39/audit-blocked-yeet.jsonl
run hatch-pet --trusted --allow-shell -- "validate pet"	BLOCKED, exit code 3	only plugin.failed, trust_state: blocked	.omx/evidence/issue39/run-self-trust-blocked.json, .omx/evidence/issue39/audit-self-trust.jsonl

중요한 보안 확인:

• self-attested --trusted / --allow-shell은 권한 소스로 인정되지 않았습니다.
• blocked path에서는 plugin.invoked가 남지 않고 plugin.failed만 기록됩니다.
• blocked audit event의 permissions_used는 빈 배열입니다.
• 모든 audit JSONL은 schemas/0.1/audit-event.schema.json으로 검증했습니다.

5. handoff / ooo auto 소비 가능 artifact 검증

security-threat-model에 대해 handoff artifact 생성을 검증했습니다.

• 실행 결과: kind: superpower_handoff
• skill: security-threat-model
• output: .omx/evidence/issue39/security-threat-model-handoff.json
• audit: .omx/evidence/issue39/audit-handoff.jsonl
• audit schema: PASS

이 handoff JSON에는 skill source/ref/path, task, permission/risk profile, instruction excerpt, progressively loaded resources, next steps가 들어가므로 ooo auto 또는 상위 AgentOS workflow 입력 brief로 넘길 수 있는 형태임을 확인했습니다.

6. AgentOS plugin-manager 통합 검증 (현재 세션 가능 범위)

이 세션에는 ouroboros CLI가 존재했지만 ooo executable은 없었습니다.

• ouroboros: /opt/homebrew/bin/ouroboros
• ooo: not found

따라서 global 환경을 오염시키지 않기 위해 isolated root를 사용해 plugin-manager 설치/신뢰 경로를 검증했습니다.

항목	결과	증거
isolated plugin add	PASS	.omx/evidence/issue39/agentos/isolated-plugin-manager.txt
installed plugin	openai-skills-superpowers 0.1.0	.omx/evidence/issue39/agentos/plugins.lock
pre-trust state	installed, missing filesystem:read	.omx/evidence/issue39/agentos/isolated-plugin-manager-trust.txt
exact scope trust grant	PASS, granted filesystem:read	.omx/evidence/issue39/agentos/plugin-trust-audit.jsonl
post-trust state	trusted, no missing required scopes	.omx/evidence/issue39/agentos/isolated-plugin-manager-trust.txt

참고: ouroboros plugin add . --plugin openai-skills-superpowers 실행 중 repo 내 다른 플러그인 target-capabilities manifest가 현재 plugin-manager schema와 맞지 않는다는 skip 메시지가 함께 출력됐지만, openai-skills-superpowers 자체는 정상 설치되었습니다.

결론

현재 세션에서 가능한 검증 범위에서는 PASS입니다.

• adapter-level AgentOS contract, catalog ingestion, permission/risk projection, audit/provenance, blocked-path firewall, self-trust 차단, handoff artifact 생성을 실제 실행으로 확인했습니다.
• plugin-manager에 isolated install/trust까지 확인했습니다.
• 단, 이 세션에는 ooo executable이 없어 ooo superpower ... dispatcher를 통한 end-to-end invocation은 실행하지 못했습니다. 이 부분은 ooo dispatcher가 설치된 AgentOS 세션에서 같은 evidence plan으로 추가 smoke를 돌리면 됩니다.

현재 증거 기준으로는 #39의 핵심 목표인 “OpenAI/Agent Skills를 Ouroboros AgentOS capability로 편입하고, 안전한 permission/audit/handoff 경계로 노출”이 구현/검증되었습니다.