| name | coding-workflow |
| description | Use this skill for any coding task that involves working with repositories, writing code, creating branches, or opening pull requests. Covers the full development workflow from cloning to PR. |
Coding Workflow
GitHub CLI (gh)
Always use the gh CLI for all GitHub operations. Both gh and git are authenticated automatically through the agent proxy.
Use gh for: cloning repos, discovering repos across orgs, creating/viewing/editing PRs, checking PR status, and viewing PR comments.
Do NOT use unauthenticated git clone https://github.com/... — use gh repo clone instead.
Forking Workflow
When you don't have write access to a repository (push fails with 403/permission denied):
- Fork it:
gh repo fork --remote=true (this adds your fork as the origin remote and renames the original to upstream)
- Push your branch to the fork:
git push -u origin <branch-name>
- Open a PR from your fork to the upstream repo:
gh pr create --repo <upstream-owner>/<repo>
To avoid wasted time, check write access early. If the repo belongs to an organization you're unlikely to have push access to, fork before starting work.
Git Workflow
- Always start by pulling the latest default branch (
main or master)
- Create a feature branch for every task
- Branch names: short, lowercase, hyphenated (e.g.,
fix-login-redirect, add-csv-export)
- NEVER push directly to the default branch
Commits
- Commit early and often — each commit is a single logical change
- Concise imperative messages:
fix redirect loop on login, add CSV export endpoint
- No filler, no AI attribution
- Squash fixup commits before opening a PR
Pull Requests
- Open PRs as drafts
- PR title: short, imperative, under 70 characters
- PR description: write professional PR descriptions that clearly explain the changes — brief summary of what changed and why, plus a test plan
- When iterating on an existing PR, use
gh to get the branch name, check it out, push changes, and update the PR description
- Do NOT merge — open as draft and wait for review
- At the bottom of each PR description, include:
---
🤖 *Generated by Computer*
Code Quality
- Run tests before pushing. Fix failures before opening a PR.
- Add tests for new functionality and bug fixes. If the repo has a test suite, follow its patterns.
- Run the project's linter and fix any issues. Check CLAUDE.md/AGENTS.md for specific lint/test commands.
- Do not leave debugging code, commented-out blocks, or TODOs.
- Follow the repo's existing patterns for code style, naming conventions, and file organization.
