How do I install the Github skill?

Run npx skillmds@latest add daboggieman/github in your terminal (requires Node.js), paste this page's agent-chat prompt into Claude, Cursor, or any MCP-connected agent, or download the SKILL.md file and copy it into your agent's skills directory.

What does the Github skill do?

Comprehensive GitHub engineering skill for repository inspection, remote state analysis, branches, commits, pull requests, issues, GitHub Actions, CI/CD, releases, repository configuration, API operations, security, troubleshooting, and verified GitHub workflows using the authenticated GitHub CLI. It is listed under DevOps & Infra on SkillMD.

Is Github safe to use?

This skill has not completed SkillMD's automated safety review yet. SkillMD never runs a skill's scripts for you; review the SKILL.md before installing.

Which AI agents work with Github?

This skill is tagged as working with Claude Code, Claude.ai, OpenAI Codex. SKILL.md is an open format, so most agents that read a skills directory can load it too.

Is Github free to use?

Yes. Installing skills from SkillMD is free, and the skill stays under its author's original license.

Who published Github?

Daboggieman (@daboggieman) published this skill. Their other Agent Skills are listed on their SkillMD profile.

Github by daboggieman — Agent Skill

Name: Github
Author: Daboggieman

GitHub Engineering Skill

1. Purpose

This skill defines how the coding agent interacts with GitHub for the Cee-Tailor project.

The agent must treat GitHub as a remote engineering system rather than merely a place to push commits.

GitHub operations can involve:

repositories
branches
commits
pull requests
reviews
issues
labels
milestones
projects
GitHub Actions
workflows
checks
releases
tags
environments
deployment state
repository configuration
permissions
secrets
variables
collaborators
branch protection
rulesets
webhooks
GitHub API resources

The agent must use evidence from the actual repository and GitHub whenever the task depends on current remote state.

2. Core Operating Principle

Use:

INSPECT → UNDERSTAND → PLAN → ACT → VALIDATE → VERIFY → REPORT

Never:

ASSUME → ACT → CLAIM SUCCESS

The agent must not infer remote GitHub state from local files, previous conversations, model memory, or assumptions.

3. Git vs GitHub

Git and GitHub are related but different systems.

Git

Git manages the local repository and its history.

Examples:

git status
git branch
git log
git diff
git commit
git fetch
git push
git pull

GitHub

GitHub provides the remote repository and collaboration infrastructure.

Examples:

gh repo view
gh pr list
gh issue list
gh run list
gh release list
gh api

The agent must distinguish:

local working tree
local branches
local commits
remote Git refs
GitHub repository state
pull request state
CI state
deployment state

A successful local Git command does not automatically prove that the corresponding GitHub operation succeeded.

4. Tool Selection

Use the smallest toolset that establishes reliable evidence.

Use Git when:

inspecting local changes
creating branches
inspecting commits
staging files
committing
fetching
pushing
inspecting local history
comparing branches

Use GitHub CLI when:

inspecting GitHub repositories
inspecting PRs
inspecting issues
inspecting Actions
inspecting releases
inspecting GitHub checks
querying GitHub's API
creating or updating GitHub resources
verifying remote GitHub state

Use Filesystem MCP when:

exploring project files
reading local source
inspecting configuration
inspecting workflow definitions
locating implementation details

Use Context7 when:

current library/API behavior matters
version-specific behavior matters
a GitHub-related dependency requires documentation

Use Fetch when:

official documentation needs to be retrieved
Context7 does not provide the required information
a public web resource must be inspected

Use Playwright when:

a GitHub-hosted frontend must be tested through a browser
an application deployment must be validated through its UI
a web-based workflow needs browser verification

5. Authentication

Before GitHub operations that require authentication:

gh auth status

If authentication is unavailable:

Stop the GitHub operation.
Report the authentication problem.
Do not request credentials in chat.
Do not print tokens.
Do not create replacement authentication mechanisms.
Do not bypass authentication.

GitHub CLI supports authenticated commands through its configured authentication mechanisms.

Never expose:

gh auth token

output in an agent report.

Never place GitHub credentials inside:

.claude/
.env
.env.local
source code
scripts
README files
skill files
commit messages
PR descriptions

6. Authentication Verification

Use:

gh auth status

If the task requires repository access:

gh repo view

Authentication alone is not proof of repository access.

Both may need to be verified.

7. Repository Identification

Before repository-specific operations:

gh repo view

For structured information:

