From go-workflow
Starts GitHub issue work: fetches details via gh CLI, creates worktree/branch, detects bug/feature, explores codebase, proposes design before implementing.
npx claudepluginhub gopherguides/gopher-ai --plugin go-workflowThis skill uses the workspace's default tool permissions.
Full issue-to-PR workflow: fetch issue, create worktree, detect type, implement with TDD, verify, and submit PR.
Generates design tokens/docs from CSS/Tailwind/styled-components codebases, audits visual consistency across 10 dimensions, detects AI slop in UI.
Records polished WebM UI demo videos of web apps using Playwright with cursor overlay, natural pacing, and three-phase scripting. Activates for demo, walkthrough, screen recording, or tutorial requests.
Delivers idiomatic Kotlin patterns for null safety, immutability, sealed classes, coroutines, Flows, extensions, DSL builders, and Gradle DSL. Use when writing, reviewing, refactoring, or designing Kotlin code.
Full issue-to-PR workflow: fetch issue, create worktree, detect type, implement with TDD, verify, and submit PR.
$start-issue <issue-number>
gh) installed and authenticatedoriginISSUE_NUM="<issue-number>"
gh issue view "$ISSUE_NUM" --json title,body,labels,state,comments
Confirm the issue exists and is open. Read the title, body, labels, and comments to understand the requirements.
Ask the user: "Would you like to create a worktree for isolated work on issue #$ISSUE_NUM?"
$create-worktree skill with the issue number, then continue working from the worktree pathIf already inside a git worktree (check: git rev-parse --git-dir differs from git rev-parse --git-common-dir), skip this step entirely.
Determine if this is a bug fix or new feature by checking:
Labels (most reliable):
bug, fix, defect, error, regression, crashenhancement, feature, feat, new, improvement, requestTitle and body patterns:
If uncertain, ask the user whether this is a bug fix or new feature.
Skip this step if a worktree was created (the branch already exists).
For bugs:
git checkout -b "fix/$ISSUE_NUM-<short-description>"
For features:
git checkout -b "feat/$ISSUE_NUM-<short-description>"
Branch protection: Never commit directly to main or master. Verify you are on the new branch before proceeding.
Before writing any code:
Do not start coding until the user confirms the approach.
Propose 2-3 approaches with concrete trade-offs:
For trivial features (single function, obvious implementation), state your plan and proceed unless the user objects.
For non-trivial features (new package, API changes, data model), wait for explicit user approval.
IRON LAW: No implementation code before tests exist and fail.
For bugs:
go test -run TestNameOfFailingTest ./path/to/package/...
For features: write comprehensive tests covering happy path, edge cases, and error conditions.
go test ./path/to/package/...
All must pass before proceeding:
go build ./...
go test ./...
golangci-lint run # if available
If any step fails, fix the issue and re-run.
Scan changed files for common issues:
filepath.Join without filepath.Clean)exec.Command with unsanitized inputStage and commit with a conventional commit message:
git add <relevant-files>
git commit -m "<type>(<scope>): <subject>
Fixes #$ISSUE_NUM"
Push the branch:
git push -u origin "$(git branch --show-current)"
Create a PR (invoke $create-pr or create manually):
gh pr create --title "<type>(<scope>): <subject>" --body "## Summary
- <what changed and why>
Fixes #$ISSUE_NUM
## Test Plan
- <how changes were tested>"
gh pr checks --watch
If checks fail, analyze the failure, fix it, commit, push, and re-check.
All of these must be true before the issue is considered done:
go build ./...)