메뉴
Platform Developer: Stage 8 deploy task. Adapter-driven deployment — read config.yml for the adapter, follow adapter instructions, write deploy-log.md and stage-08.json.
Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.
SOC 직업 분류 기준
Platform Developer: Stage 4 build task. Docker Compose setup, infra config, PR summary authoring, and Stage 4 gate writing for the platform workstream.
G7 — apply property-based testing, mutation testing, and formal verification as a stage-06d sub-stage. "Tests pass" becomes the floor; this skill raises the ceiling. Use after stage-06 PASS, when the diff contains pure functions / critical business logic / state machines worth verifying beyond examples.
Run a structured codebase audit — map architecture, assess health (compliance / tests / docs), perform deep analysis (security / performance / code quality), and synthesize a prioritized roadmap. Use this skill when the user says things like 'audit the codebase', 'understand this project', 'find problems', '/audit', or '/audit-quick'. Phases produce machine-friendly markdown outputs under docs/audit/ that downstream commands (like the implement skill) consume to know where to start work.
QA Developer: Stage 6 test-authoring phase. Map every acceptance criterion to at least one test, write the test suite, and produce pipeline/pr-qa.md. Does NOT run the suite — that is the test-execution phase (skills/qa-test-execution/SKILL.md).
Verify at Stage 6c that every metric, log, and trace promised in the design-spec is actually emitted by the shipped code. Runs on full and hotfix tracks only. Produces the stage-06c gate. Use when the platform role owns observability sign-off after build and QA.
Platform Developer: Stage 4a pre-review task. Run lint, type-check, SCA, license check, security trigger, and hygiene checks. Produce pipeline/gates/stage-04a.json.
| name | platform-deploy |
| description | Platform Developer: Stage 8 deploy task. Adapter-driven deployment — read config.yml for the adapter, follow adapter instructions, write deploy-log.md and stage-08.json. |
Use this skill when you are the Platform Developer executing the Stage 8
deploy stage. Stage 8 is adapter-driven. Read .devteam/config.yml, discover
which adapter the project has selected, and follow that adapter's instructions
in .devteam/adapters/<adapter>.md. If no adapter is configured, default to
local and follow .devteam/adapters/local.md.
pipeline/gates/stage-07.json. If "pm_signoff": true
is absent or false: write "status": "ESCALATE" with reason
"PM sign-off missing — cannot deploy" and halt.
If "deploy_requested": false, do not ask the Principal whether to
deploy. Treat it as an explicit instruction that no external deployment was
requested; use the local adapter, run/record local verification, and mark
adapter_result.external_deploy: false.pipeline/runbook.md exists and contains at minimum
a ## Rollback and ## Health signals section. If missing: write
"status": "ESCALATE" with reason "Runbook required for Stage 8"..devteam/config.yml. Find deploy.adapter. If missing,
use local. Accept one of: local, docker-compose, kubernetes,
terraform, cloud-run, gizmos, npm, custom. Unknown adapter:
write "status": "FAIL" with reason "Unknown deploy adapter." Do not
escalate for a missing adapter; local is the safe default.Read .devteam/adapters/<adapter>.md and follow the adapter's numbered procedure.
Adapters are authoritative for their own deploy story.
Every adapter's procedure ends with writing two artefacts:
pipeline/deploy-log.md: human-readable record of the deploy,
including a **Runbook**: pipeline/runbook.md §<section> line that
points a future on-call engineer at the recovery procedure.pipeline/gates/stage-08.json: gate with the baseline fields
required by .devteam/rules/gates-core.md plus:
{
"deploy_adapter": "<name>",
"environment": "<env>",
"smoke_test_passed": true,
"runbook_referenced": true,
"adapter_result": { /* adapter-specific */ }
}
On any step failure: write "status": "FAIL" with the failing output as a
blocker, halt. Do NOT auto-rollback. The runbook names the rollback
procedure and the orchestrator surfaces it to the user; a human decides
whether to roll back immediately or investigate first.
The user can follow the runbook's §Rollback section. Do not execute
rollback from the role unless the adapter explicitly declares auto-rollback
is safe for it (none of the built-in adapters do).