zhongwei/gh-elct9620-claudekit-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-29 18:25:19 +08:00
commit 92ace25b48
19 changed files with 1219 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files

97
skills/spec-scaffold/templates/adr.md Normal file
View File

@@ -0,0 +1,97 @@
[DATE] - [ARCHITECTURE_DECISION_NAME]
===
## Motivation
<!--
Motivation Example
===
Our database is heavy on read operations than write operations. After users is growing, we need to optimize read performance to ensure low latency and high availability.
### Stackholder
- **Users**: Expect fast response times when accessing data.
- **Developers**: Need to maintain and scale the database efficiently.
### Problem Statement
The current database setup is struggling to handle the increasing read load, leading to slow response times and potential downtime during peak usage periods.
-->
[DESCRIPTION_OF_THE_DECISION_PROBLEM]
### Stakeholders
- [STAKEHOLDER_1]: [ROLE_AND_INTEREST]
- [STAKEHOLDER_2]: [ROLE_AND_INTEREST]
### Problem Statement
[DETAILED_DESCRIPTION_OF_THE_PROBLEM]
## Proposed Solution
<!--
Proposed Solution Example
===
We have considered the following solutions to address the read performance issue:
### Redis Caching
Implementing Redis as an in-memory caching layer to store frequently accessed data. This will reduce the load on the primary database and speed up read operations.
### Read Replicas
Setting up read replicas of the primary database to distribute read traffic. This will help in balancing the load and improving read performance.
-->
### [SOLUTION_NAME]
[DESCRIPTION_OF_SOLUTION]
### [SOLUTION_NAME]
[DESCRIPTION_OF_SOLUTION]
## Decision
<!--
Decision Example
===
After evaluating the proposed solutions, we have decided to implement Redis Caching because it provides a significant performance boost for read operations with relatively low complexity and cost.
-->
After evaluating the proposed solutions, we have decided to implement [CHOSEN_SOLUTION_NAME] because [REASON_FOR_CHOICE].
## Consequences
<!--
Consequences Example
===
Implementing Redis Caching will have the following consequences:
### Positive Consequences
- Improved read performance, leading to faster response times for users.
- Reduced load on the primary database, enhancing overall system stability.
### Negative Consequences
- Additional infrastructure to manage and maintain (Redis server).
- Potential data consistency issues if cache is not properly invalidated.
-->
### Positive Consequences
- [POSITIVE_CONSEQUENCE_1]
- [POSITIVE_CONSEQUENCE_2]
### Negative Consequences
- [NEGATIVE_CONSEQUENCE_1]
- [NEGATIVE_CONSEQUENCE_2]

82
skills/spec-scaffold/templates/architecture.md Normal file
View File

@@ -0,0 +1,82 @@
Architecture
===
This document outlines the high-level architecture and design for the project.
## Technology Stack
<!--
Technology Stack Example
===
- **Ruby**: Primarily used for backend development.
- **Ruby on Rails**: Web application framework for building the backend services.
- **PostgreSQL**: Relational database for data storage.
- **StimulusJS**: JavaScript framework for enhancing frontend interactivity.
- **Amazon Web Services (AWS)**: Cloud platform for hosting and deploying the application.
- **RDS**: Managed relational database service provided by AWS.
Replace the above with actual technologies and versions used in your project.
-->
- [STACK_NAME]: [REQUIREMENT_DESCRIPTION]
- [STACK_NAME]: [REQUIREMENT_DESCRIPTION]
## Structure
<!--
Replace the example structure below with the actual directory structure of your project.
-->
```
|- app/
|- controllers/ # Controllers for handling requests
|- models/ # Data models
|- views/ # View templates
|- lib/ # Application-specific libraries
|- domains/ # Domain-specific logic
|- [DOMAIN_NAME]/ # Replace with actual domain names
|- services/ # Domain services
|- repositories/ # Data access layer
|- config/ # Configuration files
|- routes.rb # Application routes
```
## [PATTERN_NAME]
[PATTERN_EXPLANATION]
<!--
Add more sections related to architecture patterns, design decisions, and rationale as needed.
Pattern Example
===
## Service-Oriented Architecture (SOA)
This project follows a Service-Oriented Architecture (SOA) pattern to promote modularity and scalability. Each domain is encapsulated within its own service, allowing for independent development and deployment.
```ruby
# path: lib/domains/notification/services/send_email_service.rb
module Domains
module Notification
module Services
class SendEmailService
def initialize(user, message)
@user = user
@message = message
end
def call
# Logic to send email
end
end
end
end
end
```
- Use `#call` method to execute the service.
- Naming convention: `[Action]Service` for service classes.
- Place services under `lib/domains/[DOMAIN_NAME]/services/`.
-->

