Initial commit

This commit is contained in:
Zhongwei Li
2025-11-30 08:40:59 +08:00
commit fd99ef421d
11 changed files with 281 additions and 0 deletions

View File

@@ -0,0 +1,22 @@
{
"name": "code",
"description": "Code quality tools for comment cleanup and emoji enhancement",
"version": "0.18.0",
"author": {
"name": "Craig Motlin"
},
"skills": [
"./skills/code-quality/SKILL.md",
"./skills/comment-cleanup/SKILL.md",
"./skills/testing/SKILL.md",
"./skills/cli/SKILL.md"
],
"agents": [
"./agents/comment-cleaner.md"
],
"commands": [
"./commands/comments.md",
"./commands/all-comments.md",
"./commands/emoji.md"
]
}

3
README.md Normal file
View File

@@ -0,0 +1,3 @@
# code
Code quality tools for comment cleanup and emoji enhancement

41
agents/comment-cleaner.md Normal file
View File

@@ -0,0 +1,41 @@
---
name: comment-cleaner
description: This agent should be invoked after making code changes and before running the build or committing. It removes redundant, obvious, or outdated comments while preserving important ones like TODOs and linter directives.\n\n<example>\nContext: The user has fixed a bug and the code contains old commented-out debugging code.\nuser: "I've fixed the null pointer exception in the payment processor"\nassistant: "Good work fixing that bug. Now let me clean up the comments before we commit."\n<commentary>\nAfter bug fixes, there are often commented-out debug statements or old code. Use the comment-cleaner agent to clean these up.\n</commentary>\nassistant: "I'll run the comment-cleaner agent to remove any commented-out code and redundant comments"\n</example>\n\n<example>\nContext: The user has refactored code and there are comments describing old behavior.\nuser: "I've refactored the data processing pipeline to use the new async pattern"\nassistant: "The refactoring looks complete. Let me clean up the comments next."\n<commentary>\nRefactoring often leaves behind comments about old implementations. Use the comment-cleaner agent to remove these outdated comments.\n</commentary>\nassistant: "I'll use the comment-cleaner agent to remove any comments that describe the old synchronous implementation"\n</example>
model: haiku
color: cyan
---
🧹 Remove redundant and unnecessary comments from code.
Your role is to review code that is about to be committed and remove reundant and unnecessary comments that the LLM added while making changes.
## Comments to Remove:
- Delete any code that has been commented out
- Edit history comments - Remove comments containing past-tense verbs like "added", "removed", "changed", "updated", "modified"
- Delete comments that merely restate what the code clearly does (e.g., `// increment counter` above `counter++`)
- Remove comments that just repeat the method name in different words
## Comments to Preserve:
- Never remove comments starting with TODO, FIXME, or similar markers
- Keep comments like `// eslint-disable`, `// prettier-ignore`, `// @ts-ignore`, etc.
- Preserve comments that explain non-obvious logic or business rules
- Don't remove comments if doing so would leave empty scopes (empty catch blocks, else blocks, etc.)
- Comments that already existed before our work
## Comments to move
- End-of-line comments - These should be moved to their own line above the code they describe
- Place the comment on its own line immediately above the code it describes
- Maintain the same indentation level as the code below it
## Workflow
- Look at all comments in the uncommitted changes
- It's not enough to consider all changed files because we don't want to remove old comments
- Consider the whole diff/patch to make sure we're only removing new comments
- Remove redundant comments without hesitation
- Move end-of-line comments to their own lines
Focus only on comment cleanup - do not modify the actual code logic, only comments. After your cleanup, the code should be ready for a clean commit without clutter from development artifacts or obvious explanations.

7
commands/all-comments.md Normal file
View File

@@ -0,0 +1,7 @@
---
description: Remove obvious and redundant comments from all files
---
🧹 Remove obvious and redundant comments from all files in the codebase.
@../shared/comment-removal-rules.md

9
commands/comments.md Normal file
View File

@@ -0,0 +1,9 @@
---
description: Remove obvious and redundant comments from uncommitted changes
---
🧹 Remove obvious and redundant comments from uncommitted code changes.
📍 Only consider and only edit local code changes that are not yet committed to git.
@../shared/comment-removal-rules.md

25
commands/emoji.md Normal file
View File

@@ -0,0 +1,25 @@
---
argument-hint: file or content to enhance
description: Add appropriate emoji to make content more engaging
---
😊 Add appropriate emoji to the content we're working on to make it more engaging and easier to scan.
$ARGUMENTS
## 📍 Placement
- Add emoji at the beginning of headers before the text
- Include emoji in lists and navigation elements
- Code comments
## 🔄 Two-pass approach
1. First pass: Add the most fitting emoji for each element
2. Second pass: Replace duplicates with suitable alternatives
# 🎯 Patterns for consistency
- Match emoji to content's tone and purpose (🎉 celebrations, 🔧 technical, 📚 documentation)
- Use emoji for status indicators (✅ complete, ⏳ in progress, ❌ error, ⚠️ warning)
- Establish patterns for consistency (📝 for "Notes", 🔗 for "Links", etc.)

73
plugin.lock.json Normal file
View File

