Initial commit
This commit is contained in:
14
.claude-plugin/plugin.json
Normal file
14
.claude-plugin/plugin.json
Normal file
@@ -0,0 +1,14 @@
|
||||
{
|
||||
"name": "shavakan-skills",
|
||||
"description": "Personal skill collection: prompt engineering, git commits, and sequential thinking",
|
||||
"version": "1.0.1",
|
||||
"author": {
|
||||
"name": "shavakan",
|
||||
"email": "cs.changwon.lee@gmail.com"
|
||||
},
|
||||
"skills": [
|
||||
"./git-commit",
|
||||
"./prompt-engineer",
|
||||
"./sequential-thinking"
|
||||
]
|
||||
}
|
||||
3
README.md
Normal file
3
README.md
Normal file
@@ -0,0 +1,3 @@
|
||||
# shavakan-skills
|
||||
|
||||
Personal skill collection: prompt engineering, git commits, and sequential thinking
|
||||
81
git-commit/SKILL.md
Normal file
81
git-commit/SKILL.md
Normal file
@@ -0,0 +1,81 @@
|
||||
---
|
||||
name: git-commit
|
||||
description: Create git commits with succinct technical messages. Activates when user requests git commit creation.
|
||||
---
|
||||
|
||||
# Git Commit
|
||||
|
||||
## Overview
|
||||
|
||||
Create clean, technical git commit messages in logical units. Analyze changes and group related modifications into separate commits.
|
||||
|
||||
## Process
|
||||
|
||||
1. Run `git status` and `git diff` to analyze all changes
|
||||
2. Apply grouping algorithm to identify commit units
|
||||
3. For each unit:
|
||||
- Stage only files for that unit
|
||||
- Draft succinct message (1-2 sentences max)
|
||||
- Create commit
|
||||
4. Verify all changes are committed
|
||||
|
||||
## Grouping Algorithm
|
||||
|
||||
1. **Categorize** each file by type (priority order: Fix > Feature > Refactor > Test > Doc > Config)
|
||||
2. **Build dependency graph** (types before code, implementation before tests, refactors before fixes)
|
||||
3. **Merge units** if: same directory AND same type AND <5 files total
|
||||
4. **Keep separate** if: different types OR cross-module changes OR >4 files in group
|
||||
5. **Order commits**: dependencies first, then independents, docs last
|
||||
|
||||
**Change types:**
|
||||
- **Fix**: Bug fixes addressing specific issues
|
||||
- **Feature**: New functionality in related files
|
||||
- **Refactor**: Code restructuring without behavior changes
|
||||
- **Test**: Test additions/modifications (commit with implementation if coupled)
|
||||
- **Doc**: Documentation updates
|
||||
- **Config**: Build config, dependencies, tooling
|
||||
- **Types**: Type definition changes (commit before code using them)
|
||||
|
||||
**Coupling boundaries:**
|
||||
- **Tightly coupled** (one commit): Type changes + code using them, renames affecting imports, implementation + its tests if <3 files
|
||||
- **Independent** (separate commits): Different modules, unrelated bug fixes, separate features, docs
|
||||
|
||||
**Examples:**
|
||||
```
|
||||
✅ Good grouping:
|
||||
Commit 1: Add null check to user validation (src/validation/user.ts)
|
||||
Commit 2: Update UserForm to use new validation (src/forms/UserForm.tsx, src/forms/UserForm.test.ts)
|
||||
Commit 3: Document validation rules (docs/api/validation.md)
|
||||
|
||||
❌ Bad grouping:
|
||||
Commit 1: Update validation and fix tests and add docs (mixes 3 types, unclear scope)
|
||||
```
|
||||
|
||||
**Circular dependencies:**
|
||||
If fix A requires refactor B, create minimal commits preserving buildability: refactor first, then fix.
|
||||
|
||||
## Message Guidelines
|
||||
|
||||
**Focus on WHAT changed in the code:**
|
||||
- "Add null checks to user validation"
|
||||
- "Extract database logic into separate module"
|
||||
- "Fix memory leak in event handler cleanup"
|
||||
|
||||
**Avoid progress/milestone language:**
|
||||
- ❌ "Implement user authentication feature"
|
||||
- ❌ "Continue work on API endpoints"
|
||||
- ❌ "Add tests and improve code quality"
|
||||
|
||||
## Edge Cases
|
||||
|
||||
**Single logical unit**: All changes tightly coupled → one commit
|
||||
**Mixed changes in one file**: Use `git add -p` to stage hunks separately
|
||||
**Too many units (>6)**: Present grouping plan, ask user to confirm or merge
|
||||
|
||||
## Important
|
||||
|
||||
- Never include "Co-Authored-By: Claude" or "Generated with Claude Code"
|
||||
- No heredoc format with attribution footers
|
||||
- Describe technical change, not project progress
|
||||
- Default to multiple small commits over one large commit
|
||||
- Ensure every file is staged exactly once
|
||||
53
plugin.lock.json
Normal file
53
plugin.lock.json
Normal file
@@ -0,0 +1,53 @@
|
||||
{
|
||||
"$schema": "internal://schemas/plugin.lock.v1.json",
|
||||
"pluginId": "gh:Shavakan/claude-marketplace:skills",
|
||||
"normalized": {
|
||||
"repo": null,
|
||||
"ref": "refs/tags/v20251128.0",
|
||||
"commit": "7db1afcdc0034c05538b6c9a8d9f4120f6494d33",
|
||||
"treeHash": "565f4b17535b455037cdd8b9eda47dad40ac8a84c3d3fbf26dbde4bb11676c6a",
|
||||
"generatedAt": "2025-11-28T10:12:47.068537Z",
|
||||
"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": "shavakan-skills",
|
||||
"description": "Personal skill collection: prompt engineering, git commits, and sequential thinking",
|
||||
"version": "1.0.1"
|
||||
},
|
||||
"content": {
|
||||
"files": [
|
||||
{
|
||||
"path": "README.md",
|
||||
"sha256": "92d33b59201f6b2dc1e6a0ef1baa027546c12c75525b8030b68c855e1cc0580d"
|
||||
},
|
||||
{
|
||||
"path": "git-commit/SKILL.md",
|
||||
"sha256": "63acc52644173d7f8a0c716d4cc27a907a8f6f379f0bd4445d3c7fbd6664e3b4"
|
||||
},
|
||||
{
|
||||
"path": "prompt-engineer/SKILL.md",
|
||||
"sha256": "579b4c2a600ec7fb6c19fd7298fac9e0bf2ec1e8dcafda4eca2fb881bb1db10c"
|
||||
},
|
||||
{
|
||||
"path": ".claude-plugin/plugin.json",
|
||||
"sha256": "4f26657456496df3ec268b9b1359c6448e8a214f79808ed6e404b3483e444339"
|
||||
},
|
||||
{
|
||||
"path": "sequential-thinking/SKILL.md",
|
||||
"sha256": "8f47b9c79b2d3a2f074a34387af981a6ef74322dab1abdd73ddad363121de999"
|
||||
}
|
||||
],
|
||||
"dirSha256": "565f4b17535b455037cdd8b9eda47dad40ac8a84c3d3fbf26dbde4bb11676c6a"
|
||||
},
|
||||
"security": {
|
||||
"scannedAt": null,
|
||||
"scannerVersion": null,
|
||||
"flags": []
|
||||
}
|
||||
}
|
||||
106
prompt-engineer/SKILL.md
Normal file
106
prompt-engineer/SKILL.md
Normal file
@@ -0,0 +1,106 @@
|
||||
---
|
||||
name: prompt-engineer
|
||||
description: Build, analyze, and optimize LLM prompts and technical documentation. Activates when user wants to create, modify, review, or improve prompts, or when requests are ambiguous and need clarification before writing.
|
||||
allowed-tools: [Read, Write, Edit, WebFetch]
|
||||
---
|
||||
|
||||
# Prompt Engineer
|
||||
|
||||
## Overview
|
||||
|
||||
Specialized agent for prompt engineering and technical writing. Catches ambiguous requests and enforces brutal concision. Output has no fluff, no praise.
|
||||
|
||||
## Scope
|
||||
|
||||
**Use when:**
|
||||
- Creating new prompts from requirements
|
||||
- Analyzing existing prompts for weaknesses
|
||||
- Optimizing prompts for token efficiency
|
||||
- Debugging prompt behavior issues
|
||||
- User requests writing but gives ambiguous requirements (where? what format? who reads it?)
|
||||
- Technical documentation needing brutal concision (specs, READMEs, guides)
|
||||
|
||||
**Don't use for:**
|
||||
- Code generation (unless it's prompt code)
|
||||
- Clear, well-scoped writing requests
|
||||
|
||||
## Activation Protocol
|
||||
|
||||
Activate proactively when detecting:
|
||||
- "Write/add/note [content]" without target location specified
|
||||
- "Document this" without format or audience
|
||||
- "Add instructions for X" without scope constraints
|
||||
- Any writing request missing: where, what format, who reads it
|
||||
|
||||
Default action: Ask clarifying questions BEFORE drafting.
|
||||
|
||||
## Analysis Checklist
|
||||
|
||||
When reviewing prompts, verify and fix:
|
||||
- **Clarity**: Ambiguous phrasing → Add specificity or examples
|
||||
- **Context**: Missing background → Insert necessary domain info
|
||||
- **Constraints**: Vague boundaries → Define explicit limits
|
||||
- **Format**: Unspecified output → Add structure requirements
|
||||
- **Examples**: Abstract instructions → Provide concrete demonstrations
|
||||
- **Token efficiency**: Verbose → Cut redundancy, use delimiters
|
||||
- **Conflicts**: Contradicting rules → Resolve or prioritize
|
||||
|
||||
## Construction Principles
|
||||
|
||||
- Specific beats vague
|
||||
- Examples strengthen abstract instructions
|
||||
- Constraints prevent drift
|
||||
- Chain-of-thought for multi-step reasoning
|
||||
- Few-shot when demonstrating patterns
|
||||
- XML tags/delimiters for structure
|
||||
- Front-load critical instructions
|
||||
- Test edge cases in requirements
|
||||
|
||||
## Anti-Patterns
|
||||
|
||||
**Avoid:**
|
||||
- Conflicting instructions without priority
|
||||
- Assuming unstated context
|
||||
- Vague success criteria
|
||||
- Overloading with unrelated tasks
|
||||
- Repetitive phrasing (wastes tokens)
|
||||
- Implicit format expectations
|
||||
- Mixing persona and technical instructions messily
|
||||
|
||||
## Model-Specific Guidance
|
||||
|
||||
**Haiku**: Simpler prompts, shorter context, explicit format
|
||||
**Sonnet**: Balanced - handles complexity and nuance well
|
||||
**Opus**: Can handle highly complex prompts with subtle reasoning
|
||||
|
||||
## Validation Process
|
||||
|
||||
Before delivering a prompt:
|
||||
1. Read it as a hostile interpreter - find loopholes
|
||||
2. Check token count if efficiency matters
|
||||
3. Verify examples match instructions
|
||||
4. Test mental edge cases
|
||||
5. Ensure constraints are enforceable
|
||||
|
||||
## Iteration Strategy
|
||||
|
||||
**First draft**: Get core requirements clear
|
||||
**Second pass**: Add examples and constraints
|
||||
**Final pass**: Remove redundancy, optimize tokens
|
||||
|
||||
## Common Patterns
|
||||
|
||||
**Chain-of-Thought**: "Think step-by-step before answering"
|
||||
**Few-Shot**: Provide 2-3 input/output examples
|
||||
**Persona**: "You are an expert X who specializes in Y"
|
||||
**Template**: Create reusable structure with placeholders
|
||||
**Constitutional**: Add ethical constraints upfront
|
||||
|
||||
## Output Rules
|
||||
|
||||
- Direct feedback only
|
||||
- Cite line numbers when analyzing files
|
||||
- Propose concrete fixes with before/after
|
||||
- Explain why changes matter, not what they do
|
||||
- Question assumptions in requirements
|
||||
- Flag edge cases that break the prompt
|
||||
42
sequential-thinking/SKILL.md
Normal file
42
sequential-thinking/SKILL.md
Normal file
@@ -0,0 +1,42 @@
|
||||
---
|
||||
name: sequential-thinking
|
||||
description: Use for atypically complex problems requiring explicit step-by-step reasoning. Skill autonomously decides if sequential-thinking MCP overhead is justified based on problem complexity.
|
||||
---
|
||||
|
||||
# Sequential Thinking
|
||||
|
||||
## Overview
|
||||
|
||||
Use sequential-thinking MCP tool for problems with atypical complexity requiring explicit reasoning paths. The skill autonomously assesses whether MCP overhead provides value.
|
||||
|
||||
## When to Consider Sequential-Thinking MCP
|
||||
|
||||
Activate this skill for:
|
||||
- Multi-layered architectural decisions with significant tradeoffs
|
||||
- Complex debugging across multiple interacting systems
|
||||
- Problems with circular dependencies or non-obvious root causes
|
||||
- Design decisions requiring exploration of alternative approaches
|
||||
- Race conditions, deadlocks, or timing-sensitive bugs
|
||||
- Performance bottlenecks with unclear origins
|
||||
|
||||
## Decision Criteria
|
||||
|
||||
**Use sequential-thinking MCP when:**
|
||||
- Problem requires branching into alternative reasoning paths that should be tracked
|
||||
- Assumptions need revision as new information emerges
|
||||
- Multiple interdependent factors must be balanced simultaneously
|
||||
- High-stakes decision needs documented reasoning trail
|
||||
- Genuinely uncertain and need systematic exploration
|
||||
|
||||
**Skip sequential-thinking MCP when:**
|
||||
- Problem is complex but straightforward (linear debugging)
|
||||
- Built-in reasoning suffices
|
||||
- Task is primarily execution rather than analysis
|
||||
- Overhead not justified by complexity
|
||||
- Approach is clear, just needs implementation
|
||||
|
||||
## Usage
|
||||
|
||||
Silently assess problem complexity. Only invoke sequential-thinking MCP if explicit step tracking adds material value. Default to built-in reasoning for most tasks.
|
||||
|
||||
Do not announce use of the tool unless relevant to user.
|
||||
Reference in New Issue
Block a user