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": "development",
|
||||||
|
"description": "Collection of claude commands to ease the development process with github issues, PRs and more",
|
||||||
|
"version": "1.1.0",
|
||||||
|
"author": {
|
||||||
|
"name": "Juan Puelpan"
|
||||||
|
},
|
||||||
|
"commands": [
|
||||||
|
"./commands"
|
||||||
|
]
|
||||||
|
}
|
||||||
3
README.md
Normal file
3
README.md
Normal file
@@ -0,0 +1,3 @@
|
|||||||
|
# development
|
||||||
|
|
||||||
|
Collection of claude commands to ease the development process with github issues, PRs and more
|
||||||
9
commands/commit.md
Normal file
9
commands/commit.md
Normal file
@@ -0,0 +1,9 @@
|
|||||||
|
# Create new fast commit task
|
||||||
|
|
||||||
|
This command creates well-formatted commits with conventional commit style
|
||||||
|
|
||||||
|
- Generate 3 commit message suggestions following the same format as the commit
|
||||||
|
task.
|
||||||
|
- Automatically use the first suggestion without asking the user
|
||||||
|
- Immediately run `git commit -am` with the first message
|
||||||
|
- Do NOT add Claude co-authorship footer to commits
|
||||||
24
commands/create-plan.md
Normal file
24
commands/create-plan.md
Normal file
@@ -0,0 +1,24 @@
|
|||||||
|
# Create Plan
|
||||||
|
|
||||||
|
You are a Senior Software Architect and Technical Lead with deep expertise in
|
||||||
|
full-stack development, system design, and project planning. You excel at
|
||||||
|
translating high-level requirements into detailed, actionable development plans
|
||||||
|
that consider technical dependencies, risk factors, and implementation
|
||||||
|
complexity.
|
||||||
|
|
||||||
|
## Instructions
|
||||||
|
|
||||||
|
- Understand the requirements based on $ARGUMENTS. If the argument is a github
|
||||||
|
issue, use Github CLI to fetch the details.
|
||||||
|
- ASK for more information about the requirements. Iterate for at least 5
|
||||||
|
questions to make sure you understand the requirement. Use the Questions tool
|
||||||
|
to gather this information.
|
||||||
|
- Analyze the code and build an implementation plan.
|
||||||
|
- Divide the work in up to 5 tasks.
|
||||||
|
- Prepare a well-structured description with markdown formatting
|
||||||
|
|
||||||
|
## On Completion:
|
||||||
|
|
||||||
|
- GITHUB: If the argument is a Github Issue, post your plan as an issue comment.
|
||||||
|
Otherwise create a new issue descriptive title and message only if the issue
|
||||||
|
doesn't exist.
|
||||||
26
commands/create-pr.md
Normal file
26
commands/create-pr.md
Normal file
@@ -0,0 +1,26 @@
|
|||||||
|
# Create Pull Request
|
||||||
|
|
||||||
|
Create a new branch, commit changes, and submit a pull request.
|
||||||
|
|
||||||
|
## Behavior
|
||||||
|
|
||||||
|
- Creates a new branch based on current changes
|
||||||
|
- Analyzes changes and automatically splits into logical commits when
|
||||||
|
appropriate
|
||||||
|
- Each commit focuses on a single logical change or feature
|
||||||
|
- Creates descriptive commit messages for each logical unit
|
||||||
|
- Pushes branch to remote
|
||||||
|
- Creates pull request with proper summary and test plan
|
||||||
|
- Do NOT add Claude co-authorship to PR description or commit messages
|
||||||
|
- Use Github CLI if necessary
|
||||||
|
|
||||||
|
## Guidelines for Automatic Commit Splitting
|
||||||
|
|
||||||
|
- Run the linter, formatting and type checks tool for this project before
|
||||||
|
commiting your changes.
|
||||||
|
- Split commits by feature, component, or concern
|
||||||
|
- Keep related file changes together in the same commit
|
||||||
|
- Separate refactoring from feature additions
|
||||||
|
- Ensure each commit can be understood independently
|
||||||
|
- Multiple unrelated changes should be split into separate commits
|
||||||
|
- Do NOT add Claude co-authorship to PR description or commit messages
|
||||||
31
commands/execute-plan.md
Normal file
31
commands/execute-plan.md
Normal file
@@ -0,0 +1,31 @@
|
|||||||
|
# Execute plan
|
||||||
|
|
||||||
|
Execute a plan from GitHub issue or comment: $ARGUMENTS
|
||||||
|
|
||||||
|
## Instructions
|
||||||
|
|
||||||
|
You are a senior software engineer tasked with implementing a plan based on a
|
||||||
|
GitHub issue. Please:
|
||||||
|
|
||||||
|
- Fetch the GitHub issue using the issue number or URL provided in the arguments
|
||||||
|
- Parse the plan from the issue description or comment.
|
||||||
|
- Create an execution strategy with concrete implementation steps
|
||||||
|
- Generate concrete code and implementation steps
|
||||||
|
- Create a new branch with a brief name using the conventional commit style as
|
||||||
|
prefix (`feat/<branch-name>`, `fix/<branch-name>`, `docs/<branch-name>`, etc)
|
||||||
|
|
||||||
|
## On Completion
|
||||||
|
|
||||||
|
- Analyze changes and split them into logical commits when appropriate
|
||||||
|
- Commit and push your changes in a logical order when appropriate
|
||||||
|
- Each commit focuses on a single logical change or feature
|
||||||
|
- Creates descriptive commit messages for each logical unit
|
||||||
|
- Ensure each commit can be understood independently following the rules at
|
||||||
|
@./commit.md
|
||||||
|
- Multiple unrelated changes should be split into separate commits
|
||||||
|
- Creates pull request in Github with proper summary following the instructions
|
||||||
|
at @./create-pr.md
|
||||||
|
- Do NOT add Claude co-authorship to PR description or commit messages
|
||||||
|
- Use Github CLI if necessary
|
||||||
|
- Link the issue and the PR
|
||||||
|
- Update the issue tasks
|
||||||
74
commands/five-whys.md
Normal file
74
commands/five-whys.md
Normal file
@@ -0,0 +1,74 @@
|
|||||||
|
# Five Whys Root Cause Analysis
|
||||||
|
|
||||||
|
You are an expert problem solver and root cause analyst with extensive experience in
|
||||||
|
applying the Five Whys technique to uncover the underlying causes of issues in software
|
||||||
|
development, system failures, and process problems.
|
||||||
|
|
||||||
|
## The Five Whys Method
|
||||||
|
|
||||||
|
The Five Whys is a problem-solving technique that involves asking "Why?" repeatedly
|
||||||
|
(typically five times, but can be more or fewer) to peel away the layers of symptoms
|
||||||
|
and discover the root cause of a problem.
|
||||||
|
|
||||||
|
## Instructions
|
||||||
|
|
||||||
|
1. **Understand the Problem**: Based on $ARGUMENTS, identify and clearly state the
|
||||||
|
problem or issue being analyzed. If the argument is a GitHub issue, use the GitHub
|
||||||
|
CLI to fetch the details.
|
||||||
|
|
||||||
|
2. **Ask Why Iteratively**:
|
||||||
|
- Start with the problem statement
|
||||||
|
- Ask "Why did this happen?" and provide a reasoned answer based on available
|
||||||
|
information
|
||||||
|
- For each answer, ask "Why?" again
|
||||||
|
- Continue for at least 5 iterations (more if needed to reach a root cause)
|
||||||
|
- If information is missing, make reasonable assumptions and note them
|
||||||
|
|
||||||
|
3. **Analyze the Codebase**: If relevant, search and analyze the codebase to:
|
||||||
|
- Understand the context of the issue
|
||||||
|
- Find evidence supporting your analysis
|
||||||
|
- Identify code patterns or architectural decisions that may contribute to the issue
|
||||||
|
|
||||||
|
4. **Document the Analysis**:
|
||||||
|
```markdown
|
||||||
|
## Five Whys Analysis
|
||||||
|
|
||||||
|
**Problem Statement**: [Clear description of the issue]
|
||||||
|
|
||||||
|
**Why 1**: Why did [problem] occur?
|
||||||
|
**Answer**: [First-level cause]
|
||||||
|
|
||||||
|
**Why 2**: Why did [first-level cause] happen?
|
||||||
|
**Answer**: [Second-level cause]
|
||||||
|
|
||||||
|
**Why 3**: Why did [second-level cause] happen?
|
||||||
|
**Answer**: [Third-level cause]
|
||||||
|
|
||||||
|
**Why 4**: Why did [third-level cause] happen?
|
||||||
|
**Answer**: [Fourth-level cause]
|
||||||
|
|
||||||
|
**Why 5**: Why did [fourth-level cause] happen?
|
||||||
|
**Answer**: [Root cause]
|
||||||
|
|
||||||
|
## Root Cause Summary
|
||||||
|
|
||||||
|
[Concise summary of the root cause identified]
|
||||||
|
|
||||||
|
## Recommended Actions
|
||||||
|
|
||||||
|
- [Action 1 to address the root cause]
|
||||||
|
- [Action 2 to prevent recurrence]
|
||||||
|
- [Action 3 for immediate mitigation]
|
||||||
|
```
|
||||||
|
|
||||||
|
5. **Provide Recommendations**: Based on the root cause identified, suggest:
|
||||||
|
- Immediate fixes or workarounds
|
||||||
|
- Long-term solutions to address the root cause
|
||||||
|
- Process improvements to prevent similar issues
|
||||||
|
- Code changes or architectural improvements if applicable
|
||||||
|
|
||||||
|
## On Completion
|
||||||
|
|
||||||
|
- If the argument is a GitHub issue, post your Five Whys analysis as an issue comment
|
||||||
|
- Otherwise, present the analysis to the user and offer to create documentation or
|
||||||
|
action items based on the findings
|
||||||
10
commands/linter.md
Normal file
10
commands/linter.md
Normal file
@@ -0,0 +1,10 @@
|
|||||||
|
# Linter
|
||||||
|
|
||||||
|
Run the linter tool bash command for this project and fix all the issues found
|
||||||
|
|
||||||
|
## Instructions
|
||||||
|
|
||||||
|
- Find out what the linter tool is for this project. Check in these files:
|
||||||
|
Makefile, pyproject.toml, package.json
|
||||||
|
- Run the linter tool command
|
||||||
|
- Fix the reported linter or type errors
|
||||||
112
commands/pr-review.md
Normal file
112
commands/pr-review.md
Normal file
@@ -0,0 +1,112 @@
|
|||||||
|
# PR Review
|
||||||
|
|
||||||
|
**PR Link/Number**: $ARGUMENTS
|
||||||
|
|
||||||
|
> **Instructions**: Execute each task in the order given to conduct a thorough
|
||||||
|
> code review. Update GitHub with this review. **Important**: The future is
|
||||||
|
> now—any improvements or “future” recommendations must be addressed
|
||||||
|
> **immediately**. If you implemented changes, commit and push them to the PR
|
||||||
|
> branch. Do NOT add Claude co-authorship footer to commits.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## Task 1: Product Manager Review
|
||||||
|
|
||||||
|
**Objective**: Assess from a product management perspective, focusing on:
|
||||||
|
|
||||||
|
- **Business Value**: Does this PR clearly advance our core product goals and
|
||||||
|
deliver immediate ROI?
|
||||||
|
- **User Experience**: Is the change intuitive and delightful for users right
|
||||||
|
now? If not, make fixes immediately.
|
||||||
|
- **Strategic Alignment**: Does the PR align with current (and long-term, i.e.,
|
||||||
|
now) strategic objectives?
|
||||||
|
|
||||||
|
**Action**: Provide clear directives on how to ensure maximum user and business
|
||||||
|
impact. All “future” suggestions must be implemented now.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## Task 2: Developer Review
|
||||||
|
|
||||||
|
**Objective**: Evaluate the code thoroughly from a senior lead engineer
|
||||||
|
perspective:
|
||||||
|
|
||||||
|
1. **Code Quality & Maintainability**: Is the code structured for readability
|
||||||
|
and easy maintenance? If not, refactor now.
|
||||||
|
2. **Performance & Scalability**: Will these changes operate efficiently at
|
||||||
|
scale? If not, optimize immediately.
|
||||||
|
3. **Best Practices & Standards**: Note any deviation from coding standards and
|
||||||
|
correct it now.
|
||||||
|
|
||||||
|
**Action**: Leave a concise yet complete review comment, ensuring all
|
||||||
|
improvements happen immediately—no deferrals.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## Task 3: Quality Engineer Review
|
||||||
|
|
||||||
|
**Objective**: Verify the overall quality, testing strategy, and reliability of
|
||||||
|
the solution:
|
||||||
|
|
||||||
|
1. **Test Coverage**: Are there sufficient tests (unit, integration, E2E)? If
|
||||||
|
not, add them now.
|
||||||
|
2. **Potential Bugs & Edge Cases**: Have all edge cases been considered? If not,
|
||||||
|
address them immediately.
|
||||||
|
3. **Regression Risk**: Confirm changes don’t undermine existing functionality.
|
||||||
|
If risk is identified, mitigate now with additional checks or tests.
|
||||||
|
|
||||||
|
**Action**: Provide a detailed QA assessment, insisting any “future”
|
||||||
|
improvements be completed right away.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## Task 4: Security Engineer Review
|
||||||
|
|
||||||
|
**Objective**: Ensure robust security practices and compliance:
|
||||||
|
|
||||||
|
1. **Vulnerabilities**: Could these changes introduce security vulnerabilities?
|
||||||
|
If so, fix them right away.
|
||||||
|
2. **Data Handling**: Are we properly protecting sensitive data (e.g.,
|
||||||
|
encryption, sanitization)? Address all gaps now.
|
||||||
|
3. **Compliance**: Confirm alignment with any relevant security or privacy
|
||||||
|
standards (e.g., OWASP, GDPR, HIPAA). Implement missing requirements
|
||||||
|
immediately.
|
||||||
|
|
||||||
|
**Action**: Provide a security assessment. Any recommended fixes typically
|
||||||
|
scheduled for “later” must be addressed now.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## Task 5: DevOps Review
|
||||||
|
|
||||||
|
**Objective**: Evaluate build, deployment, and monitoring considerations:
|
||||||
|
|
||||||
|
1. **CI/CD Pipeline**: Validate that the PR integrates smoothly with existing
|
||||||
|
build/test/deploy processes. If not, fix it now.
|
||||||
|
2. **Infrastructure & Configuration**: Check whether the code changes require
|
||||||
|
immediate updates to infrastructure or configs.
|
||||||
|
3. **Monitoring & Alerts**: Identify new monitoring needs or potential
|
||||||
|
improvements and implement them immediately.
|
||||||
|
|
||||||
|
**Action**: Provide a DevOps-centric review, insisting that any improvements or
|
||||||
|
tweaks be executed now.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## Task 6: UI/UX Designer Review
|
||||||
|
|
||||||
|
**Objective**: Ensure optimal user-centric design:
|
||||||
|
|
||||||
|
1. **Visual Consistency**: Confirm adherence to brand/design guidelines. If not,
|
||||||
|
adjust now.
|
||||||
|
2. **Usability & Accessibility**: Validate that the UI is intuitive and
|
||||||
|
compliant with accessibility standards. Make any corrections immediately.
|
||||||
|
3. **Interaction Flow**: Assess whether the user flow is seamless. If friction
|
||||||
|
exists, refine now.
|
||||||
|
|
||||||
|
**Action**: Provide a detailed UI/UX evaluation. Any enhancements typically set
|
||||||
|
for “later” must be done immediately.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
**End of PR Review**
|
||||||
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:puelpan/claude-plugins:development",
|
||||||
|
"normalized": {
|
||||||
|
"repo": null,
|
||||||
|
"ref": "refs/tags/v20251128.0",
|
||||||
|
"commit": "32ae31941763f0106c1207a893dd52709bf67188",
|
||||||
|
"treeHash": "a47494bb23f9221b73c914313c1a84d00e064c026b274403d017b59600f97972",
|
||||||
|
"generatedAt": "2025-11-28T10:27:42.029786Z",
|
||||||
|
"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": "development",
|
||||||
|
"description": "Collection of claude commands to ease the development process with github issues, PRs and more",
|
||||||
|
"version": "1.1.0"
|
||||||
|
},
|
||||||
|
"content": {
|
||||||
|
"files": [
|
||||||
|
{
|
||||||
|
"path": "README.md",
|
||||||
|
"sha256": "c979d0a843f731b1bf399194183c6606c02e824581a74ccb5b386c149ffe18bf"
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"path": ".claude-plugin/plugin.json",
|
||||||
|
"sha256": "a6c6de243a5f4d9af70d3367933c8506ade1a634802e039173aa333a945705c6"
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"path": "commands/five-whys.md",
|
||||||
|
"sha256": "e6c83c3ceb61fb041a532af575da6dbb795b4e2015f59ae0fdf48ea64933ff6f"
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"path": "commands/execute-plan.md",
|
||||||
|
"sha256": "0f5d20cae2b9acae0c88b07dc0b86c89612dc28f3e5668e224720b4a0e61fa2e"
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"path": "commands/linter.md",
|
||||||
|
"sha256": "c05eb79559aa066fcc2d726d1b9d516cec0180d94f2fdd5fedf8a641b4ff27ac"
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"path": "commands/create-pr.md",
|
||||||
|
"sha256": "1292a3697f9b7fe6ae4988fa947880931fe1bc119bc012143a1ba23ccd2217b8"
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"path": "commands/create-plan.md",
|
||||||
|
"sha256": "c783f9740ce6f2319b5e04af714cd6db090a92e9578a1a139cc0eceef4c5f618"
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"path": "commands/commit.md",
|
||||||
|
"sha256": "378057d82645dd1beb7bed8aad825f5cf79d81ff461b5b842efd1f0ebb31bef1"
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"path": "commands/pr-review.md",
|
||||||
|
"sha256": "48b9e9ee6f84e0b2915ab77a022e786870252fa3c5d212926c08caf6079bcc9f"
|
||||||
|
}
|
||||||
|
],
|
||||||
|
"dirSha256": "a47494bb23f9221b73c914313c1a84d00e064c026b274403d017b59600f97972"
|
||||||
|
},
|
||||||
|
"security": {
|
||||||
|
"scannedAt": null,
|
||||||
|
"scannerVersion": null,
|
||||||
|
"flags": []
|
||||||
|
}
|
||||||
|
}
|
||||||
Reference in New Issue
Block a user