메뉴
Step-by-step release process for Flightdeck, based on v0.3.0. Covers code cleanup, versioning, changelog, testing, and publishing.
Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.
SOC 직업 분류 기준
How the multi-backend adapter system works — AgentAdapter interface, ACP protocol, session resume, and how to add new provider adapters
When debugging why an agent has the wrong provider/model, or when modifying agent creation or delegation flows.
How to get agents to use group chats for peer coordination in flightdeck-based crews. Covers hub-and-spoke anti-pattern, auto-grouping triggers, and file-lock-linked groups. Use when setting up multi-agent crews with 3+ agents or diagnosing why agents aren't collaborating directly.
When fetching from the `/coordination/activity` API and you only need specific action types (e.g., `progress_update`, `task_completed`, `delegated`).
When fetching activity data for UI display, or debugging why activity-based features show empty/stale data.
Architecture decisions and patterns from Flightdeck development (Phases 2–4). Covers feature architecture, state management, component patterns, and API design.
| name | release-process |
| description | Step-by-step release process for Flightdeck, based on v0.3.0. Covers code cleanup, versioning, changelog, testing, and publishing. |
Step-by-step process for shipping a release, based on v0.3.0.
console.log in new code (grep -rn 'console\.log' packages/web/src/ packages/server/src/)TODO / FIXME comments that should be addressedcd packages/web && npx vitest runcd packages/server && npx vitest runinfrastructure.md.cd packages/web && npx tsc --noEmit — must be 0 errorscd packages/server && npx tsc --noEmit — filter known pre-existing errorsnpm run build from repo root — must succeedversion in all 4 package.json files:
package.jsonpackages/server/package.jsonpackages/web/package.jsonpackages/docs/package.json## Unreleased header to ## [X.Y.Z] - YYYY-MM-DD⛔ HARD RULE: NEVER touch git tags — no create, no delete, no push. Tags are 100% user-managed. Only prepare version bumps in package.json and CHANGELOG updates. This caused an issue when v0.3.0 tag was pushed by an agent — user had to bump to 0.3.1. No exceptions.
Your job ends at version bump + CHANGELOG. User handles tagging.
## [0.3.0] - 2026-03-06
### Added
- **Feature name** — one-line description
### Changed
- **What changed** — description
### Removed
- **What was removed** — why
### Fixed
- **What was fixed** — root cause
When multiple agents are working on release prep:
v030-crew) to coordinate## Unreleased section in CHANGELOG.md for next cycle