菜单
Use when an agent receives a Cogni node wizard launch pack, takes over a newly published throwaway node, or must prove the node-wizard launch path end-to-end across child customization PR, child CI/image, parent pin, operator flight request, and candidate /version verification.
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
| name | node-wizard-scorecard |
| description | Use when an agent receives a Cogni node wizard launch pack, takes over a newly published throwaway node, or must prove the node-wizard launch path end-to-end across child customization PR, child CI/image, parent pin, operator flight request, and candidate /version verification. |
Use this as the first response after receiving a node launch pack. The goal is not to save the throwaway node; the goal is to prove the node-wizard launch path is reproducible by an external agent without privileged manual bridges.
If the workspace root does not contain .env.cogni, run
/contribute-to-cogni against the production operator and save the returned env
file at the repo root before doing launch work. Use that token to recall the
launch handoff knowledge block (node-launch-handoff) and search for agent
starter-kit knowledge before designing the customization PR.
Do not send the full matrix before a child customization PR exists. Before that
point, report only launch facts plus the next concrete action. A status table
with READY rows is misleading because the path has not produced a deployable
artifact and human merge latency may still be ahead.
Pre-PR first response:
Launch facts:
- node repo:
- parent PR:
- candidate URL:
Current gate: child customization PR not opened
Next action: create a minimal node repo PR and report its URL
Humans may send only a repo URL, parent PR, or short status fragment. Recover the rest from GitHub/operator state; do not ask the human to fill out the scorecard.
Return this matrix only after the child customization PR exists, or when reporting a terminal blocker that prevents opening one:
| Gate | Evidence | Status | Next action |
|---|---|---|---|
| Launch pack facts | node repo URL, parent PR, candidate URL | pass/blocked | missing fact to recover |
| Branch protection | node repo main requires the standard CI checks (and a PR) before merge | pass/blocked | enable branch protection on the spawned node repo — required checks = the standard CI set |
| Child customization PR | PR URL in node repo | pass/blocked | create PR from node repo branch |
| Child CI | required checks green | pass/blocked | fix child PR |
| Child main image | ghcr.io/<owner>/<repo>:sha-<child-main-sha> exists after merge | pass/blocked | report missing image/tag |
| Parent birth PR | merged or still open | pass/blocked | wait/ask human to merge parent PR |
| Parent pin | parent gitlink pins the image-producing child main SHA | pass/blocked | ask operator to update/publish parent pin |
| Candidate flight | requested through operator API | pass/blocked | call operator flight API only when eligible |
| Candidate verification | candidate /version matches launched child SHA | pass/blocked | run agent-first validation |
| Agent-first validation | candidate API exercised using docs/guides/agent-api-validation.md | pass/blocked | present human scorecard |
main MUST have branch protection requiring the
standard CI checks (and a PR) before merge. This is the precondition that
gives operator "merge on green" real teeth and a backstop: without it, a PR
whose checks were skipped or never ran can merge vacuously and the operator's
own merge gate becomes the only authority. With it, an RBAC-holder can safely
approve the standard CI workflows on — and merge — external-dev PRs to that
repo (including PRs the agent itself authored from a fork), because branch
protection independently enforces that the standard checks went green.main.<node>-test record. The flight upserts
it (reconcile-node-dns.sh; ci-cd.md Axiom 21). A fresh-flight NXDOMAIN is
almost always negative-cache — re-check dig <host> +short @1.1.1.1.node-substrate edge reconcile writes the Caddy
route, but on a fresh node the running config may not pick it up → the node is
Argo-Healthy and serves in-cluster yet returns external 000 (proven on
beacon prod, 2026-06-16). External 000 + DNS resolving + pod Healthy = the
edge-reload gap (bug.5031 / PR #1697), not negative cache. Heal + the full
substrate-gaps table (doltgres-DB-missing Init:CrashLoopBackOff, preview
global-lease freeze, prod-promote sourceSha footgun, no-LLM-backend) live in
node-wizard-expert SKILL.md → "Substrate E2E is NOT yet hands-off". Mirror
this into the hub entry node-formation-wizard-scorecard.main SHA as sourceSha. GitHub
merge commits differ from PR head commits, and the child push build tags
sha-${github.sha}.Do not present the node formation scorecard to the human until candidate flight
has succeeded, candidate /version matches the launched SHA, and agent-first
API validation has passed. The human-facing report must include critical repo
links, child PR/check status, image tag and digest, parent pin status, flight
status, candidate /version, and a short explanation of the child-build ->
operator-pin -> candidate-flight CI/CD path. Use
docs/spec/node-ci-cd-contract.md for the CI/CD facts and
docs/guides/agent-api-validation.md for the post-flight API exercise.
After candidate flight and /version match, prove the freshly booted node is
usable, not just deployed:
| Check | Evidence | Status |
|---|---|---|
| Registration works | new agent registration succeeds against the candidate node | pass/blocked |
| Agent graph call works | registered agent gets a successful graph/completions response; ask for a haiku. Known gap: a fresh node with no LLM/LiteLLM secret provisioned times out here (deployed ≠ usable) — report blocked with the timeout, don't paper over it | pass/blocked |
| Knowledge is live | create a knowledge contribution and confirm the node repo-spec exposes a DoltHub knowledge.remote.url | pass/blocked |
| Epoch is active | candidate node reports an active/current epoch or equivalent live epoch state | pass/blocked |
Include these rows in the human-facing scorecard when they are relevant to a fresh node spawn. If a row is blocked by missing credentials or absent endpoint surface, report the exact blocker instead of substituting a weaker health check.
main has branch protection requiring the standard CI
checks before merge (the backstop for operator run-ci + merge-on-green);
enable it if missing.main image tag./version, run agent-first API validation, and complete
fresh boot health checks.Manage which deploy-environments a Cogni node lives in (candidate-a / preview / production) via the operator app — the full request→owner-approve→verb→merge→verify loop for env (deploy-topology) membership. Use whenever an agent needs to add a node to an env or remove it from one, is asked to 'give this node a preview deploy', 'promote this node into production topology', 'take a node out of preview', 'stop deploying X to candidate-a', 'change a node's deploy reach / env set', 'onboard my node to an environment', or hits a 403 authz_denied / 503 authz_unavailable on POST /api/v1/nodes/{id}/envs. Also triggers on 'env_manager', 'can_manage_envs', 'env-membership PR', 'node deploy topology', 'catalog envs: line'. This is distinct from FLIGHTING a build (candidate-flight / can_flight) and from PROMOTING a sha (promote / can_promote_production) — env-membership changes WHERE a node is deployed, not WHICH build runs there. Do NOT use for provisioning a whole environment (that is provision-env), for secret-writes (
Take a Cogni node from NOT-deployed to live-and-validated on candidate-a, end to end, as a node-contributor agent — RBAC request → owner approve → env-membership verb (add candidate-a) → merge → Argo auto-reconcile → agent-api-validation. This is the cold-start runbook: a fresh agent with only its COGNI API key + a node id can follow it start to finish. Use when asked to 'get my node onto candidate-a', 'deploy node X to candidate-a', 'prove a node deploys e2e', 'add a node to the candidate environment', or to validate the env-membership verb against a real deployment. Distinct from node-setup (which BIRTHS a node into the registry — a prerequisite here) and from flighting/promoting a BUILD (candidate-flight / promote — which pick which image runs in an env you're already in). This picks the ENV itself, then proves the node actually deployed and answers.
Authoritative reference for the cogni-template test pyramid and production-like e2e test topology — enforcement vs test layers, vitest configs, infra prereqs, GitHub/DoltHub test org boundaries, the cogni-operator-test app, what agents can/can't run locally, coverage tracking, and the non-obvious gotchas that bite every time. Use this skill whenever the user is writing a new test, asking "which layer does this belong in", debugging a flaky test, hitting CWD/env-loading issues, deciding between unit/component/stack/external, running any `pnpm test:*` or `pnpm arch:check` / `pnpm lint` command, working with testcontainers, touching fake adapters or `APP_ENV=test`, troubleshooting skip-gates, seeing errors from `.env.test` not loading, wondering about coverage or whether a test will run in CI, or trying to decide whether to run stack/e2e locally vs defer to CI. Also trigger when the user mentions mocking the database, Privy/GitHub App construction errors in tests, the smee proxy, `pnpm test:smee`, validating the
CI/CD architecture reviewer and DevOps advisor for monorepo pipelines, branch workflows, and deployment strategy. Use this skill when reviewing GitHub Actions workflows, designing promotion pipelines, evaluating branch protection rules, reviewing deploy scripts, auditing CI/CD for anti-patterns, or making decisions about build/test/deploy strategy. Also triggers for: 'review this workflow', 'is this CI pattern correct', 'branch strategy', 'deploy pipeline design', 'release promotion', 'should we use PRs for this', 'CI is slow', 'pipeline gap analysis', 'provision', 'deploy script'.
Use whenever working on Cogni USDC credit top-ups, payment intent creation, payment activation, operator wallet funding, 0xSplits allocations, x402 outbound provider payments, Hyperbolic, EIP-3009 signatures, retired OpenRouter/Coinbase top-ups, system-tenant revenue share, repo-spec payment config, live payment rail guards, payment CI failures, or debugging money-loop behavior. Trigger on phrases like payments, payment rail, credits top-up, USDC, Split, 0xSplits, splitHash, x402, Hyperbolic, facilitator, signX402Payment, EIP-3009, OpenRouter funding, Coinbase Commerce, operator wallet, Privy wallet, markup_factor, revenue_share, system bonus, provider top-up, settlement_skipped, SPLIT_CONFIG_MISMATCH, activate payments, node payments, or "is this payment behavior validated". This skill is the launching point for future payments work and debugging.
Use when setting up, reviewing, or changing Cogni Conductor worktree bootstrap, including conductor.json, scripts/conductor-worktree-setup.sh, secret/auth symlinks, and AI launch-pack references for human or AI developers.