55
skills/spec-scaffold/templates/constitution.md Normal file
View File

@@ -0,0 +1,55 @@
---
version: [CONSTITUTION_VERSION]
ratified: [RATIFICATION_DATE]
lastAmended: [LAST_AMENDMENT_DATE]
---
<!-- Example: version: 2.1.1, ratified: 2025-10-21, lastAmended: 2025-10-21 -->
<!--
AMENDMENT REPORT
===
[SUMMARY_OF_CHANGES]
-->
# [PROJECT_NAME] Constitution
<!-- Example: Spec Constitution, TaskFlow Constitution, etc. -->
## Principles
### [PRINCIPLE_1_NAME]
<!-- Example: I. Test-First (NON-NEGOTIABLE) -->
[PRINCIPLE_1_DESCRIPTION]
<!-- Example: TDD mandatory: Tests written → User approved → Tests fail → Then implement; Red-Green-Refactor cycle strictly enforced -->
### [PRINCIPLE_2_NAME]
<!-- Example: II. Integration Testing -->
[PRINCIPLE_2_DESCRIPTION]
<!-- Example: Focus areas requiring integration tests: user-facing oriented over unit tests, making sure new features work end-to-end -->
### [PRINCIPLE_3_NAME]
<!-- Example: III. Simplicity and YAGNI -->
[PRINCIPLE_3_DESCRIPTION]
<!-- Example: Start simple and stupid, only implement what is necessary now; Incrementally enhance as needed -->
### [PRINCIPLE_4_NAME]
<!-- Example: IV. Cohesion over Coupling -->
[PRINCIPLE_4_DESCRIPTION]
<!-- Example: Group related functionality together as modules, libraries, or services; Use simple and clear interfaces for interaction -->
### [PRINCIPLE_5_NAME]
<!-- Example: V. Observability, VI. Versioning & Breaking Changes, VII. Convention over Configuration -->
[PRINCIPLE_5_DESCRIPTION]
<!-- Example: Structured logging required; Or: MAJOR.MINOR.BUILD format; Or: minimize configuration files by following conventions -->
## [SECTION_2_NAME]
<!-- Example: Other Requirements, Technical Standards, etc. -->
<!-- Omit if not applicable or not needed -->
[SECTION_2_CONTENT]
<!-- Example: Performance requirements, security standards, coding style guidelines, etc. -->
## Governance
<!-- Example: Approval processes, review requirements, compliance checks, etc. -->
[GOVERNANCE_RULES]
<!-- Example: All changes must be reviewed by at least two team members; Self-reviews before submission; All changes must pass CI tests before merging, the security review for sensitive modules, etc. -->

28
skills/spec-scaffold/templates/glossary.md Normal file
View File

@@ -0,0 +1,28 @@
Glossary
===
# Core
<!--
Glossary Table Template
===
| Term | Definition |
|--------------|-------------------------------------------------|
| User | An individual who interacts with the system. |
-->
| Term | Definition |
|--------------|-------------------------------------------------|
| [TERM] | [DEFINITION] |
<!--
Additional Sections
===
The additional sections is designed to domain-specific features. Each section should scope a particular domain or module within the project.
Do not create new sections unless user specifically requests it.
This usually happens in large projects with multiple domains, e.g. `User` has different meanings in `Authentication` and `Analytics` domains.
-->

31
skills/spec-scaffold/templates/roadmap.md Normal file
View File