@@ -0,0 +1,73 @@
{
"$schema": "internal://schemas/plugin.lock.v1.json",
"pluginId": "gh:motlin/claude-code-plugins:plugins/code",
"normalized": {
"repo": null,
"ref": "refs/tags/v20251128.0",
"commit": "c49c2062761f4b4b23537a145e15aa6a5b95fec5",
"treeHash": "bd326a6c3afff600a8ca32a128b86f830426855d1ea1ab48d09cefb21e554dc4",
"generatedAt": "2025-11-28T10:27:09.686250Z",
"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": "code",
"description": "Code quality tools for comment cleanup and emoji enhancement",
"version": "0.18.0"
},
"content": {
"files": [
{
"path": "README.md",
"sha256": "da625c632e9fae19aa5805904c5c14384b28b93aa17652319ce44c946f13867d"
},
{
"path": "agents/comment-cleaner.md",
"sha256": "ca790ad2c2bb48b04669a511ac82324332000a54d2f9ade4ccace6573adbc413"
},
{
"path": ".claude-plugin/plugin.json",
"sha256": "f146bf5fb2ebe5f394e54853af8511d92241defc75f722c68113aaa1fa7f8273"
},
{
"path": "commands/comments.md",
"sha256": "03972b934aac3eb1b1907c21eb7e2a1dd9201fab9723e37e57eee0fb5f70938c"
},
{
"path": "commands/all-comments.md",
"sha256": "ec8c1a3d03867e8aae13c69623781b4f7da714e0f42617960118da0729f467e8"
},
{
"path": "commands/emoji.md",
"sha256": "66850d849167082959bea4413f95f19c0fad53680379f41a80a8109fce5ba87f"
},
{
"path": "skills/cli/SKILL.md",
"sha256": "2aaa7ed584803b1d25f14f91a9c97a2c6d2ec0ca5010ba4ff8fba2c32162759d"
},
{
"path": "skills/testing/SKILL.md",
"sha256": "5f350092120e5cf1ca2b7914b73d5fb6e6eaf2e7ffe376f8aa0ec181c9cf0bba"
},
{
"path": "skills/comment-cleanup/SKILL.md",
"sha256": "581d48a16774b3ff946e21b1dc538b2e563fbf5b73c58ceba2ba3b955dec1a31"
},
{
"path": "skills/code-quality/SKILL.md",
"sha256": "7fa9335f57221830e1e4c4add0fa665089dd7ef06652f6708652ac1f70681f44"
}
],
"dirSha256": "bd326a6c3afff600a8ca32a128b86f830426855d1ea1ab48d09cefb21e554dc4"
},
"security": {
"scannedAt": null,
"scannerVersion": null,
"flags": []
}
}

22
skills/cli/SKILL.md Normal file
View File

@@ -0,0 +1,22 @@
---
name: cli
description: CLI guidelines. Use whenever using the Bash tool, which is almost always. Also use when you see "command not found: __zoxide_z" errors.
---
# CLI Guidelines
## Directory Navigation
- I replaced `cd` with `zoxide`. Use `command cd` to change directories
- This is the only command that needs to be prefixed with `command`
- Don't prefix `git` with `command git`
- Try not to use `cd` or `zoxide` at all. It's usually not necessary with CLI commands
- Don't run `cd <dir> && git <subcommand>`
- Prefer `git -C <dir> <subcommand>`
## Flag Names
Prefer long flag names when available:
- Don't run `git commit -m`
- Run `git commit --message` instead

View File

@@ -0,0 +1,34 @@
---
name: code-quality
description: Code quality guidelines. ALWAYS use skill for ANY code changes.
---
# Code Quality Guidelines
## Don't write forgiving code
- Don't permit multiple input formats
- In TypeScript, this means avoiding Union Type (the `|` in types)
- Use preconditions
- Use schema libraries
- Assert that inputs match expected formats
- When expectations are violated, throw, don't log
- Don't add defensive try/catch blocks
- Usually we let exceptions propagate out
- Don't keep legacy code paths as fallbacks
- Remove old code instead of keeping it around for compatibility
## Naming Conventions
- Don't use abbreviations or acronyms
- Choose `number` instead of `num` and `greaterThan` instead of `gt`
## File Management
- Prefer editing an existing file to creating a new one
- Confirm with the user before creating any new markdown files
## Style
- Emoji and unicode characters are welcome
- Use them at the beginning of comments, commit messages, and in headers in docs

View File

@@ -0,0 +1,17 @@
---
name: comment-cleanup
description: Guidelines for comments in code. Use when adding, editing, or removing comments.
---
# Comment Guidelines
- Use comments sparingly
- Don't comment out code
- Remove it instead
- Don't add comments that describe the process of changing code
- Comments should not include past tense verbs like added, removed, or changed
- Example: `this.timeout(10_000); // Increase timeout for API calls`
- This is bad because a reader doesn't know what the timeout was increased from, and doesn't care about the old behavior
- Don't add comments that emphasize different versions of the code, like "this code now handles"
- Do not use end-of-line comments
- Place comments above the code they describe

28
skills/testing/SKILL.md Normal file
View File

@@ -0,0 +1,28 @@
---
name: testing
description: Testing guidelines. Use when Writing, Editing, or reviewing tests.
---
# Testing Guidelines
## Test Naming
- Test names should not include the word "test"
## Assertions
- Test assertions should be strict
- Bad: `expect(content).to.include('valid-content')`
- Better: `expect(content).to.equal({ key: 'valid-content' })`
- Best: `expect(content).to.deep.equal({ key: 'valid-content' })`
## Mocking
- Use mocking as a last resort
- Don't mock a database, if it's possible to use an in-memory fake implementation instead
- Don't mock a larger API if we can mock a smaller API that it delegates to
- Prefer frameworks that record/replay network traffic over mocking
- Don't mock our own code
- Don't overuse the word "mock"
- Mocking means replacing behavior, by replacing method or function bodies, using a mocking framework
- In other cases use the words "fake" or "example"