菜单
Use when discussing, expanding, or designing any subsystem in SPEC.md. Use when user asks about goals, API shape, edge cases, or configuration for HTTP, Router, ORM, Queue, Mail, Views, or other framework subsystems.
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
Use when adding new API surface, modifying existing APIs, or defining TypeScript types for framework features. Use when discussing method signatures, return types, decorator APIs, or module exports.
Use when adding new files, patterns, or examples to skeleton/. Use when creating new controller, model, job, mailable, migration, view, or component in the skeleton app.
Use when making non-trivial changes, modifying public APIs, or proposing new framework features. Use when changes affect multiple files or require design decisions.
Use when designing new subsystem, comparing implementation approaches, or user asks how other frameworks handle something. Use when researching Laravel, Rails, AdonisJS, Inertia.js, or similar framework patterns.
Use after any change to skeleton/, packages/core/, or docs/. Use to verify types compile and documentation is synchronized.
| name | kubit-eliciting-spec |
| description | Use when discussing, expanding, or designing any subsystem in SPEC.md. Use when user asks about goals, API shape, edge cases, or configuration for HTTP, Router, ORM, Queue, Mail, Views, or other framework subsystems. |
Extract detailed requirements through structured questions, then capture decisions in SPEC.md with the standard template.
| Area | Questions to Ask |
|---|---|
| Scope | Goals vs non-goals? What's MVP vs later? |
| Data | Inputs/outputs? Data shapes? |
| Flow | Step-by-step lifecycle? Extension points? |
| Config | Knobs, defaults, override mechanisms? |
| Errors | Failure modes? Error types? How surfaced? |
| Edge Cases | Tricky scenarios to support or reject? |
| Security | AuthN/Z, CSRF, CORS, secrets, privacy? |
| Performance | Latency, streaming, caching, batching? |
| Extensibility | Hooks, interfaces, adapters, plugins? |
| Testing | What tests prove it? Fixtures needed? |
| Open Questions | Undecided items → add to SPEC |
HTTP Kernel: Request/response abstraction (Node vs Web)? Streaming? Middleware pipeline order? Error handling policy? Static vs app route precedence? 404/405/500 behavior?
Router: Path syntax, params, constraints? Trailing slash, case sensitivity? Named routes, reverse routing? Route groups, per-route middleware? Controller action resolution?
Controllers & DI: Construction via DI or factories? Access to request/config? Return types (text, JSON, redirects, view(), streams)? Validation strategy?
Views & Inertia: Envelope shape { component, props, url, version }? Layouts? Hydration and bundle splitting? Asset manifest? Client runtime duties? Forms/links enhancement?
ORM/DB: Table builder DSL surface? Migration runner (tracking table, up/down, transactions)? Seeding?
Queue/Jobs: Dispatch API? Queue names, retries/backoff? Idempotency, scheduling? Worker lifecycle, graceful shutdown?
Mail: Rendering API? Transport abstraction? Attachments? Preview/dev mailbox? Test fakes?
CLI: Commands, flags? Config discovery? Watch mode? Error UX?
When documenting in SPEC.md, use this structure:
## [Subsystem Name]
### Goals
### Non-Goals
### Concepts & Vocabulary
### API Surface (TypeScript)
### Configuration
### Lifecycle & Control Flow
### Edge Cases & Errors
### Security & Privacy
### Performance & Scaling
### Extensibility & Integration Points
### Testing Strategy & Fixtures
### Open Questions
### Alternatives Considered
When a decision is made, add to SPEC.md Decision Log:
## Decision Log
### YYYY-MM-DD: [Decision Title]
**Context:** [What prompted this]
**Decision:** [What was decided]
**Rationale:** [Why]
**Alternatives rejected:** [What else was considered]