Initial commit
This commit is contained in:
Zhongwei Li
92
commands/commit.md
Normal file
92
commands/commit.md
Normal file
@@ -0,0 +1,92 @@
|
||||
---
|
||||
description: Generate conventional commit message from staged changes
|
||||
argument-hint: [type] [scope] [--breaking]
|
||||
allowed-tools: Bash(git:*)
|
||||
model: haiku
|
||||
---
|
||||
|
||||
## Context
|
||||
|
||||
**Current git status:**
|
||||
!`git status`
|
||||
|
||||
**Staged changes:**
|
||||
!`git diff --cached --stat`
|
||||
|
||||
**Diff details:**
|
||||
!`git diff --cached`
|
||||
|
||||
**Recent commits for style reference:**
|
||||
!`git log -5 --oneline`
|
||||
|
||||
## Instructions
|
||||
|
||||
Analyze the staged changes and create a commit message following this structure:
|
||||
|
||||
```
|
||||
<type>[optional scope]: <description>
|
||||
|
||||
[optional body]
|
||||
|
||||
[optional footer(s)]
|
||||
```
|
||||
|
||||
### Commit Types
|
||||
|
||||
Use these standard types based on the changes:
|
||||
|
||||
- **feat**: New feature for the user (correlates to MINOR in semantic versioning)
|
||||
- **fix**: Bug fix for the user (correlates to PATCH)
|
||||
- **docs**: Documentation only changes
|
||||
- **style**: Changes that don't affect code meaning (white-space, formatting, missing semi-colons)
|
||||
- **refactor**: Code change that neither fixes a bug nor adds a feature
|
||||
- **perf**: Code change that improves performance
|
||||
- **test**: Adding missing tests or correcting existing tests
|
||||
- **build**: Changes to build system or external dependencies
|
||||
- **ci**: Changes to CI configuration files and scripts
|
||||
- **chore**: Other changes that don't modify src or test files
|
||||
- **revert**: Reverts a previous commit
|
||||
|
||||
### Requirements
|
||||
|
||||
1. **Type**: MUST be one of the types above
|
||||
2. **Scope**: OPTIONAL, indicates what part of codebase is affected (e.g., `parser`, `api`, `ui`)
|
||||
3. **Description**: REQUIRED, short summary in present tense, lowercase, no period at end
|
||||
4. **Body**: OPTIONAL, provides additional context. Use when:
|
||||
- Changes are non-trivial
|
||||
- Multiple files or concerns are affected
|
||||
- Implementation details would help reviewers
|
||||
5. **Footer**: OPTIONAL, used for:
|
||||
- Breaking changes: `BREAKING CHANGE: <description>`
|
||||
- Issue references: `Fixes #123`, `Closes #456`
|
||||
- Co-authors: `Co-authored-by: Name <email>`
|
||||
|
||||
### Breaking Changes
|
||||
|
||||
If changes include breaking changes, indicate via:
|
||||
|
||||
- Add `!` after type/scope: `feat(api)!: remove deprecated endpoints`
|
||||
- OR add footer: `BREAKING CHANGE: API v1 endpoints removed`
|
||||
|
||||
### Best Practices
|
||||
|
||||
- Keep description under 50 characters when possible
|
||||
- Use imperative mood: "add feature" not "added feature" or "adds feature"
|
||||
- Don't capitalize first letter of description
|
||||
- No period at end of description
|
||||
- Separate body from description with blank line
|
||||
- Wrap body at 72 characters
|
||||
- Explain what and why, not how
|
||||
- Reference issues and PRs in footer
|
||||
|
||||
### Output Format
|
||||
|
||||
Provide the commit message in a code block that can be copied directly. Include explanation of your choices below the commit message.
|
||||
|
||||
**Arguments**:
|
||||
|
||||
- If $ARGUMENTS provided, use them as guidance (e.g., "/commit feat auth" suggests feat type with auth scope)
|
||||
- If "--breaking" flag present, ensure breaking change is indicated
|
||||
- Otherwise, analyze changes automatically
|
||||
|
||||
Generate the commit message now.
|
||||
115
commands/implementation-plan.md
Normal file
115
commands/implementation-plan.md
Normal file
@@ -0,0 +1,115 @@
|
||||
---
|
||||
description: Create a comprehensive strategic plan with structured task breakdown
|
||||
argument-hint: Describe what you need planned (e.g., "refactor authentication system", "implement microservices")
|
||||
---
|
||||
|
||||
# Implementation Plan Command
|
||||
|
||||
You are analyzing a ticket and creating a detailed implementation plan. This is a planning phase in the SDLC workflow.
|
||||
|
||||
## Process
|
||||
|
||||
Think deep and follow these steps systematically:
|
||||
|
||||
### 1. TICKET ANALYSIS
|
||||
|
||||
- Extract key requirements, acceptance criteria, and constraints from the ticket
|
||||
- Identify the core problem/feature being requested
|
||||
- List any ambiguities or missing information and ask questions to avoid asumptions
|
||||
- State explicit assumptions for any gaps
|
||||
|
||||
### 2. CODEBASE DISCOVERY
|
||||
|
||||
- Search for relevant files, components, and modules related to the ticket
|
||||
- Identify existing patterns and conventions in the codebase
|
||||
- Map dependencies and integration points
|
||||
- Note any existing tests or documentation
|
||||
|
||||
### 3. TECHNICAL DESIGN
|
||||
|
||||
- Propose the technical approach with clear rationale
|
||||
- Identify files that need to be created, modified, or deleted
|
||||
- Define data models, APIs, or interfaces if applicable
|
||||
- Consider error handling, edge cases, and validation
|
||||
- Address security, performance, and scalability implications
|
||||
- If the solution will be reused across multiple features or projects, develop and thoroughly test the initial implementation before adapting and rolling it out to other areas.
|
||||
|
||||
### 4. IMPLEMENTATION BREAKDOWN
|
||||
|
||||
Create detailed to-do items with:
|
||||
|
||||
- Clear, actionable task descriptions
|
||||
- Logical ordering with dependencies marked
|
||||
- Estimated complexity (simple/moderate/complex)
|
||||
- Files affected per task
|
||||
- Any prerequisite setup or configuration
|
||||
|
||||
### 5. RISK & IMPACT ANALYSIS
|
||||
|
||||
- Breaking changes or backward compatibility concerns
|
||||
- Testing strategy (unit, integration, e2e)
|
||||
- Database migrations or data transformations
|
||||
- Deployment considerations
|
||||
- Rollback plan if needed
|
||||
|
||||
### 6. ALTERNATIVES CONSIDERED
|
||||
|
||||
- Present at least one alternative approach
|
||||
- Compare trade-offs (complexity, time, maintainability)
|
||||
- Justify the recommended approach
|
||||
|
||||
## Output Format
|
||||
|
||||
Provide your analysis in this structure:
|
||||
|
||||
**[TICKET SUMMARY]**
|
||||
|
||||
- Brief overview of the request
|
||||
- Key requirements (bulleted)
|
||||
- Assumptions made, but ask questions to avoid them.
|
||||
|
||||
**[CODEBASE ANALYSIS]**
|
||||
|
||||
- Relevant files and their roles
|
||||
- Existing patterns to follow
|
||||
- Integration points
|
||||
|
||||
**[TECHNICAL APPROACH]**
|
||||
|
||||
- Recommended solution with rationale
|
||||
- Architecture/design decisions
|
||||
- Key trade-offs
|
||||
|
||||
**[IMPLEMENTATION PLAN]**
|
||||
Detailed to-do list:
|
||||
|
||||
1. Task name [complexity] — files affected, brief description
|
||||
2. Task name [complexity] — files affected, brief description
|
||||
...
|
||||
|
||||
**[TESTING STRATEGY]**
|
||||
|
||||
- Test scenarios to cover
|
||||
- Testing approach per layer
|
||||
|
||||
**[RISKS & MITIGATIONS]**
|
||||
|
||||
- Identified risks with mitigation strategies
|
||||
- Rollback approach
|
||||
|
||||
**[ALTERNATIVES]**
|
||||
|
||||
- Alternative approach(es) with when to prefer them
|
||||
|
||||
## Quality Standards
|
||||
|
||||
- Be decisive and assertive in recommendations
|
||||
- Reference specific file paths and symbols from the codebase
|
||||
- Don't fabricate—if uncertain about an API or pattern, note it
|
||||
- Optimize for shipping value quickly with the simplest workable solution
|
||||
- Consider repository conventions and existing patterns
|
||||
- Minimum back-and-forth: make explicit assumptions and proceed
|
||||
|
||||
## Usage
|
||||
|
||||
**Now analyze the provided ticket and create the implementation plan following the process above.**
|
||||
Reference in New Issue
Block a user