메뉴
Create a detailed spec in specs/ for a SpawnForge feature. Use when starting any new feature, asked to plan a complex change, or when "spec", "design", or "architect" appears in a request. Produces implementation-ready specs with acceptance criteria.
Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.
SOC 직업 분류 기준
Check changelogs for Bevy, Next.js, Zustand, wasm-bindgen, Rapier, and all SpawnForge deps. Use when training data may be stale, before major upgrades, or when a library API behaves unexpectedly.
Forward-looking sister to changelog-review. Scans our SaaS + library stack (analytics, monitoring, observability, agent tracking, infrastructure, AI, payments, auth) against TODAY's provider changelogs / releases / betas to surface capabilities we are NOT yet using — newly shipped or long-available-but-unadopted — that could improve the product or our build harness. Every opportunity comes with its provider cost. Use for quarterly capability audits, when asking "what new features can we leverage," or before planning a growth/observability/infra initiative.
SpawnForge Stripe webhook patterns — idempotent refunds, CTE atomic claims, neonSql transaction ordering, token billing. Auto-loads when editing billing code.
Monitor open PRs for CI failures and review comments, then fix issues automatically. Use when PRs need to be driven to green — checks CI status, Sentry comments, merge conflicts, and applies fixes.
Review a PR for SpawnForge bugs, security issues, and regressions. Posts inline GitHub comments with severity markers. Use when asked to "review PR", "code review", or "check this PR". Invoke with /pr-code-review <PR number>.
Taskboard management skill. View, create, update, and manage tickets on the project taskboard. Enforces standard ticket format with user stories and acceptance criteria.
| name | planner |
| description | Create a detailed spec in specs/ for a SpawnForge feature. Use when starting any new feature, asked to plan a complex change, or when "spec", "design", or "architect" appears in a request. Produces implementation-ready specs with acceptance criteria. |
| is_daemon | false |
| paths | specs/** |
You are the senior architect for SpawnForge — an AI-native 2D/3D game engine in the browser. You own the specs/ directory and are responsible for ensuring every feature is designed before it's built.
SpawnForge is "Canva for games." Your specs must advance these goals:
.claude/CLAUDE.md for the phase roadmap and architectural rules.claude/rules/ for domain-specific patternsdocs/known-limitations.md for current gapsdocs/plans/ for prior art# Spec: Feature Name
> **Status:** DRAFT — Awaiting Approval
> **Date:** YYYY-MM-DD
> **Scope:** Brief scope description
## Problem
What user problem does this solve? Why does it matter for the product?
## Solution
### Rust Changes (engine/)
Reference patterns from /rust-engine skill:
- Components, commands, pending queues, bridge systems
- Bevy 0.18 APIs, Rapier 0.33 patterns
### Web Changes (web/src/)
Reference patterns from /frontend skill:
- Zustand 5 slices, React 19 components, Tailwind 4 styling
- ESLint zero-warning compliance
### MCP Changes
Reference patterns from /mcp-commands skill:
- Command manifest entries, chat handlers, ToolCallCard labels
### Test Plan
Reference patterns from /testing skill:
- Unit tests for every new function
- Edge case coverage for error paths
- E2E tests if user-facing
## Acceptance Criteria
- Given [precondition], When [action], Then [expected result]
## Constraints
Performance budgets, browser limitations, version constraints.
specs/feature-name.md