zhongwei/gh-williballenthin-aiwilli-claude
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-30 09:06:18 +08:00
commit 0531721c82
7 changed files with 699 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files

12
.claude-plugin/plugin.json Normal file
View File

@@ -0,0 +1,12 @@
{
"name": "wb",
"description": "core extensions for Claude",
"version": "0.0.0-2025.11.28",
"author": {
"name": "Willi Ballenthin",
"email": "willi.ballenthin@gmail.com"
},
"skills": [
"./skills"
]
}

3
README.md Normal file
View File

@@ -0,0 +1,3 @@
# wb
core extensions for Claude

57
plugin.lock.json Normal file
View File

@@ -0,0 +1,57 @@
{
"$schema": "internal://schemas/plugin.lock.v1.json",
"pluginId": "gh:williballenthin/aiwilli:claude/",
"normalized": {
"repo": null,
"ref": "refs/tags/v20251128.0",
"commit": "d65dcd650168483c2f50de5a4eb4fbfbf0927cd6",
"treeHash": "88f696a2248efab4b3cf7f30cbdaabeb49a2cfc6f608c527583c69e50207e8a3",
"generatedAt": "2025-11-28T10:29:01.949904Z",
"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": "wb",
"description": "core extensions for Claude",
"version": null
},
"content": {
"files": [
{
"path": "README.md",
"sha256": "dc35e55cb77e1dafddd9f2fc26072a388c6aada964f5fe10b5cc98f372777421"
},
{
"path": ".claude-plugin/plugin.json",
"sha256": "9c4e580ff96aeb6c117b9724b870bb7e8abac19e5acf729e2abbdcf51291fe68"
},
{
"path": "skills/working-with-sqlite/SKILL.md",
"sha256": "d8abf08012a3f32cc2187ca77c1f739c218daccc57eb47bf2381cdee86083968"
},
{
"path": "skills/working-with-git/SKILL.md",
"sha256": "d13a771f3fb3320fa9f3857fc819bce081fa6ca78399dc33ce22a97631e09cbb"
},
{
"path": "skills/working-with-jj/SKILL.md",
"sha256": "84f3e26be801cc41c9eb5da0999453ade1ce2c57840c63cd9dfc912c6879bbca"
},
{
"path": "skills/codex-review/SKILL.md",
"sha256": "a83b1d0978eead6f4f2574601eb278ea6423414f08542bd2db6a8c40056d15d7"
}
],
"dirSha256": "88f696a2248efab4b3cf7f30cbdaabeb49a2cfc6f608c527583c69e50207e8a3"
},
"security": {
"scannedAt": null,
"scannerVersion": null,
"flags": []
}
}

182
skills/codex-review/SKILL.md Normal file
View File

