agentleFS
buildpad-aibuildpad-ai/skills/buildpad-spec-quick/SKILL.md

buildpad-spec-quick

Skill1 starsChanged 27 days agoMITView on GitHub

Quick spec generation with interactive or automatic mode

The file

Show its rules and text

We split this skill into the rules it gives an agent

20 rules. About 0 are common, 13 are distinctive, and 7 are very specific to this project.

  • ≈0

    Common · estimate

    Many files like this have a rule of this kind.

  • ≈13

    Distinctive · estimate

    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
  1. Distinctive:

    After Phase 4, run the final sanity review before exiting

    line 19
  2. Distinctive:

    Stop ONLY after the sanity review completes or if error occurs

    line 20
  3. Distinctive:

    Before claiming quick generation is complete, run one lightweight sanity review over the generated requirements, design, and tasks.

    line 27
  4. Very specific:

    If contains --auto: Automatic Mode (execute all 4 phases)

    line 34
  5. Very specific:

    If .kiro/specs/{feature-name}/brief.md exists (created by /buildpad-discovery), read it for discovery context (problem, approach, scope, …

    line 57
  6. Very specific:

    Use brief content as the project description instead of $ARGUMENTS

    line 58
  7. Distinctive:

    Keep name concise (2-4 words ideally)

    line 63
  8. Very specific:

    Use Glob to check .kiro/specs/*/

    line 66
  9. Very specific:

    If directory exists with only brief.md (no spec.json), use that directory (discovery created it)

    line 67
  10. Very specific:

    Use Bash: mkdir -p .kiro/specs/{feature-name} (skip if already exists from discovery)

    line 71
  11. Distinctive:

    If "no": Stop, show current state

    line 100
  12. Distinctive:

    If "yes": Continue to Phase 2

    line 101
  13. Distinctive:

    Wait for completion. IGNORE any "Next Step" message (it is for standalone usage).

    line 109
  14. Distinctive:

    Wait for completion. IGNORE any "Next Step" message.

    line 125
  15. Distinctive:

    After Phase 4, run a lightweight sanity review before claiming completion.

    line 149
  16. Distinctive:

    Prefer a fresh review subagent when the host supports it.

    line 152
  17. Distinctive:

    Do requirements, design, and tasks tell a coherent story?

    line 154
  18. Very specific:

    If the review finds only task-plan-local issues, repair or update the generated tasks.md once, then re-run the sanity review.

    line 157
  19. Distinctive:

    If the review finds a real requirements/design gap or contradiction, stop and report follow-up instead of claiming the quick spec is …

    line 158
  20. Distinctive:

    After each phase, show brief progress:

    line 198

≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

Quick Spec Generator

<instructions> ## CRITICAL: Automatic Mode Execution Rules

If --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 subagents, 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 --auto flag 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:

  1. Check for Brief:
    • If .kiro/specs/{feature-name}/brief.md exists (created by /buildpad-discovery), read it for discovery context (problem, approach, scope, constraints)
    • Use brief content as the project description instead of $ARGUMENTS
  2. 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)
  3. Check Uniqueness:
    • Use Glob to check .kiro/specs/*/
    • If directory exists with only brief.md (no spec.json), use that directory (discovery created it)
    • Otherwise if feature name exists, append -2, -3, etc.
  4. Create Directory:
    • Use Bash: mkdir -p .kiro/specs/{feature-name} (skip if already exists from discovery)
  5. Initialize Files from Templates:

    a. Read templates:

    - .kiro/settings/templates/specs/init.json
    - .kiro/settings/templates/specs/requirements-init.md

    b. Replace placeholders:

    {{FEATURE_NAME}} → feature-name
    {{TIMESTAMP}} → current ISO 8601 timestamp (use `date -u +"%Y-%m-%dT%H:%M:%SZ"`)
    {{PROJECT_DESCRIPTION}} → description
    en → language code (detect from user's input language, default to `en`)

    c. Write files using Write tool:

    - .kiro/specs/{feature-name}/spec.json
    - .kiro/specs/{feature-name}/requirements.md
  6. Output Progress: "Phase 1/4 complete: Spec initialized at .kiro/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 /buildpad-spec-requirements {feature-name} via the Skill tool.

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 /buildpad-spec-design {feature-name} -y via the Skill tool. 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 /buildpad-spec-tasks {feature-name} -y via the Skill tool.

Note: -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, and tasks.md directly from disk. If brief.md exists, use it only as supporting context.
  • Prefer a fresh review subagent 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.md once, 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 .kiro/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:
- specs/{feature}/spec.json
- specs/{feature}/requirements.md ({X} requirements)
- specs/{feature}/design.md ({Y} components, {Z} endpoints)
- specs/{feature}/tasks.md ({N} tasks)

Skipped: /buildpad-validate-gap, /buildpad-validate-design

Sanity review: PASSED | FOLLOW-UP REQUIRED

Next Steps:
1. Review generated specs (especially design.md)
2. Optional: `/buildpad-validate-gap {feature}`, `/buildpad-validate-design {feature}`
3. Start implementation: `/buildpad-impl {feature}`

Safety & Fallback

Error Scenarios

Template Missing:

  • Check .kiro/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 /buildpad-spec-{next-phase} {feature}"

Sanity Review Failed:

  • Stop workflow
  • Report the exact contradiction, missing prerequisite, or task-plan issue
  • Suggest targeted follow-up with /buildpad-spec-design {feature}, /buildpad-spec-tasks {feature}, or manual edits depending on the finding

User Cancellation (Interactive Mode):

  • Stop gracefully
  • Show completed phases
  • Suggest manual continuation

Download now (ZIP)

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
What did you use it for? e.g. Reviewing pull requests in a Rails app

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.