**Skill**: convert-to-speckit
Inherits all available tools
Additional assets for this skill
This skill inherits all available tools. When active, it can use any tool Claude has access to.
Skill: convert-to-speckit
Purpose: Convert existing docs/reverse-engineering/ documentation into GitHub Spec Kit specifications
Use Case: Repository has reverse engineering docs from StackShift Gears 1-2, but needs proper Spec Kit format
This skill reads your existing reverse engineering documentation and converts it into properly formatted GitHub Spec Kit specifications, ready for the /speckit-* workflow commands.
Your repository should have:
docs/reverse-engineering/ directory with documentation files.specify/templates/ with Spec Kit templates (will be created if missing)docs/reverse-engineering/specs/F{NNN}-{feature}/spec.md filesI'll scan for reverse engineering documentation:
docs/reverse-engineering/
├── functional-specification.md
├── data-architecture.md
├── api-documentation.md
├── integration-points.md
├── business-logic.md
├── deployment-architecture.md
└── [other analysis files]
Action: Let me read all files in this directory to understand the application.
From the documentation, I'll identify distinct features. Each feature becomes one specification.
Examples of features:
Question for you: After I list the features I found, you can:
For each feature, I'll create a properly formatted specification following this structure:
specs/F{NNN}-{feature-slug}/spec.md# Feature Specification: {Feature Name}
**Feature Branch**: `{NNN}-{feature-slug}`
**Created**: {date}
**Status**: Draft
**Priority**: P0 | P1 | P2
## User Scenarios & Testing *(mandatory)*
### User Story 1 - {Capability} (Priority: P0/P1/P2)
As a {user type}, I need {capability} so that {benefit}.
**Why this priority**: {Business value explanation}
**Independent Test**: {How to test this in isolation}
**Acceptance Scenarios**:
1. **Given** {precondition}, **When** {action}, **Then** {outcome}
2. **Given** {precondition}, **When** {action}, **Then** {outcome}
3. **Given** {precondition}, **When** {action}, **Then** {outcome}
---
{3-5 user stories per feature}
---
### Edge Cases
- {5-10 edge cases that need handling}
## Requirements *(mandatory)*
### Functional Requirements
- **FR-001**: System MUST {requirement}
- **FR-002**: System MUST {requirement}
- **FR-003**: System SHOULD {optional requirement}
{10-15 functional requirements}
### Key Entities *(if data-related)*
- **{Entity}**: {Description}
## Success Criteria *(mandatory)*
### Measurable Outcomes
- **SC-001**: {Metric}: {Expected value}
- **SC-002**: {Performance metric}
{8-12 success criteria}
### Non-Functional Requirements
- **Performance**: {Response times, throughput}
- **Reliability**: {Uptime, error rates}
- **Security**: {Auth, encryption, protection}
- **Maintainability**: {Code quality, tests}
## Assumptions
1. {Technical assumptions}
2. {Environment assumptions}
{3-7 assumptions}
## Dependencies
- {External systems, libraries, services}
## Out of Scope
- {Things NOT in this feature}
- {Future enhancements}
## References
- {Documentation links}
- {Standards followed}
| Source | Target |
|---|---|
| Capabilities, features, "what it does" | User Stories |
| API endpoints, request/response | Functional Requirements |
| Database tables, schemas | Key Entities |
| Business rules, validation | Acceptance Scenarios |
| Error conditions, limits | Edge Cases |
| External APIs, services | Dependencies |
| Tech stack, frameworks | Implementation details (plan.md, not spec.md) |
Spec.md describes WHAT, not HOW:
Stay technology-agnostic:
Focus on outcomes:
Implementation details go in plan.md, which is created later via /speckit-plan.
Before completing, I'll verify each spec has:
API: POST /api/auth/login
- Takes email and password
- Returns JWT token
- Returns 401 if invalid
- Rate limited to 5 attempts
### User Story 1 - Secure Login (Priority: P0)
As a registered user, I need to log in with email and password so that I can access my account securely.
**Why this priority**: Core authentication is critical for all user features.
**Independent Test**: Submit valid credentials, verify token returned.
**Acceptance Scenarios**:
1. **Given** valid email and password, **When** login submitted, **Then** authentication token and user profile returned
2. **Given** invalid credentials, **When** login submitted, **Then** 401 error returned without revealing which field failed
3. **Given** 5 failed attempts, **When** login submitted, **Then** 429 rate limit error returned
### Functional Requirements
- **FR-001**: System MUST accept email and password via secure HTTPS
- **FR-002**: System MUST validate email format before auth
- **FR-003**: System MUST return auth token on successful verification
- **FR-004**: System MUST return 401 for invalid credentials
- **FR-005**: System MUST rate limit to prevent brute force (5 attempts)
- **FR-006**: System MUST return 429 when rate limit exceeded
### Success Criteria
- **SC-001**: Login succeeds for valid credentials 99.9% of time
- **SC-002**: Login completes within 500ms at 95th percentile
- **SC-003**: Rate limiting activates after 5 attempts per 15 minutes
I'm ready to help convert your reverse engineering docs to Spec Kit format.
What I need from you:
docs/reverse-engineering/ with documentation?What I'll deliver:
specs/F{NNN}-{feature}/spec.md formatNext steps after conversion:
/speckit-plan on each spec to create implementation plans/speckit-tasks to generate actionable task lists/speckit-implement to execute the implementationLet's begin!
I'll start by reading your docs/reverse-engineering/ directory. Please confirm you're ready, and I'll begin the conversion process.