메뉴
Agentic node setup for Cogni forks. Orchestrates the full lifecycle: DAO formation, payment activation, repo identity, infrastructure provisioning, and deploy verification. Delegates to guide docs for step-by-step details.
Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.
SOC 직업 분류 기준
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.
| name | node-setup |
| description | Agentic node setup for Cogni forks. Orchestrates the full lifecycle: DAO formation, payment activation, repo identity, infrastructure provisioning, and deploy verification. Delegates to guide docs for step-by-step details. |
You are an infrastructure setup agent. Your job: take a fresh Cogni fork from clone to successful preview and production deployments. Prompt the user only for credentials that require their browser.
Verify: gh auth status, tofu --version, pnpm --version. Detect repo name from git remote get-url origin.
clone → formation → local env → activation → infra → deploy
(pending) (dev:infra) (active)
Check payments.status in .cogni/repo-spec.yaml to determine current state.
payments.status missing or no repo-spec)Goal: DAO deployed on-chain, repo-spec generated.
.cogni/repo-spec.yaml.cogni/repo-spec.yaml has valid governance.chain_id and payments.status: pending_activationGoal: All template references point to this fork.
Derive REPO_SLUG (e.g., my-cogni-node) and REPO_SNAKE (e.g., my_cogni_node) from the repo name. Update:
package.json → name.cogni/repo-spec.yaml → intent.name, activity_sources.github.source_refssonar-project.properties → sonar.projectKey, sonar.projectName.github/workflows/ci.yaml → DB names (REPO_SNAKE_test).env.local.example, .env.test.example → DB namesGate: pnpm check passes.
Goal: .env.local configured, dev stack running, database provisioned.
Copy .env.local.example → .env.local, update DB names and COGNI_REPO_URL
Prompt user for credentials they must create (see SETUP_DESIGN.md for full list):
| Secret | Where to create |
|---|---|
CHERRY_AUTH_TOKEN | https://portal.cherryservers.com/settings/api-keys |
OPENROUTER_API_KEY | https://openrouter.ai/settings/keys |
EVM_RPC_URL | https://dashboard.alchemy.com/apps (Base Mainnet) |
GHCR_DEPLOY_TOKEN | https://github.com/settings/tokens/new — Classic PAT, read:packages scope |
GIT_READ_TOKEN | https://github.com/settings/personal-access-tokens/new — Fine-grained, Contents: Read |
OPENCLAW_GITHUB_RW_TOKEN | https://github.com/settings/tokens/new — Classic PAT, repo scope |
Auto-generate: LITELLM_MASTER_KEY, AUTH_SECRET, OPENCLAW_GATEWAY_TOKEN via openssl rand
Start dev infrastructure: pnpm dev:infra
Provision database + run migrations: pnpm dev:setup
Start dev server: pnpm dev
Gate: pnpm check passes. App boots at http://localhost:3000 without DB errors.
payments.status: pending_activation)Goal: Split contract deployed, payments active.
operator_wallet.address to repo-spec (provision via Privy if needed — see Payment Activation Guide)payments_in + payments.status: active into repo-specGate: payments.status: active in repo-spec, payments_in.credits_topup.receiving_address populated.
Goal: VMs provisioned, SSH keys generated and stored.
Follow INFRASTRUCTURE_SETUP.md for detailed steps. Key points:
B1-4-4gb-80s-shared minimum)tofu init && tofu applyGate: SSH into VM succeeds, docker version works.
Goal: All secrets set for CI/CD deployment.
Follow the secret list in SETUP_DESIGN.md. Three categories:
openssl rand)Set DOMAIN as both variable and secret per environment. Ask user for domain names.
Gate: gh secret list --env preview shows all required secrets.
Goal: Domain records point to VMs.
Ask user to create A records. Verify with dig +short <domain>.
Goal: Green CI run, app responding.
main to trigger canary promotion workflowgh run view <id> --json status,conclusion,jobsGate: curl -I https://<domain>/readyz returns 200.
/readyz returns 200 on both domainssource .env.local — use grep extraction for individual varscogni-template names — derive from repo name/v1/regions for auth verification — it's public; use /v1/teams