Spec sequential
Use after /dream-team:plan to write a sequential execution spec. No arguments needed — picks up conversation context from the brainstorming session.From its SKILL.md
npx -y skills add Ratler/dream-team --skill spec-sequentialAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
One thing to look at
- 16 stars16 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.
SKILL.md
3.7 KB, as published. Nobody here has run it
Write Sequential Spec
Convert the brainstorming conversation into a formal spec file for sequential execution — single session, no sub-agents, tasks run one at a time.
Prerequisites: This skill assumes /dream-team:plan has already been run in this session. If the conversation has no brainstorming context (no discussed requirements, no confirmed approach, no validated task breakdown), stop and tell the user: "No brainstorming context found. Run /dream-team:plan <prompt> first to explore requirements and design."
What To Do
- Read the spec template at
${CLAUDE_PLUGIN_ROOT}/templates/spec-template.mdand the spec writing guide at${CLAUDE_PLUGIN_ROOT}/templates/spec-writing-guide.md. Follow the guide's filename format, ambiguity elimination, and git instructions. - Summarize the agreed plan from the conversation — confirm with the user before writing.
- Write the spec, filling in all base sections from the brainstorming context.
- Set frontmatter
mode: sequentialandspec-version: 1. - Set frontmatter
playwright: trueif the brainstorming decided to use Playwright MCP, otherwiseplaywright: false. - Set frontmatter
frontend-design: trueif the brainstorming discussed frontend/UI work and design direction, otherwisefrontend-design: false. - If
frontend-design: true, fill in the## Design Directionsection with the aesthetic style, stack, component libraries, and design notes from the brainstorming conversation. Auto-suggest component libraries based on the chosen stack if not explicitly discussed. - Tasks must be strictly linear — each depends on the previous one.
- Do NOT include Team Members, Team Configuration, Review Policy, or agent assignment fields.
- Fill in the
## Cleanupsection with any teardown commands needed (stop servers, remove temp files). Use "N/A" if nothing to clean up. - Save to
specs/YYYY-MM-DD-<descriptive-kebab-case>.mdusing today's date.
Task Rules
- Every task depends on the previous task (task 2 depends on task 1, task 3 depends on task 2, etc.)
- No
Assigned To,Agent Type,Background, orParallelfields - Each task has: Task ID, Depends On, Description with specific action items, Files, and Tests
- The Tests field lists test file paths and test cases the task must produce. Use "N/A" only for tasks with zero testable code (research, docs, config-only).
- Every builder task must include a
**Files**field listing exactly which files it creates or modifies, prefixed withcreates:ormodifies:. Review and validation tasks may omit this field. - Start with foundational work, end with a validation task
- Keep tasks small — each should take 2-10 minutes to implement
- Each builder task should produce 1-3 files and ~100-300 lines of code. If a task would be larger, split it into smaller tasks with clear file boundaries.
- The second-to-last task MUST be a code review task — re-read all changed files, check for bugs, missing edge cases, security issues, and style. Fix anything found before final validation.
Report
After saving and committing the spec, output:
Spec written (sequential mode)
File: specs/YYYY-MM-DD-<name>.md
Tasks: <number of tasks>
Complexity: <simple | medium | complex>
Execute with: /dream-team:build specs/YYYY-MM-DD-<name>.md