From vamfi-software-consultancy
This skill should be used when the user asks to "create a spec", "break this into tasks", "spec out this feature", "write a spec for this story", "convert requirements to tasks", "plan this initiative", or needs to turn any natural language requirement into a structured, agent-executable task breakdown following the 2026 Spec Kit pattern.
npx claudepluginhub vamfi/vamfi-plugins --plugin vamfi-software-consultancyThis skill uses the workspace's default tool permissions.
Convert any natural language requirement into a structured specification that drives the entire downstream delivery pipeline. Based on the 2026 Spec Kit pattern used by GitHub and leading engineering organisations.
Generates design tokens/docs from CSS/Tailwind/styled-components codebases, audits visual consistency across 10 dimensions, detects AI slop in UI.
Records polished WebM UI demo videos of web apps using Playwright with cursor overlay, natural pacing, and three-phase scripting. Activates for demo, walkthrough, screen recording, or tutorial requests.
Delivers idiomatic Kotlin patterns for null safety, immutability, sealed classes, coroutines, Flows, extensions, DSL builders, and Gradle DSL. Use when writing, reviewing, refactoring, or designing Kotlin code.
Convert any natural language requirement into a structured specification that drives the entire downstream delivery pipeline. Based on the 2026 Spec Kit pattern used by GitHub and leading engineering organisations.
Spec-driven planning is the universal entry point for any VAMFI engagement work. It transforms vague briefs, PRD sections, or user stories into structured specs with acceptance criteria, measurable task breakdowns, and dependency maps. This makes work agent-executable and leaves nothing to interpretation.
Apply spec-driven planning before any implementation, story shaping, or delivery planning work. It is especially valuable when:
Extract from the provided requirement:
If any of these are missing, state the assumption or ask the one most important question.
Produce a spec document with this structure:
# Spec: [Title]
## Goal
[One paragraph: what outcome does this achieve and for whom?]
## Scope
**In scope:**
- [item 1]
- [item 2]
**Out of scope:**
- [item 1]
- [item 2]
## Acceptance Criteria
- [ ] Given [context], when [action], then [result]
- [ ] Given [context], when [edge case], then [expected handling]
## Constraints
- [Technical, regulatory, performance, or timeline constraints]
## Assumptions
| Assumption | Confidence | Owner | Validation |
|---|---|---|---|
| [assumption] | High/Med/Low | [name] | [how to validate] |
## Open Questions
- [Question that must be answered before implementation begins]
Break the spec into numbered, measurable, independently executable tasks:
## Task Breakdown
1. [Task title] — [1-2 sentence description of exactly what to do]
- Input: [what this task requires]
- Output: [what this task produces]
- Estimate: [XS/S/M]
2. [Next task]
- Input: [...]
- Output: [...]
- Estimate: [...]
Rules for task breakdown:
Identify which tasks must complete before others can start:
Task 1 → Task 3
Task 2 → Task 4
Task 1, Task 2 → Task 5
Flag the critical path: the longest chain of dependent tasks.
If the work spans multiple VAMFI agents, suggest which agent handles which task:
Produce the complete spec document as formatted markdown, followed by the task breakdown table, dependency map, and optional agent assignment. Offer to save to docs/vamfi/spec-[feature-name].md.
references/spec-examples.md — Complete worked examples of well-formed specsreferences/task-breakdown-patterns.md — Patterns for breaking down different types of work