Improve/skill review optimization

.github/workflows/skill-preview.yml

@@ -0,0 +1,13 @@
+name: Skill Review
+on:
+  pull_request:
+    paths: ['**/SKILL.md']
+jobs:
+  review:
+    runs-on: ubuntu-latest
+    permissions:
+      pull-requests: write
+      contents: read
+    steps:
+      - uses: actions/checkout@v4
+      - uses: tesslio/skill-review@22e928dd837202b2b1d1397e0114c92e0fae5ead # main

skills/commit/SKILL.md

@@ -1,73 +1,48 @@
 ---
 name: commit
-description: Create git commits from current changes using Conventional Commits format. Use when ready to commit staged or unstaged changes.
+description: "Analyze diffs, stage files, and generate descriptive commit messages using Conventional Commits format. Use when ready to commit staged or unstaged changes, write a commit message, save changes, or check in code."
 allowed-tools: Bash(git add:*), Bash(git status:*), Bash(git commit:*), Bash(git branch:*), Bash(git diff:*), Bash(git log:*)
 ---
 # Commit Changes
 
-You are tasked with creating git commits for the changes made during this session.
+This skill creates git commits for changes made during the current session. Commits are authored solely by the user with no AI attribution, co-author lines, or "Generated with Claude" messages.
 
 ## Process:
 
-1. **Think about what changed:**
-   - Review the conversation history and understand what was accomplished
+1. **Assess changes:**
+   - Review the conversation history to understand what was accomplished
    - Run `git status` to see current changes
    - Run `git diff` to understand the modifications
-   - Consider whether changes should be one commit or multiple logical commits
+   - Determine whether changes should be one commit or multiple logical commits
 
-2. **Plan your commit(s):**
-   - Identify which files belong together
-   - Draft clear, descriptive commit messages
-   - Use imperative mood in commit messages
-   - Focus on why the changes were made, not just what
+2. **Plan commits:**
+   - Identify which files belong together in logical, atomic groups
+   - Draft clear, descriptive commit messages focused on why the changes were made, not just what
 
-3. **Add changes to the staging area:**
-   - Add files that you want to commit to the staging area using: `git add "<file-path>"`. Always use the exact file path with quotes to avoid any errors.
-   - Confirm the changes were added to the staging area with `git status`
+3. **Stage files:**
+   - Add files using: `git add "<file-path>"` (always quote the exact file path)
+   - Confirm staging with `git status`
 
-4. **Create commit with proper format:**
+4. **Compose the commit message:**
    - Get current branch name: `git branch --show-current`
    - Extract issue number from branch name (first part before the dash)
    - Detect issue tracker:
      - If branch starts with `hey-` → Linear issue (format: `HEY-123`)
      - Otherwise → GitHub issue (format: `#123`)
-   - Follow **Conventional Commits** format: `<type>[optional scope]: <description> <issue-ref>`
+   - Format: `<type>[optional scope]: <description> <issue-ref>`
    - Types: `feat`, `fix`, `docs`, `style`, `refactor`, `perf`, `test`, `build`, `ci`, `chore`
-   - Description: Lowercase, imperative mood, no period at end
-   - Add issue reference at the end to create a link
+   - Description: lowercase, imperative mood ("add" not "added"), no period at end
    - Examples:
-     - Linear: `feat(dashboard): add comprehensive user dashboard component with profile management HEY-123`
-     - GitHub: `fix(media): handle multiple file types and size limits in upload validation #45`
+     - Linear: `feat(dashboard): add user dashboard with profile management HEY-123`
+     - GitHub: `fix(media): handle multiple file types in upload validation #45`
      - Linear: `refactor(auth): simplify token validation logic HEY-78`
      - GitHub: `docs(api): update authentication endpoint documentation #92`
-   - NEVER add "Generated with Claude Code" or similar AI attribution
 
 5. **Execute commit:**
-   - Create the commit using: `git commit -m "FORMATTED_MESSAGE"`
-   - Confirm the commit was successful with `git status`
+   - Run: `git commit -m "FORMATTED_MESSAGE"`
+   - Confirm success with `git status`
 
-6. **Repeat steps 3-5 for each change:**
-   - If changes should be committed separately, repeat steps 2-4 for each change.
-   - If changes should be committed in the same commit, repeat steps 2-4 for each change.
-   - Confirm there are no changes left to commit with `git status`
-   - If there are no changes, exit with `echo "No changes to commit"`
-
-## Important:
-- **NEVER add co-author information or Claude attribution**
-- Always follow **Conventional Commits** format: `<type>[optional scope]: <description> <issue-ref>`
-- Types: `feat`, `fix`, `docs`, `style`, `refactor`, `perf`, `test`, `build`, `ci`, `chore`
-- Use imperative mood (e.g., "add" not "added" or "adds")
-- Description should be lowercase and descriptive
-- Issue reference format depends on tracker:
-  - Linear issues (branch `hey-X`): Use `HEY-123` format
-  - GitHub issues: Use `#123` format
-- Commits should be authored solely by the user
-- Do not include any "Generated with Claude" messages
-- Do not add "Co-Authored-By" lines
-- Write commit messages as if the user wrote them
-
-## Remember:
-- You have the full context of what was done in this session
-- Group related changes together
-- Keep commits focused and atomic when possible
-- The user trusts your judgment - they asked you to commit
+6. **Multiple commits:**
+   - Repeat steps 3-5 for each additional logical commit
+   - Confirm no uncommitted changes remain with `git status`
+   - If nothing remains, exit with `echo "No changes to commit"`

skills/create-pr/SKILL.md

@@ -1,48 +1,48 @@
 ---
 name: create-pr
