Expert at managing GitHub issue relationships including parent/sub-issues, blocking dependencies, and tracking links using the GraphQL API. Auto-invokes when creating issue hierarchies, setting parent-child relationships, managing dependencies, or linking related issues.
Auto-invokes when creating parent-child issue hierarchies, managing dependencies, or linking related issues via GraphQL API. Manages sub-issues, blocking relationships, and complex issue graphs beyond standard CLI capabilities.
/plugin marketplace add C0ntr0lledCha0s/claude-code-plugin-automations/plugin install github-workflows@claude-code-plugin-automationsThis skill is limited to using the following tools:
scripts/manage-relationships.pyYou are an expert at managing GitHub issue relationships using the GraphQL API. This skill provides capabilities beyond the standard gh issue CLI, enabling proper parent-child hierarchies, dependency tracking, and issue linking.
Auto-invoke this skill when the conversation involves:
Create explicit parent-child relationships using GitHub's sub-issues feature.
Add Sub-Issue:
python3 {baseDir}/scripts/manage-relationships.py add-sub-issue \
--parent 67 \
--child 68
Remove Sub-Issue:
python3 {baseDir}/scripts/manage-relationships.py remove-sub-issue \
--parent 67 \
--child 68
List Sub-Issues:
python3 {baseDir}/scripts/manage-relationships.py list-sub-issues --issue 67
Track blocking dependencies between issues.
View Dependencies:
python3 {baseDir}/scripts/manage-relationships.py show-dependencies --issue 68
Query complex relationship graphs.
Get Parent:
python3 {baseDir}/scripts/manage-relationships.py get-parent --issue 68
Get All Relationships:
python3 {baseDir}/scripts/manage-relationships.py show-all --issue 67
Creates a parent-child relationship.
mutation {
addSubIssue(input: {
issueId: "PARENT_NODE_ID",
subIssueId: "CHILD_NODE_ID"
}) {
issue { number title }
subIssue { number title }
}
}
Input Fields:
issueId (required): Parent issue node IDsubIssueId: Child issue node IDsubIssueUrl: Alternative - child issue URLreplaceParent: Boolean to replace existing parentRemoves a parent-child relationship.
mutation {
removeSubIssue(input: {
issueId: "PARENT_NODE_ID",
subIssueId: "CHILD_NODE_ID"
}) {
issue { number }
subIssue { number }
}
}
Reorders sub-issues within a parent.
mutation {
reprioritizeSubIssue(input: {
issueId: "PARENT_NODE_ID",
subIssueId: "CHILD_NODE_ID",
afterId: "SIBLING_NODE_ID"
}) {
issue { number }
}
}
query {
repository(owner: "OWNER", name: "REPO") {
issue(number: 67) {
# Parent-child
parent { number title }
subIssues(first: 50) {
nodes { number title state }
}
subIssuesSummary {
total
completed
percentCompleted
}
# Dependencies
blockedBy(first: 10) {
nodes { number title }
}
blocking(first: 10) {
nodes { number title }
}
# Tracking (from task lists)
trackedInIssues(first: 10) {
nodes { number title }
}
trackedIssues(first: 10) {
nodes { number title }
}
trackedIssuesCount
}
}
}
For operations not covered by scripts, use gh api graphql directly:
gh api graphql -f query='
query {
repository(owner: "OWNER", name: "REPO") {
issue(number: 67) { id }
}
}'
gh api graphql -f query='
mutation {
add1: addSubIssue(input: {issueId: "PARENT_ID", subIssueId: "CHILD1_ID"}) {
subIssue { number }
}
add2: addSubIssue(input: {issueId: "PARENT_ID", subIssueId: "CHILD2_ID"}) {
subIssue { number }
}
}'
gh api graphql -f query='
query {
repository(owner: "OWNER", name: "REPO") {
issue(number: 67) {
number
title
subIssues(first: 100) {
nodes {
number
title
state
subIssues(first: 10) {
nodes { number title }
}
}
}
}
}
}'
When creating a parent issue with children:
# Step 1: Get IDs
python3 {baseDir}/scripts/manage-relationships.py get-ids --issues 67,68,69,70
# Step 2: Add relationships
python3 {baseDir}/scripts/manage-relationships.py add-sub-issue --parent 67 --child 68
python3 {baseDir}/scripts/manage-relationships.py add-sub-issue --parent 67 --child 69
python3 {baseDir}/scripts/manage-relationships.py add-sub-issue --parent 67 --child 70
# Step 3: Verify
python3 {baseDir}/scripts/manage-relationships.py list-sub-issues --issue 67
For complex hierarchies:
Epic (#1)
├── Feature A (#2)
│ ├── Task A1 (#5)
│ └── Task A2 (#6)
└── Feature B (#3)
└── Task B1 (#7)
# Top-level children
python3 {baseDir}/scripts/manage-relationships.py add-sub-issue --parent 1 --child 2
python3 {baseDir}/scripts/manage-relationships.py add-sub-issue --parent 1 --child 3
# Nested children
python3 {baseDir}/scripts/manage-relationships.py add-sub-issue --parent 2 --child 5
python3 {baseDir}/scripts/manage-relationships.py add-sub-issue --parent 2 --child 6
python3 {baseDir}/scripts/manage-relationships.py add-sub-issue --parent 3 --child 7
# Use replaceParent flag
python3 {baseDir}/scripts/manage-relationships.py add-sub-issue \
--parent 100 \
--child 68 \
--replace-parent
"Issue may not contain duplicate sub-issues"
"Sub issue may only have one parent"
--replace-parent flag or remove from current parent first"Issue not found"
# Check if issue has parent
python3 {baseDir}/scripts/manage-relationships.py get-parent --issue 68
# List all relationships
python3 {baseDir}/scripts/manage-relationships.py show-all --issue 68
This skill requires:
gh CLI authenticated with appropriate permissionstype:epic label for parent issues❌ WRONG - Task lists create "tracked" relationships, not parent-child:
## Child Issues
- [ ] #68
- [ ] #69
- [ ] #70
✅ CORRECT - Use GraphQL addSubIssue mutation:
python manage-relationships.py add-sub-issue --parent 67 --child 68
python manage-relationships.py add-sub-issue --parent 67 --child 69
python manage-relationships.py add-sub-issue --parent 67 --child 70
Why it matters:
❌ WRONG - Using issue numbers directly in GraphQL:
mutation {
addSubIssue(input: {issueId: "67", subIssueId: "68"}) { ... }
}
✅ CORRECT - Get node IDs first, then use them:
# Step 1: Get node IDs
python manage-relationships.py get-ids --issues 67,68
# Step 2: Use node IDs in mutation
mutation {
addSubIssue(input: {
issueId: "I_kwDOQTQw6c7Z4spt",
subIssueId: "I_kwDOQTQw6c7Z4swL"
}) { ... }
}
Why it matters: GraphQL uses node IDs (not issue numbers). The script handles this automatically, but direct API calls require the conversion.
❌ WRONG - Adding sub-issue without checking existing parent:
python manage-relationships.py add-sub-issue --parent 100 --child 68
# Error: Sub issue may only have one parent
✅ CORRECT - Check first, then use --replace-parent if needed:
# Check existing parent
python manage-relationships.py get-parent --issue 68
# If has parent, use replace flag
python manage-relationships.py add-sub-issue --parent 100 --child 68 --replace-parent
Why it matters: Each issue can only have one parent. Attempting to add to a new parent without the replace flag will fail.
❌ WRONG - Creating cycles in hierarchy:
# A is parent of B
python manage-relationships.py add-sub-issue --parent A --child B
# Then trying to make B parent of A
python manage-relationships.py add-sub-issue --parent B --child A
# Error: Cannot create circular reference
✅ CORRECT - Plan hierarchy before creating:
Epic (#1)
├── Feature A (#2)
│ └── Task A1 (#5)
└── Feature B (#3)
└── Task B1 (#7)
Why it matters: GitHub prevents circular references. Plan your hierarchy structure before creating relationships.
❌ WRONG - Adding relationships without verification:
python manage-relationships.py add-sub-issue --parent 67 --child 68
# Just assume it worked
✅ CORRECT - Verify relationships were created:
python manage-relationships.py add-sub-issue --parent 67 --child 68
python manage-relationships.py list-sub-issues --issue 67
# Confirms: Sub-issues (4): #68, #69, #70, #71
Why it matters: API calls can fail silently or partially. Always verify the result matches expectations.
❌ WRONG - Too many levels of nesting:
Epic
└── Theme
└── Feature
└── Story
└── Task
└── Subtask (6 levels!)
✅ CORRECT - Keep hierarchy shallow (2-3 levels):
Epic
├── Feature A
│ ├── Task A1
│ └── Task A2
└── Feature B
└── Task B1
Why it matters: Deep nesting becomes hard to manage and navigate. Most projects work well with 2-3 levels maximum.
gh issue CLI does NOT support relationship managementgh api graphql for relationships- [ ] #68) create "tracked" relationships, not parent-childCreating algorithmic art using p5.js with seeded randomness and interactive parameter exploration. Use this when users request creating art using code, generative art, algorithmic art, flow fields, or particle systems. Create original algorithmic art rather than copying existing artists' work to avoid copyright violations.
Applies Anthropic's official brand colors and typography to any sort of artifact that may benefit from having Anthropic's look-and-feel. Use it when brand colors or style guidelines, visual formatting, or company design standards apply.
Create beautiful visual art in .png and .pdf documents using design philosophy. You should use this skill when the user asks to create a poster, piece of art, design, or other static piece. Create original visual designs, never copying existing artists' work to avoid copyright violations.