zhongwei/gh-byborgai-prompt-collection-aitt
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-29 18:02:48 +08:00
commit b79afb344c
15 changed files with 973 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files

77
commands/code-review.md Normal file
View File

@@ -0,0 +1,77 @@
---
allowed-tools: Read, Grep, Glob, Bash, TodoWrite
description: "Analyze code quality, security, performance, and architecture"
---
# /code-review - Code Review
## Purpose
Execute comprehensive code analysis across quality, security, performance, and architecture domains.
## Usage
```bash
/code-review [branch]
```
## Execution
1. Discover and categorize files for analysis based on the diff between the current branch and the target branch:
- Use `git diff {branch_argument}...$(git branch --show-current)` where `{branch_argument}` is the first argument (defaults to 'master' if not provided)
2. Apply appropriate analysis tools and techniques:
- **Quality**: Code style, complexity, maintainability, technical debt assessment, SOLID principles compliance, error handling patterns
- **Security**: Vulnerability scanning, dependency checks, threat modeling, authentication/authorization flaws, data exposure risks, input validation
- **Performance**: Profiling, bottleneck identification, resource usage analysis, scalability assessment, Core Web Vitals (frontend), memory management (leaks, dangling pointers, buffer overflows)
- **Architecture**: Design patterns, modularity, scalability, coupling analysis, separation of concerns, future-proofing evaluation
- **Testing**: Test quality, edge case handling, test pyramid compliance (DO NOT run tests, just analyze test
- **Maintainability**: Code readability, documentation quality, code comments, naming conventions, modularity
coverage and quality)
- Based on an initial quick analysis, add additional checks if necessary
3. Generate findings with severity ratings
4. Create actionable recommendations with priorities, only if issues are found
- Severity levels:
- High: Critical issues that must be addressed immediately
- Medium: Important issues that should be resolved soon
- Low: Minor issues that can be addressed later
- List should be sorted by severity
- Include file project root relative filepaths and line numbers for each issue
- Focus on changes and the effects of those changes, not the entire file
5. Present ONLY a nicely formatted compact markdown table of text-based analysis report nothing else
- If you have positive findings, just add a tick mark next to the section that you used as a point to review
- Start with the positive findings and then list the improvements at the end
- Only include list of improvements
- Include:
- File paths in a following format: `./path/to/file.js:line_number` (DO NOT include ranges just where the issue
is)
- Issues found
- Severity
- Recommendations
### Example Output
```text
| Category | Assessment | Notes |
|----------------|------------|-------------------------------------------------------|
| Quality ✓ | Good | Clean JWT implementation following best practices |
| Security ⚠️ | Poor | Critical JWT verification vulnerability present |
| Performance ✓ | Good | Efficient key caching and library migration |
| Architecture ✓ | Good | Well-structured auth system with feature flag support |
Improvements Needed
| File | Issue | Severity | Recommendation |
|---------------------------------------------|------------------------------------------|----------|---------------------------------------------------------------------|
| ./src/util/jwt-token.ts:26 | Incorrect key selection for verification | High | Use publicKey instead of checking privateKey for token verification |
| ./src/middlewares/auth-middleware.ts:68 | Hardcoded httpOnly setting | Medium | Use consistent auth v2 flag check like in login route |
| ./src/app/portal/api/user/login/route.ts:82 | Age verification expiry inconsistency | Low | Consider using consistent expiry calculation method |
```
DO NOT include any other text, explanations, or comments outside the markdown table.
## Claude Code Integration
- Uses Glob for systematic file discovery
- Leverages Grep for pattern-based analysis
- Applies Read for deep code inspection
- Maintains structured analysis reporting

80
commands/commit-suggest.md Normal file
View File

