Initial commit

.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"
+  ]
+}

README.md

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

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.

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.

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

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: "<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.

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

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