gh repo view --json name,nameWithOwner,owner,url,isPrivate,defaultBranchRef

Use the returned repository identity.

Do not assume:

owner
repository name
default branch
visibility
remote URL

when the CLI can determine them.

8. Explicit Repository Targeting

When operating on a repository other than the current repository, explicitly identify it:

gh <command> --repo OWNER/REPO

or:

gh api repos/OWNER/REPO

Do not accidentally operate on another repository because of:

current working directory
GH_REPO
shell state
copied commands
stale context

Before consequential operations, verify the repository target.

9. Local Repository Baseline

Before modifying GitHub-related project state:

git status --short
git branch --show-current
git remote -v

Then inspect recent history:

git log --oneline --decorate -10

For modifications:

git diff

For staged modifications:

git diff --cached

10. Preserve Unrelated User Changes

If the working tree already contains unrelated modifications:

do not discard them
do not reset them
do not overwrite them
do not stage them accidentally
do not include them in a commit unless requested

Before staging:

git status --short

Inspect individual files before adding them.

11. Repository State Model

When investigating a GitHub task, determine which state is relevant.

State A — Working tree

Question:

What has the user changed locally?

Use:

git status
git diff

State B — Local Git history

Question:

What commits exist locally?

Use:

git log

State C — Remote Git refs

Question:

What branches/tags exist on the configured remote?

Use:

git ls-remote

State D — GitHub repository

Question:

What does GitHub currently report?

Use:

gh repo view
gh api

State E — Pull request

Question:

What is the PR state?

Use:

gh pr view
gh pr checks

State F — CI

Question:

Did GitHub Actions actually execute successfully?

Use:

gh run list
gh run view

State G — Deployment

Question:

Did the deployment actually complete?

Use:

GitHub Actions
deployment provider
application runtime
Playwright where appropriate

Never substitute one state for another.

12. Branch Management

Inspect local branches:

git branch

Inspect remote branches:

git branch -r

Inspect the GitHub branch list:

gh api repos/{owner}/{repo}/branches

Inspect a specific branch:

gh api repos/{owner}/{repo}/branches/{branch}

13. Creating Branches

Before creating a branch:

git status --short
git branch --show-current

Create:

git switch -c <branch-name>

Use descriptive branch names.

Examples:

feature/customer-measurements
feature/admin-dashboard
fix/authentication-redirect
fix/order-validation
refactor/api-client
docs/setup-guide
test/checkout-flow

Do not create meaningless names such as:

test
new
branch2
stuff
fix-final
final-final

unless the user explicitly requests them.

14. Branch Naming

Prefer:

<type>/<short-description>

Common types:

feature/
fix/
refactor/
docs/
test/
chore/
security/
perf/

The branch name should communicate intent.

15. Pushing a New Branch

After validation:

git push -u origin <branch>

Verify:

git ls-remote --heads origin <branch>

Then optionally verify through GitHub:

gh api repos/{owner}/{repo}/branches/<branch>

Do not report:

branch successfully pushed

until remote verification has succeeded.

16. Branch Deletion

Deleting branches is potentially destructive.

Never delete a branch unless explicitly authorized.

Before deletion:

git branch --show-current

Verify the target branch.

For remote deletion:

git push origin --delete <branch>

Afterward verify:

git ls-remote --heads origin <branch>

An empty result is evidence that the remote Git ref is gone.

17. Force Push

Never use:

git push --force

unless explicitly authorized.

Prefer:

git push --force-with-lease

when force-pushing has been explicitly authorized and is technically necessary.

Before force-pushing:

identify the branch
inspect the current remote state
inspect local commits
determine what history will be replaced
confirm authorization

Never force-push to the default branch unless explicitly requested and justified.

18. Commit Inspection

Inspect:

git log --oneline --decorate -20

Inspect a commit:

git show <commit>

Inspect changed files:

git show --stat <commit>

Inspect a remote commit through GitHub:

gh api repos/{owner}/{repo}/commits/<sha>

Do not claim a commit exists remotely without verifying remote state.

19. Commit Verification

After:

git push

verify the branch:

git ls-remote --heads origin <branch>

If the exact commit matters:

git ls-remote origin <branch>

Then compare the returned SHA with the intended commit.

20. Pull Request Discovery

List PRs:

gh pr list

List more:

gh pr list --limit 50

Search PRs:

gh search prs "<query>" --repo OWNER/REPO

Check the PR associated with the current branch:

gh pr status

