메뉴
Point a local Spec Kitty CLI at Spec Kitty SaaS on Upsun (main or preview): set sync vars via use-upsun-env.sh, authenticate against Upsun Teamspace, check readiness, or drain local events.
Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.
| name | spk-team-upsun-cli-sync |
| description | Point a local Spec Kitty CLI at Spec Kitty SaaS on Upsun (main or preview): set sync vars via use-upsun-env.sh, authenticate against Upsun Teamspace, check readiness, or drain local events. |
Wire a local spec-kitty CLI to Spec Kitty SaaS on Upsun. Prefer the SaaS
repo's scripts/use-upsun-env.sh over hand-written env exports: it resolves the
primary Upsun URL and keeps the variable contract consistent.
In the spec-kitty-saas checkout, consult as needed:
docs/runbooks/upsun-cli-auth-and-sync.md (auth + drain),
docs/runbooks/upsun-preview-environments.md (preview env lookup),
docs/env-var-contract.md, and scripts/use-upsun-env.sh (env setup).
Constants: project 67rt36f456a5m, app teamspace, main env main, main URL
fallback https://main-bvxea6i-67rt36f456a5m.us-3.platformsh.site.
Start in spec-kitty-saas. Run eval "$(scripts/use-upsun-env.sh main)" (or
<branch-env> for a preview; no argument uses the current git branch). It
exports SPEC_KITTY_ENABLE_SAAS_SYNC=1, SPEC_KITTY_SAAS_URL=<upsun-primary-url>,
and SPEC_KITTY_HOME=$HOME/.spec-kitty-upsun. Then wire the local CLI from the
sibling spec-kitty checkout:
cd ../spec-kitty
spec-kitty auth login --force
spec-kitty auth whoami
spec-kitty auth doctor --server
spec-kitty sync server "$SPEC_KITTY_SAAS_URL"
spec-kitty sync opt-in
spec-kitty sync status --check
Local testing rule: any command touching hosted auth, tracker, or sync must run
with SPEC_KITTY_ENABLE_SAAS_SYNC=1. The env script sets it; preserve it when
composing commands manually.
Health-check before trusting an environment:
curl -sS "$SPEC_KITTY_SAAS_URL/health/"
curl -sS "$SPEC_KITTY_SAAS_URL/health/ready/"
upsun environment:info -p 67rt36f456a5m -e <env-name> --no-interaction
Pass a Keychain-stored Upsun token inline (do not print it):
UPSUN_CLI_TOKEN="$(security find-generic-password -a "$USER" -s upsun-cli-token -w)".
Drain only when the local event queue must be sent to the target
(spec-kitty sync now --report sync-report.json). Behavior:
success, duplicate, or failed_permanent,
so sync now is not replay-safe across transient Upsun environments.<root>/queues/queue-<hash>.db, legacy fallback <root>/queue.db. <root> is
SPEC_KITTY_HOME when set, else ~/.spec-kitty on POSIX.SPEC_KITTY_HOME now isolates all local state — sync config, hosted-auth
session/refresh-lock, event queues and active scope, the Lamport clock, the
sync daemon, and tracker credentials/cache — not just runtime assets, giving
the Upsun target a fully isolated session (fixes
#2171). When unset on
Windows it resolves onto the platformdirs app-data base; existing
~/.spec-kitty data is not auto-migrated. Verify by running a config-writing
command under temp HOME + SPEC_KITTY_HOME — config.toml must appear only
under $SPEC_KITTY_HOME, never $HOME/.spec-kitty.upsun ssh -p 67rt36f456a5m -e <env-name> -A teamspace -- \
'.venv/bin/python manage.py reconcile_sync_drain --json'
Add --drain to force pending server-side durable drain rows. An empty local
queue means the CLI has no queued rows for that scope — it does not prove SaaS
projections finished.
Recognize when a mission is a bulk edit and drive the occurrence-classification guardrail on the user's behalf. Triggers: user says any variant of "rename X to Y", "change the terminology", "migrate all occurrences", "replace across the codebase", "the X feature is now the Y feature", "sed everywhere", or any request that touches the same identifier/path/key in many files. Also triggers on gate errors mentioning "change_mode", "occurrence_map.yaml", "Bulk Edit Gate: BLOCKED", or "Bulk Edit Review: Diff Compliance". Does NOT handle: line-level semantic refactors inside one file, adding a new feature that creates new identifiers without changing existing ones, or reviewing finished missions for fidelity.
Review a fully merged Spec Kitty mission post-merge (all WPs done/approved) to verify spec→code fidelity, FR coverage, drift, risks, and security. Triggers: "review the merged mission", "post-merge mission review", "verify the completed mission", "audit the mission implementation", "mission-level acceptance review", "is this mission releasable", "final review before tagging", "cross-WP coverage audit". Does NOT handle: per-WP review during implementation (use spec-kitty-runtime-review), implement-review loop orchestration (use spec-kitty-implement-review), setup or repair (use spec-kitty-setup-doctor), or glossary maintenance (use spec-kitty-glossary-context).
Drive the canonical spec-kitty next --mission <handle> control loop for mission advancement. Load agent profiles at init, apply action-scoped doctrine context at each step boundary, and pull specific tactics/directives on demand. Triggers: "run the next step", "what should runtime do next", "advance the mission", "what is the next task", "continue the workflow", "what step comes next". Does NOT handle: setup or repair requests, purely editorial glossary or doctrine maintenance, or direct code review.
Understand how Spec Kitty missions work: the 4 built-in mission types, how they define workflows via step contracts and action indices, how missions and work packages relate, how templates are resolved through the 5-tier chain, and how doctrine artifacts (procedures, tactics, directives) compose mission behavior. Triggers: "what missions are available", "how do missions work", "which mission should I use", "explain the mission system", "what is a mission", "change the mission", "mission templates", "step contracts", "action index", "mission procedures". Does NOT handle: runtime loop advancement (use runtime-next), setup or repair (use setup-doctor), governance (use charter-doctrine), or glossary curation (use glossary-context).
Discover the Spec Kitty 3.2.0 spk skill hierarchy, naming convention, legacy aliases, and the correct skill for a user intent.
Deploy a bounded, profile-loaded adversarial review squad at an SDD point-cut (post-spec, post-plan, post-tasks, pre-merge, or an ad-hoc decision) so independent doctrine lenses converge on findings one reviewer would miss. Triggers: "deploy a squad", "adversarial squad", "post-tasks anti-laziness pass", "pre-spec investigation squad", "brownfield check", "second opinion on this design", "review squad", "run a multi-lens review". Does NOT handle: the implement-review loop (use spec-kitty-implement-review), spec/plan/tasks generation, or direct code editing by the orchestrator. It is an optional, charter/memory-activated enrichment — it never gates a mission.