Write a workflow for formal spec-driven development based on TLA+
This commit is contained in:
parent
c2f2d4e857
commit
bb7422f4c0
9 changed files with 944 additions and 0 deletions
65
.claude/commands/formspec.init.0.md
Normal file
65
.claude/commands/formspec.init.0.md
Normal file
|
|
@ -0,0 +1,65 @@
|
|||
---
|
||||
description: Initialize formspec project structure
|
||||
argument-hint: <system-description>
|
||||
allowed-tools: [Read, Write, Edit, Glob, Grep, Bash]
|
||||
---
|
||||
|
||||
# FormSpec Init
|
||||
|
||||
You are initializing a formal-specification-driven development project. Your job is to create the `spec/` directory structure and a foundational `spec/system.md` document.
|
||||
|
||||
## Steps
|
||||
|
||||
### 1. Check for existing spec/ directory
|
||||
|
||||
Use Glob to check if `spec/system.md` already exists in the project root.
|
||||
|
||||
If it exists: **STOP**. Tell the user that the project is already initialized and they should use `/formspec.design.1` to add features. Do not modify anything.
|
||||
|
||||
### 2. Gather system description
|
||||
|
||||
If `$ARGUMENTS` is provided, use it as the high-level system description.
|
||||
|
||||
If `$ARGUMENTS` is empty or too vague to work with, ask the user to describe:
|
||||
- What the system is and its purpose
|
||||
- Who the primary actors are (users, services, external systems)
|
||||
- Key constraints (non-negotiable properties like statelessness, partition tolerance, latency bounds, security requirements)
|
||||
|
||||
### 3. Create directory structure
|
||||
|
||||
Create the following directories:
|
||||
```
|
||||
spec/formal/subsystems/
|
||||
spec/features/
|
||||
spec/verification/
|
||||
```
|
||||
|
||||
### 4. Generate spec/system.md
|
||||
|
||||
Write `spec/system.md` with the following structure. Fill in the System Overview and Architectural Constraints based on the gathered description. Leave Feature Index and Changelog empty with placeholder text.
|
||||
|
||||
```markdown
|
||||
# System Design
|
||||
|
||||
## System Overview
|
||||
|
||||
[What is this system, who uses it, why does it exist. Derived from the user's description.]
|
||||
|
||||
## Architectural Constraints
|
||||
|
||||
[Non-negotiable properties of the system. Each constraint should be a clear, testable statement.]
|
||||
|
||||
## Feature Index
|
||||
|
||||
*No features designed yet. Use `/formspec.design.1 <feature-name>` to add features.*
|
||||
|
||||
## Changelog
|
||||
|
||||
*No changes recorded yet.*
|
||||
```
|
||||
|
||||
The System Overview should be a concise but complete description — enough for someone unfamiliar with the project to understand what they're looking at. The Architectural Constraints should be concrete and specific, not vague aspirations.
|
||||
|
||||
### 5. Report
|
||||
|
||||
Tell the user what was created and suggest they proceed with `/formspec.design.1 <feature-name>` to start designing features.
|
||||
Loading…
Add table
Add a link
Reference in a new issue