21. Pull Request Inspection

View:

gh pr view <number>

Structured:

gh pr view <number> \
  --json number,title,state,author,headRefName,baseRefName,isDraft,mergeable,statusCheckRollup,url

Inspect comments when necessary:

gh pr view <number> --comments

Inspect the diff:

gh pr diff <number>

Inspect changed file names:

gh pr diff <number> --name-only

22. Pull Request Investigation

When investigating a PR:

identify the repository
identify the PR number
inspect title/body
inspect source branch
inspect target branch
inspect commits
inspect changed files
inspect diff
inspect checks
inspect reviews
inspect comments
inspect merge state
inspect conflicts if relevant
inspect linked issues if relevant

Do not review only the PR title.

23. Creating Pull Requests

Before creating a PR:

git status --short
git branch --show-current
git diff
git log --oneline --decorate -10

Run relevant validation.

Then push the branch:

git push -u origin <branch>

Create:

gh pr create

For explicit control:

gh pr create \
  --base <base> \
  --head <head> \
  --title "<title>" \
  --body "<body>"

GitHub CLI supports gh pr create with explicit base/head/title/body and can also use repository defaults when not explicitly supplied.

24. Pull Request Description Quality

A PR body should normally contain:

Summary

What changed?

Problem

Why was the change necessary?

Implementation

What was changed technically?

Validation

What was tested?

Risk

What could potentially be affected?

Verification

What was actually verified?

Do not claim tests were run if they were not run.

25. PR Title Rules

Prefer titles that describe the actual change.

Good:

Add customer measurement persistence
Fix order creation validation
Implement admin order filtering
Add Playwright checkout coverage

Avoid:

Update stuff
Fix things
Changes
Final fix
Important

26. Draft Pull Requests

Use draft PRs when implementation is incomplete but remote collaboration is useful:

gh pr create --draft

Do not mark a PR ready merely because the code compiles.

Before:

gh pr ready

verify:

implementation complete
tests complete
review complete
no known blocking errors
intended CI checks are available

27. Pull Request Checks

Inspect:

gh pr checks <number>

Possible states include:

queued
in progress
successful
failed
cancelled
skipped

Do not call queued or running checks successful.

28. Pull Request Review

Inspect:

gh pr diff <number>

Then inspect relevant project files locally.

Review:

correctness
architecture
error handling
security
type safety
API contracts
tests
performance
maintainability
backwards compatibility
database implications
frontend behavior
accessibility where applicable

Use the existing code-review, security, testing, and verification skills when relevant.

29. Review Comments

When reporting review findings, use evidence.

Each significant finding should identify:

file
relevant code
problem
consequence
recommended direction

Do not manufacture issues merely to make the review appear thorough.

30. Approving PRs

Approval is a consequential GitHub action.

Do not approve a PR unless explicitly authorized.

If asked to review but not approve:

inspect
report findings
do not submit approval

31. Requesting Changes

Requesting changes is also a consequential GitHub action.

Only do so when explicitly authorized.

Before requesting changes:

gh pr diff <number>
gh pr checks <number>

Base findings on concrete evidence.

32. Merging Pull Requests

Merging is consequential.

Never merge automatically unless the user explicitly requests it.

Before merging:

gh pr view <number>
gh pr checks <number>

Verify:

correct repository
correct PR
correct base branch
expected head branch
required checks
review requirements
mergeability
intended merge strategy

Possible strategies include:

merge
squash
rebase

Use the strategy explicitly requested by the user.

If none is specified, do not silently make a consequential choice when the choice matters.

33. Merge Verification

After merging:

gh pr view <number>

Verify the PR state.

If branch deletion was requested, verify it separately.

Do not report:

merged successfully

based solely on the command returning without an obvious error.

34. Issues

List:

gh issue list

View:

gh issue view <number>

Structured:

gh issue view <number> \
  --json number,title,state,author,labels,assignees,url

Search:

gh search issues "<query>" --repo OWNER/REPO

35. Creating Issues

Create only when explicitly requested:

gh issue create

Or:

gh issue create \
  --title "<title>" \
  --body "<body>"

A useful issue should contain:

problem
expected behavior
actual behavior
reproduction steps
environment
evidence
relevant logs
acceptance criteria

Do not create an issue simply because a problem was discovered unless the workflow calls for it.

36. Closing Issues

Closing is consequential.

Only close when explicitly authorized.

Before closing:

gh issue view <number>