@@ -0,0 +1,80 @@
---
allowed-tools: Read, Grep, Glob, Bash, TodoWrite, Bash(git add .), Bash(scripts/find-ticket-from-branch.sh)
argument-hint: "[--breaking] [--type <type>] [--ticket <ticket>]"
description: "This command suggests a commit message for current changes without executing the commit and copies the commit command to clipboard"
---
# /commit-suggest - Suggests a commit message for current changes
## Purpose
This command suggests a well-formatted commit message with conventional commit messages based on the current changes in the repository.
## Usage
```bash
/commit-suggest
```
Force breaking change structure with:
```bash
/commit-suggest --breaking
```
Force commit type with:
```bash
/commit-suggest --type <type>
```
Where `<type>` is one of: feat, fix, docs, style, refactor, perf, test, chore
Force ticket ID with:
```bash
/commit-suggest --ticket <ticket>
```
## What This Command Does
1. Runs `.claude/scripts/find-ticket-from-branch.sh` script to extract a related ticket ID from the current branch name and include it in the commit message if found
- If a `--ticket <ticket>` argument is provided, it MUST use that ticket ID instead of extracting from branch name
- If no ticket ID is found you MUST prompt the user and wait to provide one before proceeding any steps further
2. Checks staged files with `git status`
- If no files are staged, automatically adds all modified/new files with `git add .`
3. Analyzes the changes with `git diff --cached` to understand what is being committed. Quickly identify:
- File types modified (components, tests, docs, config, etc.)
- Nature of changes (new features, bug fixes, refactoring, etc.)
- Scope of impact (single feature, multiple areas, etc.)
4. Suggests a conventional commit message that accurately reflects the changes being committed `[<JIRA ticket reference>] <type>: <description>`
- Types: feat, fix, docs, style, refactor, perf, test, chore
- Use present tense, imperative mood
- Keep first line under 72 characters
- Be specific but concise
- Use multiple lines if necessary
- Single-line example: `[PROJ-123] fix: resolve memory leak in rendering process`
- Multi-line example:
```text
[PROJ-123] feat: add user authentication module
- Implement login and registration endpoints
- Add JWT-based authentication
- Update user model with password hashing
```
5. Outputs the suggested git commit command with the message: `git commit -m "<suggested message>"`
6. Copies the suggested git commit command to clipboard with `pbcopy`
## Important Notes
- Do NOT execute the commit, only suggest the commit message and copy the commit command to clipboard
- You MUST follow conventional commit standards when suggesting the commit message
- You MUST suggest a commit message that accurately reflects the changes being committed
- Prioritize speed - make quick, accurate assessments
- Follow conventional commit standards strictly
- Be decisive in commit type classification
- Ensure commit message accurately reflects the actual changes
- Handle edge cases gracefully (no changes, merge conflicts, etc.)

10
commands/e2e-test/plan.md Normal file
View File

@@ -0,0 +1,10 @@
# Usage
```bash
/e2e-test:plan
```
## Execution
1. Explore **$ARGUMENTS** website and gathering information about its functionalities with e2e-test-qa subagent.
2. With the gathered data, plan e2e test scenarios for later implementation into @test_plan.md file with e2e-test-planner subagent.

16
commands/e2e-test/write.md Normal file
View File

@@ -0,0 +1,16 @@
# Usage
```bash
/e2e-test:write
```
Or, to focus on a specific section of the test plan:
```bash
/e2e-test:write [test_plan_section]
```
## Execution
1. Read the @test_plan.md in the project root directory and create e2e playwright test scenarios based on unmarked items and prompted plan sections `[test_plan_section]` with e2e-test-writer subagent.
2. After finishing creating the tests, update the @test_plan.md file by marking the completed items with a checkmark.

42
commands/manual-test.md Normal file
View File

