ワンクリックで
bring-up-bc
Launch an already-scaffolded Bounded Context as a running, online container and verify it reaches the online state
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
メニュー
Launch an already-scaffolded Bounded Context as a running, online container and verify it reaches the online state
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
SOC 職業分類に基づく
Run the open, interactive discovery conversation that turns a directional or ambiguous prompt into a written, grounded intent record
Frame two or more shaped options against each other, surface the tradeoffs, and run the deciding conversation with the product authority
Order the candidates and commitments into a defensible sequence, capturing the ordering and its rationale as a prioritization record
Continuously maintain the map of the product's problem space so every candidate and intent has a place to hang, producing problem-space map revisions
Render the product's current state outward as an honest, grounded narrative, producing a README, site, or current-state revision that traces to real capability
Take a validated intent and drive a single candidate to shaped — bounded, de-risked, and ready for a commitment decision
| name | bring-up-bc |
| description | Launch an already-scaffolded Bounded Context as a running, online container and verify it reaches the online state |
This skill is the launch leg of standing up a Bounded Context. It assumes the BC repository already exists (scaffolded and pushed to a remote) and is registered in the fleet manifest. Its job is to launch that BC as a running container and confirm it has come online and is reachable on the shop's inbox/outbox bus.
The companion create-bc skill owns the from-scratch path (scaffold → remote →
manifest) and cross-references this skill for the launch leg. When you are only
re-launching an existing, already-registered BC, you start here.
This is lead-shop work: only the lead operates bc-container and reads the
fleet-wide shop-msg bc-status view.
Launch the BC with bc-container launch. The launcher pulls the BC's repo into
a fresh container built from the pinned bc-base image, wires it onto the shop
network, and points it at the agent-vault broker so the BC's outbound calls get
real credentials injected on the wire.
bc-container launch <bc-name>
bc-container reads the BC's entry from bc-manifest.yaml — the registration
the create-bc flow wrote — for the repo URL, image pin, network, broker, and
env-file. If you are launching a BC that create-bc just registered, those
flags are already recorded; you do not re-pass them here.
BCLAUNCHER_HOST_HOME devcontainer fact (bind-mounted-home case only)BCLAUNCHER_HOST_HOME is required only for the workspace-mount /
bind-mounted-home devcontainer launch case — it is not a universal
launch-time setting. When the BC runs inside a devcontainer with a
bind-mounted home directory, the launcher needs the host path of that home
so it can bind-mount it into the container at the same location the in-container
tooling expects. That host path is supplied through the BCLAUNCHER_HOST_HOME
environment variable:
# workspace-mount / bind-mounted-home devcontainer case only:
export BCLAUNCHER_HOST_HOME="$HOME"
bc-container launch <bc-name>
In that bind-mounted-home case, without BCLAUNCHER_HOST_HOME set the launcher
cannot resolve the host side of the bind mount and the container comes up with a
home that is missing the credential-helper config, the git identity, and the
agent-vault client material the BC needs.
A clone-path BC launch does not require BCLAUNCHER_HOST_HOME. On the
clone path the launcher pulls the BC's repo into a fresh container and the
container's credentials arrive on the wire through the agent-vault broker — there
is no bind-mounted host home to resolve, so there is nothing for
BCLAUNCHER_HOST_HOME to point at. Do not treat BCLAUNCHER_HOST_HOME as
universally required for every launch; set it only for the bind-mounted-home
devcontainer case above.
onlineA launch that returns exit 0 only means the container started; it does not
mean the BC has registered on the bus and is ready to receive dispatches. Verify
the BC reaches online through the fleet status view:
shop-msg bc-status
shop-msg bc-status reports each registered BC and its current state. Watch the
target BC's row transition to online. A BC that is stuck in a starting or
errored state has not come up cleanly — read its container logs before
dispatching any work to it. Do not consider the bring-up complete until
shop-msg bc-status shows the BC online.
bc-container launch <bc-name> ran with BCLAUNCHER_HOST_HOME exported to the
host home directory; a clone-path launch does not require it.shop-msg bc-status shows the BC in the online state.shop-msg ping/dispatch (it is reachable on the bus, not
merely "container running").The end-to-end launch path is still being hardened. Narrate each step to the
user as you go and confirm the online transition with them before treating the
BC as ready for real dispatches — a green container is not yet a proven online
BC.