Understand why it is being closed.

After closing:

gh issue view <number>

Verify the final state.

37. Issue Comments

Comment only when required.

Use:

gh issue comment <number> --body "<comment>"

Do not post speculative statements as facts.

Do not post credentials, tokens, private data, or secrets.

38. Issue Linking

When appropriate, link implementation to issues through PR descriptions.

Examples:

Fixes #123
Closes #123

Do not claim an issue will close unless the GitHub semantics actually support the reference being used.

39. GitHub Actions

List workflow runs:

gh run list

List more:

gh run list --limit 50

Inspect:

gh run view <run-id>

Inspect failed logs:

gh run view <run-id> --log-failed

Watch:

gh run watch <run-id>

40. CI Failure Investigation

When CI fails:

Step 1

Identify the failed run:

gh run list

Step 2

Inspect:

gh run view <run-id>

Step 3

Inspect failed logs:

gh run view <run-id> --log-failed

Step 4

Identify:

workflow
job
step
command
exact error

Step 5

Inspect the corresponding local workflow.

Step 6

Determine whether the problem is:

application code
dependency
test
environment
workflow configuration
secret/configuration
permissions
network
external service

Step 7

Reproduce locally where possible.

Step 8

Fix the smallest root cause.

Step 9

Validate locally.

Step 10

Push.

Step 11

Verify the new GitHub Actions run.

41. CI Completion Rule

Never say:

CI is fixed.

until a new relevant run has been inspected.

Correct reporting:

The previous run failed because X. The workflow was changed to Y. A new run was triggered, and run Z completed successfully.

If the new run is still running:

The fix has been pushed and the new CI run is still in progress.

42. Workflow Inspection

List workflows:

gh workflow list

View a workflow:

gh workflow view <workflow>

Inspect workflow files locally:

find .github/workflows -type f -maxdepth 1 -print

Read the relevant YAML before modifying it.

43. Running Workflows

A workflow can be manually dispatched only when appropriate and supported.

Before dispatching:

identify exact workflow
inspect its inputs
confirm target branch/ref
understand consequences

Use:

gh workflow run <workflow>

When branch/ref matters, specify it explicitly.

After dispatch:

gh run list

Find the resulting run and verify it.

44. Cancelling Workflows

Cancellation is consequential.

Only cancel when authorized.

Before cancellation:

gh run view <run-id>

Then:

gh run cancel <run-id>

Verify:

gh run view <run-id>

45. Re-running Workflows

Only rerun when appropriate.

Understand whether the failure is transient or deterministic.

A rerun is not a fix.

If a workflow fails due to code/configuration, fix the cause instead of repeatedly rerunning it.

46. GitHub Actions Security

When inspecting workflows, look for:

excessive permissions
secret exposure
untrusted input
shell injection
unsafe interpolation
untrusted pull request code
inappropriate event triggers
dependency installation
third-party actions
mutable action tags
unsafe artifact handling
unsafe deployment credentials

Do not modify security-sensitive workflows casually.

Use the security skill when the issue is significant.

47. Action Versioning

When encountering:

uses: owner/action@...

determine what reference is being used.

Possible references include:

tag
branch
commit SHA

Do not blindly upgrade Actions.

When current behavior matters, research official documentation.

48. Releases

List:

gh release list

View:

gh release view <tag>

Structured:

gh release view <tag> \
  --json name,tagName,isDraft,isPrerelease,publishedAt,url

Creating a release is consequential.

Only do so when explicitly requested.

49. Release Validation

Before creating a release verify:

intended commit
intended tag
tests
build
version
changelog
release artifacts
deployment implications

After publishing:

gh release view <tag>

Verify:

release exists
correct tag
correct status
correct assets
expected publication state

50. Tags

Inspect local tags:

git tag

Inspect remote tags:

git ls-remote --tags origin

Do not create/delete tags without authorization.

A release and a tag are related but not identical concepts.

51. GitHub API

Use gh api when the dedicated CLI commands do not expose enough information.

GitHub CLI's gh api performs authenticated GitHub API requests and supports options such as JSON filtering, pagination, custom methods, fields, headers, and request bodies.

Example:

gh api repos/{owner}/{repo}

Example:

gh api repos/{owner}/{repo}/branches

Example:

gh api repos/{owner}/{repo}/actions/runs

52. API Placeholder Rules

Within a repository, placeholders such as:

{owner}
{repo}
{branch}

can be resolved by GitHub CLI in supported contexts.

