| name | rosy-github |
| description | Use this skill for ANY interaction with the hiibolt/rosy GitHub project — issues, PRs, branches, the project board, or any reference to a GitHub issue number (#N). This includes: creating, reading, updating, closing, or commenting on issues; managing the project board (moving items, changing status/priority/size); creating, reviewing, or merging PRs; managing branches; searching issues; and starting work on an issue. Triggers on: "#N" (any issue number reference), "start #N", "work on #N", "pick up #N", "begin #N", "what's #N", "new issue", "create issue", "plan feature", "open a ticket", "move to ready", "close issue", "update the board", "check PR", "what's the status of #N", "add a comment", "assign to", "change priority", "create a branch", "link PR", "open PR", "merge PR", "review PR", or any reference to GitHub issues, PRs, or the project board. Also triggers when the user describes a problem, idea, or change that should become a tracked work item — even casually phrased. When in doubt, trigger this skill.
|
Rosy GitHub
The single skill for all GitHub interactions on hiibolt/rosy. Covers issue
creation, issue management, project board operations, PR workflows, and branch
management. Rosy is a transpiler from ROSY (a reimplementation of COSY INFINITY)
to Rust — issues often involve language constructs, type system work, or
transpiler internals.
Core Philosophy
For issue creation: have a conversation, not an intake form. Cover everything,
feel like nothing.
For everything else (updates, board moves, PR ops): be fast and direct. The user
wants something done — do it, confirm it, move on.
Team Reference
| Handle | Role / Notes |
|---|
@hiibolt | Owner, sole maintainer, implementer |
@claude | You — review, scaffolding, implementation, suggestions |
Repo: hiibolt/rosy
Board Fields (Rosy project)
Field metadata is hardcoded below. These IDs rarely change. If any item-edit call
fails with an invalid field or option ID error, run gh project field-list 7 --owner hiibolt --format json
once to refresh, update your working memory with the new values, and retry.
Project Number: 7
Project ID: PVT_kwHOBXC3xM4BSd_s
Repo Node ID: R_kgDOPgpY3w
| Field | Field ID | Options (name = ID) |
|---|
| Status | PVTSSF_lAHOBXC3xM4BSd_szg__kR0 | Planning=f75ad846, Ready=61e4505c, In progress=47fc9ee4, Done=98236657 |
| Priority | PVTSSF_lAHOBXC3xM4BSd_szg__kSU | Now=79628723, Soon=0a877460, Long-Term=da944a9c |
| Size | PVTSSF_lAHOBXC3xM4BSd_szg__kSY | Tiny=6c6483d2, Small=f784b110, Moderate=7515a9f1, Large=817d0097, X-Large=db339eb2, Gigantic=8fa6379f |
Status column meanings:
Planning — scope/criteria/approach still need refinementReady — fully defined, unblocked, could be picked up today- New issues default to
Planning unless the interview produced a complete spec
Priority/Size: Ask during the interview; use the IDs above when writing.
Assignees: @hiibolt (and/or @claude when appropriate).
Labels (pre-fetched)
Use these label names directly with --label flags. IDs included for GraphQL if needed.
| Name | ID | Color | Description |
|---|
bug | LA_kwDOPgpY388AAAACIJSjiw | d73a4a | Something isn't working |
documentation | LA_kwDOPgpY388AAAACIJSjkg | 0075ca | Improvements or additions to documentation |
duplicate | LA_kwDOPgpY388AAAACIJSjlg | cfd3d7 | This issue or pull request already exists |
enhancement | LA_kwDOPgpY388AAAACIJSjmg | a2eeef | New feature or request |
good first issue | LA_kwDOPgpY388AAAACIJSjpg | 7057ff | Good for newcomers |
help wanted | LA_kwDOPgpY388AAAACIJSjnw | 008672 | Extra attention is needed |
invalid | LA_kwDOPgpY388AAAACIJSjrA | e4e669 | This doesn't seem right |
question | LA_kwDOPgpY388AAAACIJSjsw | d876e3 | Further information is requested |
wontfix | LA_kwDOPgpY388AAAACIJSjuA | ffffff | This will not be worked on |
performance | LA_kwDOPgpY388AAAACcXbcJQ | ff9900 | Performance optimization |
Session Memory
To avoid redundant API calls within a single conversation:
- Field metadata: Always use the hardcoded Board Fields table. Only run
gh project field-list if an item-edit fails (stale ID recovery).
- Project ID: Always use
PVT_kwHOBXC3xM4BSd_s. Do NOT run gh project view.
- Labels: Always use the hardcoded Labels table above. Do NOT run
gh label list.
CLI Tools Reference
All operations use the gh CLI (pre-installed). Run commands via the Bash tool.
Issue Operations
| Operation | Command |
|---|
| Create issue | gh issue create --repo hiibolt/rosy --title "..." --body "..." --label "enhancement" --assignee hiibolt |
| Get issue | gh issue view <N> --repo hiibolt/rosy |
| Get issue (JSON) | gh issue view <N> --repo hiibolt/rosy --json title,body,state,labels,assignees,comments |
| Update issue | gh issue edit <N> --repo hiibolt/rosy [--title "..." --body "..." --add-label "..." --add-assignee "..."] |
| Close issue | gh issue close <N> --repo hiibolt/rosy |
| Comment on issue | gh issue comment <N> --repo hiibolt/rosy --body "..." |
| Search issues | gh search issues --repo hiibolt/rosy "<query>" |
| List open issues | gh issue list --repo hiibolt/rosy --state open --json number,title,labels,assignees |
Project Board Operations
| Operation | Command |
|---|
| List board items | gh project item-list 7 --owner hiibolt --format json --limit 100 |
| Add item to board | gh project item-add 7 --owner hiibolt --url <issue-url> --format json |
| Edit item field | gh project item-edit --id <item-id> --project-id PVT_kwHOBXC3xM4BSd_s --field-id <field-id> --single-select-option-id <option-id> |
| Archive item | gh project item-archive 7 --owner hiibolt --id <item-id> |
| Refresh field metadata | gh project field-list 7 --owner hiibolt --format json |
Note: item-edit sets one field per call. To set Status + Priority + Size, make 3 calls.
The item-add command returns JSON with the item ID when --format json is used.
Branch & PR Operations
| Operation | Command |
|---|
| Create branch | git checkout -b <branch-name> master && git push -u origin <branch-name> |
| Create PR | gh pr create --repo hiibolt/rosy --title "..." --body "..." --base master --head <branch> |
| Get PR | gh pr view <N> --repo hiibolt/rosy |
| Get PR (JSON) | gh pr view <N> --repo hiibolt/rosy --json title,body,state,files,reviews,comments,statusCheckRollup |
| PR changed files | gh pr diff <N> --repo hiibolt/rosy |
| PR status/checks | gh pr checks <N> --repo hiibolt/rosy |
| Review PR | gh pr review <N> --repo hiibolt/rosy --approve --body "..." (or --request-changes / --comment) |
| Merge PR | gh pr merge <N> --repo hiibolt/rosy [--squash|--merge|--rebase] |
| List open PRs | gh pr list --repo hiibolt/rosy --state open --json number,title,headRefName,author,createdAt |
| Update PR branch | gh pr update-branch <N> --repo hiibolt/rosy |
Routing
Determine which workflow to use based on the user's request:
| Request type | Workflow |
|---|
| Create a new issue / plan a feature / report a bug | Issue Creation (Phases 0–3 below) |
| Everything else (update, comment, close, move, branch, PR, search) | Quick Actions (see below) |
Quick Actions
For non-creation operations, skip the interview. Just do the thing and confirm.
Issue Operations
- Read issue:
gh issue view — show title, body, state, assignees, labels
- Update issue:
gh issue edit with the relevant flags
- Close issue:
gh issue close
- Comment on issue:
gh issue comment — post the comment, confirm with link
- Search issues:
gh search issues --repo hiibolt/rosy
Board Operations
- Move item to a column: use the Status field ID and option ID from the Board Fields table, then call
item-edit
- Special: moving to "In progress" — when an item moves to In progress, also:
- Assign the issue:
gh issue edit <N> --repo hiibolt/rosy --add-assignee hiibolt (if not already assigned).
- Create a feature branch:
git checkout -b <issue-number>-<short-description> master && git push -u origin <branch>. Skip if a branch for this issue already exists.
- Link branch to issue:
gh issue comment <N> --repo hiibolt/rosy --body '**[Started]** Working on branch \`'`
- Confirm with: the new status, assignee, and branch name so the user can
git fetch && git checkout immediately.
- Change priority/size: use the field IDs and option IDs from the Board Fields table, then call
item-edit
- Add existing issue to board:
gh project item-add 7 --owner hiibolt --url <issue-url>
- Archive item:
gh project item-archive 7 --owner hiibolt --id <item-id>
Branch & PR Operations
- Create branch for issue: use pattern
<issue-number>-<short-description>. All issue work must happen on a feature branch, never directly on master.
- Create PR:
gh pr create — set title, body, head branch, base branch (master). Always include Closes #<issue-number> in the PR body so GitHub auto-links and auto-closes the issue on merge. After creation, add to the project board via gh project item-add and set Status to "In progress" using the hardcoded field IDs.
- Check PR status:
gh pr view or gh pr checks
- Review PR:
gh pr diff to see changes, then gh pr review
- Merge PR:
gh pr merge — confirm merge method with user first. Do not auto-set the board status to "Done" — leave that for the user or a separate explicit action.
- List open PRs:
gh pr list --state open
For all quick actions: execute, confirm the result with a link or summary, done.
If any call fails, report the error clearly.
Live Issue Updates
When actively working on an issue (i.e. it's In Progress and you're writing code), keep
the issue thread alive as a development log using gh issue comment. This gives
visibility without anyone having to ask "how's it going?"
When to Comment
| Trigger | What to post |
|---|
| Starting work | Branch name, initial approach/plan, files you expect to touch |
| Major milestone reached | What was completed, what's next |
| Approach change | Why the original plan didn't work, what you're doing instead |
| Blocker hit | What's blocking, what you've tried, whether you need input |
| PR opened | Link to the PR, brief summary of what's included |
| Work complete | Final summary: what was done, any follow-up items or tech debt noted |
Tone & Format
Keep comments short and scannable. Use this rough format:
**[Status]** Brief headline
- Bullet points with details
- Keep to 2-4 bullets max
Status tags: [Started], [Progress], [Milestone], [Pivot], [Blocked], [PR Ready], [Done]
Do not narrate every file edit or minor refactor. Comment at meaningful boundaries —
when something is done, changed, or stuck.
Commit Cadence
While working on an issue, commit frequently — don't let large amounts of work
accumulate uncommitted. Follow these guidelines:
- Commit after each logical unit of work: a new AST node, a completed operator
implementation, a test passing. Roughly every 15-30 minutes of active coding.
- Commit before pivoting: if you're about to change approach or move to a different
part of the task, commit what you have first.
- Commit before anything risky: about to refactor something that might break? Commit
the working state first.
- Use descriptive commit messages that reference the issue number (e.g.
#42: implement DA division operator).
- Never go more than ~30 minutes of coding without a commit.
Proactively ask the user if they'd like to commit when you've completed a meaningful
chunk of work — don't wait for them to remember.
Issue Creation Workflow
Phase 0 — Read the Room (silent)
Before speaking, do these steps:
-
Classify the issue as feature, bug, or chore/refactor. Load the
matching template from templates/.
-
Gauge readiness: does the user already have a fully-formed spec, or are they
still figuring it out?
- Fast-track: If they arrive with a clear goal, acceptance criteria, and enough
detail to fill the template — skip the interview. Go straight to Phase 2, draft
the issue, and confirm.
- Standard: If they're still thinking, start the conversation (Phase 1).
-
Scan for duplicates:
gh search issues --repo hiibolt/rosy "<keywords>"- If likely duplicates exist, mention them conversationally before proceeding
-
Field metadata: Use the hardcoded values from the Board Fields table.
Do NOT run gh project view or gh project field-list.
Then begin. Don't announce the phases. Just talk.
Phase 1 — The Interview
Your goal is to draw out a fully specified work item through natural dialogue.
Internally track what you still need — but never recite the list.
Required for all issue types:
- One-sentence goal
- Acceptance criteria (checkboxes — how do we know it's done?)
- At least one test case (happy path + one edge case)
- Priority (relative to current board state)
- Size (rough effort signal)
- Status column:
Planning or Ready
Additionally required by type:
| Feature | Bug | Chore |
|---|
| Why now / motivation | Steps to reproduce | What & why |
| Concrete deliverables | Expected vs actual behavior | Approach / plan |
| Out of scope | Environment / context | Behavior changes (if any) |
Nice-to-have (capture if mentioned, don't force):
- Dependencies or risks
- Related issues
- COSY INFINITY compatibility notes
Rosy-specific considerations:
- Does this affect the PEG grammar (
rosy.pest)?
- Does this add a new AST node? Which trait impls are needed?
- Does this need new TypeRule registries or IntrinsicTypeRule entries?
- Does the TDD rule apply (COSY/ROSY output diffing)?
- Is there a relevant COSY manual chapter to reference?
Tone:
- Make creative suggestions — "What about the edge case where the DA order is 0?"
- Notice what's missing and ask sideways — "So if someone passes a complex number here, what should happen?"
- Offer your opinion: "I'd call this Soon priority since it blocks the operator completeness goal..."
- Keep it technical but fun. We're reimagining a 30-year-old language.
Exit condition: When you have a complete picture, present a draft summary and ask:
"Does this capture it? Anything to add or change before I make it real?"
Read references/quality-checklist.md silently before presenting the summary. If any
quality gate is red, address it conversationally — don't dump the checklist.
Phase 2 — Structured Draft
Format the issue body using the loaded template from templates/. Show the user:
- The title (using the template's title format)
- The full body
One final confirmation: "Look good?"
Phase 3 — Act
Once confirmed, execute these steps in order:
Step 1 — Create the issue:
gh issue create --repo hiibolt/rosy \
--title "<from Phase 2>" \
--body "<from Phase 2>" \
--label "<matching type: enhancement, bug, etc.>" \
--assignee "<agreed assignees>"
Step 2 — Add to project board:
gh project item-add 7 --owner hiibolt --url <issue-url> --format json
Parse the item ID from the JSON output.
Step 3 — Set board fields (one item-edit call per field):
gh project item-edit \
--id <item-id> \
--project-id PVT_kwHOBXC3xM4BSd_s \
--field-id <from Board Fields table> \
--single-select-option-id <from Board Fields table>
Set in this order:
- Status — using Board Fields table
- Priority — using Board Fields table
- Size — using Board Fields table
Step 4 — Confirm:
Report to the user:
- Issue URL
- Board placement summary (status, priority, size, assignees)
- One-line summary
Error recovery: If any item-edit call fails with an invalid field or option ID,
run gh project field-list 7 --owner hiibolt --format json once to refresh the metadata,
update working memory, and retry. For other failures, report clearly which step failed
and offer to retry. Never silently skip a field.
Reference Files
references/quality-checklist.md — Quality gates; read silently before exiting Phase 1templates/feature.md — Issue body template for featurestemplates/bug.md — Issue body template for bugstemplates/chore.md — Issue body template for chores/refactors
What Good Looks Like
For issue creation: A great issue should be passable directly to someone with
zero ROSY context and they should know exactly what to build, how to test it, and
when it's done. If it couldn't do that, go back to Phase 1.
For quick actions: Fast, correct, confirmed. Execute the operation, report the
result with a link, move on. No ceremony needed.
