메뉴
Plan and build a new GOWDK feature or substantial capability, from spec to verified vertical slice. Use for new user-facing behavior, new compiler/runtime capabilities, or large changes that need a feature spec and implementation plan.
Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.
SOC 직업 분류 기준
Write or update a GOWDK pull request title/body. Use for local branches or GitHub PRs that need a concise why/what/verification summary, issue links, migration notes, and generated-output or docs impact.
Bump the GOWDK release version. Use when updating the CLI version, VS Code extension package version, install snippets, release docs, release notes, or validating a 0.x release metadata change.
Write or update GOWDK documentation across product, engineering, language, compiler, reference, onboarding, examples, and agent guidance.
Change GOWDK language syntax or semantics. Use for parser, formatter, lexer, analyzer, diagnostics, `.gwdk` metadata, `view {}` markup, guards, routes, layouts, actions, APIs, `build`, `server`, `paths`, or docs/examples for language behavior.
Review GOWDK code changes, a PR, or a subsystem for correctness and maintainability. Use for code review requests, pre-merge checks, or auditing a diff against GOWDK product and contract rules.
Change GOWDK compiler internals without changing public language behavior. Use for AST shape, analyzer passes, IR (`gwdkir`) structure and invariants, lowering, diagnostics registry plumbing, validation order, or compiler performance work.
| name | gowdk-feature |
| description | Plan and build a new GOWDK feature or substantial capability, from spec to verified vertical slice. Use for new user-facing behavior, new compiler/runtime capabilities, or large changes that need a feature spec and implementation plan. |
Prefer one working vertical slice over broad scaffolding.
docs/product/roadmap.md (capability matrix with
Implemented/Partial/Planned per surface). A feature is not "done" until its
roadmap row is accurate.docs/engineering/decisions/): 0002 compile-first render model (build-time
default, request-time opt-in), 0003 JS default / WASM islands opt-in,
0005 generated-Go emission boundary, 0006 compiler/runtime boundary,
0007 static-first SPA navigation, 0008 bounded client language,
0009 optional inline Go authoring.docs/language/grammar.md, internal/parser) → IR
(gwdkir.Program, lowering in internal/gwdkanalysis) → validation +
diagnostics registry (internal/compiler,
internal/diagnostics/registry.go) → generators
(internal/buildgen/internal/appgen) → runtime (runtime/, addons/) →
editor (internal/lsp, editors/vscode) → docs + examples/..agents/templates/feature-spec.md and
.agents/templates/implementation-plan.md under docs/.docs/engineering/dependency-policy.md — no new
production dependency without a documented reason or an ADR.docs/product/vision.md, docs/product/requirements.md,
docs/product/roadmap.md, and docs/engineering/architecture.md. Check
the ADR list above for prior decisions touching the feature.examples/ app or a passing CLI smoke beats stubs across layers.examples/ when the feature has user-facing syntax;
CI runs gowdk check/build over examples, so the example is also a gate.go test ./...
go build ./cmd/gowdk
scripts/test-go-modules.sh
go run ./cmd/gowdk build --out /tmp/gowdk-feature <your example>.gwdk
gowdk-language-change.gowdk-generated-output..agents/templates/adr.md under docs/engineering/decisions/ (next number
after the highest existing one).State what slice works end to end, what is intentionally deferred, which roadmap row changed, and which commands prove the acceptance criteria.