Do not rely on that behavior blindly.

When clarity matters, use explicit values.

53. API Read Operations

Prefer GET/read operations when investigating.

Examples:

gh api repos/{owner}/{repo}

gh api repos/{owner}/{repo}/pulls

gh api repos/{owner}/{repo}/issues

gh api repos/{owner}/{repo}/actions/runs

Read before write.

54. API Write Operations

API writes include:

POST
PATCH
PUT
DELETE

Treat them as consequential.

Before performing a write:

identify target
identify endpoint
identify method
identify payload
confirm authorization
execute
verify resulting state

Never use a write request merely because it is technically available.

55. API Pagination

When a result can contain many records, consider pagination.

Example:

gh api --paginate repos/{owner}/{repo}/issues

Do not assume the first page contains the complete dataset.

56. API Filtering

Use --jq when structured output is required:

gh api repos/{owner}/{repo} --jq '.full_name'

For machine-readable output, prefer JSON or structured output over parsing human-formatted text.

57. API Troubleshooting

If gh api fails:

inspect the exact HTTP/API error
verify authentication
verify repository
verify endpoint
verify method
verify permissions
verify request payload
verify API documentation if behavior is uncertain

Do not blindly retry destructive requests.

58. GitHub Search

Search repository code:

gh search code "<query>" --repo OWNER/REPO

Search issues:

gh search issues "<query>" --repo OWNER/REPO

Search PRs:

gh search prs "<query>" --repo OWNER/REPO

Search repositories:

gh search repos "<query>"

Search is discovery, not proof.

After finding a relevant result, inspect the actual object.

59. Repository File Inspection

If remote file contents are required:

gh api repos/{owner}/{repo}/contents/{path}

For a branch:

gh api "repos/{owner}/{repo}/contents/{path}?ref=<branch>"

Use local filesystem tools when the local repository is authoritative for the task.

Use GitHub API when the remote version matters.

60. GitHub Configuration

Repository configuration can include:

Actions
variables
secrets
rulesets
environments
branch protection
permissions
labels
collaborators
project settings

Configuration changes are high-impact.

Inspect before modifying.

Never change repository settings without explicit authorization.

61. Secrets

Never retrieve and display secret values.

Never place secret values in:

logs
PRs
issues
commits
source files
skill files

When a secret is required, use the appropriate GitHub secret mechanism.

When inspecting secret configuration, verify existence/status without exposing values whenever possible.

62. Accidental Secret Detection

Before pushing:

git diff
git status --short

Look for:

API_KEY=
TOKEN=
PASSWORD=
SECRET=
PRIVATE_KEY
DATABASE_URL=

Also inspect suspicious files.

If a secret is found:

stop
do not push
determine whether it has already been committed
notify the user
rotate the credential if exposure occurred
remove it safely
verify repository history as necessary

Do not simply delete the current copy if the secret already exists in Git history.

63. GitHub Environment Variables

Distinguish:

local .env
GitHub Actions variables
GitHub Actions secrets
repository variables
environment variables
organization-level configuration

Never assume one is automatically available in another environment.

64. Deployment Verification

A successful GitHub Actions workflow does not automatically prove the deployed application is functioning.

Deployment verification may require:

GitHub Actions verification
deployment provider verification
runtime health check
API verification
browser verification

Use Playwright when UI behavior needs verification.

Use backend/runtime tests for APIs.

65. Deployment Failure Investigation

Determine:

workflow failure?
build failure?
deployment failure?
environment configuration?
database migration?
runtime crash?
health check failure?
DNS?
external service?

Do not collapse these into "deployment failed" without evidence.

66. Repository Health Check

When asked to assess repository health, inspect:

git status --short
git branch --show-current
git remote -v
git log --oneline --decorate -10
gh repo view
gh pr status
gh issue status
gh run list

Then inspect relevant project configuration.

Report each category independently.

67. GitHub Status Investigation

For a broad question such as:

What's happening with this repository?

Inspect:

gh repo view
gh pr list
gh issue list
gh run list

Then determine:

current branch
active PRs
open issues
recent CI activity
recent releases
local uncommitted changes

Do not provide a vague summary when concrete state is available.

68. GitHub + Git Recovery

If local Git history and GitHub state appear inconsistent:

Do not immediately reset anything.

First inspect:

git status
git branch -avv
git remote -v
git log --all --decorate --graph --oneline -30
git ls-remote origin

Then inspect GitHub:

