zhongwei/gh-mll-lab-claude-plugin-marketplace-plugins-spec
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Initial commit

Browse Source
This commit is contained in:
Zhongwei Li
2025-11-30 08:40:45 +08:00
commit 34a84658e9
6 changed files with 291 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files

12
.claude-plugin/plugin.json Normal file
View File

@@ -0,0 +1,12 @@
{
"name": "spec",
"description": "A plugin for spec-driven development",
"version": "1.0.0",
"author": {
"name": "MLL",
"email": "info@mll.com"
},
"commands": [
"./commands"
]
}

3
README.md Normal file
View File

@@ -0,0 +1,3 @@
# spec
A plugin for spec-driven development

100
commands/design.md Normal file
View File

@@ -0,0 +1,100 @@
# Specs - Design
This command documents technical architecture, sequence diagrams, and implementation considerations. It's a great place to capture the big picture of how the system will work, including the components and their interactions.
## Usage
To create a new design, just type:
```
/spec:design <jira_issue_id>
```
## What This Command Does
1. Checks if the folder with a filepath-safe version of <jira_issue_id> already exists under `.specs` and has a `requirements.md` file. If not, it stops and asks the user to create the requirements first with `/spec:req <jira_issue_id>`.
2. Checks if a file named `design.md` exists in the folder, if not it creates one.
3. Based on the requirements defined in `requirements.md`, it generates a preliminary design document in `design.md` with appropriate format.
## Appropriate Format
```md
<!-- markdownlint-disable-file MD024 -->
<!-- markdownlint-disable-file MD013 -->
<!-- markdownlint-disable-file MD040 -->
# Design Document
One or two short paragraphs to describe what the design implements.
Example:
```
This design implements Google Sign In as an additional authentication method for the existing Next.js application. The solution integrates Google as an identity provider with Amazon Cognito, leveraging the existing AWS Amplify authentication flow while adding a new UI option for users to authenticate with their Google accounts.
The design maintains the current authentication architecture and user management system, extending it to support federated identity through Google OAuth 2.0.
```
## Architecture
### High-Level Flow
Describe the flow at a high level.
Example:
```
1. **User Interface**: Enhanced sign-in page with both Cognito and Google authentication options
2. **Identity Provider**: Google OAuth 2.0 configured as a federated identity provider in Cognito
3. **Authentication Flow**: AWS Amplify handles OAuth flow with Google through Cognito
4. **User Management**: Existing user creation and session management remains unchanged
```
### Component Interaction
Create a mermaid diagram to illustrate the interaction between components.
## Components and Interfaces
### 1. Infrastructure Changes
Describe any infrastructure changes needed, such as new AWS resources or modifications to existing ones. Omit if not applicable.
### 2. Frontend UI Changes
Describe any changes to the frontend user interface, such as new components, modified layouts, or updated styles. Omit if not applicable.
### 3. Authentication Configuration
Describe any changes to the authentication configuration, such as new identity providers, modified authentication flows, or updated security settings. Omit if not applicable.
### 4. API Changes
Describe any changes to the backend APIs, such as new endpoints, modified request/response formats, or updated security settings. Omit if not applicable.
### 5. Database Changes
Describe any changes to the database schema, such as new tables, modified columns, or updated relationships. Omit if not applicable.
### 6. Environment Variables
Describe any changes to the environment variables, such as new variables, modified values, or updated configurations. Omit if not applicable.
## Data Models
Create a section for each data model affected by the design. Include the model name, a description of its purpose, and any relevant fields or relationships.
## Error Handling
Describe how errors will be handled in the system, including any new error types, error messages, or error handling flows. Omit if not applicable.
## Unit Testing Strategy
Describe the approach to unit testing for the new design, including any new test cases, testing frameworks, or testing strategies. We always strive to have 100% test coverage. Omit if not applicable.
## Other Considerations
Create separate sections for any additional considerations that may impact the design, such as performance optimizations, security implications, or compliance requirements.
```

41
commands/impl.md Normal file
View File

@@ -0,0 +1,41 @@
# Specs - Implementation plan and JIRA Issues
This command provides a detailed implementation plan with discrete, trackable tasks and sub-tasks.
Each task is clearly defined, with a clear description, expected outcome, and any necessary resources or dependencies.
## Usage
To create a new implementation plan with JIRA issues, just type:
```
/spec:impl <jira_issue_id>
```
## What This Command Does
1. Checks if the folder with <jira_issue_id> already exists under `.specs` and has a `requirements.md` and `design.md` file. If not, it stops and asks the user to create the design first with `/spec:design <feature>`.
2. Checks if a file named `tasks.md` exists in the folder, if not it creates one.
3. Based on the design defined in `design.md`, it generates an implementation plan in `tasks.md` with appropriate format.
4. It creates a sub-task in JIRA for each task in the implementation plan under the Jira issue <jira_issue_id>.
5. It asks the user to review the implementation plan and JIRA issues before proceeding.
6. If the user wants to make changes, it updates the tasks in `tasks.md` and the corresponding JIRA issues.
7. Once the user has confirmed the implementation plan and JIRA issues, it proceeds with the execution one task at a time as long as all tasks are implemented. When starting a task, it transitions the JIRA issue to "In Progress".
## Appropriate format
```md
<!-- markdownlint-disable-file MD024 -->
<!-- markdownlint-disable-file MD013 -->
<!-- markdownlint-disable-file MD040 -->
# Implementation Plan
- [ ] 1. Short description of the task (<jira_issue_id_1>)
- Relevant sub-tasks or steps to complete the task
- \_Requirements: 5.1, 1.1, etc. (see requirements.md)
- [ ] 2. Another task description (<jira_issue_id_2>)
- Relevant sub-tasks or steps to complete the task
- \_Requirements: 5.2, 4.1, etc. (see requirements.md)
```

