@waoooo/claude-skills 1.0.0

package/skills/github-pr-creation/SKILL.md

@@ -0,0 +1,137 @@
+---
+name: github-pr-creation
+description: Creates GitHub Pull Requests with automated validation and task tracking. Use when user wants to create PR, open pull request, submit for review, or check if ready for PR. Analyzes commits, validates task completion, generates Conventional Commits title and description, suggests labels. NOTE - for merging existing PRs, use github-pr-merge instead.
+---
+
+# GitHub PR creation
+
+Creates Pull Requests with task validation, test execution, and Conventional Commits formatting.
+
+## Current state
+
+!`git rev-parse --abbrev-ref HEAD 2>/dev/null`
+!`git log @{u}..HEAD --oneline 2>/dev/null || echo "(no upstream tracking)"`
+
+## Core workflow
+
+### 1. Confirm target branch
+
+**ALWAYS ask user before proceeding:**
+
+```
+Creating PR from [current-branch] to [target-branch]. Correct?
+```
+
+| Branch flow | Typical target |
+|-------------|---------------|
+| feature/* | develop |
+| fix/* | develop |
+| hotfix/* | main/master |
+| develop | main/master |
+
+### 2. Search for task documentation
+
+Look for task/spec files that describe what this PR should accomplish. Common locations by tool:
+
+| Tool/Convention | Path |
+|-----------------|------|
+| AWS Kiro | `.kiro/specs/*/tasks.md` |
+| Cursor | `.cursor/rules/*.md`, `.cursorrules` |
+| Trae | `.trae/rules/*.md` |
+| GitHub Issues | `gh issue list --assignee @me --state open` |
+| Generic | `docs/specs/`, `specs/`, `tasks.md`, `TODO.md` |
+
+Extract task IDs, titles, descriptions, and requirements references when found.
+
+### 3. Analyze commits
+
+For each commit on this branch, identify type, scope, task references, and breaking changes. Map commits to documented tasks when task files exist.
+
+### 4. Verify task completion
+
+If task documentation exists:
+
+1. Identify main task from branch name (e.g., `feature/task-2-*` -> Task 2)
+2. Find all sub-tasks (e.g., Task 2.1, 2.2, 2.3)
+3. Check which sub-tasks are referenced in commits
+4. Report missing sub-tasks
+
+**If tasks incomplete**, STOP and show status:
+```
+Task 2 INCOMPLETE: 1/3 sub-tasks missing
+- Task 2.1: done
+- Task 2.2: done
+- Task 2.3: MISSING
+```
+
+Ask user whether to complete missing tasks or proceed anyway.
+
+### 5. Run tests
+
+Run the project test suite. Tests **MUST** pass before creating PR.
+
+### 6. Determine PR type and generate title
+
+| Branch flow | Title prefix |
+|-------------|-------------|
+| feature/* -> develop | `feat(scope):` |
+| fix/* -> develop | `fix(scope):` |
+| hotfix/* -> main | `hotfix(scope):` |
+| develop -> main | `release:` |
+| refactor/* -> develop | `refactor(scope):` |
+
+**Title format**: `<type>(<scope>): <description>`
+- Type: dominant commit type (feat > fix > refactor)
+- Scope: most common scope from commits (kebab-case)
+- Description: imperative, lowercase, no period, max 50 chars
+
+### 7. Generate PR body
+
+Use the appropriate template from `references/pr_templates.md` based on PR type and populate with gathered data.
+
+### 8. Suggest labels
+
+**ALWAYS check available labels first:**
+
+```bash
+gh label list
+```
+
+Match commit types to available project labels. The project may use different names than standard (e.g., "feature" instead of "enhancement").
+
+| Commit type | Common label names |
+|-------------|-------------------|
+| feat | feature, enhancement |
+| fix | bug, bugfix |
+| refactor | refactoring, tech-debt |
+| docs | documentation |
+| ci | ci/cd, infrastructure |
+| security | security |
+| hotfix | urgent, priority:high |
+
+**If no matching label exists**: suggest creating one. The user may have removed default labels, so offering to add relevant ones is appropriate.
+
+### 9. Create PR
+
+**ALWAYS show title, body, and labels for user approval first.**
+
+```bash
+gh pr create --title "[title]" --body "$(cat <<'EOF'
+[body content]
+EOF
+)" --base [base_branch] --label [labels]
+```
+
+## Important rules
+
+- **ALWAYS** confirm target branch with user
+- **ALWAYS** run tests before creating PR
+- **ALWAYS** show PR content for approval before creating
+- **ALWAYS** check available labels with `gh label list` before suggesting
+- **ALWAYS** use HEREDOC for body to preserve formatting
+- **NEVER** create PR without user confirmation
+- **NEVER** modify repository files (read-only analysis)
+
+## References
+
+- `references/pr_templates.md` - PR body templates for all types (feature, release, bugfix, hotfix, refactoring, docs, CI/CD)

package/skills/github-pr-creation/references/pr_templates.md

@@ -0,0 +1,187 @@
+# PR templates
+
+Select the template matching the PR type.
+
+---
+
+## Feature (feature/* -> develop)
+
+**Title**: `feat(<scope>): <description>`
+
+```markdown
+## What
+- [List of implemented features/components]
+- [Main functionality highlights]
+
+## Why
+- [Business/operational impact]
+- [Pain points resolved]
+
+## Details
+### Task X.Y: [Task title]
+- [Implementation detail 1]
+- [Implementation detail 2]
+- **Requirements**: X, Y, Z
+
+## Checklist
+- [ ] Main feature implemented
+- [ ] Tests written and passing
+- [ ] Documentation updated
+- [ ] Code review ready
+```
+
+---
+
+## Release (develop -> main)
+
+**Title**: `release: version X.Y with [main features]`
+
+```markdown
+## What
+This release includes:
+- [Feature set 1 - Task N]
+- [Feature set 2 - Task M]
+
+## Why
+[Release motivation, milestone reached]
+
+## Details
+### Task N: [Feature name] (COMPLETE)
+- **Task N.1**: [Description]
+- **Task N.2**: [Description]
+- **Requirements**: X, Y, Z
+
+## Testing
+- Coverage: XX%
+- Integration tests: pass/fail
+
+## Checklist
+- [ ] All tasks completed
+- [ ] No breaking changes (or documented)
+- [ ] Migration guide prepared (if needed)
+```
+
+---
+
+## Bugfix (fix/* -> develop)
+
+**Title**: `fix(<scope>): <description>`
+
+```markdown
+## What
+Fix for [problem description]
+
+## Problem
+[Bug description, how it manifests, impact]
+
+## Solution
+[Explanation of implemented solution]
+
+## Testing
+- [How the fix was tested]
+- [Regression tests added]
+
+## Checklist
+- [ ] Bug resolved
+- [ ] Regression tests added
+- [ ] No side effects introduced
+```
+
+---
+
+## Hotfix (hotfix/* -> main)
+
+**Title**: `hotfix(<scope>): <critical fix>`
+
+```markdown
+## HOTFIX
+
+### Issue
+[Description of critical production issue]
+
+### Root cause
+[Identified cause]
+
+### Fix
+[Implemented solution]
+
+### Impact
+- Affected users: [estimate]
+- Downtime: [if applicable]
+
+### Rollback plan
+[Rollback plan if needed]
+
+## Checklist
+- [ ] Fix tested in staging
+- [ ] Approval for urgent deploy
+- [ ] Post-deploy monitoring planned
+```
+
+---
+
+## Refactoring (refactor/* -> develop)
+
+**Title**: `refactor(<scope>): <description>`
+
+```markdown
+## What
+Refactoring of [component/module]
+
+## Why
+- [Motivation: performance, maintainability, technical debt]
+
+## Changes
+- [Change 1]
+- [Change 2]
+
+## Impact
+- **Functional**: None (behavior unchanged)
+- **Performance**: [expected improvements]
+- **Maintainability**: [benefits]
+
+## Checklist
+- [ ] Functional behavior unchanged
+- [ ] Existing tests passing
+- [ ] New tests added (if needed)
+```
+
+---
+
+## Documentation (docs/*)
+
+**Title**: `docs(<scope>): <description>`
+
+```markdown
+## What
+Documentation update for [area]
+
+## Changes
+- [Document 1]: [change type]
+- [Document 2]: [change type]
+
+## Motivation
+[Why this documentation is needed]
+```
+
+---
+
+## CI/CD and infrastructure
+
+**Title**: `ci(<scope>): <description>` or `chore(<scope>): <description>`
+
+```markdown
+## What
+[Pipeline/infrastructure change]
+
+## Changes
+- [Change 1]
+- [Change 2]
+
+## Impact
+- Build time: [variation]
+- Deploy process: [variation]
+
+## Testing
+[How it was verified]
+```

package/skills/github-pr-merge/SKILL.md

@@ -0,0 +1,112 @@
+---
+name: github-pr-merge
+description: Merges GitHub Pull Requests after validating pre-merge checklist. Use when user wants to merge PR, close PR, finalize PR, complete merge, approve and merge, or execute merge. Runs pre-merge validation (tests, lint, CI, comments), confirms with user, merges with proper format, handles post-merge cleanup.
+---
+
+# GitHub PR merge
+
+Merges Pull Requests after validating pre-merge checklist and handling post-merge cleanup.
+
+## Current PR
+
+!`gh pr view --json number,title,state -q '"PR #\(.number): \(.title) (\(.state))"' 2>/dev/null`
+
+## Core workflow
+
+### 1. Check comments status
+
+Verify all review comments have at least one reply:
+
+```bash
+REPO=$(gh repo view --json nameWithOwner -q '.nameWithOwner')
+PR=$(gh pr view --json number -q '.number')
+
+# Find unreplied comment IDs
+gh api repos/$REPO/pulls/$PR/comments --jq '
+  [.[] | select(.in_reply_to_id) | .in_reply_to_id] as $replied |
+  [.[] | select(.in_reply_to_id == null) | select(.id | IN($replied[]) | not) | .id]
+'
+```
+
+**If unreplied comments exist:**
+- **STOP** the merge process
+- Inform user: "Found unreplied comments: [IDs]. Run github-pr-review first."
+- **NEVER** reply to comments from this skill
+
+### 2. Run validation
+
+Run tests, linting, and verify CI checks. All **MUST** pass before proceeding.
+
+```bash
+gh pr checks $PR
+```
+
+### 3. Confirm with user
+
+**ALWAYS show checklist summary and ask before merging:**
+
+```
+Pre-merge checklist:
+- Tests: passing
+- Lint: passing
+- CI: green
+- Comments: all replied
+
+Ready to merge PR #X. Proceed?
+```
+
+### 4. Execute merge
+
+```bash
+gh pr merge $PR --merge --delete-branch --body "$(cat <<'EOF'
+- Key change 1
+- Key change 2
+- Key change 3
+
+Reviews: N/N addressed
+Tests: X passed (Y% cov)
+Refs: Task N, Req M
+EOF
+)"
+```
+
+**Merge strategy**: always `--merge` (merge commit), never squash or rebase.
+
+`--delete-branch` automatically deletes the remote branch after merge.
+
+### 5. Post-merge cleanup
+
+```bash
+git checkout develop && git pull origin develop
+```
+
+## Merge message format
+
+Concise format for a clean git log:
+
+```
+- Key change 1 (what was added/fixed)
+- Key change 2
+- Key change 3
+
+Reviews: 7/7 addressed (Gemini 5, Codex 2)
+Tests: 628 passed (88% cov)
+Refs: Task 8, Req 14-15
+```
+
+- 3-5 bullet points max for changes
+- One line each for reviews summary, test results, and task references
+- No headers (##), no verbose sections
+- Total: ~10 lines max
+
+## Important rules
+
+- **ALWAYS** run tests, lint, and CI checks before merging
+- **ALWAYS** verify all review comments have replies
+- **ALWAYS** confirm with user before executing merge
+- **ALWAYS** use merge commit (`--merge`), never squash/rebase
+- **ALWAYS** delete feature branch after successful merge
+- **NEVER** merge with failing tests, lint, or CI checks
+- **NEVER** skip user confirmation
+- **NEVER** reply to PR comments from this skill - use github-pr-review instead
+- **STOP** merge if unreplied comments exist and direct user to review skill

package/skills/github-pr-review/SKILL.md

@@ -0,0 +1,110 @@
+---
+name: github-pr-review
+description: Handles PR review comments and feedback resolution. Use when user wants to resolve PR comments, handle review feedback, fix review comments, address PR review, check review status, respond to reviewer, verify PR readiness, review PR comments, analyze review feedback, evaluate PR comments, assess review suggestions, or triage PR comments. Fetches comments via GitHub CLI, classifies by severity, applies fixes with user confirmation, commits with proper format, replies to threads.
+---
+
+# GitHub PR review
+
+Resolves Pull Request review comments with severity-based prioritization, fix application, and thread replies.
+
+## Current PR
+
+!`gh pr view --json number,title,state -q '"PR #\(.number): \(.title) (\(.state))"' 2>/dev/null`
+
+## Core workflow
+
+### 1. Fetch and classify comments
+
+```bash
+REPO=$(gh repo view --json nameWithOwner -q '.nameWithOwner')
+PR=$(gh pr view --json number -q '.number')
+gh api repos/$REPO/pulls/$PR/comments
+```
+
+Filter out replies (`in_reply_to_id != null`). Classify originals by severity and process in order: CRITICAL > HIGH > MEDIUM > LOW.
+
+| Severity | Indicators | Action |
+|----------|------------|--------|
+| CRITICAL | `critical.svg`, "security", "vulnerability" | Must fix |
+| HIGH | `high-priority.svg`, "High Severity" | Should fix |
+| MEDIUM | `medium-priority.svg`, "Medium Severity" | Recommended |
+| LOW | `low-priority.svg`, "style", "nit" | Optional |
+
+See `references/severity_guide.md` for full detection patterns (Gemini badges, Cursor comments, keyword fallback, related comments heuristics).
+
+### 2. Process each comment
+
+For each comment, in severity order:
+
+1. **Show context**: comment ID, severity, file:line, quote
+2. **Read affected code** and propose fix
+3. **Confirm with user** before applying
+4. **Apply fix** if approved
+5. **Verify ALL issues** in the comment are addressed (multi-issue comments are common)
+
+### 3. Commit changes
+
+Use git-commit skill format. Functional fixes get separate commits, cosmetic fixes are batched:
+
+| Change type | Strategy |
+|-------------|----------|
+| Functional (CRITICAL/HIGH) | Separate commit per fix |
+| Cosmetic (MEDIUM/LOW) | Single batch `style:` commit |
+
+Reference the comment ID in the commit body.
+
+### 4. Reply to threads
+
+**Important**: use `--input -` with JSON. The `-f in_reply_to=...` syntax does NOT work.
+
+```bash
+COMMIT=$(git rev-parse --short HEAD)
+gh api repos/$REPO/pulls/$PR/comments \
+  --input - <<< '{"body": "Fixed in '"$COMMIT"'. Brief explanation.", "in_reply_to": 123456789}'
+```
+
+**Reply templates** (no emojis, minimal and professional):
+
+| Situation | Template |
+|-----------|----------|
+| Fixed | `Fixed in [hash]. [brief description of fix]` |
+| Won't fix | `Won't fix: [reason]` |
+| By design | `By design: [explanation]` |
+| Deferred | `Deferred to [issue/task]. Will address in future iteration.` |
+| Acknowledged | `Acknowledged. [brief note]` |
+
+### 5. Run tests and push
+
+Run the project test suite. All tests must pass before pushing. Push all fixes together to minimize review loops.
+
+### 6. Submit review (optional)
+
+After addressing all comments, formally submit a review:
+
+- `gh pr review $PR --approve --body "..."` - all comments addressed, PR is ready
+- `gh pr review $PR --request-changes --body "..."` - critical issues remain
+- `gh pr review $PR --comment --body "..."` - progress update, no decision yet
+
+## Avoiding review loops
+
+When bots (Gemini, Codex, etc.) review every push:
+
+1. **Batch fixes**: accumulate all fixes, push once
+2. **Draft PR**: convert to draft during fixes
+3. **Commit keywords**: some bots respect `[skip ci]` or `[skip review]`
+
+## Important rules
+
+- **ALWAYS** confirm before modifying files
+- **ALWAYS** verify ALL issues in multi-issue comments are fixed
+- **ALWAYS** run tests before pushing
+- **ALWAYS** reply to resolved threads using standard templates
+- **ALWAYS** submit formal review (`gh pr review`) after addressing all comments
+- **NEVER** use emojis in commit messages or thread replies
+- **NEVER** skip HIGH/CRITICAL comments without explicit user approval
+- **Functional fixes** -> separate commits (one per fix)
+- **Cosmetic fixes** -> batch into single `style:` commit
+
+## References
+
+- `references/severity_guide.md` - Severity detection patterns (Gemini badges, Cursor comments, keyword fallback, related comments heuristics)

package/skills/github-pr-review/references/severity_guide.md

@@ -0,0 +1,168 @@
+# Severity guide
+
+Reference guide for interpreting severity levels from automated review comments (Gemini, Cursor, and others).
+
+## Severity Badges
+
+Gemini uses visual badges in review comments to indicate severity:
+
+### CRITICAL
+**Badge**: `![critical](https://www.gstatic.com/codereviewagent/critical.svg)`
+
+**Visual**: Red badge with "critical" text
+
+**Meaning**: Must be fixed before merge. Indicates:
+- Security vulnerabilities
+- Data loss risks
+- Logic errors causing incorrect behavior
+- Infinite loops or deadlocks
+- Memory leaks or resource exhaustion
+
+**Action**: Stop and fix immediately. These block merge.
+
+---
+
+### HIGH
+**Badge**: `![high](https://www.gstatic.com/codereviewagent/high-priority.svg)`
+
+**Visual**: Orange badge
+
+**Meaning**: Should be fixed. Indicates:
+- Performance issues
+- Error handling gaps
+- Potential race conditions
+- Missing validation on important paths
+
+**Action**: Address before merge unless there's a strong reason not to.
+
+---
+
+### MEDIUM
+**Badge**: `![medium](https://www.gstatic.com/codereviewagent/medium-priority.svg)`
+
+**Visual**: Yellow badge
+
+**Meaning**: Recommended fix. Indicates:
+- Code style issues
+- Minor refactoring opportunities
+- Unreachable code (dead code)
+- Duplicate logic
+- Missing edge case handling
+
+**Action**: Address if time permits, or create follow-up issue.
+
+---
+
+### LOW
+**Badge**: `![low](https://www.gstatic.com/codereviewagent/low-priority.svg)`
+
+**Visual**: Blue/gray badge
+
+**Meaning**: Optional improvement. Indicates:
+- Import ordering
+- Naming conventions
+- Documentation suggestions
+- Minor style preferences
+
+**Action**: Optional. Can be skipped with justification.
+
+---
+
+## Detection Patterns
+
+### Badge Detection (Primary)
+```python
+# In comment body, look for:
+"critical.svg" → CRITICAL
+"high-priority.svg" → HIGH
+"medium-priority.svg" → MEDIUM
+"low-priority.svg" → LOW
+```
+
+### Cursor Comments
+```
+<!-- **High Severity** --> → HIGH
+<!-- **Medium Severity** --> → MEDIUM
+```
+
+### Keyword Detection (Fallback)
+When badges or HTML comments aren't present, infer from keywords:
+
+| Keywords | Severity |
+|----------|----------|
+| security, vulnerability, injection, XSS, SQL | CRITICAL/HIGH |
+| dangerous, unsafe, exploit | CRITICAL |
+| performance, slow, O(n²) | HIGH |
+| error handling, exception, catch | HIGH |
+| unreachable, dead code, unused | MEDIUM |
+| refactor, simplify, consolidate | MEDIUM |
+| style, formatting, PEP, naming | LOW |
+| import order, whitespace | LOW |
+
+---
+
+## Related Comments Detection
+
+Comments are often related when:
+
+1. **Consequence relationship**: Comment B is a consequence of fixing Comment A
+   - Keywords: "consequence", "result of", "as mentioned above"
+
+2. **Same root cause**: Multiple comments about the same underlying issue
+   - Keywords: "root cause", "same issue", "related to"
+
+3. **Unreachable code**: After an exception handling fix, related `except` blocks may become unreachable
+   - Pattern: CRITICAL exception handling → MEDIUM unreachable code
+
+4. **Same function/method**: Comments within ~100 lines in the same file, where one is CRITICAL and others are MEDIUM/LOW
+
+---
+
+## Example: Exception Handling Pattern
+
+Common scenario from Gemini reviews:
+
+**Comment 1 (CRITICAL)**: Exception handling in `method_x()` needs refactoring:
+- FileNotFoundError should fail-fast, not retry
+- Generic exceptions need sleep to avoid busy-loop
+
+**Comment 2 (MEDIUM)**: `except FileNotFoundError` block at line 186 is unreachable
+→ This is a CONSEQUENCE of fixing Comment 1
+
+**Comment 3 (MEDIUM)**: `except FileNotFoundError` block at line 473 is unreachable
+→ Also a CONSEQUENCE of fixing Comment 1
+
+**Resolution**: Fix Comment 1 first. Comments 2 and 3 will be automatically resolved.
+
+---
+
+## Gemini Config Reference
+
+Gemini behavior is controlled by `.gemini/config.yaml`:
+
+```yaml
+code_review:
+  threshold: LOW          # Minimum severity to report
+  auto_fix: false         # Whether to suggest auto-fixes
+  blocking: false         # Whether reviews block merge
+```
+
+When `threshold: LOW`, all severities are reported.
+When `blocking: false`, reviews are advisory only.
+
+---
+
+## Workflow Integration
+
+1. **Fetch comments**: Parse severity from badge URLs in comment body
+2. **Sort by severity**: CRITICAL → HIGH → MEDIUM → LOW
+3. **Group related**: Use heuristics above
+4. **Process CRITICAL first**: These often resolve MEDIUM/LOW comments
+5. **Skip LOW if needed**: They're optional by definition
+
+---
+
+## References
+
+- [Gemini Code Assist Documentation](https://cloud.google.com/gemini/docs/discover/code-assist)
+- [GitHub PR Review API](https://docs.github.com/en/rest/pulls/comments)