Run any Skill in Manus with one click

gh-board

Stars19

Forks14

UpdatedJuly 17, 2026 at 21:32

Operate any GitHub Projects (v2) board by name — add issues/PRs, find existing items, set Status/Priority/Size or any single-select field — without hardcoding field or option IDs. Use whenever the user asks to move an item on a project board ("move

Installation

Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.

Run Skill in Manus

Source

guillermoscript

guillermoscript/lms-front

View GitHub Repository View Creator Repositories

Download

Run Skill in Manus

Related occupationsSOC

Based on SOC occupation classification

Software DevelopersComputer and Mathematical Occupations·SOC 15-1252

File Explorer

3 files

SKILL.md

readonly

More from this repository

same repository

ai-landing-builder

guillermoscript/lms-front

How the AI landing-page builder works in this LMS — the json-render → Puck pipeline that lets creators generate a full landing page from a sentence and then refine it by hand in the Puck editor. Use this skill whenever the task touches AI page generation, the "Generate with AI" button, the json-render catalog/spec/bridge, the Puck landing-page blocks, or the /api/landing/generate route — including adding a new block type, debugging a generated page that renders blank/crashes, changing what the AI is allowed to emit, fixing OpenAI structured-output schema errors in this area, or regenerating the puck-fields manifest. Reach for it even when the user just says "the landing page generator", "the AI page thing", or names one of the lib/json-render files, since the pipeline has several non-obvious invariants that are easy to break without it.

2026-07-1819

gh-repo-config

guillermoscript/lms-front

Discover the current repo's GitHub-workflow facts — repo name, authenticated gh user, project board, PR template, Slack channel, branch/commit conventions, build/test commands — and cache the non-discoverable ones in <repo-root>/.claude/gh-workflow.config.json so they're asked at most once per repo. Use at the start of any GitHub workflow (work-issue, ship-pr, gh-board rely on it), or when the user asks "what conventions does this repo use", wants to change a saved board/Slack/reviewer setting, or a workflow skill needs a config value it doesn't have.

2026-07-1719

issue-plan

guillermoscript/lms-front

Read a GitHub issue and produce a posted plan of attack — gather the issue with its comments and references, survey the code it touches (read-only), author a short plan (root cause, approach, risks, test plan), then assign the issue, move it to In Progress on the board (if configured), and post the plan as the issue comment teammates read. Use when the user asks to "plan this issue", "read

2026-07-1719

ship-pr

guillermoscript/lms-front

Take an implemented branch to a reviewable pull request — author a template-compliant PR body with a QA script, open it as a draft with labels/milestone/assignee mirrored from the issue, link it to the project board, flip it to ready only when it's genuinely reviewable, announce it on Slack with a reviewer mention (if Slack is connected), and post the final close-out comments on the PR and its issue once it's approved and merged. Use when the user asks to "open a PR for this branch", "ship this", "mark the PR ready", "announce this PR on Slack", or says a PR was merged and wants it closed out ("it's merged", "close out

2026-07-1719

ui-evidence

guillermoscript/lms-front

Produce visual proof of a UI change and post it to the pull request — "before" screenshots captured while the code is still untouched, a recorded GIF of the changed flow, matching "after" screenshots, and the private-repo browser-upload dance to attach them as a PR comment. Use whenever a change touches anything a user can see or click (components, pages, styles, client-side behavior) and a reviewer needs visual evidence, or when the user asks to "record a GIF of this change", "take before/after screenshots", or "post the screenshots to the PR".

2026-07-1719

work-issue

guillermoscript/lms-front

End-to-end GitHub issue workflow, repo-agnostic — read an issue, plan it, move it to In Progress on the project board (if one exists), implement it with efficient-fable orchestration, verify UI changes with a recorded GIF, open a template-compliant PR set to In Review with labels and milestone, and announce it on Slack for review (if connected). Supports extra skills as +args (e.g. "/work-issue <url> +shadcn +animate"). Use whenever the user pastes a GitHub issue URL or issue number and wants it worked on — "work on this issue", "pick up

2026-07-1719

name	gh-board
description	Operate any GitHub Projects (v2) board by name — add issues/PRs, find existing items, set Status/Priority/Size or any single-select field — without hardcoding field or option IDs. Use whenever the user asks to move an item on a project board ("move

GH Board — GitHub Projects (v2) operations by name

Everything here is backed by the bundled scripts/board.sh, which resolves field and option IDs by name at call time via gh project field-list — nothing is hardcoded to a specific board, so it works against any Projects v2 board. The script is bundled with this skill (not the target repo): invoke it by the skill's own path, <skill-dir>/scripts/board.sh, where <skill-dir> is wherever this SKILL.md was loaded from.

Preconditions

The script needs two env vars on every call:

GH_PROJECT_OWNER=<github-org-or-user> GH_PROJECT_NUMBER=<number>

Resolve them in this order:

Already known in this session — use them.
The repo's workflow config: .claude/gh-workflow.config.json, key projectBoard: { "owner": ..., "number": ... }. Read it via the gh-repo-config skill's config.sh get .projectBoard (or plain jq if that skill isn't loaded).
Discover: gh project list --owner <org-from-repo> --format json — if exactly one open project plausibly covers this repo, propose it to the user. If none or ambiguous, ask which board (owner + number), and offer to save the answer to the config so it's never asked again.

If the user says there is no board, or none can be found, board operations are simply skipped — that's an expected state, not a failure.

Commands

board.sh add <issue-or-pr-url>              Add to board (idempotent), prints item id
board.sh find <owner/repo> <number>         Print item id for issue/PR #N; empty if absent
board.sh set-field <item-id> <field> <opt>  Set any single-select field by name
board.sh status <item-id> <name>            Shorthand: set-field ... Status <name>
board.sh priority <item-id> <name>          Shorthand: set-field ... Priority <name>
board.sh size <item-id> <name>              Shorthand: set-field ... Size <name>
board.sh has-field <field-name>             Exit 0 if the board has this field

set-field (and its shorthands) warns and exits 0 when the board lacks the field or option — a board without a Priority column shouldn't crash a pipeline that tries to set one. Check the command's output if you need to know whether the set actually happened.

Recipes

Find-or-add, then set status — the standard bookkeeping move. find first, because add on an existing item still costs an API call and you usually want to know whether the item was already being tracked:

export GH_PROJECT_OWNER=<owner> GH_PROJECT_NUMBER=<number>
ITEM=$(<skill-dir>/scripts/board.sh find <owner>/<repo> <N>)
[ -z "$ITEM" ] && ITEM=$(<skill-dir>/scripts/board.sh add <issue-or-pr-url>)
<skill-dir>/scripts/board.sh status "$ITEM" "In Progress"

Check before offering — when deciding whether to even mention a field like Size or Priority, probe first so you don't offer options the board doesn't have:

<skill-dir>/scripts/board.sh has-field "Size" && echo "board tracks Size"

Match option names exactly as the board defines them ("In Progress", not in-progress). When unsure what options exist, list them:

gh project field-list "$GH_PROJECT_NUMBER" --owner "$GH_PROJECT_OWNER" \
  --format json --jq '.fields[] | {name, options: [.options[]?.name]}'

Conventions worth keeping

Issues and PRs are separate board items. A PR that closes an issue doesn't inherit the issue's board item — add the PR itself if it should appear on the board.
Let automation do the final flip. An issue's Status flips to Done by the board's built-in automation when its closing PR merges — don't set Done manually and race it.
Draft PRs read as In Progress, ready PRs as In Review. Whatever moves a PR out of draft should also move its board item.

Failure modes

set-field warns "board has no field/option ... skipped" — the board's fields or options were renamed/removed. Re-run the field-list command above to see what exists now; since everything resolves by name this usually just needs the caller to use the new name (and, if the name lives in a saved config, update the config).
find prints nothing — the item isn't on this board. Expected; follow with add.
Auth/permission errors from gh — the authenticated user may lack project scope: gh auth refresh -s project usually fixes it. Tell the user rather than retrying blindly.