-description: Create a pull request from the current branch with quality checks. Use when changes are ready for review, after committing.
+description: "Create a pull request from the current branch with lint, typecheck, and test validation. Use when changes are ready for review, after committing. Triggers: PR, open a PR, submit for review, merge request, push for review."
 allowed-tools: Bash(gh pr:*), Bash(git:*), Bash(npm test:*), Bash(npm run lint:*), Bash(npm run typecheck:*), Read, Glob, Grep
 ---
 
 # Create Pull Request
 
-You are tasked with creating a pull request from the current branch.
+The agent creates a pull request from the current branch, running lint, typecheck, and test validation before submission.
 
 ## Process:
 
 ### 1. Pre-flight Checks
 - Run `git status` to check for uncommitted changes
 - If there are uncommitted changes:
   - Show the uncommitted changes clearly
-  - Tell the user: "You have uncommitted changes. Please either:"
+  - Prompt the user: "You have uncommitted changes. Please either:"
     - "1. Exit and run `/commit` to commit your changes first (recommended)"
     - "2. Stash the changes temporarily with `git stash`"
     - "3. Continue anyway if these changes aren't meant for this PR"
-  - Wait for user's decision
+  - Wait for the user's decision
 - Run `git branch --show-current` to get the current branch name
-- Verify we're not on main/master branch
+- Verify the branch is not main/master
 
 ### 2. Code Quality Verification
 Run the following checks in parallel:
-- `npm run lint` - Check for linting issues
-- `npm run typecheck` - Check for TypeScript errors
-- `npm test` - Run the test suite
+- `npm run lint` - Linting issues
+- `npm run typecheck` - TypeScript errors
+- `npm test` - Test suite
 
 If any checks fail:
-- Show me the errors
-- Ask if I want to fix them before creating the PR
-- If yes, help fix the issues and re-run the checks
+- Display the errors
+- Ask the user whether to fix them before creating the PR
+- If yes, fix the issues and re-run the checks
 
 ### 3. Analyze Changes
-- Run `git log origin/main..HEAD --oneline` to see commits that will be in the PR
+- Run `git log origin/main..HEAD --oneline` to see commits included in the PR
 - Run `git diff origin/main...HEAD --stat` to see changed files summary
 - Run `git diff origin/main...HEAD` to understand the full changes
 - Identify the type of changes (feature, bugfix, refactor, chore, etc.)
 
 ### 4. Extract Context
-- If branch name contains an issue number (e.g., "123-feature-name"), extract it
-- Look for related issue by checking recent commits for issue references
-- Understand the purpose and scope of the changes
+- If the branch name contains an issue number (e.g., "123-feature-name"), extract it
+- Look for related issues by checking recent commits for issue references
+- Determine the purpose and scope of the changes
 
 ### 5. Draft PR Description
 Create a comprehensive PR description with:
@@ -78,13 +78,12 @@ Closes #[issue-number] (if applicable)
 ```
 
 ### 6. Review with User
-- Show me the draft PR title and description
+- Show the draft PR title and description
 - Ask: "Does this look good? Any changes needed?"
 - Wait for approval or make requested changes
 
 ### 7. Push Changes
 - Run `git push -u origin HEAD` to push the branch to remote
-- This ensures the branch exists on GitHub before creating the PR
 
 ### 8. Create the PR
 After approval, create the PR using:
@@ -99,25 +98,16 @@ gh pr create \
 Note: PRs are created as drafts by default to allow for final review before requesting feedback.
 
 ### 9. Post-Creation
-- Show me the PR URL
+- Display the PR URL
 - Run `gh pr view --web` to open the PR in browser (optional)
 - Suggest next steps:
   - Request reviews from team members
   - Add labels if needed
   - Link to project board if applicable
 
-## Important Notes:
-- Always ensure all tests pass before creating PR
-- Use conventional commit style for PR titles when possible
-- Include issue numbers for automatic linking
-- Be thorough in the description - it helps reviewers
-- Check for any .env or sensitive data in the diff
-
 ## PR Title Format Examples:
 - `feat: Add user authentication system`
 - `fix: Resolve date parsing issue in calendar`
 - `refactor: Improve appointment service performance`
 - `chore: Update dependencies to latest versions`
 - `docs: Add API documentation for new endpoints`
-
-Remember: A good PR description saves review time and provides context for future reference.

skills/fix-ci/SKILL.md

@@ -4,7 +4,7 @@ description: "Run Prisma generate, lint (auto-fix), typecheck, and tests; iterat
 allowed-tools: Bash(npx prisma generate:*), Bash(npm run db:generate:*), Bash(npm run lint:*), Bash(npm run lint:fix:*), Bash(npm run typecheck:*), Bash(npm test:*)
 ---
 
-You are running in a Next.js + TypeScript project.
+This skill operates in a Next.js + TypeScript project.
 
 ## Goal
 
@@ -14,7 +14,7 @@ Get the repo into a clean state by:
 3) passing typecheck,
 4) passing tests.
 
-Then produce a short status report (OK/FAIL for each step) plus any follow-ups I should do.
+Then produce a short status report (OK/FAIL for each step) plus any recommended follow-ups.
 
 ## What to do
 
@@ -48,21 +48,3 @@ Follow this sequence. After each step, if it fails, apply minimal, safe fixes an
     Lint: [OK|FAIL] (counts, key rules fixed)
     Typecheck: [OK|FAIL] (top 1–2 culprits)
     Tests: [OK|FAIL] (failing suites & test names)
-
-
-## Runbook (you may run these as needed)
-
-- Prisma:
-  - `npm run db:generate`
-  - `npx prisma generate`
-
-- Lint:
-  - `npm run lint`
-  - `npm run lint:fix`
-
-- Types:
-  - `npm run typecheck`
-
-- Tests:
-  - `npm test`
-