gh repo view
gh pr list

Determine:

local-only commits
remote-only commits
divergent branches
missing refs
unrelated histories
deleted branches
incorrect upstream tracking

Only then plan recovery.

69. Unrelated Histories

If Git reports:

fatal: refusing to merge unrelated histories

Do not immediately use:

git pull --allow-unrelated-histories

First determine why the histories are unrelated.

Inspect:

git log --all --graph --decorate --oneline
git remote -v
git branch -avv

Inspect the GitHub repository:

gh repo view

Determine whether:

wrong remote
wrong branch
repository reinitialization
independent history
accidental repository replacement
branch mismatch

Only then choose a recovery strategy.

70. Remote Branch Conflicts

If a remote branch exists unexpectedly:

git ls-remote --heads origin

Inspect GitHub:

gh api repos/{owner}/{repo}/branches

Do not delete or overwrite the branch before understanding its purpose.

71. Push Rejection

If:

git push

is rejected:

Determine whether it is:

non-fast-forward
permissions
protected branch
authentication
remote hook
workflow policy
repository rule

Inspect:

git status
git branch -vv
git fetch origin

Then inspect GitHub state if needed.

Never force-push as the first response.

72. Protected Branches and Rules

If GitHub rejects a push or merge because of repository rules:

Do not attempt to bypass them.

Inspect the relevant PR/check/rules state.

If necessary, use the intended workflow:

branch → PR → checks → review → merge

Repository protection is a constraint to work with, not something to circumvent.

73. GitHub Actions Permissions

When Actions fail due to permissions:

Inspect the workflow's:

permissions:

and relevant GitHub configuration.

Use least privilege.

Do not grant:

permissions: write-all

as a generic fix.

Grant only the permission required by the operation.

74. Dependency Changes Through GitHub

When a GitHub workflow requires a dependency change:

identify dependency
inspect package manager
inspect current version
inspect lockfile
research current documentation if necessary
make minimal change
run tests
inspect diff
push
verify CI

Do not upgrade unrelated dependencies.

75. GitHub Actions Dependency Failures

If a CI job fails because a package/action changed:

Determine:

exact dependency
installed version
requested version
lockfile state
runtime version
operating system
relevant GitHub runner
official documentation

Do not assume the latest version is compatible.

76. GitHub Documentation Research

When GitHub behavior is uncertain:

Prefer:

official GitHub CLI documentation
official GitHub documentation
installed command help
current repository configuration
runtime evidence
community sources when necessary

Use Context7 or Fetch when appropriate.

Do not rely solely on model memory for current CLI behavior.

77. Version-Sensitive CLI Behavior

Before using unfamiliar gh functionality:

gh --version

Then:

gh <command> --help

For current documentation, consult the official GitHub CLI documentation.

Do not invent flags.

If a command fails because a flag does not exist, inspect:

gh <command> --help

before attempting alternatives.

78. GitHub CLI Extensions

Do not install arbitrary gh extensions automatically.

If an extension appears useful:

identify why it is needed
inspect its source/repository
assess trust
assess whether built-in gh functionality is sufficient
install only when explicitly authorized

Prefer built-in commands.

79. GitHub CLI Aliases

Do not create global aliases automatically.

Project-specific automation should normally live in project documentation/scripts rather than modifying the user's global CLI configuration.

If an alias is requested, verify the exact command it will execute.

80. GitHub Agent Skills

The installed gh version may expose additional GitHub CLI functionality beyond the core commands.

Do not automatically install external agent skills.

If an external GitHub skill is proposed:

inspect its source
understand its permissions
determine whether it duplicates existing project skills
assess trust
obtain explicit authorization before installing

The project's .claude/skills/ system remains the primary project instruction layer.

81. Cee-Tailor GitHub Architecture

For Cee-Tailor, use this conceptual architecture:

Claude Code / FCC
        │
        ▼
Project Instructions
        │
        ├── CLAUDE.md
        ├── AGENT_WORKFLOW.md
        │
        ▼
Skills
        │
        ├── github
        ├── git
        ├── testing
        ├── verification
        ├── security
        ├── debugging
        ├── research
        └── code-review
        │
        ▼
Tools
        │
        ├── Filesystem MCP
        ├── Context7 MCP
        ├── Fetch MCP
        ├── Playwright MCP
        ├── Git
        └── GitHub CLI
        │
        ▼
Cee-Tailor Repository

The GitHub skill should coordinate with the other skills rather than duplicate them.

