RonanCodes/jira-to-gh
skills/jira-to-gh/SKILL.md
Bridge a Jira (DAFO) ticket to the agent-native GitHub repo flow. Two modes — --mirror creates a one-to-one GH issue in RonanCodes/dataforce with linkbacks both ways; --prd seeds /ro:write-a-prd from the ticket body and publishes the PRD as a GH parent issue. Use when a Taskforce-filed DAFO ticket needs to enter the Skip+Ronan implementation pipeline.
development
Updated May 22, 2026
$ install --global
skillsauthnpx skillsauth add RonanCodes/ronan-skills jira-to-ghInstall this skill globally with one command. Works with Claude Code, Cursor, and Windsurf.
Security Scan Results
3 of 9 scanners reported clean
Some scanners were skipped, did not run, or reported a non-clean status. Review each row below.
3
Scanners Passed
9
Scanners in report
Clean
TrivyContainer and dependency vulnerability scanner
95%
Clean
SemgrepStatic code analysis for vulnerabilities
95%
Clean
mcp-scan (Snyk)Model Context Protocol security validation
95%
Skipped
Snyk (dep)Open source security scanning
50%
Skipped
Socket.devSupply chain security analysis
50%
Skipped
VirusTotalMulti-engine malware detection
50%
Skipped
CrowdStrikeAdvanced threat intelligence
50%
Skipped
OSV-ScannerOpen Source Vulnerability database check
50%
Skipped
OWASP Dep-Check
50%
Last scanned: May 22, 2026, 2:14 AM173.3s1 file scanned
SKILL.md
- name:
- jira-to-gh
- description:
- Bridge a Jira (DAFO) ticket to the agent-native GitHub repo flow. Two modes — --mirror creates a one-to-one GH issue in RonanCodes/dataforce with linkbacks both ways; --prd seeds /ro:write-a-prd from the ticket body and publishes the PRD as a GH parent issue. Use when a Taskforce-filed DAFO ticket needs to enter the Skip+Ronan implementation pipeline.
- category:
- project-management
- argument-hint:
- <DAFO-KEY> [--mirror | --prd] [--repo <owner/name>] [--label <l>]
- allowed-tools:
- Bash(gh *) Bash(claude mcp *) Bash(grep *) Read
Jira → GitHub bridge
The Taskforce partners file work in Jira (DAFO board). Skip and Ronan implement in RonanCodes/dataforce using the agent-native repo pattern (ready-for-agent label, PRDs as GH issues, ralph/planner-worker consume from the queue). This skill is the bridge.
One-way by default: Jira → GitHub. Status drift is acceptable — Jira reflects the partner-facing state ("In Review" until they sign off), GH reflects the implementation state ("merged" the moment a PR lands). Skill ensures URLs are linked both ways so anyone can navigate.
Usage
/ro:jira-to-gh DAFO-42 # default: --mirror, into RonanCodes/dataforce
/ro:jira-to-gh DAFO-42 --mirror # one-to-one GH issue
/ro:jira-to-gh DAFO-42 --prd # seed /ro:write-a-prd from ticket body, publish as GH parent
/ro:jira-to-gh DAFO-42 --mirror --repo RonanCodes/some-other-repo
Prerequisites
/ro:jiraworking (atlassian MCP authenticated)ghCLI authenticated againstRonanCodes(or whichever target org)- For
--prd: the/ro:write-a-prdskill installed;/ro:repo-moderesolved topersonalfor the target repo so the PRD publishes to GH and not.ralph/
Mode: --mirror (default)
For: small / well-specified DAFO tickets that map to a single agent slice.
Steps:
- Fetch the Jira ticket via the atlassian MCP (typically
getJiraIssue). Capture: summary, description, type (Bug/Story/Task/Feature), labels, reporter, current status. - Build the GH issue body in this shape:
## Source Mirrored from Jira **DAFO-42** — https://simplicitylabs.atlassian.net/browse/DAFO-42 Reporter: <Jira reporter name> Type: <Bug|Story|Task|Feature> ## Description <Jira description, converted to GitHub-flavoured markdown> - Create the GH issue via
gh issue create:- Title: same as Jira summary
- Labels:
ready-for-agent, plus a type-derived label (bug,feature,task) - Body: as above
- Comment on the Jira ticket via the atlassian MCP with the GH issue URL:
Mirrored to GitHub for implementation: <gh issue URL> Status updates will appear here when the GH issue closes. - Print both URLs + the issue number so the user can navigate.
Mode: --prd
For: larger DAFO tickets that need decomposition into vertical slices, or anything the user wants grilled with Matt Pocock's 7-section template.
Steps:
- Fetch the Jira ticket as in
--mirror. - Hand off to
/ro:write-a-prdwith the ticket body as the seed brief. The PRD interview will grill on Problem / Users / Scope / Out-of-Scope / Acceptance / Risks / Sequencing. - Once the PRD is published as a GH issue (write-a-prd handles that in personal repo mode), comment on the Jira ticket:
PRD authored from this ticket: <gh parent issue URL> Next: slicing into vertical-slice issues via /ro:slice-into-issues. - Recommend the next step —
/ro:slice-into-issues <PRD#>— but do not run it automatically. User decides when to slice. - Print both URLs + suggest the user invoke
/ro:slice-into-issueswhen ready.
Status sync — keep it simple
This skill does NOT auto-sync status. Reason: Jira lifecycle (Taskforce-facing) and GH lifecycle (implementation-facing) diverge intentionally. A DAFO ticket can sit in "In Review" while three GH PRs ship and re-ship around it.
Convention:
- When the GH issue closes (PR merged with
Closes #N), the user (or a close-with-summary subagent) should run/ro:jira move DAFO-42 "In Review"and post a comment with the deploy URL. - When the change is actually live in production and Taskforce can verify,
/ro:jira move DAFO-42 done.
The "Done means shipped" rule from the partnership chat is preserved by keeping the moves manual.
Failure modes
| Symptom | Cause | Fix |
|---|---|---|
| gh: command not found or auth error | gh not installed / not auth'd | Install gh, run gh auth login |
| Jira ticket fetched but description is empty | DAFO ticket was filed without body | Fetch comments too and use the first comment as description |
| Markdown formatting from Jira renders ugly on GH | Atlassian wiki markup vs GitHub MD difference | The MCP usually returns ADF/markdown; if it returns wiki markup, run through a converter or strip noise manually |
| /ro:write-a-prd opens but doesn't know about the Jira context | Seed not passed cleanly | Pre-format the brief as a single paragraph before the handoff; mention the DAFO key in the first line |
Why one-way (not bidirectional)
- Two-way sync invites loop bugs (close-on-close ping-pong) and conflict cases (status drift while edits are in flight).
- The partner contract is "Jira is the source of truth for partner-facing state, GH is the source of truth for implementation state, links bridge them." That contract is preserved by manual status moves on the Jira side.
- If bidirectional becomes painful enough to want, file as a DAFO ticket and revisit. Don't pre-build for it.
Related
/ro:jira— basic ticket CRUD/ro:write-a-prd— Matt Pocock 7-section PRD interview, publishes to GH/ro:slice-into-issues— vertical-slice a PRD into ready-for-agent children/ro:ralph,/ro:planner-worker— consume the ready-for-agent queue- Partnership pattern note:
[[agent-native-repo-pocock]]inllm-wiki-skill-lab
Related Skills
RonanCodes/skills/worktree
development
VerifiedTrustedCommunity
--- name: worktree description: Coordinate multiple agents on one repo via a worktree-lock pool, so two agents never clobber each other's working tree. Acquire the first free slot (main, then beta/gamma… worktrees, created on demand), work there on your own branch, release when you've pushed. Use before modifying any repo that might be in use by another agent (factory, dataforce, etc.), or whenever you're told a repo is being worked on. Backed by `ro worktree`. category: development argument-hin
SKILL.mdUpdated May 25, 2026
RonanCodes/skills/ship
testing
VerifiedTrustedCommunity
--- name: ship description: Ship a feature branch the local-CI-first way — run the full local gate, push, open a PR, squash-merge, then deploy, without waiting on GitHub Actions. Use when a branch is ready for main and you want it merged and deployed now. Reads CI policy from `ro ci` (default skips remote CI because GitHub Actions billing keeps hitting limits). Sibling to /ro:gh-ship (waits on GitHub checks) and /ro:cf-ship (the deploy half). Triggers on "ship it", "ship this", "merge and deploy
SKILL.mdUpdated May 25, 2026
RonanCodes/skills/setup-logging
testing
VerifiedTrustedCommunity
--- name: setup-logging description: Set up (or audit) the observability stack in a TanStack Start + Cloudflare Workers app so it is "diagnosable by default" — structured logging (logtape) with a request context carrying trace_id + userId + tenant/orgId, a trace_id propagated FE→BE→logs→Sentry→PostHog, Cloudflare Workers observability enabled, and Sentry + PostHog wired. Two modes: `setup` (wire it into an app) and `audit` (check an existing app + report gaps). Use when scaffolding a new app, wh
SKILL.mdUpdated May 24, 2026
RonanCodes/env
development
VerifiedTrustedCommunity
Manage credentials INSIDE the active ~/.claude/.env file — read which token/account to use for a given app (Simplicity vs Dataforce vs Ronan-personal), add or update a secret WITHOUT it passing through the chat (an interactive Terminal window prompts for it), and track secrets that were exposed in a transcript so they get rotated. Sibling to /ro:context (which switches WHICH env file is active). Use when the user wants to add an API key/token/secret, asks "which credential do I use for X", needs the env organized/labelled, or a secret was pasted into the chat and should be rotated.
SKILL.mdUpdated May 24, 2026