Initial commit
This commit is contained in:
11
.claude-plugin/plugin.json
Normal file
11
.claude-plugin/plugin.json
Normal file
@@ -0,0 +1,11 @@
|
|||||||
|
{
|
||||||
|
"name": "spec-manager-plugin",
|
||||||
|
"description": "Manage specification files for spec-driven development workflow with feat, fix, docs, refactor, and chore scopes",
|
||||||
|
"version": "1.0.0",
|
||||||
|
"author": {
|
||||||
|
"name": "Stefan Cho"
|
||||||
|
},
|
||||||
|
"skills": [
|
||||||
|
"./skills"
|
||||||
|
]
|
||||||
|
}
|
||||||
3
README.md
Normal file
3
README.md
Normal file
@@ -0,0 +1,3 @@
|
|||||||
|
# spec-manager-plugin
|
||||||
|
|
||||||
|
Manage specification files for spec-driven development workflow with feat, fix, docs, refactor, and chore scopes
|
||||||
69
plugin.lock.json
Normal file
69
plugin.lock.json
Normal file
@@ -0,0 +1,69 @@
|
|||||||
|
{
|
||||||
|
"$schema": "internal://schemas/plugin.lock.v1.json",
|
||||||
|
"pluginId": "gh:devstefancho/claude-plugins:spec-manager-plugin",
|
||||||
|
"normalized": {
|
||||||
|
"repo": null,
|
||||||
|
"ref": "refs/tags/v20251128.0",
|
||||||
|
"commit": "384acaa530f147cff84c94e4b18f85b920b1253a",
|
||||||
|
"treeHash": "aaab8dda354fee64d07c150c98fd1b6bcb5d4b1570e963bfc234f839692949b4",
|
||||||
|
"generatedAt": "2025-11-28T10:16:21.479721Z",
|
||||||
|
"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-manager-plugin",
|
||||||
|
"description": "Manage specification files for spec-driven development workflow with feat, fix, docs, refactor, and chore scopes",
|
||||||
|
"version": "1.0.0"
|
||||||
|
},
|
||||||
|
"content": {
|
||||||
|
"files": [
|
||||||
|
{
|
||||||
|
"path": "README.md",
|
||||||
|
"sha256": "ab77b60e19d29269550663219d2086c0ffeed520d7f1bb35cf414eac143be58f"
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"path": ".claude-plugin/plugin.json",
|
||||||
|
"sha256": "f60dbc1a88689cf533ff8df70555671896a442455f1e122f37d5a7377b64a7b3"
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"path": "skills/spec-manager/SKILL.md",
|
||||||
|
"sha256": "a173518dc403ed3716079232f5d97b3d68baf9e0c276fdd4e4c887dc5ccfed44"
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"path": "skills/spec-manager/templates/feat-template.md",
|
||||||
|
"sha256": "31babff63fe469b0faf260ccbb5967bb8da40659259cd58b1bca1208df642e7b"
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"path": "skills/spec-manager/templates/docs-template.md",
|
||||||
|
"sha256": "47e14310a836112fdbb19359694b5835a55f18c0a921b2ec1ce0acd9eeb07617"
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"path": "skills/spec-manager/templates/chore-template.md",
|
||||||
|
"sha256": "54cf1b25912eb339d6b2efe5fbde173610aae5c52d73d71e1b54f108f30162bd"
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"path": "skills/spec-manager/templates/spec-template.md",
|
||||||
|
"sha256": "4f5789641c59db08aa30acb2616a82ceb67e6c6f6043fb7cdbacb03dffeea87a"
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"path": "skills/spec-manager/templates/refactor-template.md",
|
||||||
|
"sha256": "e4e7499f5e33ec367dd5dd50dc3316cfa1c6f2dee853a497004c4462d9c7ced8"
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"path": "skills/spec-manager/templates/fix-template.md",
|
||||||
|
"sha256": "eebba8e7ba1cb60bf6eba799bd8dfa5d79df7931ead1a73da55bfc20b4969413"
|
||||||
|
}
|
||||||
|
],
|
||||||
|
"dirSha256": "aaab8dda354fee64d07c150c98fd1b6bcb5d4b1570e963bfc234f839692949b4"
|
||||||
|
},
|
||||||
|
"security": {
|
||||||
|
"scannedAt": null,
|
||||||
|
"scannerVersion": null,
|
||||||
|
"flags": []
|
||||||
|
}
|
||||||
|
}
|
||||||
54
skills/spec-manager/SKILL.md
Normal file
54
skills/spec-manager/SKILL.md
Normal file
@@ -0,0 +1,54 @@
|
|||||||
|
---
|
||||||
|
name: spec-manager
|
||||||
|
description: Manage specification files for spec-driven development. Use when creating, updating, or deleting spec files. Supports feat, fix, docs, refactor, and chore scopes.
|
||||||
|
allowed-tools: Read, Write, Glob, Grep, Bash, AskUserQuestion
|
||||||
|
---
|
||||||
|
|
||||||
|
# Spec Manager
|
||||||
|
|
||||||
|
Manages specification files in `specs/{scope}/{work-name}.md` for spec-driven development workflow.
|
||||||
|
|
||||||
|
## Principles
|
||||||
|
|
||||||
|
1. **One spec = one task** (unless frontend + backend work together)
|
||||||
|
2. **No "before" sections** - Focus only on the final desired state
|
||||||
|
3. **XML tag format** - Use XML tags for structure (varies by scope)
|
||||||
|
4. **Minimal code examples** - Avoid code in specs; if necessary, keep it brief and illustrative
|
||||||
|
5. **Check for duplicates** - Always verify if similar specs exist before creating
|
||||||
|
|
||||||
|
## Operations
|
||||||
|
|
||||||
|
### Create
|
||||||
|
1. Analyze request and infer scope (feat/fix/docs/refactor/chore)
|
||||||
|
2. Search `specs/{scope}/` for similar existing specs
|
||||||
|
3. If found, ask: "Create new", "Update existing", or "Cancel"
|
||||||
|
4. If ambiguous scope, ask user to confirm
|
||||||
|
5. Generate filename (lowercase-with-hyphens)
|
||||||
|
6. Use appropriate template based on scope
|
||||||
|
7. Fill in XML tags based on user request
|
||||||
|
|
||||||
|
### Update
|
||||||
|
1. List existing specs in relevant scope
|
||||||
|
2. Let user select which to update
|
||||||
|
3. Verify update aligns with original purpose
|
||||||
|
4. If purpose changed significantly, suggest new spec
|
||||||
|
5. Apply changes while maintaining XML structure
|
||||||
|
|
||||||
|
### Delete
|
||||||
|
1. List all specs organized by scope
|
||||||
|
2. Let user select spec(s) to delete
|
||||||
|
3. Confirm and remove
|
||||||
|
|
||||||
|
### List
|
||||||
|
Display all specs organized by scope directory structure.
|
||||||
|
|
||||||
|
## Templates
|
||||||
|
|
||||||
|
See templates directory for scope-specific XML tag structures:
|
||||||
|
- `feat` → [templates/feat-template.md](templates/feat-template.md)
|
||||||
|
- `fix` → [templates/fix-template.md](templates/fix-template.md)
|
||||||
|
- `docs` → [templates/docs-template.md](templates/docs-template.md)
|
||||||
|
- `refactor` → [templates/refactor-template.md](templates/refactor-template.md)
|
||||||
|
- `chore` → [templates/chore-template.md](templates/chore-template.md)
|
||||||
|
|
||||||
|
Each template uses different XML tags appropriate to its scope.
|
||||||
27
skills/spec-manager/templates/chore-template.md
Normal file
27
skills/spec-manager/templates/chore-template.md
Normal file
@@ -0,0 +1,27 @@
|
|||||||
|
# [Chore Name]
|
||||||
|
|
||||||
|
<purpose>
|
||||||
|
What maintenance task, tooling update, or dependency change is needed and why.
|
||||||
|
</purpose>
|
||||||
|
|
||||||
|
<changes>
|
||||||
|
What will be changed:
|
||||||
|
- Dependency updates
|
||||||
|
- Configuration changes
|
||||||
|
- Build/CI improvements
|
||||||
|
- Tooling modifications
|
||||||
|
</changes>
|
||||||
|
|
||||||
|
<impact>
|
||||||
|
Impact on the project:
|
||||||
|
- Breaking changes (if any)
|
||||||
|
- Required developer actions
|
||||||
|
- Environment or setup changes
|
||||||
|
</impact>
|
||||||
|
|
||||||
|
<verification>
|
||||||
|
How to verify the changes work:
|
||||||
|
- Build/CI checks
|
||||||
|
- Local development verification
|
||||||
|
- Deployment verification (if applicable)
|
||||||
|
</verification>
|
||||||
28
skills/spec-manager/templates/docs-template.md
Normal file
28
skills/spec-manager/templates/docs-template.md
Normal file
@@ -0,0 +1,28 @@
|
|||||||
|
# [Documentation Update]
|
||||||
|
|
||||||
|
<purpose>
|
||||||
|
What documentation needs to be created or updated and why.
|
||||||
|
</purpose>
|
||||||
|
|
||||||
|
<scope>
|
||||||
|
What will be documented:
|
||||||
|
- Topic or feature area 1
|
||||||
|
- Topic or feature area 2
|
||||||
|
- Topic or feature area 3
|
||||||
|
</scope>
|
||||||
|
|
||||||
|
<content_outline>
|
||||||
|
High-level structure of the documentation:
|
||||||
|
- Section 1: Brief description
|
||||||
|
- Section 2: Brief description
|
||||||
|
- Section 3: Brief description
|
||||||
|
|
||||||
|
Include audience (developers, users, etc.) and tone/style considerations.
|
||||||
|
</content_outline>
|
||||||
|
|
||||||
|
<completion_criteria>
|
||||||
|
How to verify documentation is complete:
|
||||||
|
- Coverage check 1
|
||||||
|
- Coverage check 2
|
||||||
|
- Accuracy verification steps
|
||||||
|
</completion_criteria>
|
||||||
27
skills/spec-manager/templates/feat-template.md
Normal file
27
skills/spec-manager/templates/feat-template.md
Normal file
@@ -0,0 +1,27 @@
|
|||||||
|
# [Feature Name]
|
||||||
|
|
||||||
|
<purpose>
|
||||||
|
What feature is being added and why it's needed.
|
||||||
|
</purpose>
|
||||||
|
|
||||||
|
<requirements>
|
||||||
|
- User story or requirement 1
|
||||||
|
- User story or requirement 2
|
||||||
|
- User story or requirement 3
|
||||||
|
</requirements>
|
||||||
|
|
||||||
|
<implementation>
|
||||||
|
High-level approach:
|
||||||
|
- Architecture pattern or design choice
|
||||||
|
- Key components or modules involved
|
||||||
|
- Important technical considerations
|
||||||
|
|
||||||
|
Avoid detailed code - focus on structure and decisions.
|
||||||
|
</implementation>
|
||||||
|
|
||||||
|
<testing>
|
||||||
|
Verification plan:
|
||||||
|
- Functional test scenario 1
|
||||||
|
- Functional test scenario 2
|
||||||
|
- Edge cases to verify
|
||||||
|
</testing>
|
||||||
25
skills/spec-manager/templates/fix-template.md
Normal file
25
skills/spec-manager/templates/fix-template.md
Normal file
@@ -0,0 +1,25 @@
|
|||||||
|
# [Bug Fix Name]
|
||||||
|
|
||||||
|
<problem>
|
||||||
|
Description of the bug or issue. What is broken and how it manifests.
|
||||||
|
</problem>
|
||||||
|
|
||||||
|
<root_cause>
|
||||||
|
Why the bug occurs - the underlying cause.
|
||||||
|
</root_cause>
|
||||||
|
|
||||||
|
<solution>
|
||||||
|
How to fix it:
|
||||||
|
- Approach to resolve the issue
|
||||||
|
- Components that need changes
|
||||||
|
- Any side effects to consider
|
||||||
|
|
||||||
|
Keep implementation details minimal.
|
||||||
|
</solution>
|
||||||
|
|
||||||
|
<testing>
|
||||||
|
How to verify the fix:
|
||||||
|
- Reproduce steps that should now work
|
||||||
|
- Regression tests to ensure nothing breaks
|
||||||
|
- Edge cases related to the bug
|
||||||
|
</testing>
|
||||||
25
skills/spec-manager/templates/refactor-template.md
Normal file
25
skills/spec-manager/templates/refactor-template.md
Normal file
@@ -0,0 +1,25 @@
|
|||||||
|
# [Refactoring Name]
|
||||||
|
|
||||||
|
<motivation>
|
||||||
|
Why this refactoring is needed - code quality issues, maintainability concerns, or technical debt.
|
||||||
|
</motivation>
|
||||||
|
|
||||||
|
<current_state>
|
||||||
|
Brief description of what exists now that needs refactoring.
|
||||||
|
</current_state>
|
||||||
|
|
||||||
|
<target_state>
|
||||||
|
What the code should look like after refactoring:
|
||||||
|
- Structural improvements
|
||||||
|
- Pattern or architecture changes
|
||||||
|
- Quality improvements (readability, maintainability, performance)
|
||||||
|
|
||||||
|
Focus on design and structure, not specific code.
|
||||||
|
</target_state>
|
||||||
|
|
||||||
|
<testing>
|
||||||
|
How to ensure refactoring doesn't break functionality:
|
||||||
|
- Existing tests that should pass
|
||||||
|
- New tests if behavior changes
|
||||||
|
- Performance benchmarks if applicable
|
||||||
|
</testing>
|
||||||
26
skills/spec-manager/templates/spec-template.md
Normal file
26
skills/spec-manager/templates/spec-template.md
Normal file
@@ -0,0 +1,26 @@
|
|||||||
|
# [Title]
|
||||||
|
|
||||||
|
<purpose>
|
||||||
|
Brief description of what needs to be accomplished and why.
|
||||||
|
</purpose>
|
||||||
|
|
||||||
|
<requirements>
|
||||||
|
- Requirement 1
|
||||||
|
- Requirement 2
|
||||||
|
- Requirement 3
|
||||||
|
</requirements>
|
||||||
|
|
||||||
|
<implementation>
|
||||||
|
High-level technical approach and key decisions. Avoid specific code details.
|
||||||
|
|
||||||
|
Keep this concise - focus on architecture, patterns, and important constraints rather than detailed implementation.
|
||||||
|
|
||||||
|
If code examples are necessary, keep them minimal and illustrative only.
|
||||||
|
</implementation>
|
||||||
|
|
||||||
|
<testing>
|
||||||
|
How to verify the implementation:
|
||||||
|
- Test scenario 1
|
||||||
|
- Test scenario 2
|
||||||
|
- Test scenario 3
|
||||||
|
</testing>
|
||||||
Reference in New Issue
Block a user