82. GitHub Task Classification

Classify the task before acting.

Type A — Information

Examples:

What PRs exist?
What failed?
What branch is remote?
What issues are open?

Read-only investigation.

Type B — Local Git

Examples:

create branch
inspect commit
prepare changes

Use Git primarily.

Type C — Remote Git

Examples:

push branch
inspect remote refs

Use Git + verification.

Type D — Collaboration

Examples:

create PR
comment on issue
request review

Use gh.

Type E — CI/CD

Examples:

investigate failed Actions
rerun workflow
inspect deployment

Use gh run, gh workflow, Git, and relevant project tools.

Type F — Repository Administration

Examples:

rules
secrets
variables
permissions
settings

High-impact. Explicit authorization required.

Type G — Release

Examples:

tag
release
assets

High-impact. Explicit authorization required.

83. Read-Only First

When uncertain, begin with read-only commands.

Examples:

git status
git log
git branch -avv
gh repo view
gh pr list
gh issue list
gh run list
gh release list

Only transition to write operations after understanding the state.

84. Minimal Change Principle

GitHub-related changes must be minimal.

Do not:

reorganize unrelated files
rewrite workflows unnecessarily
upgrade unrelated dependencies
change repository settings unnecessarily
alter branch strategy unnecessarily
create unnecessary issues
create unnecessary PRs

Make the smallest change that solves the requested problem.

85. Evidence Categories

Every important GitHub conclusion should be categorized mentally as:

FACT

Directly observed.

Example:

gh pr checks 12 reports three successful checks.

INFERENCE

Derived from evidence.

Example:

The failing test appears related to the changed API contract.

UNKNOWN

Not established.

Example:

The production deployment status has not been verified.

Never present inference or unknown information as fact.

86. Completion Criteria

A GitHub task is complete only when the requested end state has been verified.

Examples:

"Push this branch"

Complete when:

git push

succeeds and remote state is verified.

"Create a PR"

Complete when:

gh pr create

succeeds and:

gh pr view <number>

confirms the PR.

"Fix CI"

Complete only after the new relevant CI run is inspected.

"Merge the PR"

Complete only after the PR state confirms it is merged.

"Publish the release"

Complete only after:

gh release view <tag>

confirms the release state.

87. Never Claim Unverified Success

Never say:

Done.
Everything works.
CI passes.
The PR is ready.
The deployment succeeded.
The branch is pushed.
The release is live.

unless the relevant state has actually been verified.

Prefer:

Implemented locally; CI has not yet been verified.

or:

The branch was pushed and the remote branch was confirmed. CI is still running.

88. Final GitHub Verification Loop

For meaningful GitHub tasks:

1. Inspect local state
        ↓
2. Inspect GitHub state
        ↓
3. Understand target
        ↓
4. Make change
        ↓
5. Validate locally
        ↓
6. Inspect diff
        ↓
7. Commit
        ↓
8. Push
        ↓
9. Verify remote state
        ↓
10. Verify CI / PR / release if applicable
        ↓
11. Report evidence

89. Security Review Trigger

Invoke the security skill when the task involves:

authentication
authorization
secrets
tokens
GitHub Actions permissions
deployment credentials
repository permissions
environment configuration
third-party GitHub Actions
dependency supply chain
webhooks
GitHub Apps
OAuth
API credentials

Do not treat GitHub access as inherently safe.

90. Testing Review Trigger

Invoke the testing skill when:

code changes
CI changes
workflow changes
PR creation
bug fixes
API changes
frontend changes
database changes

Testing should be proportionate to the change.

91. Verification Skill Trigger

Invoke the verification skill when:

the user asks whether something works
CI status matters
a PR status matters
a deployment matters
a remote branch matters
a release matters
an API operation matters
a GitHub state claim needs proof

92. Research Skill Trigger

Invoke research when:

current GitHub CLI behavior is uncertain
a GitHub API endpoint is unclear
repository rules are unclear
a third-party Action needs investigation
a dependency/action version matters
GitHub behavior has changed

Use authoritative sources first.

93. Debugging Skill Trigger

Invoke debugging when:

GitHub Actions fail
pushes fail
PR creation fails
API requests fail
authentication fails
remote state appears inconsistent
deployment workflows fail

Capture the exact error before diagnosing.

94. Multi-Skill Workflow

For a typical feature:

planning
    ↓
architecture
    ↓
implementation
    ↓
testing
    ↓
