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.
1---2name: coding-workflow3description: 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.4---56# Coding Workflow78## GitHub CLI (`gh`)910Always use the `gh` CLI for all GitHub operations. Both `gh` and `git` are authenticated automatically through the agent proxy.1112Use `gh` for: cloning repos, discovering repos across orgs, creating/viewing/editing PRs, checking PR status, and viewing PR comments.1314Do NOT use unauthenticated `git clone https://github.com/...` — use `gh repo clone` instead.1516## Forking Workflow1718When you don't have write access to a repository (push fails with 403/permission denied):19201. Fork it: `gh repo fork --remote=true` (this adds your fork as the `origin` remote and renames the original to `upstream`)212. Push your branch to the fork: `git push -u origin <branch-name>`223. Open a PR from your fork to the upstream repo: `gh pr create --repo <upstream-owner>/<repo>`2324To 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.2526## Git Workflow2728- Always start by pulling the latest default branch (`main` or `master`)29- Create a feature branch for every task30- Branch names: short, lowercase, hyphenated (e.g., `fix-login-redirect`, `add-csv-export`)31- NEVER push directly to the default branch3233## Commits3435- Commit early and often — each commit is a single logical change36- Concise imperative messages: `fix redirect loop on login`, `add CSV export endpoint`37- No filler, no AI attribution38- Squash fixup commits before opening a PR3940## Pull Requests4142- Open PRs as **drafts**43- PR title: short, imperative, under 70 characters44- PR description: write professional PR descriptions that clearly explain the changes — brief summary of what changed and why, plus a test plan45- When iterating on an existing PR, use `gh` to get the branch name, check it out, push changes, and update the PR description46- Do NOT merge — open as draft and wait for review47- At the bottom of each PR description, include:4849```50---51🤖 *Generated by Computer*52```5354## Code Quality5556- Run tests before pushing. Fix failures before opening a PR.57- Add tests for new functionality and bug fixes. If the repo has a test suite, follow its patterns.58- Run the project's linter and fix any issues. Check CLAUDE.md/AGENTS.md for specific lint/test commands.59- Do not leave debugging code, commented-out blocks, or TODOs.60- Follow the repo's existing patterns for code style, naming conventions, and file organization.
thanakijwanavit