@@ -0,0 +1,42 @@
---
allowed-tools: Read, Grep, Glob, Bash, TodoWrite, WebFetch, WebSearch
description: "Analyzes merged commit changes from input and manual tests the related features on production with Playwright MCP using chrome"
---
# /manual-test - Manual test change in production
## Purpose
This command allows you to manually test changes in production with a chrome browser by reading merged commit changes and testing the related features on production using Playwright MCP.
## Usage
```bash
/manual-test [production_url] [commit_hash]
```
Or --no-verify to skip the manual test plan confirmation step:
```bash
/manual-test [production_url] [commit_hash] --no-verify
```
## What This Command Does
1. Reads and Analyzes the changes to identify the features that need to be tested based on the provided **$commit_hash** changes.
- Uses the `git diff` command to get the changes made in the specified commit only.
- Identifies the files and functionalities that have been modified or added.
- Constructs a list of features that need to be tested based on the commit changes.
- Constructs a manual test plan based on the identified features.
- You MUST output the test plan in a structured format for the user.
- If `--no-verify` is not specified you MUST ask for confirmation or modifications on the plan to proceed with the manual testing.
2. Run the manual tests on the production URL provided:
- Open the specified **$production_url** and follows the test plan created in the first step.
- DO NOT write any code or scripts, this is a manual testing process.
- Accept cookies and privacy policies if needed.
- If in doubt or the application requires authentication (login), stop and ask the user for clarification on how to proceed with the testing otherwise DO NOT wait for user to interact with the browser.
3. Outputs the results of the manual tests, including any issues, bugs, ux concerns found or confirmations of successful tests in a structured format.
- If any issues were found, provide detailed information about the issue, including steps to reproduce, expected vs actual behavior.
- If all tests pass, confirm that the features are functioning as expected.
- Close the browser after completing the tests.
- Clear `.playwright-mcp` directory to ensure no test data is left behind.

54
commands/summarize-changes.md Normal file
View File

@@ -0,0 +1,54 @@
---
allowed-tools: Read, Grep, Glob, Bash
description: "This command quickly summarizes current changes using git diff"
---
# /summarize-changes - Summarizes current changes using git diff
## Purpose
This command analyzes the current changes in the git repository using `git diff HEAD` and provides a concise and short summary of the modifications, additions, and deletions. It helps developers quickly understand the scope and impact of their changes before committing.
## Usage
```bash
/summarize-changes
```
For a shorter summary, use:
```bash
/summarize-changes --short
```
## What This Command Does
1. Analyzes the changes with `git diff HEAD` to understand what is being changed. Quickly identify:
- File types modified (components, tests, docs, config, etc.)
- Nature of changes (new features, bug fixes, refactoring, breaking changes etc.)
- Scope of impact (single feature, multiple areas, etc.)
2. Outputs a structured summary of the changes in a commit message style:
- The first line MUST be a title of the overall changes.
- If `--short` is not specified, use bullet points to organize the changes in a list format under the title and an empty line (max 5 bullet points).
- Maximum line length is 72 characters for each line in the summary.
- Use present tense, imperative mood.
- Be specific but concise.
- Prioritize speed - make quick, accurate assessments
## Important Notes
- Do NOT output any explanation on what you are doing, just the final summary.
- Do NOT ask any further questions, just provide the summary based on the changes.
- ONLY output the final summary, do NOT include any explanations, questions, next steps or additional text as the output will be used directly as a commit message.
Example Changes Summary Output:
```text
Add user authentication module
- Implement login and registration endpoints
- Add JWT-based authentication
- Update user model with password hashing
```
Example Short Changes Summary Output: "Add user authentication module with login, registration and JWT-based auth"

142
commands/update-npm-packages.md Normal file
View File

