菜单
Use when building, auditing, or planning a private or public company plugin store, Codex marketplace, internal AI operating layer, plugin catalog, store governance model, or client-specific plugin distribution surface.
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
Use when the user asks about Eidos, Eidos AGI, platform status, `eidos do`, closeout, cleanup before done, docket-task orchestration, evidence verification, praxis learning, gateway routing, vault/secrets, plugins, or which Eidos AGI specialist system should handle a task. This skill tells Codex to call the installed `eidos` CLI first; MCP and plugins should only point to CLIs, while CLIs provide progressive reveal of the deeper tool graph.
Investigate current context before predicting likely futures, failures, user objections, and concrete changes. Use when Zoltar needs to research an app, plugin, architecture, workflow, plan, decision, or implementation and answer what is likely to go wrong, what evidence supports it, what complaint or failure is being prevented, and what should change today.
Answer a specific foresight decision question with researched evidence, a clear judgment, likely futures, user complaint prediction, and concrete changes. Use when Daniel asks whether an idea, implementation, plugin, architecture, or workflow is likely to be regretted, whether it is the right thing in the right place with the right authority, or what decision should be made given future effects.
Compatibility entrypoint for Zoltar foresight. Use when Daniel mentions Zoltar, asks to predict the future, asks for second-order effects, asks what he will complain about, or wants future-backed product/spec changes; route the work through researched evidence, judgment, structured output, doer/checker handoff, and self-improvement notes rather than generic prediction.
Maintain and check the Eidos marketplace when plugins must work in both Claude Code and Codex. Use when adding, refactoring, auditing, or debugging marketplace plugins, dual-host packaging, .claude-plugin and .codex-plugin manifests, root marketplace entries, source/store/cache drift, install proof, or host-neutral plugin payloads.
Challenge whether a Zoltar prediction, product idea, plugin, workflow, category framing, or architecture is overfit to existing market patterns. Use when Daniel asks for a Challenger Matrix, anti-consensus review, category redefinition, frontier user needs, non-consensus futures, Doubter voice, or whether an answer is too derivative, market-shaped, competitor-shaped, or copied from current agent/product patterns.
基于 SOC 职业分类
| name | build-plugin-stores |
| description | Use when building, auditing, or planning a private or public company plugin store, Codex marketplace, internal AI operating layer, plugin catalog, store governance model, or client-specific plugin distribution surface. |
Use this skill when a user wants Eidos to build a plugin store for a company, team, client, or operating domain.
A successful plugin store is a governed distribution system for AI operating capability. It is not just a plugin list.
The store must answer:
Start by identifying placement:
/Users/dshanklinbv/repos-eidos-agi, /Users/dshanklinbv/repos-greenmark-waste-solutions, or another company root.eidos-agi, greenmark-waste-solutions, or a client-specific namespace.If the user already supplied these fields, state the inferred placement and proceed.
Prefer this layout for Codex stores:
<store-repo>/
├── .agents/plugins/marketplace.json
├── plugins/
│ └── <plugin-name>/
│ ├── .codex-plugin/plugin.json
│ ├── README.md
│ └── skills/<skill-name>/SKILL.md
└── README.md
Use .claude-plugin/marketplace.json and .claude-plugin/plugin.json as needed for Claude Code distribution.
Treat source, store, cache, config, and active session as separate proof surfaces:
~/.codex/plugins/cache/<store>/<plugin>/<version>.~/.codex/config.toml.Do not claim a plugin is installed or usable until the relevant surfaces have been checked.
Build narrowly scoped plugins:
cerebro, holiday-management, gate-approvals, phone-agent.Each plugin needs:
Before a store is presented as ready, verify:
felix plugin doctor <plugin-path> passes where Felix is available.Use review gates based on risk:
High-risk plugins must document approval requirements and fail-closed behavior. If the company has a Gate-style approval system, route external effects through it.
Every store should have a recurring review cadence:
The review should check stale docs, broken install paths, cache/config drift, private-data leakage, and whether any plugin should be split, promoted, paused, or removed.
When building a store, produce:
Keep the first store small. The value is trust, repeatability, and discoverability, not breadth.