commit 922f513d97eecf4b47d6708af8e9d9347cebed8e Author: Zhongwei Li Date: Sun Nov 30 08:57:49 2025 +0800 Initial commit diff --git a/.claude-plugin/plugin.json b/.claude-plugin/plugin.json new file mode 100644 index 0000000..fa5898b --- /dev/null +++ b/.claude-plugin/plugin.json @@ -0,0 +1,12 @@ +{ + "name": "workflow", + "description": "Workflow automation commands for Git operations with conventional commits formatting for pull requests", + "version": "1.0.0", + "author": { + "name": "Scott", + "email": "scott.jungling@gmail.com" + }, + "commands": [ + "./commands" + ] +} \ No newline at end of file diff --git a/README.md b/README.md new file mode 100644 index 0000000..e9f7ce5 --- /dev/null +++ b/README.md @@ -0,0 +1,3 @@ +# workflow + +Workflow automation commands for Git operations with conventional commits formatting for pull requests diff --git a/commands/check-and-resolve.md b/commands/check-and-resolve.md new file mode 100644 index 0000000..bfe0302 --- /dev/null +++ b/commands/check-and-resolve.md @@ -0,0 +1,204 @@ +--- +description: Run npm run check:all if available and resolve all issues found +preapprovedTools: + - Bash(npm:*) + - Bash(git:*) + - Read(**/*.*) + - Edit(**/*.*) + - Write(**/*.*) + - Grep + - Glob + - TodoWrite +--- + +You are tasked with running quality checks and resolving all issues found. Follow these steps: + +# Workflow Overview + +```mermaid +flowchart TD + Start([Start]) --> DetectEnv[Run npm run to list scripts] + DetectEnv --> HasScript{check:all available?} + + HasScript -->|No| AskUser[Ask about alternative scripts] + HasScript -->|Yes| RunChecks[Run npm run check:all] + + RunChecks --> ParseOutput[Parse errors, warnings, failures] + ParseOutput --> CreateTodos[Create TodoWrite list for all issues] + + CreateTodos --> HasIssues{Issues found?} + HasIssues -->|No| Success[All checks pass] + HasIssues -->|Yes| NextIssue[Get next issue from todo] + + NextIssue --> MarkInProgress[Mark todo as in_progress] + MarkInProgress --> ReadCode[Read affected files] + ReadCode --> UnderstandIssue[Analyze root cause] + + UnderstandIssue --> FixIssue[Apply targeted fix with Edit] + FixIssue --> Verify[Re-run npm run check:all] + + Verify --> FixWorked{Issue resolved?} + FixWorked -->|Yes| MarkComplete[Mark todo as completed] + FixWorked -->|No| Attempts{Attempts < 3?} + + Attempts -->|Yes| TryAgain[Try alternative approach] + TryAgain --> ReadCode + Attempts -->|No| MarkBlocked[Mark as blocked, ask user] + + MarkComplete --> MoreIssues{More issues?} + MarkBlocked --> MoreIssues + + MoreIssues -->|Yes| NextIssue + MoreIssues -->|No| FinalCheck[Run full npm run check:all] + + FinalCheck --> AllPassed{All checks pass?} + AllPassed -->|No| NewIssues[Add new issues to todo] + NewIssues --> NextIssue + AllPassed -->|Yes| Summary[Provide completion summary] + + Summary --> End([End]) + Success --> End + AskUser --> End + + style Start fill:#90EE90 + style End fill:#90EE90 + style Success fill:#90EE90 + style MarkBlocked fill:#FFB6C1 + style AllPassed fill:#87CEEB +``` + +# 1. Environment Detection + +First, check if this is a Node.js project and if the check:all script is available: + +1. Run `npm run` to list all available scripts +2. Check if `check:all` is in the output +3. If the script is not available, inform the user and ask if they want to: + - Run alternative scripts (list the available ones from npm run output) + - Skip the check phase and just review existing issues + +# 2. Run Quality Checks + +If `npm run check:all` is available: + +1. **Run the check command**: + ```bash + npm run check:all + ``` + +2. **Capture and analyze output**: + - Parse the output to identify all errors, warnings, and failures + - Categorize issues by type: + - Type errors (TypeScript) + - Linting errors (ESLint, etc.) + - Test failures + - Formatting issues + - Other build/check errors + +3. **Create a task plan** using TodoWrite: + - Create one todo item for each distinct issue or group of related issues + - Use descriptive names like "Fix type error in auth.ts:42" or "Resolve 5 ESLint errors in utils/" + - Set the first task to in_progress + +# 3. Resolve Issues Systematically + +For each issue found: + +1. **Read affected files**: + - Use Read tool to examine the problematic code + - Understand the context and root cause + +2. **Fix the issue**: + - Use Edit tool to make targeted fixes + - Ensure fixes are minimal and focused + - Prefer fixing root causes over suppressing warnings + +3. **Verify the fix**: + - Re-run `npm run check:all` to confirm the issue is resolved + - If new issues appear, add them to the todo list + - Mark the current todo as completed when verified + +4. **Move to next issue**: + - Update TodoWrite to mark current task completed + - Set next task to in_progress + - Continue until all issues are resolved + +# 4. Final Verification + +After resolving all issues: + +1. **Run full check suite**: + ```bash + npm run check:all + ``` + +2. **Verify clean output**: + - Ensure all checks pass with no errors or warnings + - If any issues remain, add them to the todo list and continue resolving + +3. **Summary**: + - Provide a summary of all issues resolved + - Note any issues that couldn't be automatically fixed (if any) + +# Resolution Strategies + +## Type Errors +- Add missing type annotations +- Fix type mismatches +- Add proper null/undefined checks +- Update interface definitions if needed +- Consider using type assertions only as last resort + +## Linting Errors +- Fix formatting issues +- Remove unused variables/imports +- Add missing dependencies to useEffect/useCallback +- Fix accessibility issues (a11y) +- Resolve complexity warnings with refactoring + +## Test Failures +- Update test expectations if code behavior changed correctly +- Fix broken test setup/teardown +- Add missing mocks or test data +- Fix async timing issues +- Update snapshots if UI changed intentionally + +## Formatting Issues +- Let the formatter handle these automatically +- Run `npm run format` or similar if available +- Ensure .prettierrc or similar config is respected + +# Important Rules + +- **Never suppress errors** without understanding them - always fix the root cause +- **Keep changes focused** - one issue at a time +- **Verify after each fix** - don't accumulate untested changes +- **Use TodoWrite** to track progress and give user visibility +- **Ask for clarification** if an issue's resolution is ambiguous +- **Document breaking changes** if any fixes require API changes +- **Preserve functionality** - fixes should not change working behavior +- **Stay idempotent** - re-running should be safe if interrupted + +# Error Handling + +If a fix creates new issues: +- Undo the problematic change +- Add the new issue to the todo list +- Try an alternative approach +- Ask user for guidance if stuck + +If stuck on an issue for more than 2-3 attempts: +- Mark it in the todo list as blocked +- Ask the user for guidance +- Move to next issue and return later + +# Workflow Summary + +1. Detect environment and check if npm run check:all is available +2. Run checks and capture all issues +3. Create comprehensive todo list with all issues +4. Resolve issues one by one, verifying each fix +5. Re-run full check suite to confirm all issues resolved +6. Provide summary of work completed + +Proceed with running the checks and resolving all issues found. diff --git a/commands/clarify-issue.md b/commands/clarify-issue.md new file mode 100644 index 0000000..98bfdcb --- /dev/null +++ b/commands/clarify-issue.md @@ -0,0 +1,228 @@ +--- +allowed-tools: Bash(gh issue view:*), + Bash(gh issue edit:*), + Bash(git status:*), + AskUserQuestion, + Read(**/*.md), + Write(**/*.md), + Edit(**/*.md), + mcp__use_browser, + mcp__plugin_ui-engineering_figma-mcp__* +argument-hint: [issue-url] +description: Clarify ambiguities in a GitHub issue through structured questioning +--- + +Clarify ambiguities in GitHub issue: $ARGUMENTS + +## Argument Validation + +- Ensure an issue URL or number was provided and prompt the user if not. +- Extract the issue number from the URL if a full URL was provided. + +## Context Gathering + +Fetch the issue details using `gh`: + +```bash +gh issue view "$ISSUE_NUMBER" --json number,title,body,url,labels,state +``` + +Parse the issue title and body to understand the current specification. + +## Ambiguity Detection + +Analyze the issue against these nine categories to identify gaps: + +1. **Functional Scope & Behavior** + - What specific capabilities must be delivered? + - What's explicitly out of scope? + - How should the feature behave in normal conditions? + +2. **Domain & Data Model** + - What entities, attributes, and relationships are involved? + - What validation rules apply? + - Are there existing data structures to extend or new ones to create? + +3. **Interaction & UX Flow** + - What's the user journey or workflow? + - What inputs are required and what outputs are produced? + - How should errors or feedback be communicated to users? + +4. **Non-Functional Quality Attributes** + - What are the performance, security, or accessibility requirements? + - What scale or load must be supported? + - Are there compliance or regulatory constraints? + +5. **Integration & External Dependencies** + - What APIs, services, or systems must integrate? + - What data formats or protocols are required? + - Are there authentication or authorization requirements? + +6. **Edge Cases & Failure Handling** + - What happens with invalid, missing, or malformed input? + - How should timeouts, network failures, or unavailable services be handled? + - What error states need graceful degradation? + +7. **Constraints & Tradeoffs** + - What technical or business constraints exist? + - What tradeoffs between speed, quality, scope are acceptable? + - What's the priority if resources are limited? + +8. **Terminology & Consistency** + - Are terms used consistently throughout the spec? + - Do any terms need clear definitions? + - Are there naming conventions to follow? + +9. **Completion Signals** + - What defines "done" for this feature? + - What testing is required? + - What documentation must be updated? + +For each category, assign a status: +- **Clear**: Well-defined and actionable +- **Partial**: Some information present but gaps remain +- **Missing**: No information or critically incomplete + +## Question Generation + +Generate up to 5 targeted clarification questions that: +- Address the highest-impact ambiguities (Partial or Missing categories) +- Materially affect architecture, data modeling, testing, UX, operations, or compliance +- Exclude trivial stylistic preferences +- Can be answered with either: + - Multiple-choice (2-4 options with clear descriptions) + - Short-phrase responses + +For each question: +- Clearly state what's ambiguous and why it matters +- If multiple-choice, identify and explain the recommended option +- Ensure answers will directly inform implementation decisions + +## Interactive Clarification + +Use the `AskUserQuestion` tool to present clarifications: + +1. Present questions one at a time (or in small batches if related) +2. For multiple-choice questions: + - Set the recommended option based on best practices or issue context + - Provide clear descriptions for each option explaining tradeoffs + - Use `multiSelect: false` for mutually exclusive choices +3. For open-ended questions: + - Provide example options with an "Other" choice + - Keep option descriptions concise but informative + +Example AskUserQuestion usage: +``` +{ + "questions": [ + { + "question": "What should happen when a user tries to perform this action without authentication?", + "header": "Auth handling", + "multiSelect": false, + "options": [ + { + "label": "Redirect to login", + "description": "Send user to login page with return URL. Standard web app pattern." + }, + { + "label": "Show 401 error", + "description": "Return 401 status. Better for API endpoints." + }, + { + "label": "Graceful degradation", + "description": "Show limited functionality without auth. Good for public features." + } + ] + } + ] +} +``` + +## Answer Integration + +After receiving answers from the user: + +1. **Create clarifications file** (if it doesn't exist): + - Write to `/tmp/claude/issue-$ISSUE_NUMBER-clarifications.md` + - Format with: + ```markdown + # Clarifications for Issue #$ISSUE_NUMBER + + ## Date: YYYY-MM-DD + + ### [Category Name] + + **Q:** [Question text] + **A:** [User's answer with reasoning if applicable] + + --- + ``` + +2. **Update existing clarifications** (if file exists): + - Use Read tool to load existing content + - Use Edit tool to append new Q&A under today's date + - Ensure no duplicate questions + +3. **Update the GitHub issue**: + - Write updated issue body to `/tmp/claude/issue-$ISSUE_NUMBER-body.md` + - Add or update a `## Clarifications` section at the end + - Include date-stamped Q&A entries + - Use Read tool to verify content + - Update issue: `gh issue edit $ISSUE_NUMBER --body-file /tmp/claude/issue-$ISSUE_NUMBER-body.md` + +4. **Validate**: + - Check for contradictions with previous answers + - Ensure terminology consistency + - Verify formatting is preserved + +## Session Management + +- Maximum 10 questions per session (stop earlier if all critical gaps addressed) +- Allow user to signal completion with "done", "stop", or "skip" +- If quota exhausted, report any remaining high-impact items + +## Completion Report + +After clarification session ends, provide: + +```markdown +## Clarification Summary + +**Questions asked:** X +**Questions answered:** Y +**Issue updated:** #$ISSUE_NUMBER + +**Coverage by Category:** +| Category | Status | Notes | +|----------|--------|-------| +| Functional Scope | Clear/Partial/Missing | ... | +| Domain Model | Clear/Partial/Missing | ... | +| ... | ... | ... | + +**Next Steps:** +- [Suggested action based on coverage] +- [Any remaining ambiguities to address] +- [Ready to proceed with implementation? Yes/No] +``` + +## Important Rules + +- NEVER ask trivial or stylistic questions that don't affect implementation +- NEVER speculate about tech stack unless blocking functional clarity +- ALWAYS respect "done"/"stop" signals +- ALWAYS update the issue incrementally after each answer to prevent data loss +- ALWAYS provide reasoning for recommended options in multiple-choice questions +- Keep questions focused and actionable +- Prioritize questions by implementation impact + +## Workflow Summary + +1. Fetch issue with `gh issue view` → extract title and body +2. Analyze against 9-category taxonomy → identify ambiguities +3. Generate up to 5 high-impact clarification questions +4. Use `AskUserQuestion` tool → collect structured responses +5. Write clarifications to temp file → update issue with `gh issue edit --body-file` +6. Validate for consistency and contradictions +7. Provide coverage summary and next steps + +Proceed with clarifying the issue following these guidelines. diff --git a/commands/commit-and-push.md b/commands/commit-and-push.md new file mode 100644 index 0000000..26e1dcc --- /dev/null +++ b/commands/commit-and-push.md @@ -0,0 +1,109 @@ +--- +description: Create a conventional commit and push to current branch +args: + - name: pre-commit-action + description: Optional action to perform before committing (e.g., "run tests", "update version", "lint code") +preapprovedTools: + - Bash(git:*) + - Read(**/*.*) + - Grep + - Glob + - TodoWrite +--- + +You are tasked with creating a conventional commit and pushing to the current branch following these strict requirements: + +# Pre-Commit Action + +If the user provided a pre-commit action argument ($1), perform that action FIRST before proceeding with the commit workflow: +- Read and understand what action is requested +- Execute the requested action (e.g., run tests, update version numbers, run linters) +- Verify the action completed successfully +- If the action fails, STOP and report the error - do not proceed with commit +- If the action succeeds, continue with the commit workflow below + +If no pre-commit action was specified, proceed directly to the commit workflow. + +# Conventional Commit Types +Use these standard types for commits: +- `feat`: New feature +- `fix`: Bug fix +- `docs`: Documentation only +- `style`: Code style changes (formatting, no logic change) +- `refactor`: Code refactoring (no functional changes) +- `perf`: Performance improvements +- `test`: Adding or updating tests +- `chore`: Build process, dependencies, tooling +- `ci`: CI/CD configuration changes +- `revert`: Reverting previous commits + +# Commit Creation Workflow + +1. **Review changes**: + - Run `git status` to see all changed files + - Run `git diff` to see unstaged changes + - Run `git diff --staged` to see already-staged changes + +2. **Review commit style**: + - Run `git log -5 --oneline` to understand the project's commit message style + +3. **Selectively stage files** (NEVER use `git add .` or `git add -A`): + - Review the output of `git status` carefully + - Stage files individually using `git add ...` + - **EXCLUDE these file patterns** (never stage): + - Secret/credential files: `.env`, `.env.*`, `credentials.json`, `secrets.*`, `*.key`, `*.pem` + - IDE configs: `.vscode/`, `.idea/`, `*.swp`, `*.swo`, `.DS_Store` + - Build artifacts: `node_modules/`, `dist/`, `build/`, `target/`, `*.log` + - Temporary files: `tmp/`, `temp/`, `*.tmp`, `*.cache` + - Personal configs: `.env.local`, `config.local.*` + - If you detect any of these patterns in changed files, **STOP and ask the user** before proceeding + - Only stage files that are directly related to the changes being committed + +4. **Create conventional commit**: + - **Title format**: `{type}({scope}): {short description}` or `{type}: {short description}` + - Title should be max 72 characters + - Use imperative mood ("add feature" not "added feature") + - **Extended description**: Multi-line explanation of: + - What changed and why + - Any breaking changes or important notes + - Related issues or tickets + - NEVER include co-authorship credit to Claude or any AI agent + - Format: Use git commit with heredoc for proper multi-line formatting + +Example commit: +```bash +git commit -m "$(cat <<'EOF' +feat(auth): add user authentication system + +Implements JWT-based authentication with refresh tokens. +Includes middleware for protected routes and token validation. +Adds login, logout, and token refresh endpoints. + +Breaking change: API now requires Authorization header for protected routes. +EOF +)" +``` + +5. **Push changes**: + - Get current branch name: `git branch --show-current` + - Push only the current branch: `git push origin {current-branch}` + - If the branch doesn't exist on remote, use: `git push -u origin {current-branch}` + +# Important Rules +- NEVER add "Co-Authored-By: Claude" or any AI attribution to commits +- NEVER use `git add .` or `git add -A` - always stage files selectively +- Always use conventional commit format +- Keep commit titles concise and descriptive (max 72 chars) +- Include meaningful extended descriptions for context +- Ensure commits are atomic and focused +- STOP and ask user if potentially sensitive files are detected in changes +- Only push the current branch (no tags, no other branches) + +# Workflow Summary +1. Review changes → `git status`, `git diff` +2. Review recent commits → `git log -5 --oneline` +3. **Selectively stage files** (review each file, exclude sensitive/generated files) +4. Create conventional commit with extended description using heredoc +5. Push current branch to remote + +Proceed with creating the commit and pushing following these guidelines. diff --git a/commands/fix-issue.md b/commands/fix-issue.md new file mode 100644 index 0000000..487c6ae --- /dev/null +++ b/commands/fix-issue.md @@ -0,0 +1,126 @@ +--- +allowed-tools: Bash(gh issue view:*), + Bash(gh issue comment:*), + Bash(gh pr create:*), + Bash(gh pr list:*), + Bash(git status:*), + Bash(git branch:*), + Bash(git switch:*), + Bash(git checkout:*), + Bash(git add:*), + Bash(git commit:*), + Bash(git push:*), + Bash(lsof:*) +argument-hint: [issue-number] +description: Analyze and fix a GitHub issue end-to-end with plan, branch, tests, and draft PR +--- + +Analyze and fix GitHub issue #$ARGUMENTS. + +## Argument validation + +- Ensure an issue number was provided and prompt the user if not. + +## Context + +- Issue (JSON): `gh issue view "$ARGUMENTS" --json number,title,body,url,labels,assignees,state,author,createdAt,updatedAt` +- Issue (human): `gh issue view "$ARGUMENTS"` +- Current branch: `git branch --show-current` +- Git status: `git status -sb` +- Open PRs referencing #$ARGUMENTS: `gh pr list --state open --search "$ARGUMENTS in:title,body" --json number,title,url,headRefName,author` + +## Inputs + +- $ARGUMENTS = issue number (required) +- Type and branch slug are auto-inferred from the issue (no additional args). + +## Your task + +1. Analysis and Clarification (use subagent) + + - Launch a general-purpose subagent to analyze the issue and gather requirements + - The subagent should: + - Read and summarize the issue: problem, acceptance criteria, scope, and risks + - Identify any ambiguities or missing information + - **Use the AskUserQuestion tool** to ask structured clarifying questions about: + - Edge cases and error handling requirements + - Scope boundaries (what's in/out of scope) + - Implementation approach preferences + - Testing expectations and coverage requirements + - Any missing acceptance criteria + - Breaking changes or migration concerns + - Return a comprehensive summary including user responses + - Wait for the subagent to complete and review the analysis before proceeding + +2. Plan (propose and wait for confirmation) + + - Based on the analysis and clarification responses, propose a minimal, testable plan (files to change, tests to add, migration notes if any). + - Post the proposed plan to the issue: + - Create temp file: `gh issue comment $ARGUMENTS --edit-last --body-file /dev/null 2>/dev/null || true` (to get template if available) + - Write plan to temp file: Use Write tool to create `/tmp/claude/issue-comment-$ARGUMENTS.md` with the concise plan summary + - Use Read tool to verify the content if needed + - Post comment: `gh issue comment $ARGUMENTS --body-file /tmp/claude/issue-comment-$ARGUMENTS.md` + - **Wait for user confirmation before making repo changes.** + +3. Branch management + + - If on main or default branch, create a branch: + - Type: infer from labels/title (fix|feat|chore|docs|refactor). Default: fix. + - Slug: derive from issue title (kebab-case, <=50 chars). Fallback: "issue-$ARGUMENTS". + - Branch name: {type}/issue-$ARGUMENTS-{slug} + - Commands to use (after approval): + - git switch -c {branch} OR git checkout -b {branch} + +4. Code search and implementation + + - Identify impacted modules and cross-cutting concerns. + - Implement the fix/feature with small, logical commits. + +5. Tests and local verification + + - Prefer unit tests. If integration tests needed, call that out. + - Heuristics: + - If `package.json` exists: run `npm run check:all` and `npm test` if available. + - If a Python project: run `uvx pytest` and `ruff` if configured. + - If Go: run `go test ./...`. + - Ensure dev server on port 3000 is not already running before starting any local server. + +6. Quality gates + + - Ensure code passes linting, formatting, and type checks available in the repo. + - Keep changes minimal and well-scoped. + +7. Commit + + - Use a conventional commit message; include issue reference. + - Example: ": : (#$ARGUMENTS)" (type inferred) + - Do NOT attribute to Claude in the commit message. + +8. PR (draft) with Problem/Solution format + + - Push branch and create a draft PR that links the issue: + - Write PR body to temp file using Write tool at `/tmp/claude/pr-body-issue-$ARGUMENTS.md`: + ```markdown + ## Problem + + [Describe what's broken or missing] + + ## Solution + + [Explain what changed and why] + + ## Testing + + [How to test these changes] + + Fixes #$ARGUMENTS + ``` + - Use Edit tool to update the temp file with actual problem/solution descriptions + - Use Read tool to verify the content before creating PR + - Create PR: `gh pr create --draft --title "(): (#$ARGUMENTS)" --body-file /tmp/claude/pr-body-issue-$ARGUMENTS.md` + +## Notes + +- Use GitHub CLI (gh) for all GitHub operations. +- Keep interactions idempotent and ask for confirmation before pushing or creating PRs. +- If repo tooling is unclear, ask whether to enable/add tests or linters for this fix. diff --git a/commands/pr.md b/commands/pr.md new file mode 100644 index 0000000..94908c3 --- /dev/null +++ b/commands/pr.md @@ -0,0 +1,121 @@ +--- +description: Create a pull request with conventional commits formatting +preapprovedTools: + - Bash(git:*) + - Bash(gh:*) + - Read(**/*.*) + - Grep + - Glob + - TodoWrite +--- + +You are tasked with creating a pull request following these strict requirements: + +# Branch Management +1. Check the current branch using `git branch --show-current` +2. Get the default branch using `git symbolic-ref refs/remotes/origin/HEAD | sed 's@^refs/remotes/origin/@@'` +3. If we're on the main/default branch: + - Analyze the changes to determine the appropriate conventional commit type + - Create a new branch using the format: `{type}/{short-description}` (e.g., `fix/auth-token-validation`, `feat/add-dark-mode`) + - The short-description should be kebab-case and descriptive + - Check out the new branch + +# Conventional Commit Types +Use these standard types for commits and branch names: +- `feat`: New feature +- `fix`: Bug fix +- `docs`: Documentation only +- `style`: Code style changes (formatting, no logic change) +- `refactor`: Code refactoring (no functional changes) +- `perf`: Performance improvements +- `test`: Adding or updating tests +- `chore`: Build process, dependencies, tooling +- `ci`: CI/CD configuration changes +- `revert`: Reverting previous commits + +# Commit Creation +1. Review all staged and unstaged changes using `git status` and `git diff` +2. Review recent commit messages for style consistency using `git log -5 --oneline` +3. **Selectively stage files** (NEVER use `git add .` or `git add -A`): + - Review the output of `git status` carefully + - Stage files individually using `git add ...` + - **EXCLUDE these file patterns** (never stage): + - Secret/credential files: `.env`, `.env.*`, `credentials.json`, `secrets.*`, `*.key`, `*.pem` + - IDE configs: `.vscode/`, `.idea/`, `*.swp`, `*.swo`, `.DS_Store` + - Build artifacts: `node_modules/`, `dist/`, `build/`, `target/`, `*.log` + - Temporary files: `tmp/`, `temp/`, `*.tmp`, `*.cache` + - Personal configs: `.env.local`, `config.local.*` + - If you detect any of these patterns in changed files, **STOP and ask the user** before proceeding + - Only stage files that are directly related to the changes being committed +4. Create commits with: + - **Title format**: `{type}({scope}): {short description}` or `{type}: {short description}` + - Title should be max 72 characters + - Use imperative mood ("add feature" not "added feature") + - **Extended description**: Multi-line explanation of: + - What changed and why + - Any breaking changes or important notes + - Related issues or tickets + - NEVER include co-authorship credit to Claude or any AI agent + - Format: Use git commit with heredoc for proper multi-line formatting + +Example commit: +```bash +git commit -m "$(cat <<'EOF' +feat(auth): add user authentication system + +Implements JWT-based authentication with refresh tokens. +Includes middleware for protected routes and token validation. +Adds login, logout, and token refresh endpoints. + +Breaking change: API now requires Authorization header for protected routes. +EOF +)" +``` + +# Pull Request Creation +1. Push the branch to remote with tracking: `git push -u origin {branch-name}` +2. Create PR using `gh pr create` with: + - **PR Title**: Same format as commit title - `{type}({scope}): {short description}` + - **PR Description**: Use Problem & Solution format with temp file: + - Write initial template to temp file using Write tool at `/tmp/claude/pr-body.md`: + ```markdown + ## Problem + [Describe the problem being solved, why this change is needed, or what gap this fills] + + ## Solution + [Explain the approach taken to solve the problem] + [Include specific implementation details] + [Note any important technical decisions] + + ## Testing + [How to test these changes] + + ## Related Issues + [Link any related issues if applicable] + ``` + - Use Edit tool to replace placeholders with actual content based on git diff and commit analysis + - Use Read tool to verify the final content before creating PR + - Create PR: `gh pr create --title "type(scope): description" --body-file /tmp/claude/pr-body.md` + +3. Return the PR URL to the user + +# Important Rules +- NEVER add "Co-Authored-By: Claude" or any AI attribution to commits or PRs +- NEVER push directly to main/default branch +- NEVER use `git add .` or `git add -A` - always stage files selectively +- Always use conventional commit format +- Keep commit titles concise and descriptive (max 72 chars) +- Include meaningful extended descriptions for context +- Ensure commits are atomic and focused +- Use Problem & Solution format for all PR descriptions +- STOP and ask user if potentially sensitive files are detected in changes + +# Workflow Summary +1. Check current branch → create feature branch if on main +2. Review changes with `git status` and `git diff` → determine commit type +3. **Selectively stage files** (review each file, exclude sensitive/generated files) +4. Create conventional commit with extended description +5. Push branch → create PR with Problem & Solution format +6. Return PR URL + +Proceed with creating the pull request following these guidelines. diff --git a/plugin.lock.json b/plugin.lock.json new file mode 100644 index 0000000..96a6d79 --- /dev/null +++ b/plugin.lock.json @@ -0,0 +1,61 @@ +{ + "$schema": "internal://schemas/plugin.lock.v1.json", + "pluginId": "gh:sjungling/claude-plugins:plugins/workflow", + "normalized": { + "repo": null, + "ref": "refs/tags/v20251128.0", + "commit": "788f8c12aba11e2215b2844ec867b1f9abf4f4ca", + "treeHash": "0bc1fa1ebf586d59daaccac352a997801278d640df84ec29f118b7148d67d7e0", + "generatedAt": "2025-11-28T10:28:23.876095Z", + "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": "workflow", + "description": "Workflow automation commands for Git operations with conventional commits formatting for pull requests", + "version": "1.0.0" + }, + "content": { + "files": [ + { + "path": "README.md", + "sha256": "57ec432a4549d7cc0342be4e6e03988d40233b3e302440a741860542e2144aa6" + }, + { + "path": ".claude-plugin/plugin.json", + "sha256": "ff87270313116ec3608cbd5ae49314e8b72bafef0c6c8a395df21058b501b1f7" + }, + { + "path": "commands/clarify-issue.md", + "sha256": "49c71069004e7dc9b287ae7ea313b0540faba5293d0aece547baf00b084a624e" + }, + { + "path": "commands/pr.md", + "sha256": "940465e290777ee71d63c69720b37d883d1cc9b3d6dc6b64c1edb911c26e2ea2" + }, + { + "path": "commands/check-and-resolve.md", + "sha256": "7e9658de8a44fa054d6d37f3281720cf44bc7ce5ceba67385255e56c80707d1f" + }, + { + "path": "commands/fix-issue.md", + "sha256": "509390a1d83579685c66c8b998e817fbb1bf24bae867fac413e53c5fc1858391" + }, + { + "path": "commands/commit-and-push.md", + "sha256": "da7a36d504592c594c96ee430220085325c771de6a60e8056ae84bc69d954f3c" + } + ], + "dirSha256": "0bc1fa1ebf586d59daaccac352a997801278d640df84ec29f118b7148d67d7e0" + }, + "security": { + "scannedAt": null, + "scannerVersion": null, + "flags": [] + } +} \ No newline at end of file