@@ -0,0 +1,142 @@
---
allowed-tools: Read, Grep, Glob, Bash, TodoWrite, Bash(npx), Bash(npm), Bash(git add .), Bash(git status), Bash(git commit), AskUserQuestion, WebSearch, WebFetch
argument-hint: '[--target <patch|minor|major>] [--package <name>] [--safe] [--skip <pkg1,pkg2,...>]'
description: 'Continuously updates NPM packages one at a time, verifies each update, and commits them until no more updates are available or user stops the process.'
---
# /update-npm-packages — Continuously update NPM packages one by one
## Purpose
Automate your "one-package-at-a-time" update flow with minimal risk. **Continuously** selects and applies eligible updates (preferring PATCH, then MINOR, optionally MAJOR), records changelog summaries, runs basic checks, and commits each update automatically. The process continues until no more updates are available or the user interrupts it.
## Usage
/update-npm-packages
/update-npm-packages --target patch
/update-npm-packages --target minor
/update-npm-packages --target major
/update-npm-packages --package <name>
/update-npm-packages --safe
/update-npm-packages --skip react,eslint,chalk
/update-npm-packages --audit-level high
/update-npm-packages --safe --audit-level critical
## Flags
--target <patch|minor|major> Specify update level: PATCH (default), MINOR, or MAJOR. Default behavior: patch→minor fallback (no major unless explicitly specified)
--package <name> Update ONLY this specific package and exit (no loop, no other packages)
--safe Enable interactive mode - pause before each update for user approval after showing changelog research
--skip <pkg1,pkg2,...> Comma-separated list of package names to skip (e.g., "react,eslint,chalk"). Packages in this list will be excluded from updates
--audit-level <low|moderate|high|critical> Set the audit severity threshold for blocking updates (default: moderate). Updates introducing vulnerabilities at or above this level will require user approval
## What This Command Does
**This command runs in a LOOP until no more updates are available or the user stops it.**
### Initial Setup (Once per run)
1. **Check git working directory**
- Run `git status --porcelain` to check for uncommitted changes
- **If working directory is NOT clean** (has uncommitted changes):
- Display the current status to the user
- Use `AskUserQuestion` to ask: "Your working directory has uncommitted changes. Would you like to: (1) stash changes and continue, (2) commit changes first, or (3) abort?"
- Responses:
- `stash` or `1` - Run `git stash push -m "Auto-stash before package updates"` and continue
- `commit` or `2` - Stop and ask user to commit manually first
- `abort` or `3` - Exit the command immediately
- **If working directory is clean**: Proceed to next step
2. **Confirm auto-update mode (only if --safe flag is NOT present)**
- **If `--safe` flag is NOT present**: Use `AskUserQuestion` tool to confirm automatic updates
- Question: "This will automatically update packages without manual approval. Continue?"
- Options: `["yes", "no"]`
- Responses:
- `yes` - Proceed with automatic updates
- `no` - Exit the command immediately
- **If `--safe` flag is present**: Skip this confirmation (user will approve each update individually)
3. **Determine ticket**
- Try `.claude/scripts/find-ticket-from-branch.sh` to get ticket ID from branch
### For Each Package (Repeats automatically)
4. **Select ONE eligible update (STEP 1)**
- **If `--package` is provided**: Use ONLY that specific package, ignore skip list, ignore target preference
- After processing this package, **exit immediately** (do not continue loop)
- If the package is not available for update, report this and exit
- **Otherwise** (no `--package` flag):
- **Apply skip list**: If `--skip` flag is provided, use that comma-separated list (e.g., `react,eslint,chalk`). Use `npx ncu --reject` with the skip list to exclude these packages
- **If no `--skip` flag is provided**: No packages are skipped (no default skip list)
- **If `--target major` is specified**: Run `npx ncu -t major` (with `--reject` if skip list exists). If none found, **exit loop**: "All updates completed"
- **If `--target minor` is specified**: Run `npx ncu -t minor` (with `--reject` if skip list exists). If none found, **exit loop**: "All updates completed"
- **If `--target patch` is specified or no target**: Run `npx ncu -t patch` (with `--reject` if skip list exists). If none found, run `npx ncu -t minor`. If none, **exit loop**: "All updates completed"
- Choose exactly ONE package per iteration
5. **Quick research (STEP 2, ≤2 minutes)**
- Look up the package changelog on npm/GitHub
- **Always display** a short summary of key changes to the user (breaking changes, new features, bug fixes)
- **Always append** the summary to `package-updates-changelog.md` at repo root (create if missing)
- If info is hard to find within ~2 minutes, write/display a brief general note and proceed
6. **User approval (STEP 2a, only with --safe flag)**
- **If `--safe` flag is present**: Display the research findings to the user
- Show: package name, current version, target version, and changelog summary
- Use `AskUserQuestion` tool to ask: "Proceed with this update? (yes/no/skip-all)"
- Responses:
- `yes` - Continue with this update
- `no` - Skip this package and move to next one
- `skip-all` - Stop the loop entirely
- **If `--safe` flag is NOT present**: Skip this step and proceed automatically
7. **Apply the update (STEP 3)**
- **Always run**: `npm install <pkg>@<targetVersion>` (e.g., `npm install inquirer@12.6.3`)
- No dry-run mode - this command actually applies updates
8. **Verify basics + Security audit (STEP 4)**
- **Security audit check**:
- Run `npm audit --audit-level=moderate --json` to check for vulnerabilities
- Parse the JSON output to count vulnerabilities by severity (critical, high, moderate, low)
- **If new critical or high vulnerabilities are introduced** (compare with pre-update baseline if available):
- Display the vulnerability details to the user (package name, severity, description)
- Use `AskUserQuestion` to ask: "This update introduces critical/high security vulnerabilities. Would you like to: (1) revert this update, (2) continue anyway, (3) try npm audit fix, or (4) view detailed audit report?"
- Responses:
- `revert` or `1` - Revert the update (`git reset --hard HEAD~1 && npm install`) and stop the loop
- `continue` or `2` - Proceed with the update despite vulnerabilities (log warning in changelog)
- `fix` or `3` - Run `npm audit fix` and re-verify, then ask for confirmation again if issues remain
- `report` or `4` - Run `npm audit` (human-readable format) and display full report, then ask again
- **If moderate or low vulnerabilities**: Log them in the changelog but continue (non-blocking)
- Unless `--no-verify`, run:
- `npm install && npx tsc --noEmit` (always, if TypeScript is present)
- Conditionally run: `npm run storybook` / `npm run eslint` / `npm run test` / `npm run build` (only if relevant scripts exist in package.json)
- **If verification scripts are not available or fail to run**: Use `AskUserQuestion` to ask the user:
- "Verification script(s) not available or failed. Would you like to: (1) skip verification and continue, (2) suggest alternative verification steps, or (3) stop the update process?"
- On errors: attempt quick fixes or **revert** (`git reset --hard HEAD~1 && npm install`) and stop the loop
9. **Commit the update (STEP 5)**
- Stage: `git add package.json package-lock.json`
- **Auto-commit** with conventional format:
`<TICKET> chore: update <package> from <oldVersion> to <newVersion>`
- Keep first line ≤72 chars; imperative mood; accurate, concise
10. **Continue to next package**
- **If `--package` was specified**: Exit immediately after committing (single package mode)
- **Otherwise**: Automatically return to STEP 1 and process the next package
- Loop continues until no more updates or user interrupts
## Important Notes
- **Continuous operation**: Processes ALL available updates automatically, one package at a time (unless `--package` is specified)
- **Single package mode**: Use `--package <name>` to update only one specific package and exit immediately
- **Prefer PATCH over MINOR**: Default behavior checks patch updates first; only moves to minor if no patches available (unless specific `--target` is used)
- **MAJOR version updates**: Use `--target major` to explicitly enable MAJOR version updates. By default, MAJOR updates are NOT processed due to potential breaking changes
- **Custom skip list**: Use `--skip pkg1,pkg2,pkg3` to exclude specific packages from updates. No default skip list (unless `--package` is used - then skip list is ignored)
- **Security audit**: Each update is automatically checked for security vulnerabilities using `npm audit`. Critical/high vulnerabilities require user approval before proceeding
- **Audit level control**: Use `--audit-level <low|moderate|high|critical>` to set the severity threshold for blocking updates (default: moderate)
- **Auto-commit each update**: Every successful update gets its own commit immediately
- **Follow conventional commits**: Format is `TICKET chore: update <package> from <old> to <new>`
- **Stop on errors**: If verification fails, revert the update and stop the loop (don't continue to next package)
- **User can interrupt**: Press Ctrl+C or stop the command at any time to halt the process
- **Automatic changelog tracking**: All update summaries are automatically written to `package-updates-changelog.md`, including any security vulnerability notes
- **Safe mode**: Use `--safe` flag for interactive approval before each update - ideal for teams that want manual review

120
commands/write-unit-tests.md Normal file
View File

@@ -0,0 +1,120 @@
---
allowed-tools: Read, Grep, Glob, Bash, TodoWrite
description: "Write unit and integration tests for new or existing code"
---
# /write-unit-tests - Write unit and integration tests
## Purpose
Generate unit and integration tests for newly added code or specified existing file to ensure functionality and reliability.
## Usage
For newly added code:
```bash
/write-unit-tests
```
Or for exisiting file:
```bash
/write-unit-tests [file_to_test]
```
## Execution
1. **Test Framework Detection**
- Identify the testing framework in use (Jest, Vitest, Mocha, PyTest, RSpec, etc.)
- Review existing test structure and conventions
- Check test configuration files and setup
- Understand project-specific testing patterns
2. **Code Analysis for Testing**
- If `[file_to_test]` is provided, analyze the specified file for testing.
- If `[file_to_test]` is NOT provided, identify the newly added code by comparing the current branch with the development branch
- Checks which files are staged with `git status`
- If 0 files are staged, automatically adds all modified and new files with `git add`
- Use `git diff` to analyze changes, compare to master/main or branch name given from arguments: **$ARGUMENTS**
- Analyze the code that needs testing, ONLY create tests for newly added code or `[file_to_test]` if provided.
- Identify public interfaces and critical business logic
- Map out dependencies and external interactions
- Understand error conditions and edge cases
3. **Test Strategy Planning**
- Determine test levels needed:
- Unit tests for individual functions/methods
- Integration tests for component interactions
- Plan test coverage goals and priorities
- Identify mock and stub requirements
4. **Unit Test Implementation**
- Test individual functions and methods in isolation
- Cover happy path scenarios first
- Test edge cases and boundary conditions
- Test error conditions and exception handling
- Use proper assertions and expectations
5. **Test Structure and Organization**
- Follow the AAA pattern (Arrange, Act, Assert)
- Use descriptive test names that explain the scenario
- Group related tests using test suites/describe blocks
- Keep tests focused and atomic
6. **Mocking and Stubbing**
- Mock external dependencies and services
- Stub complex operations for unit tests
- Use proper isolation for reliable tests
- Avoid over-mocking that makes tests brittle
7. **Data Setup and Teardown**
- Create test fixtures and sample data
- Set up and tear down test environments cleanly
- Use factories or builders for complex test data
- Ensure tests don't interfere with each other
8. **Integration Test Writing**
- Test component interactions and data flow
- Test API endpoints with various scenarios
- Test database operations and transactions
- Test external service integrations
9. **Error and Exception Testing**
- Test all error conditions and exception paths
- Verify proper error messages and codes
- Test error recovery and fallback mechanisms
- Test validation and security scenarios
10. **Security Testing**
- Test authentication and authorization
- Test input validation and sanitization
- Test for common security vulnerabilities
- Test access control and permissions
11. **Test Utilities and Helpers**
- Create reusable test utilities and helpers
- Build test data factories and builders
- Create custom matchers and assertions
- Set up common test setup and teardown functions
## Output and Important Notes
- The output is a set of unit and integration tests formatted for the appropriate testing framework.
- Include comments where necessary to explain complex logic or edge cases.
- Make sure every function or component has corresponding tests.
- DO NOT modify, update, or refactor any implementation (non-test) code under any circumstances.
- If a test is failing due to a mismatch with the implementation, update ONLY the test code to accurately reflect the current implementation, unless explicitly instructed otherwise.
- If you believe the implementation is incorrect, DO NOT change it; instead, leave a comment in the test file describing the suspected issue for human review.
- Run linter and formatter on the test files to ensure they adhere to the project's coding standards.
- After linter issue fixes rerun the tests to ensure they still pass, fix any issues that arise after the linter changes. DO NOT stop fixing until all tests pass.