82
commands/req.md Normal file
View File

@@ -0,0 +1,82 @@
# Specs - Requirements from JIRA Story
This command captures user stories and acceptance criteria in structured EARS notation. It does not implement anything, but helps to define the requirements clearly.
## Usage
To create a new requirement, just type:
```
/spec:req <jira_issue_id>
```
## What This Command Does
1. Retrieves the story with the given ID <jira_issue_id> from JIRA.
2. Checks if a folder with a filepath-safe version of <jira_issue_id> already exists under `.specs`, if not it creates it.
3. Checks if a file named `requirements.md` exists in the newly created folder, if not it creates one.
4. Turns the description of the JIRA story into a fully fleshed out `requirements.md` file in the appropriate format.
5. Asks the user for additional details to fill out the requirements. This is a repetitive process until all details are captured.
6. Once finished, it asks the user to review the `requirements.md` file.
7. If the user approves, it determines the changes to the original requirements and posts them as comment to the JIRA issue in the language of the original issue description.
## Appropriate Format
```md
<!-- markdownlint-disable-file MD024 -->
<!-- markdownlint-disable-file MD013 -->
<!-- markdownlint-disable-file MD040 -->
# Requirements Document
## Introduction
Describe the feature in a detailed paragraph.
## Requirements
### Requirement 1
**User Story** Describe the user story for requirement 1.
#### Acceptance Criteria
1. Describe the first acceptance criterion in EARS format.
2. Describe the second acceptance criterion in EARS format.
3. Describe the third acceptance criterion in EARS format.
### Requirement 2
**User Story** Describe the user story for requirement 2.
#### Acceptance Criteria
1. Describe the first acceptance criterion in EARS format.
2. Describe the second acceptance criterion in EARS format.
```
## EARS format
EARS (Easy Approach to Requirements Syntax) notation provides a structured format for writing clear, testable requirements. Each acceptance criterion should be expressed in the following format:
```
WHEN [condition/event]
THE SYSTEM SHALL [expected behavior]
```
```
IF [unwanted condition/event],
THEN THE SYSTEM SHALL [system response/behavior]
```
```
WHILE [system state],
THE SYSTEM SHALL [system response/behavior]
```
```
WHERE [feature],
THE SYSTEM SHALL [system response/behavior]
```
Note these patterns can be combined for more complex scenarios.

53
plugin.lock.json Normal file
View File

@@ -0,0 +1,53 @@
{
"$schema": "internal://schemas/plugin.lock.v1.json",
"pluginId": "gh:mll-lab/claude-plugin-marketplace:plugins/spec",
"normalized": {
"repo": null,
"ref": "refs/tags/v20251128.0",
"commit": "171abede76a6aadd7c18f2bd9959a321b55ff248",
"treeHash": "37345b37a922369133543c14800ff284b1037ed4622f4ea54edbc7e122f2253d",
"generatedAt": "2025-11-28T10:27:07.469618Z",
"toolVersion": "publish_plugins.py@0.2.0"
},
"origin": {
"remote": "git@github.com:zhongweili/42plugin-data.git",
"branch": "master",
"commit": "aa1497ed0949fd50e99e70d6324a29c5b34f9390",
"repoRoot": "/Users/zhongweili/projects/openmind/42plugin-data"
},
"manifest": {
"name": "spec",
"description": "A plugin for spec-driven development",
"version": "1.0.0"
},
"content": {
"files": [
{
"path": "README.md",
"sha256": "bb7f99d8035b22211296727098466e8c985116794e437ea8d189d62c8f787312"
},
{
"path": ".claude-plugin/plugin.json",
"sha256": "694b5e23f08e0411bcb8a9e1cd56477d15a6a8b6a95937cab271718f588e6706"
},
{
"path": "commands/req.md",
"sha256": "c6f0ad0fb383c6b8ac5af23ec86b999c6eb6511fb5259a163707fe1c990e7b76"
},
{
"path": "commands/impl.md",
"sha256": "8a9ec0cf0d6a3155cd7c36278eeaf7ea7a61c3b6315bcd22991216ba2d217f1c"
},
{
"path": "commands/design.md",
"sha256": "55b14e785945080d8ba78264b6e8c11ae4bdda7cb043f545a62cd6d2696bd019"
}
],
"dirSha256": "37345b37a922369133543c14800ff284b1037ed4622f4ea54edbc7e122f2253d"
},
"security": {
"scannedAt": null,
"scannerVersion": null,
"flags": []
}
}