kiro-spec-quick
Skill3 starsChanged 6 months agoApache-2.0View on GitHub
Quick spec generation with interactive or automatic mode
3 other projects use a version of this, 3 of them edited.
Adopted by
Most recently taken up by
- aiproxer/aiproxeredited, first seen Nov 8, 2026
- growilabs/growiedited, first seen Oct 8, 2026
- kyuki3rain/cc-sdd-adredited, first seen Jul 27, 2026
Other versions3 projects use a version of this.
Word for word · 0
None found.
Edited · 3
- growilabs/growi★ 1.5k86% same
- aiproxer/aiproxer★ 2293% same
- kyuki3rain/cc-sdd-adr★ 087% same
Wrote their own version · 0
None found.
How matches are found. Word for word: the exact same text. Edited: shares passages with this file (“99% same” means 99% of its five-word phrases also appear here; 10% or more counts). Their own version: similar meaning, or, weakest, the same name. We can’t tell which project had it first. Projects are counted among the 200 most-starred candidates, and mentions are links to the repository we found, up to 50 per site, so both counts are a floor.
In this repository34 other files it gives its agents.
- cc-sdd-restack-after-mergeSkill
- cc-sdd-review-slice-stackSkill
- ci-stable-log-testingSkill
- create-issueSkill
- docker-deployment-guideSkill
- hibernate-pcSkill
- kiro-debugSkill
- kiro-discoverySkill
- kiro-implSkill
- kiro-reviewSkill
- kiro-spec-batchSkill
- kiro-spec-designSkill
- kiro-spec-initSkill
- kiro-spec-requirementsSkill
- kiro-spec-statusSkill
- kiro-spec-tasksSkill
- kiro-steering-customSkill
- kiro-steeringSkill
- kiro-validate-designSkill
- kiro-validate-gapSkill
- kiro-validate-implSkill
- kiro-verify-completionSkill
- notion-pdfSkill
- playwright-scraperSkill
- pptx-slides-creatorSkill
- pr-creatorSkill
- pytest-marksSkill
- python-readable-codeSkill
- resolve-pr-review-threadsSkill
- sec-diff-reviewSkill
- sec-full-scanSkill
- sec-runtime-scanSkill
- skill-creatorSkill
- storage-stateSkill
The file
Show its rules and text
We split this skill into the rules it gives an agent
20 rules. 13 are common, 0 are distinctive, and 7 are very specific to this project.
13
Common
Most of the 3 edited versions we read keep these.
0
Distinctive
This author's own choices. Worth a look.
7
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Common: line 17
After Phase 4, run the final sanity review before exiting
- Common: line 18
Stop ONLY after the sanity review completes or if error occurs
- Common: line 25
Before claiming quick generation is complete, run one lightweight sanity review over the generated requirements, design, and tasks.
- Very specific: line 32
If contains --auto: Automatic Mode (execute all 4 phases)
- Very specific: line 55
If docs/specs/{feature-name}/brief.md exists (created by /kiro-discovery), read it for discovery context (problem, approach, scope, …
- Very specific: line 56
Use brief content as the project description instead of $ARGUMENTS
- Common: line 61
Keep name concise (2-4 words ideally)
- Very specific: line 64
Use Glob to check docs/specs/*/
- Very specific: line 65
If directory exists with only brief.md (no spec.json), use that directory (discovery created it)
- Very specific: line 69
Use Bash: mkdir -p docs/specs/{feature-name} (skip if already exists from discovery)
- Common: line 98
If "no": Stop, show current state
- Common: line 99
If "yes": Continue to Phase 2
- Common: line 107
Wait for completion. IGNORE any "Next Step" message (it is for standalone usage).
- Common: line 123
Wait for completion. IGNORE any "Next Step" message.
- Common: line 145
After Phase 4, run a lightweight sanity review before claiming completion.
- Common: line 148
Prefer a fresh review sub-agent when the host supports it.
- Common: line 150
Do requirements, design, and tasks tell a coherent story?
- Very specific: line 153
If the review finds only task-plan-local issues, repair or update the generated tasks.md once, then re-run the sanity review.
- Common: line 154
If the review finds a real requirements/design gap or contradiction, stop and report follow-up instead of claiming the quick spec is …
- Common: line 194
After each phase, show brief progress:
“Common” is measured: kept by at least 6 in 10 of the 3 edited versions of this file we could read. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
Quick Spec Generator
<instructions>
## CRITICAL: Automatic Mode Execution RulesIf --auto flag is present in $ARGUMENTS, you are in AUTOMATIC MODE.
In Automatic Mode:
- Execute ALL 4 phases in a continuous loop without stopping
- Display progress after each phase (e.g., "Phase 1/4 complete: spec initialized")
- IGNORE any "Next Step" messages from Phase 2-4 (they are for standalone usage)
- After Phase 4, run the final sanity review before exiting
- Stop ONLY after the sanity review completes or if error occurs
Core Task
Execute 4 spec phases sequentially. In automatic mode, execute all phases without stopping. In interactive mode, prompt user for approval between phases.
Before claiming quick generation is complete, run one lightweight sanity review over the generated requirements, design, and tasks. If the host supports fresh sub-agents, use one. Otherwise run the sanity review inline.
Execution Steps
Step 1: Parse Arguments and Initialize
Parse $ARGUMENTS:
- If contains
--auto: Automatic Mode (execute all 4 phases) - Otherwise: Interactive Mode (prompt at each phase)
- Extract description (remove
--autoflag if present)
Example:
"User profile with avatar upload --auto" → mode=automatic, description="User profile with avatar upload"
"User profile feature" → mode=interactive, description="User profile feature"Display mode banner and proceed to Step 2.
Step 2: Execute Phase Loop
Execute these 4 phases in order:
Phase 1: Initialize Spec (Direct Implementation)
Core Logic:
- Check for Brief:
- If
docs/specs/{feature-name}/brief.mdexists (created by/kiro-discovery), read it for discovery context (problem, approach, scope, constraints) - Use brief content as the project description instead of
$ARGUMENTS
- If
- Generate Feature Name:
- Convert description to kebab-case
- Example: "User profile with avatar upload" → "user-profile-avatar-upload"
- Keep name concise (2-4 words ideally)
- Check Uniqueness:
- Use Glob to check
docs/specs/*/ - If directory exists with only
brief.md(nospec.json), use that directory (discovery created it) - Otherwise if feature name exists, append
-2,-3, etc.
- Use Glob to check
- Create Directory:
- Use Bash:
mkdir -p docs/specs/{feature-name}(skip if already exists from discovery)
- Use Bash:
Initialize Files from Templates:
a. Read templates:
- docs/settings/templates/specs/init.json - docs/settings/templates/specs/requirements-init.mdb. Replace placeholders:
{{FEATURE_NAME}} → feature-name {{TIMESTAMP}} → current ISO 8601 timestamp (use `date -u +"%Y-%m-%dT%H:%M:%SZ"`) {{PROJECT_DESCRIPTION}} → description ja → language code (detect from user's input language, default to `en`)c. Write files using Write tool:
- docs/specs/{feature-name}/spec.json - docs/specs/{feature-name}/requirements.md- Output Progress: "Phase 1/4 complete: Spec initialized at docs/specs/{feature-name}/"
Automatic Mode: IMMEDIATELY continue to Phase 2.
Interactive Mode: Prompt "Continue to requirements generation? (yes/no)"
- If "no": Stop, show current state
- If "yes": Continue to Phase 2
Phase 2: Generate Requirements
Invoke /kiro-spec-requirements {feature-name}.
Wait for completion. IGNORE any "Next Step" message (it is for standalone usage).
Output Progress: "Phase 2/4 complete: Requirements generated"
Automatic Mode: IMMEDIATELY continue to Phase 3.
Interactive Mode: Prompt "Continue to design generation? (yes/no)"
- If "no": Stop, show current state
- If "yes": Continue to Phase 3
Phase 3: Generate Design
Invoke /kiro-spec-design {feature-name} -y. The -y flag auto-approves requirements.
Wait for completion. IGNORE any "Next Step" message.
Output Progress: "Phase 3/4 complete: Design generated"
Automatic Mode: IMMEDIATELY continue to Phase 4.
Interactive Mode: Prompt "Continue to tasks generation? (yes/no)"
- If "no": Stop, show current state
- If "yes": Continue to Phase 4
Phase 4: Generate Tasks
Invoke /kiro-spec-tasks {feature-name} -y. The -y flag auto-approves requirements, design, and tasks.
Wait for completion.
Output Progress: "Phase 4/4 complete: Tasks generated"
Final Sanity Review
After Phase 4, run a lightweight sanity review before claiming completion.
- Review
requirements.md,design.md, andtasks.mddirectly from disk. Ifbrief.mdexists, use it only as supporting context. - Prefer a fresh review sub-agent when the host supports it. Pass only file paths and the review objective; the reviewer should read the generated files itself.
- Review focus:
- Do requirements, design, and tasks tell a coherent story?
- Are there obvious contradictions, missing prerequisites, or missing task coverage for required design work?
- Are
_Depends:_,_Boundary:_, and(P)markers plausible for implementation?
- If the review finds only task-plan-local issues, repair or update the generated
tasks.mdonce, then re-run the sanity review. - If the review finds a real requirements/design gap or contradiction, stop and report follow-up instead of claiming the quick spec is implementation-ready.
All 4 phases plus sanity review complete.
Output final completion summary (see Output Description section) and exit.
Important Constraints
Error Handling
- Any phase failure stops the workflow
- Display error and current state
- Suggest manual recovery command
</instructions>Output Description
Mode Banners
Interactive Mode:
Quick Spec Generation (Interactive Mode)
You will be prompted at each phase.
Note: Skips gap analysis and design validation.Automatic Mode:
Quick Spec Generation (Automatic Mode)
All phases execute automatically without prompts.
Note: Skips optional validations (gap analysis, design review) and user approval prompts. Internal review gates still run.
Final sanity review still runs.Intermediate Output
After each phase, show brief progress:
Spec initialized at docs/specs/{feature}/
Requirements generated → Continuing to design...
Design generated → Continuing to tasks...Final Completion Summary
Provide output in the language specified in spec.json:
Quick Spec Generation Complete!
## Generated Files:
- docs/specs/{feature}/spec.json
- docs/specs/{feature}/requirements.md ({X} requirements)
- docs/specs/{feature}/design.md ({Y} components, {Z} endpoints)
- docs/specs/{feature}/tasks.md ({N} tasks)
Quick generation skipped:
- `/kiro-validate-gap` - Gap analysis (integration check)
- `/kiro-validate-design` - Design review (architecture validation)
Sanity review: PASSED | FOLLOW-UP REQUIRED
## Next Steps:
1. Review generated specs (especially design.md)
2. Optional validation:
- `/kiro-validate-gap {feature}` - Check integration with existing codebase
- `/kiro-validate-design {feature}` - Verify architecture quality
3. Start implementation: `/kiro-impl {feature}`
Safety & Fallback
Error Scenarios
Template Missing:
- Check
docs/settings/templates/specs/exists - Report specific missing file
- Exit with error
Directory Creation Failed:
- Check permissions
- Report error with path
- Exit with error
Phase Execution Failed (Phase 2-4):
- Stop workflow
- Show current state and completed phases
- Suggest: "Continue manually from
/kiro-spec-{next-phase} {feature}"
Sanity Review Failed:
- Stop workflow
- Report the exact contradiction, missing prerequisite, or task-plan issue
- Suggest targeted follow-up with
/kiro-spec-design {feature},/kiro-spec-tasks {feature}, or manual edits depending on the finding
User Cancellation (Interactive Mode):
- Stop gracefully
- Show completed phases
- Suggest manual continuation
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

