Cloud-PeekCloud-Peek/agent-skills/skills/github-project-board/SKILL.md

github-project-board

Skill1 starsChanged 4 months agoApache-2.0View on GitHub

Use when Codex needs to inspect or update GitHub Projects v2 boards for CloudPeek issues or pull requests: finding project membership, adding items to the correct board, moving cards through Status/phase values, claiming work, moving bug fixes through Open/Claimed/Release Candidate/Closed/Stale, or verifying project-board state after issue or PR work.

1 other project uses a version of this.

Adopted by

Most recently taken up by

aaitor/skill-github-projectstheir own version, first seen Nov 1, 2026

Other versions1 project uses a version of this.
Word for word · 0
None found.
Edited · 0
None found.
Wrote their own version · 1
aaitor/skill-github-projects★ 2same name
How matches are found. Word for word: the exact same text. Edited: shares passages with this file (“99% same” means 99% of its five-word phrases also appear here; 10% or more counts). Their own version: similar meaning, or, weakest, the same name. We can’t tell which project had it first. Projects are counted among the 200 most-starred candidates, and mentions are links to the repository we found, up to 50 per site, so both counts are a floor.
In this repository13 other files it gives its agents.
- feature-development-workflowSkill
- gh-release-train-mergeSkill
- implement-issueSkill
- nist-buildSkill
- nist-designSkill
- nist-planSkill
- nist-releaseSkill
- nist-respondSkill
- nist-testSkill
- plan-to-issueSkill
- prettifySkill
- pr-from-branchSkill
- release-candidate-reviewSkill

The file

Show its rules and text

We split this skill into the rules it gives an agent

14 rules. About 0 are common, 11 are distinctive, and 3 are very specific to this project.

≈0
Common · estimate
Many files like this have a rule of this kind.
≈11
Distinctive · estimate
This author's own choices. Worth a look.
3
Very specific
Tied to their project's names, files or tools. Probably skip.

Common
Distinctive
Very specific
could be automatic: a setting could enforce it

Distinctive:
If the user names a project board, use that board.
line 24
Very specific:
If a Projects v2 GraphQL call fails because the token lacks project scope, tell the user to run gh auth refresh -s project, then continue …
line 29
Distinctive:
Read the existing item field values when the card already exists so you can report old status -> new status.
line 38
Distinctive:
If the target already belongs to one or more projects, update those project items unless the user named a specific board.
line 42
Distinctive:
Write the smallest safe mutation:
line 51
Distinctive:
Add an issue or PR to a project only when the user requested that board or the board choice is deterministic from labels and project …
line 52
Distinctive:
Do not close issues, merge PRs, archive cards, delete items, or mark no-fix/stale without an explicit user request or a workflow that …
line 57
Distinctive:
If the item is on no board and the user did not authorize adding it, say so clearly instead of guessing.
line 65
Distinctive:
Always verify the live options before writing.
line 70
Very specific:
No fix required: comment with the reason, move Bug Fixes to Stale (fix not required), and close the issue only when requested.
line 91
Very specific:
Prefer gh api graphql for Projects v2 operations.
line 96
Distinctive:
Treat project writes as best-effort when part of a larger implementation workflow.
line 98
Distinctive:
Keep project state auditable: mention comments, assignments, linked PRs, and status transitions in the final response.
line 101
Distinctive:
Do not expose GitHub tokens or raw authorization headers in logs, comments, or final output.
line 103

≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.

Files

SKILL.md

GitHub Project Board

Overview

Manage CloudPeek GitHub Projects v2 board state with live discovery. Always query the board, field, item, and option IDs immediately before writing; never reuse stale IDs from notes, logs, or old skill output.

For detailed GraphQL snippets and the current CloudPeek phase map, read references/projects-v2-graphql.md when you need to inspect or mutate a board.

Workflow

Resolve the target:
- Infer owner/repo with gh repo view --json owner,name when the user does not provide it.
- Accept issue URLs, PR URLs, #123, or bare numbers. Confirm whether a bare number is an issue or PR if local context does not make it obvious.
- If the user names a project board, use that board. Otherwise inspect the target's existing project items and labels before choosing a board.
Verify GitHub access:
- Run gh auth status.
- If a Projects v2 GraphQL call fails because the token lacks project scope, tell the user to run gh auth refresh -s project, then continue with any read-only repo work that is still possible.
Inspect before writing:
- Fetch the issue or PR metadata, labels, assignees, state, linked PRs, and project items.
- Fetch active organization projects and the selected project's Status single-select options.
- Read the existing item field values when the card already exists so you can report old status -> new status.
Choose the board and phase:
- If the target already belongs to one or more projects, update those project items unless the user named a specific board.
- For bug-labelled issues, prefer the Bug Fixes project when adding a card or interpreting phases.
- For normal product work, prefer the main CloudPeek project unless the user names a roadmap/customer/GTM board.
- Match requested phases case-insensitively, but require an exact single option after normalization. If two options could match, ask before writing.
Write the smallest safe mutation:
- Add an issue or PR to a project only when the user requested that board or the board choice is deterministic from labels and project conventions.
- Move the card by updating the Status field with the discovered option ID.
- Assign yourself only when the user asks to claim/start/implement the work, or when another skill's workflow explicitly says to claim it.
- Do not close issues, merge PRs, archive cards, delete items, or mark no-fix/stale without an explicit user request or a workflow that requires that outcome.
Verify and report:
- Re-read the item or project field value after mutation.
- Summarize target, board, old phase, new phase, assignment/comment changes, and any skipped project updates.
- If the item is on no board and the user did not authorize adding it, say so clearly instead of guessing.

CloudPeek Phase Guidance

Always verify the live options before writing. Current board conventions:

Bug Fixes: Open -> Claimed -> Release Candidate (PR) -> Closed (merged), plus Stale (fix not required).
Standard work boards such as CloudPeek, Permissions V2 Roadmap, and CloudPeek GTM: Backlog -> Ready -> In progress -> In review -> Done.
Mastec: Todo -> In Progress -> Done.

Common mappings:

Starting or claiming a bug: assign the owner and move Bug Fixes to Claimed.
Opening a bug-fix PR: ensure the PR body links the issue, then move Bug Fixes to Release Candidate (PR).
Merged bug fix: verify the closing PR merged and the issue closed, then move Bug Fixes to Closed (merged) if automation did not.
Starting standard work: move the selected board to In progress.
Opening a standard-work PR: move the selected board to In review.
Completed standard work: move to Done only after merge/close or explicit user confirmation.
No fix required: comment with the reason, move Bug Fixes to Stale (fix not required), and close the issue only when requested.

Guardrails

Prefer gh api graphql for Projects v2 operations; classic project and issue status commands do not update Projects v2 single-select fields.
Treat project writes as best-effort when part of a larger implementation workflow. If board mutation fails, report the error and continue with the code work unless the user specifically asked only for board management.
Keep project state auditable: mention comments, assignments, linked PRs, and status transitions in the final response.
Do not expose GitHub tokens or raw authorization headers in logs, comments, or final output.

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

It worked
Partly
It didn't

What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

Check your setup, free