@@ -0,0 +1,182 @@
---
name: codex-review
description: Request an external review from Codex (OpenAI) to get a second perspective on designs, implementations, diffs, or architecture decisions
---
# Codex Review
Use this skill when you need a second perspective on work in progress. Codex excels at identifying gaps in reasoning, missing requirements, architectural concerns, and flawed assumptions - especially early in the planning process when issues are cheapest to fix.
## When to Use
Invoke this skill when the user wants an external perspective, especially during early phases:
- Brainstorming sessions - validating ideas and approaches
- Requirements gathering - checking for gaps or contradictions
- Design documents - reviewing architecture and technical decisions
- Implementation plans - validating approach before writing code
- Occasionally: reviewing code or diffs when explicitly requested
## How to Invoke Codex
Codex runs in non-interactive mode via `codex exec`. Pass all content directly via stdin.
**Command template:**
```bash
printf "%s" "$CONTENT_TO_REVIEW" | codex exec \
-m "gpt-5.1-codex-max" \
-c 'model_reasoning_effort="high"' \
-s read-only \
-
```
The `-` at the end tells Codex to read the prompt from stdin. Use `printf "%s"` instead of `echo` to safely handle content with backslashes or leading dashes.
## Preparing the Content
Before invoking Codex, gather all relevant context into a single prompt. Codex has no access to the filesystem or any context beyond what you provide.
**Important:** Strip sensitive data (API keys, tokens, credentials, secrets) from content before sending to Codex. If the context is unclear or you need specific focus areas, prompt the user for guidance.
**For brainstorming or ideas:**
```
## Review Request: Idea Validation
Please review the following ideas/approach for gaps, risks, and flawed assumptions.
### Proposal:
<the idea, approach, or brainstorm output>
### Context:
<problem being solved, constraints, goals>
```
**For requirements:**
```
## Review Request: Requirements
Please review these requirements for completeness, contradictions, and missing edge cases.
### Requirements:
<the requirements>
### Context:
<what system/feature these are for>
```
**For design documents:**
```
## Review Request: Design
Please review the following design for gaps, risks, and potential issues.
### Design:
<the design document or architecture>
### Context:
<background, constraints, goals>
```
**For code or diffs (when explicitly requested):**
Fetch the content using the project's VCS (git, jj, etc.) with color codes stripped. Frame the request appropriately:
```
## Review Request: Implementation
Please review the following for correctness, edge cases, and potential issues.
### Content:
<code or diff>
### Context:
<what this does, why it was changed>
```
## The Review Prompt
Always append these instructions to ensure structured output:
```
---
## Output Format
Provide your review in the following sections only:
### Blocking Issues
Issues that MUST be addressed before proceeding. These are bugs, security vulnerabilities, logic errors, or design flaws that would cause problems.
### Non-blocking Issues
Suggestions for improvement that are not critical. Style concerns, minor optimizations, or alternative approaches worth considering.
### Outstanding Questions
Questions that need clarification from the author. Ambiguities in requirements, unclear design decisions, or missing context.
### Further Ideas
Optional enhancements or future considerations. Ideas that could improve the work but are out of scope for now.
If a section has no items, write "None identified."
```
## Full Example
```bash
# Build the prompt with content and output format instructions
PROMPT=$(cat <<'REVIEW_EOF'
## Review Request: Design
Please review the following design for gaps, risks, and potential issues.
### Design:
We're building a caching layer for our API. The plan is:
1. Use Redis for distributed caching
2. Cache all GET responses for 5 minutes
3. Invalidate on any write operation to related resources
4. Fall back to database on cache miss
### Context:
- High-traffic API (~10k requests/minute)
- Eventually consistent is acceptable
- Must not serve stale data after writes
### Additional Focus:
Pay attention to cache invalidation edge cases.
---
## Output Format
Provide your review in the following sections only:
### Blocking Issues
Issues that MUST be addressed before proceeding. These are bugs, security vulnerabilities, logic errors, or design flaws that would cause problems.
### Non-blocking Issues
Suggestions for improvement that are not critical. Style concerns, minor optimizations, or alternative approaches worth considering.
### Outstanding Questions
Questions that need clarification from the author. Ambiguities in requirements, unclear design decisions, or missing context.
### Further Ideas
Optional enhancements or future considerations. Ideas that could improve the work but are out of scope for now.
If a section has no items, write "None identified."
REVIEW_EOF
)
# Invoke Codex
printf "%s" "$PROMPT" | codex exec \
-m "gpt-5.1-codex-max" \
-c 'model_reasoning_effort="high"' \
-s read-only \
-
```
## After the Review
1. Display the full review report to the user
2. Prompt the user to:
- Answer any outstanding questions
- Address blocking issues (these should be resolved)
- Comment on non-blocking issues and further ideas (accept, reject, or defer)
3. If the user wants to address issues, help them implement the fixes
4. Consider re-running the review after significant changes

166
skills/working-with-git/SKILL.md Normal file
View File

