Create a feature specification from a natural language description — generates user stories with Given/When/Then scenarios, functional requirements (FR-XXX), success criteria, and a quality checklist. Use when starting a new feature, writing a PRD, defining user stories, capturing acceptance criteria, or documenting requirements for a product idea.
From jm-adknpx claudepluginhub javimontano/jm-adk-alfaThis skill uses the workspace's default tool permissions.
agents/guardian.mdagents/lead.mdagents/specialist.mdagents/support.mdevals/evals.jsonknowledge/body-of-knowledge.mdknowledge/knowledge-graph.mdprompts/meta.mdprompts/primary.mdprompts/variations/deep.mdprompts/variations/quick.mdreferences/constitution-loading.mdreferences/formatting-guide.mdreferences/model-recommendations.mdreferences/phase-separation-rules.mdtemplates/output.docx.mdtemplates/output.htmlSearches, retrieves, and installs Agent Skills from prompts.chat registry using MCP tools like search_skills and get_skill. Activates for finding skills, browsing catalogs, or extending Claude.
Create or update a feature specification from a natural language description. [EXPLICIT]
$ARGUMENTS
You MUST consider the user input before proceeding (if not empty). [EXPLICIT]
Load constitution per constitution-loading.md (soft mode — warn if missing, proceed without). [EXPLICIT]
The text after /iikit-01-specify is the feature description. [EXPLICIT]
Before proceeding with feature specification, analyze the user description for bug-fix intent using contextual analysis (not keyword-only): [EXPLICIT]
Bug-fix signals (keywords in a fixing context): "fix", "crash", "broken", "bug", "doesn't work", "fails", "error" when used to describe existing broken behavior.
NOT bug-fix (keywords in a new-feature context): "Add error handling", "Implement crash recovery", "Create bug tracking" — these describe new capabilities, not fixes to existing behavior.
Decision rule: Is the primary intent to fix existing broken behavior or to add new capability? Keywords alone are insufficient — evaluate the full description.
If bug-fix intent is detected: [EXPLICIT]
/iikit-bugfix instead."/iikit-bugfix '<the user description>'/iikit-bugfix/iikit-bugfixCreate 2-4 word action-noun name from description: [EXPLICIT]
Check current branch. If on main/master/develop, suggest creating feature branch (default). If already on feature branch, suggest skipping. [EXPLICIT]
Unix/macOS/Linux:
bash .tessl/tiles/tessl-labs/intent-integrity-kit/skills/iikit-core/scripts/bash/create-new-feature.sh --json "$ARGUMENTS" --short-name "your-short-name"
# Add --skip-branch if user declined branch creation
Windows (PowerShell):
pwsh .tessl/tiles/tessl-labs/intent-integrity-kit/skills/iikit-core/scripts/powershell/create-new-feature.ps1 -Json "$ARGUMENTS" -ShortName "your-short-name"
# Add -SkipBranch if user declined
Parse JSON for BRANCH_NAME, SPEC_FILE, FEATURE_NUM. Only run ONCE per feature. [EXPLICIT]
[NEEDS CLARIFICATION: question] (max 3) when choice significantly impacts scope and no reasonable default existsWrite to SPEC_FILE using spec-template.md structure. [EXPLICIT]
Scan for implementation details per phase-separation-rules.md (Specification section). Auto-fix violations, re-validate until clean. [EXPLICIT]
Generate FEATURE_DIR/checklists/requirements.md covering: content quality (no implementation details), requirement completeness, feature readiness. [EXPLICIT]
Generate FEATURE_DIR/qa/acceptance-criteria.md from the spec's SC-XXX success criteria: [EXPLICIT]
# Acceptance Criteria — {Feature Name}
Generated from spec.md | {date} [EXPLICIT]
## Success Criteria Checklist
- [ ] SC-001: {description} — Target: {measurable target}
- [ ] SC-002: {description} — Target: {measurable target}
...
## Traceability
| SC | Linked FR | Verifiable By |
|----|-----------|---------------|
| SC-001 | FR-001, FR-002 | Unit test / E2E |
Each SC-XXX from spec.md becomes a checkable acceptance criterion with a measurable target. [EXPLICIT]
If [NEEDS CLARIFICATION] markers remain, present each as a question with options table and wait for user response. [EXPLICIT]
Output: branch name, spec file path, checklist results, readiness for next phase. [EXPLICIT]
If spec.md already exists: extract semantic elements (stories, requirements, criteria), compare with new content per formatting-guide.md (Semantic Diff section), show downstream impact warnings, ask confirmation before overwriting. [EXPLICIT]
git add specs/*/spec.md specs/*/checklists/requirements.md .specify/active-feature
git commit -m "spec: <feature-short-name> specification"
Regenerate the dashboard so the pipeline reflects the new spec: [EXPLICIT]
bash .tessl/tiles/tessl-labs/intent-integrity-kit/skills/iikit-core/scripts/bash/generate-dashboard-safe.sh
Windows: pwsh .tessl/tiles/tessl-labs/intent-integrity-kit/skills/iikit-core/scripts/powershell/generate-dashboard-safe.ps1 [EXPLICIT]
Run: bash .tessl/tiles/tessl-labs/intent-integrity-kit/skills/iikit-core/scripts/bash/next-step.sh --phase 01 --json [EXPLICIT]
Windows: pwsh .tessl/tiles/tessl-labs/intent-integrity-kit/skills/iikit-core/scripts/powershell/next-step.ps1 -Phase 01 -Json [EXPLICIT]
Parse the JSON and present: [EXPLICIT]
clear_after is true: suggest /clear before proceedingnext_step as the primary recommendationalt_steps non-empty: list as alternativesnext_step and each alt_step, include the model_tier from the JSON so the user knows which model is best for each option. Look up tiers in model-recommendations.md for agent-specific switch commands.Format:
Specification complete! [EXPLICIT]
Next: [/clear → ] <next_step> (model: <tier>) [EXPLICIT]
[- <alt_step> — <reason> (model: <tier>)]
- Dashboard: file://$(pwd)/.specify/dashboard.html (resolve the path)
Example invocations: [EXPLICIT]
| Scenario | Handling |
|---|---|
| Empty or minimal input | Request clarification before proceeding |
| Conflicting requirements | Flag conflicts explicitly, propose resolution |
| Out-of-scope request | Redirect to appropriate skill or escalate |