zhongwei/gh-sjungling-claude-plugins-plugins-workflow
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-30 08:57:49 +08:00
commit 922f513d97
8 changed files with 864 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files

12
.claude-plugin/plugin.json Normal file
View File

@@ -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"
]
}

3
README.md Normal file
View File

@@ -0,0 +1,3 @@
# workflow
Workflow automation commands for Git operations with conventional commits formatting for pull requests

204
commands/check-and-resolve.md Normal file
View File

@@ -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.

228
commands/clarify-issue.md Normal file
View File

@@ -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.

109
commands/commit-and-push.md Normal file
View File

@@ -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 <file1> <file2> ...`
- **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.

126
commands/fix-issue.md Normal file
View File

@@ -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: "<type>: <scope>: <subject> (#$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 "<type>(<scope>): <subject> (#$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.

121
commands/pr.md Normal file
View File

@@ -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 <file1> <file2> ...`
- **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.

61
plugin.lock.json Normal file
View File

@@ -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": []
}
}