@@ -0,0 +1,166 @@
---
name: working-with-git
description: Git version control cheatsheet - viewing history, making commits, diffs, and descriptions
---
# Working with Git
Quick reference for common Git operations used in development workflows.
## Detecting Git
Check if the project uses Git:
```bash
test -d .git && echo "git" || echo "not git"
```
## Viewing the Log
**Show recent commits:**
```bash
git log --oneline -10
```
**Show log with graph:**
```bash
git log --oneline --graph --all -10
```
**Show specific commit:**
```bash
git log -1 <commit-sha>
```
**Find commits by message:**
```bash
git log --oneline --grep="keyword"
```
## Viewing Diffs
**See uncommitted changes:**
```bash
git diff
```
**See staged changes:**
```bash
git diff --cached
```
**Diff between commits:**
```bash
git diff <base-sha>..<head-sha>
```
**Diff stats:**
```bash
git diff --stat <base-sha>..<head-sha>
```
**Show what changed in a commit:**
```bash
git show <commit-sha>
```
## Getting Commit References
**Current commit SHA:**
```bash
git rev-parse HEAD
```
**Parent commit SHA:**
```bash
git rev-parse HEAD~1
```
**Branch's remote tracking commit:**
```bash
git rev-parse origin/main
```
**Relative references:**
- `HEAD` - current commit
- `HEAD~1` or `HEAD^` - parent commit
- `HEAD~2` - grandparent commit
- `origin/main` - remote branch tip
## Making Commits
**Stage and commit:**
```bash
git add <files>
git commit -m "commit message"
```
**Commit all tracked changes:**
```bash
git commit -am "commit message"
```
**Stage specific hunks interactively:**
```bash
git add -p
```
## Modifying Commit Descriptions
**Amend last commit message:**
```bash
git commit --amend -m "new message"
```
**Amend last commit (open editor):**
```bash
git commit --amend
```
**Change older commit messages (interactive rebase):**
```bash
git rebase -i HEAD~3
```
(Then mark commits with `reword` in the editor)
## Branch Information
**Current branch:**
```bash
git branch --show-current
```
**Check if branch tracks remote:**
```bash
git rev-parse --abbrev-ref --symbolic-full-name @{u} 2>/dev/null
```
## Quick Status
**See working tree status:**
```bash
git status
```
**Short status:**
```bash
git status -s
```
## Common Patterns
**Get range for code review:**
```bash
BASE_SHA=$(git rev-parse HEAD~1)
HEAD_SHA=$(git rev-parse HEAD)
echo "Reviewing: $BASE_SHA..$HEAD_SHA"
```
**Compare against main:**
```bash
git diff origin/main..HEAD
```
**See files changed:**
```bash
git diff --name-only <base>..<head>
```

246
skills/working-with-jj/SKILL.md Normal file
View File