code-review
    ↓
security
    ↓
verification
    ↓
git
    ↓
github

Not every task requires every skill.

Select only the relevant skills.

95. GitHub + Planning

Before a complex GitHub operation, planning should establish:

desired outcome
affected repository
branch
expected changes
validation
remote operation
verification criteria

Do not start with GitHub writes.

96. GitHub + Architecture

For architectural changes:

Inspect:

repository structure
existing PRs
existing issues
workflow architecture
deployment architecture
package boundaries

Avoid designing around assumptions.

97. GitHub + Code Review

When reviewing a PR:

Repository
    ↓
PR metadata
    ↓
Diff
    ↓
Changed files
    ↓
Related implementation
    ↓
Tests
    ↓
CI
    ↓
Security
    ↓
Review findings

98. GitHub + Documentation

When creating GitHub-facing documentation:

Ensure it explains:

purpose
setup
usage
validation
limitations
operational workflow

Do not document commands that have not been verified.

99. GitHub + Frontend Verification

For Cee-Tailor frontend changes:

inspect PR
inspect diff
run frontend checks
start application when appropriate
use Playwright
verify the actual browser behavior
inspect GitHub checks
report both local and remote evidence

Do not treat successful TypeScript compilation as proof that the UI works.

100. GitHub + Backend Verification

For backend changes:

inspect diff
run type/static checks
run tests
start application if necessary
test affected endpoints
inspect CI
verify PR state

Do not treat a successful build as proof of runtime correctness.

101. Database Changes

For database migrations:

Inspect:

migration files
migration ordering
model changes
API contract
deployment process
CI migration behavior

Do not modify production database state unless explicitly authorized.

102. GitHub Actions and Database Migrations

If CI/deployment runs migrations:

Determine:

where migration executes
which database it targets
what credentials are used
whether migrations are reversible
whether deployment ordering matters

Never blindly rerun destructive migrations.

103. Monorepo Awareness

Cee-Tailor contains multiple application/package areas.

Potential areas include:

apps/web
apps/api
packages/config
packages/contracts
packages/ui
scripts

When a GitHub change affects one area:

inspect affected package
inspect related packages
inspect root configuration
inspect CI workflows
avoid unrelated modifications

104. Commit Scope

A commit should normally represent one coherent logical change.

Avoid mixing:

feature code
dependency upgrades
unrelated formatting
workflow changes
documentation cleanup

unless they are intentionally part of the same change.

105. PR Scope

A PR should normally have one coherent purpose.

If the work contains unrelated changes, separate them when practical.

Do not create multiple PRs merely for the sake of separation when the architecture genuinely requires one change.

106. Generated Files

Before committing generated files, determine whether they are:

…(truncated)

Github

File contents

GitHub Engineering Skill

1. Purpose

2. Core Operating Principle

3. Git vs GitHub

Git

GitHub

4. Tool Selection

Use Git when:

Use GitHub CLI when:

Use Filesystem MCP when:

Use Context7 when:

Use Fetch when:

Use Playwright when:

5. Authentication

6. Authentication Verification

7. Repository Identification

8. Explicit Repository Targeting

9. Local Repository Baseline

10. Preserve Unrelated User Changes

11. Repository State Model

State A — Working tree

State B — Local Git history

State C — Remote Git refs

State D — GitHub repository

State E — Pull request

State F — CI

State G — Deployment

12. Branch Management

13. Creating Branches

14. Branch Naming

15. Pushing a New Branch

16. Branch Deletion

17. Force Push

18. Commit Inspection

19. Commit Verification

20. Pull Request Discovery

21. Pull Request Inspection

22. Pull Request Investigation

23. Creating Pull Requests

24. Pull Request Description Quality

Summary

Problem

Implementation

Validation

Risk

Verification

25. PR Title Rules

26. Draft Pull Requests

27. Pull Request Checks

28. Pull Request Review

29. Review Comments

30. Approving PRs

31. Requesting Changes

32. Merging Pull Requests

33. Merge Verification

34. Issues

35. Creating Issues

36. Closing Issues

37. Issue Comments

38. Issue Linking

39. GitHub Actions

40. CI Failure Investigation

Step 1

Step 2

Step 3

Step 4

Step 5

Step 6

Step 7

Step 8

Step 9

Step 10

Step 11

41. CI Completion Rule

42. Workflow Inspection

43. Running Workflows

44. Cancelling Workflows

45. Re-running Workflows