coding-workflow

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):

1. Fork it: gh repo fork --remote=true (this adds your fork as the origin remote and renames the original to upstream)
2. Push your branch to the fork: git push -u origin <branch-name>
3. 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.