메뉴
Write a technical or feature specification covering behavior, states, edge cases, and acceptance criteria. Use whenever the user mentions spec, feature spec, technical spec, behavior spec, or needs a document that an engineer can implement against.
Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.
SOC 직업 분류 기준
Audit a brand's full identity (logo, typography, color, voice, visual language) for consistency, distinctiveness, and gap. Use when the user asks for a brand audit, identity review, brand health check, or wants to evaluate how a brand shows up across surfaces.
Plan a content calendar tied to product, brand, or marketing goals. Use when the user asks for a content plan, editorial calendar, content strategy, posting schedule, or wants to map content to themes and audiences over a period of time.
Write a sequence of emails for onboarding, nurture, sales, lifecycle, or launch. Use when the user asks for a drip campaign, email sequence, welcome series, onboarding emails, sales cadence, or any multi-email flow tied to a goal.
Design an a/b test or experiment including hypothesis, metrics, sample size, and analysis plan. Use whenever the user mentions a/b test, experiment, split test, multivariate test, or needs to design a test that produces a decision-quality result.
Audit a design or component for WCAG accessibility compliance. Use whenever the user mentions a11y, accessibility audit, WCAG check, contrast issues, keyboard navigation, screen reader support, focus order, or asks if a design is accessible.
Extract a brand voice guide from existing copy samples. Use whenever the user shares past copy and asks to define a voice, document a voice, create voice guidelines, or wants to make their existing voice teachable and repeatable.
| name | spec-writing |
| description | Write a technical or feature specification covering behavior, states, edge cases, and acceptance criteria. Use whenever the user mentions spec, feature spec, technical spec, behavior spec, or needs a document that an engineer can implement against. |
a spec answers "how will this behave in every situation it could be in?" without describing implementation.
a prd says why and what. a spec says how it behaves. the prd answers "should we build it?". the spec answers "what exactly are we building?".
# [feature name] spec
## overview
one paragraph: what this is, who uses it, what it lets them do.
## user-facing behavior
### entry points
how do users get here. list every path.
### primary flow
step by step, what the user does and what the system does back.
### states
- default
- loading
- empty
- partial (some data present, some missing)
- error
- success
- offline
for each, describe: what's shown, what's interactive, what changes when state changes.
### edge cases
list them explicitly:
- input outside expected range
- network failure mid-action
- concurrent edits
- expired auth
- permission boundaries
- very large inputs
- very small or zero inputs
- characters outside ascii
- timezone considerations
## data
### inputs
each field: name, type, validation, source.
### outputs
each piece of data the system produces or stores.
### persistence
what gets saved, where, for how long.
## permissions
who can see what.
who can do what.
how permission changes propagate.
## acceptance criteria
given/when/then statements that pass when the feature is correctly built:
given [precondition]
when [action]
then [expected result]
write enough of these to cover every state and every edge case.
## out of scope
explicit list of things adjacent that this spec does not address.
## open questions
what's not decided yet and who decides.