Initial commit

This commit is contained in:
Zhongwei Li
2025-11-30 08:57:15 +08:00
commit 61d1e720d8
6 changed files with 187 additions and 0 deletions

View File

@@ -0,0 +1,12 @@
{
"name": "dev",
"description": "Development and testing tools",
"version": "0.0.1",
"author": {
"name": "Kento Shirasawa",
"email": "shirasawa@novalumo.com"
},
"commands": [
"./commands"
]
}

3
README.md Normal file
View File

@@ -0,0 +1,3 @@
# dev
Development and testing tools

14
commands/commit.md Normal file
View File

@@ -0,0 +1,14 @@
# Commit
Commit changes to the repository.
## Rules
- Use English for commit messages except for specific terms that are better left untranslated.
- Follow the Conventional Commits specification.
- Use the format `type(scope): description` for commit messages.
- Use `fix`, `feat`, `chore`, `docs`, `style`, `refactor`, `test`, `perf`, and `build` as types.
- Use `scope` to indicate the area of the codebase affected by the change.
- Ensure that the commit message is clear and concise.
- Include relevant issue references in the commit message if applicable (e.g., `Fixes #123`).
- Avoid committing large changes in a single commit; break down into logical units.

97
commands/orchestrator.md Normal file
View File

@@ -0,0 +1,97 @@
# Orchestrator
Split complex tasks into sequential steps, where each step can contain multiple parallel subtasks.
## Process
1. **Initial Analysis**
- First, analyze the entire task to understand scope and requirements
- Identify dependencies and execution order
- Plan sequential steps based on dependencies
2. **Step Planning**
- Break down into 2-4 sequential steps
- Each step can contain multiple parallel subtasks
- Define what context from previous steps is needed
3. **Step-by-Step Execution**
- Execute all subtasks within a step in parallel
- Wait for all subtasks in current step to complete
- Pass relevant results to next step
- Request concise summaries (100-200 words) from each subtask
4. **Step Review and Adaptation**
- After each step completion, review results
- Validate if remaining steps are still appropriate
- Adjust next steps based on discoveries
- Add, remove, or modify subtasks as needed
5. **Progressive Aggregation**
- Synthesize results from completed step
- Use synthesized results as context for next step
- Build comprehensive understanding progressively
- Maintain flexibility to adapt plan
## Example Usage
When given "analyze test lint and commit":
**Step 1: Initial Analysis** (1 subtask)
- Analyze project structure to understand test/lint setup
**Step 2: Quality Checks** (parallel subtasks)
- Run tests and capture results
- Run linting and type checking
- Check git status and changes
**Step 3: Fix Issues** (parallel subtasks, using Step 2 results)
- Fix linting errors found in Step 2
- Fix type errors found in Step 2
- Prepare commit message based on changes
_Review: If no errors found in Step 2, skip fixes and proceed to commit_
**Step 4: Final Validation** (parallel subtasks)
- Re-run tests to ensure fixes work
- Re-run lint to verify all issues resolved
- Create commit with verified changes
_Review: If Step 3 had no fixes, simplify to just creating commit_
## Key Benefits
- **Sequential Logic**: Steps execute in order, allowing later steps to use earlier results
- **Parallel Efficiency**: Within each step, independent tasks run simultaneously
- **Memory Optimization**: Each subtask gets minimal context, preventing overflow
- **Progressive Understanding**: Build knowledge incrementally across steps
- **Clear Dependencies**: Explicit flow from analysis → execution → validation
## Implementation Notes
- Always start with a single analysis task to understand the full scope
- Group related parallel tasks within the same step
- Pass only essential findings between steps (summaries, not full output)
- Use TodoWrite to track both steps and subtasks for visibility
- After each step, explicitly reconsider the plan:
- Are the next steps still relevant?
- Did we discover something that requires new tasks?
- Can we skip or simplify upcoming steps?
- Should we add new validation steps?
## Adaptive Planning Example
```
Initial Plan: Step 1 → Step 2 → Step 3 → Step 4
After Step 2: "No errors found in tests or linting"
Adapted Plan: Step 1 → Step 2 → Skip Step 3 → Simplified Step 4 (just commit)
After Step 2: "Found critical architectural issue"
Adapted Plan: Step 1 → Step 2 → New Step 2.5 (analyze architecture) → Modified Step 3
```

8
commands/refactor.md Normal file
View File

@@ -0,0 +1,8 @@
# Refactoring Suggestions for Project
Review the structure and content of this project and provide specific refactoring suggestions. Pay attention to the following points when making your proposals:
1. **Code Readability**: Check whether the code is readable and easy to understand. Verify if variable names, function names, and class names are appropriate, and if comments are adequately provided.
2. **Code Reusability**: Consider whether there is duplicated code and if common processes can be consolidated into functions or classes.
3. **Performance**: Check for areas where code execution speed or memory usage can be improved.
4. **Test Coverage**: Verify whether unit tests and integration tests are sufficiently covered, and if any necessary tests are missing.

53
plugin.lock.json Normal file
View File

@@ -0,0 +1,53 @@
{
"$schema": "internal://schemas/plugin.lock.v1.json",
"pluginId": "gh:siraken/claude-plugins:dev",
"normalized": {
"repo": null,
"ref": "refs/tags/v20251128.0",
"commit": "0e6c1145a3f986d5fbfb7bb7443298b3b83a9ce2",
"treeHash": "233b5ab772d4b119084dfb06787943e6efb82d642ac3c70e6a22edf95b020065",
"generatedAt": "2025-11-28T10:28:21.327246Z",
"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": "dev",
"description": "Development and testing tools",
"version": "0.0.1"
},
"content": {
"files": [
{
"path": "README.md",
"sha256": "c7a40452b6f55db094bf7e7e02cdc6b932cb1c362f2498e4d3e3fe1257bfc5cb"
},
{
"path": ".claude-plugin/plugin.json",
"sha256": "354783f02d827612970639814df67113ae19795ade03c18151fce6ae9545af8d"
},
{
"path": "commands/orchestrator.md",
"sha256": "12a7e6c2f02aba940db913e97df7547ae906c6e5f6cc0edb25ce539bf7eb6141"
},
{
"path": "commands/refactor.md",
"sha256": "7db6964f972d2579b5329673109a72467dcd043a7b4d29897a839a2e082da6c4"
},
{
"path": "commands/commit.md",
"sha256": "d8b9c5414d14cd770597fa6f6eca6ce88bfd73d2c4ba5a6916f2ae0e9c429cae"
}
],
"dirSha256": "233b5ab772d4b119084dfb06787943e6efb82d642ac3c70e6a22edf95b020065"
},
"security": {
"scannedAt": null,
"scannerVersion": null,
"flags": []
}
}