القائمة
Use for Phase 2 (Specify): write SPECIFICATION.md with EARS, REQ-IDs, and acceptance criteria. Trigger on sdd_write_spec, sdd_turnkey_spec, sdd_validate_ears, or /specky-specify.
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
استنادا إلى تصنيف SOC المهني
This skill should be used when the user asks to 'research codebase', 'scan tech stack', 'import documents', 'discovery questions', or needs guidance on Phase 1 research. Also trigger on 'sdd research', 'brownfield scan', 'import transcript', or 'check ecosystem'.
Use for Phase 4 (Design): produce DESIGN.md with architecture, API contracts, data model, and Mermaid diagrams. Trigger on sdd_write_design, sdd_generate_all_diagrams, or /specky-design.
Use for contracted implementation planning, executable TDD bindings, IaC, Docker, devcontainer, local environment, or Codespaces tools after an APPROVE analysis gate.
Use when starting or resuming Specky work, selecting lifecycle/workload/mode/capabilities, diagnosing config/state, or choosing an agent/tool.
This skill should be used when the user asks to 'orchestrate pipeline', 'run full pipeline', 'coordinate phases', 'advance phase', or needs guidance on end-to-end pipeline execution. Also trigger on 'specky orchestrate', 'phase transition', 'LGTM gate', 'pipeline status', or 'which agent for this phase'.
Use for Phase 6 (Analyze): completeness audit, cross-analysis, compliance, and ANALYSIS.md gate decision. Trigger on sdd_run_analysis, sdd_cross_analyze, sdd_compliance_check, or sdd_check_sync.
| name | specky-spec-engineer |
| description | Use for Phase 2 (Specify): write SPECIFICATION.md with EARS, REQ-IDs, and acceptance criteria. Trigger on sdd_write_spec, sdd_turnkey_spec, sdd_validate_ears, or /specky-specify. |
spec_dir and feature_number from signed state.sdd_write_spec Shape{
"feature_name": "Order API",
"feature_number": "001",
"spec_dir": ".specs",
"discovery_answers": {"DQ-001": "Reviewed answer with evidence"},
"requirements": [{
"id": "REQ-API-001",
"ears_pattern": "event_driven",
"text": "When a client submits a valid order, the system shall return the created order identifier.",
"acceptance_criteria": ["A valid request returns one persisted order identifier"]
}],
"force": false
}
Every requirement needs a unique uppercase REQ-{DOMAIN}-{NNN}, valid EARS prose, and measurable acceptance criteria. force: true is an explicit decision to persist validation warnings; never use it automatically.
Call sdd_validate_ears with spec_dir and feature_number. The tool is always feature-scoped; direct stateless validation is not a second hidden mode.
sdd_turnkey_spec operates only on an already initialized feature. Required: matching feature_name, feature_number, spec_dir, explicit force, complete discovery_context, explicit clarification_responses, and one or more caller-authored requirements containing ID, declared EARS pattern, title, EARS text, measurable acceptance criteria, and source evidence. It validates and assembles these inputs; it does not infer requirements, NFRs, criteria, or clarification questions and cannot create Constitution or state.
Use sdd_figma_to_spec only when figma capability is enabled. Required: file key, optional node ID, explicit feature identity and force. The feature name comes from state, not a second input.