@@ -0,0 +1,31 @@
Roadmap
===
# Core
<!--
Roadmap Table Template
===
| Updated At | Feature Name | Description | Status |
|------------|-----------------------------------------------------|-------------------------------------------------|-------------|
| 2024-01-15 | [User Authentication](./features/user-auth.spec.md) | Implement user login and registration features. | In Progress |
| 2024-02-10 | [Data Export](./features/data-export/spec.md) | Allow users to export their data in CSV format. | Planned |
Available Status:
- Planned: No any code implementation yet.
- In Progress: Code implementation is ongoing or new scenarios are being added/modified.
- Completed: Feature implementation is done and no more changes expected.
-->
| Updated At | Feature Name | Description | Status |
|--------------|----------------|---------------|----------|
| [UPDATED_AT] | [FEATURE_NAME] | [DESCRIPTION] | [STATUS] |
<!--
Additional Sections
===
The additional sections is designed to domain-specific features. Each section should scope a particular domain or module within the project.
Do not create new sections unless user specifically requests it.
-->

128
skills/spec-scaffold/templates/specification.md Normal file
View File

@@ -0,0 +1,128 @@
[FEATURE NAME]
===
**Created On:** [CREATION_DATE]
**Last Updated:** [LAST_UPDATED_DATE]
**Brief Description:** [BRIEF_DESCRIPTION]
## Purpose
<!--
Explain why this feature is needed and what problem it solves. And what value it delivers to users.
-->
[PURPOSE_DESCRIPTION]
## User Stories and Acceptance Criteria **(mandatory)**
<!--
IMPORTANT: User stories should be PRIORITIZED as user journeys ordered by importance.
Each story should be INDEPENDENTLY TESTABLE - meaning implementing ONE story at a time,
you should focus on delivering viable MVP (Minimum Viable Product) to produce value early and often.
Assign priorities (P1, P2, P3, etc.) to each story, where P1 is the most critical.
Think of each story as a standalone slice of functionality that can be:
- Developed independently
- Tested independently
- Deployed independently
- Demonstrated to users independently
-->
<!--
User Story Template
===
### User Story X - [BRIEF_TITLE] (Priority: PX)
**Priority Explanation:** [Explain why this priority was assigned]
**Value Deliveried:** [Describe how this story delivers value independently with testable outcomes]
```gherkin
A brief description of the user story.
Scenario: [Title of the scenario]
When [event occurs]
Then [ensure some outcomes]
Rule: [If any specific business rules apply which group multiple scenarios]
Scenario: [Title of another scenario]
Given [initial context]
When [event occurs]
Then [ensure some outcomes]
```
- Use `Background:` to define any common preconditions if needed.
- Use `Rule:` to define any specific business rules if needed.
- Use `Examples:` to provide data tables for scenarios if needed.
--->
### User Story 1 - [BRIEF_TITLE] (Priority: P1)
**Priority Explanation:** [Explain why this priority was assigned]
**Value Deliveried:** [Describe how this story delivers value independently with testable outcomes]
<!--
Use Gherkin style to define acceptance criteria for the user story.
-->
```gherkin
A brief description of the user story.
Background:
Given [initial context]
And [more initial context]
Scenario: [Title of the scenario]
When [event occurs]
Then [ensure some outcomes]
Scenario: [Title of another scenario]
Given [initial context]
When [event occurs]
Then [ensure some outcomes]
```
---
### User Story 2 - [BRIEF_TITLE] (Priority: P2)
**Priority Explanation:** [Explain why this priority was assigned]
**Value Deliveried:** [Describe how this story delivers value independently with testable outcomes]
```gherkin
A brief description of the user story.
Scenario: [Title of the scenario]
When [event occurs]
Then [ensure some outcomes]
```
---
### User Story 3 - [BRIEF_TITLE] (Priority: P3)
**Priority Explanation:** [Explain why this priority was assigned]
**Value Deliveried:** [Describe how this story delivers value independently with testable outcomes]
```gherkin
A brief description of the user story.
Scenario: [Title of the scenario]
Given [initial context]
When [event occurs]
Then [ensure some outcomes]
```
---
[Add more user stories as needed, following the same format]
## Unclarified Items
<!--
IMPORTANT: This section only include items which user allowed to be left unclear after asking for clarifications.
The edge cases not covered by existing information should be explicitly listed here for future resolution.
-->
- [NAME_OF_ITEM]: explanation of what is unclear and why.
- [NAME_OF_ITEM]: explanation of what is unclear and why.