// Implement features using Spec Driven Development (SDD) workflow. Creates design and task documents with approval gates.
Use this skill when optimizing Jazz applications for speed, responsiveness, and scalability. Covers crypto setup, efficient data modeling, and UI patterns to prevent lag.
Use this skill when optimizing Jazz applications for speed, responsiveness, and scalability. Covers crypto setup, efficient data modeling, and UI patterns to prevent lag.
Use this skill when writing or running performance benchmarks for Jazz packages. Covers cronometro setup, file conventions, gotchas with worker threads, and how to compare implementations.
Generate changeset files for versioning and changelog management in this monorepo.
Use this skill when designing data schemas, implementing sharing workflows, or auditing access control in Jazz applications. It covers the hierarchy of Groups, Accounts, and CoValues, ensuring data is private by default and shared securely through cascading permissions and invitations.
Design and implement collaborative data schemas using the Jazz framework. Use this skill when building or working with Jazz apps to define data structures using CoValues. This skill focuses exclusively on schema definition and data modeling logic.
| name | spec |
| description | Implement features using Spec Driven Development (SDD) workflow. Creates design and task documents with approval gates. |
Use this skill when the user asks to implement a feature. This workflow ensures proper planning and approval before any code is written.
Follow these steps in order. Do not skip steps. Always ask for explicit approval before moving to the next step.
Create a feature directory under .specs/{feature_name} using kebab-case for the name.
This step is opt-in and must be explicitly requested by the user.
If the user requests requirements, create requirements.md in the feature directory with:
Example EARS patterns:
Example structure:
# Requirements
## Introduction
[Brief context about what this feature addresses and why it's needed]
## User Stories & Acceptance Criteria
### US-1: [User Story Title]
**As a** [role], **I want** [goal], **so that** [benefit].
**Acceptance Criteria:**
- When [user action], the system shall [expected behavior]
- While [state], the system shall [maintain condition]
- Where [optional condition], the system shall [handle appropriately]
After creating the requirements document, refine it:
Do not proceed until all critical ambiguities are resolved. Minor open questions can be noted as assumptions in the design document.
If requirements are created, get approval before proceeding to the design document.
Create design.md in the feature directory with:
Show the code snippets of the core parts of the implementation in the design.
We prioritize integration testing, and show a couple of test snippets as example of testing strategy.
After creating the design document, refine it:
Do not proceed until all critical gaps are resolved. Minor open questions can be noted as assumptions.
Ask the user: "Does the design look good? If so, we can move on to the implementation plan."
Wait for explicit approval before proceeding.
Once design is approved, create tasks.md in the feature directory with:
Example structure:
# Implementation Tasks
## Tasks
- [ ] 1. Create data model for [entity]
- [ ] 2. Add API endpoint for [action]
- [ ] 3. Implement validation logic
- [ ] 4. Add unit tests for [component]
- [ ] 5. Add integration tests for [feature]
Ask the user: "Do the tasks look good?"
Wait for explicit approval.
Do not implement any code. The workflow ends here. Implementation should be a separate activity initiated by the user.
user-authentication)