@@ -0,0 +1,246 @@
---
name: working-with-jj
description: Jujutsu (jj) version control cheatsheet - viewing history, making commits, diffs, and descriptions
---
# Working with Jujutsu (jj)
Quick reference for common Jujutsu operations used in development workflows.
Jujutsu is a Git-compatible VCS that eliminates staging and treats your working directory as an actual commit that continuously updates.
## Detecting Jujutsu
Check if the project uses jj:
```bash
test -d .jj && echo "jj" || echo "not jj"
```
## Key Concepts
- **`@`** - Your current working copy (like Git's HEAD)
- **`@-`** - Parent of working copy (like Git's HEAD~1)
- **No staging area** - Changes are automatically recorded
- **Change IDs** - Stable identifiers that survive rebases
- **Commit IDs** - Traditional hashes compatible with Git
## Recommended Workflow
**The jj way:**
1. Make edits to files
2. Run `jj new` to create a new commit (repeat for every logical change)
3. After a series of commits, go back and review with `jj log`
4. Add meaningful descriptions with `jj describe <change-id> -m "description"`
5. Squash related commits together with `jj squash`
This workflow creates fine-grained history as you work, then lets you organize it meaningfully afterward.
## Viewing the Log
**Show recent commits:**
```bash
jj log -r @~10..@
```
**Show full log:**
```bash
jj log
```
**Show specific commit:**
```bash
jj show <change-id>
```
**Show log with more detail:**
```bash
jj log --stat
```
## Viewing Diffs
**See current changes:**
```bash
jj diff
```
**Diff specific commit:**
```bash
jj diff -r <change-id>
```
**Diff between two commits:**
```bash
jj diff --from <base> --to <head>
```
**Git-style diff output:**
```bash
jj diff --git
```
**Show what changed in a commit:**
```bash
jj show <change-id>
```
## Getting Commit References
**Current commit ID:**
```bash
jj log -r @ -T commit_id --no-graph
```
**Parent commit ID:**
```bash
jj log -r @- -T commit_id --no-graph
```
**Get change ID:**
```bash
jj log -r @ -T change_id --no-graph
```
**Revset references:**
- `@` - working copy commit
- `@-` - parent commit
- `@--` - grandparent commit
- `root()` - the root commit
- `trunk()` - main branch tip
## Making Commits
**Create new commit (after editing files):**
```bash
jj new
```
**Create new commit with message:**
```bash
jj new -m "commit message"
```
**Commit current changes with description:**
```bash
jj describe -m "commit message"
jj new
```
**Note:** Unlike Git, jj automatically tracks file changes. No `add` command needed!
## Setting Descriptions
**Set description for current commit:**
```bash
jj describe -m "new description"
```
**Set description in editor:**
```bash
jj describe
```
**Set description for specific commit:**
```bash
jj describe <change-id> -m "description"
```
## Organizing Commits
**Squash current commit into parent:**
```bash
jj squash
```
**Squash specific commit into its parent:**
```bash
jj squash -r <change-id>
```
**Squash current commit into a specific commit:**
```bash
jj squash --into <target-change-id>
```
**Move changes from one commit to another:**
```bash
jj move --from <source> --to <target>
```
**Edit an earlier commit:**
```bash
jj edit <change-id>
```
(Make changes, then `jj new` to continue)
**Split a commit into multiple:**
```bash
jj split <change-id>
```
## Status Information
**See current status:**
```bash
jj status
```
**See bookmark (branch) info:**
```bash
jj bookmark list
```
## Common Patterns
**Get range for code review:**
```bash
BASE_SHA=$(jj log -r @- -T commit_id --no-graph)
HEAD_SHA=$(jj log -r @ -T commit_id --no-graph)
echo "Reviewing: $BASE_SHA..$HEAD_SHA"
```
**Compare against trunk:**
```bash
jj diff --from trunk() --to @
```
**See files changed:**
```bash
jj diff --summary
```
## Git Interoperability
**Fetch from Git remote:**
```bash
jj git fetch
```
**Push to Git remote:**
```bash
jj git push
```
**Export to colocated Git repo:**
```bash
jj git export
```
## Workflow Comparison
| Task | Git | Jujutsu |
|------|-----|---------|
| Make commit | `git add . && git commit -m "msg"` | `jj describe -m "msg" && jj new` |
| See changes | `git diff` | `jj diff` |
| View history | `git log` | `jj log` |
| Get current SHA | `git rev-parse HEAD` | `jj log -r @ -T commit_id --no-graph` |
| Amend commit | `git commit --amend` | `jj describe` (then `jj new` if done) |
| No staging | (N/A) | Automatic! |
## Why Jujutsu?
- **No staging area confusion** - Edit files, they're tracked
- **No detached HEAD** - All commits are reachable
- **Conflict tracking** - Conflicts are first-class objects
- **Safe experimentation** - Easy to undo anything
- **Git compatible** - Works with GitHub, GitLab, etc.

33
skills/working-with-sqlite/SKILL.md Normal file
View File

@@ -0,0 +1,33 @@
---
name: working-with-sqlite
description: Preferences and tricks for working with SQLite databases
---
You're already an expert in SQL, and especially SQLite. Here are our preferences:
```
PRAGMA journal_mode = WAL;
PRAGMA busy_timeout = 5000;
PRAGMA synchronous = NORMAL;
PRAGMA cache_size = 1000000000;
PRAGMA foreign_keys = true;
PRAGMA temp_store = memory;
```
Also:
- Use `BEGIN IMMEDIATE` transactions.
- Use `STRICT` tables.
When creating tables with lots of data:
1. create table,
2. insert rows in large transactions, with 10s of thousands of rows a time,
3. then create indices at the end.
4. `ANALYZE` and `VACUUM` if necessary
Use read-only connections when appropriate:
```python
conn = sqlite3.connect('file:database.db?mode=ro', uri=True)
```