메뉴
Use when the user wants to ship, release, publish, deploy, package, list in a marketplace, or learn how a product ships over time.
Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.
SOC 직업 분류 기준
| name | use-shipr |
| description | Use when the user wants to ship, release, publish, deploy, package, list in a marketplace, or learn how a product ships over time. |
Shipr is the persistent Eidos shipping operator. It learns each product's
release shape and keeps release memory under .shipr/.
shipr model --project . --write --json
shipr frontier --project . --json
The model should identify:
shipr attempt --project . \
--goal "ship the next release" \
--status planned \
--proof "pytest -q" \
--json
Every release attempt should leave proof, blockers, and one lesson that should be automatic next time.
When eidos ship --json is available, preserve the structured gate results
instead of flattening them into prose:
eidos ship . --json > /tmp/eidos-ship.json
shipr attempt --project . --eidos-ship-report /tmp/eidos-ship.json --json
shipr frontier --project . --json
Shipr will infer ready vs blocked, store blocked gate IDs, retain a compact
gate summary, and surface next actions in the frontier.
Shipr routes through:
forge-forge for which forges applyship-forge for release hygienesecurity-forge for safety and secret scansfoss-forge for public package qualitylearning-forge for durable lessonsloss-forge for release quality measurementShipr may inspect projects and write local release memory. Stop before public tags, package publishes, production deploys, credential changes, payments, filings, and outbound announcements unless the user explicitly approves.
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.