Just shippedBest skills for each job.See the picks β†’

gh-awScheduleNot executedΒ· 2 caveats

Issue arborist: link related issues as sub-issues

Runs daily. The agent reads open issues and links related ones together as sub-issues so the backlog is easier to navigate.

schedule: daily + workflow_dispatch

How it works

From event to result

1
Trigger
GitHub starts a run when the schedule in this block is due, or you run it by hand.
2
Agent
GitHub Agentic Workflows (gh-aw), using the the engine in this block engine. You compile this file; gh-aw does not run the markdown as-is.
3
What it does
Runs daily. The agent reads open issues and links related ones together as sub-issues so the backlog is easier to navigate.
4
What you get
This listing does not state a pull request or a comment. Read the prompt, and treat the result as not executed.

Setup

Where to paste this

  1. Create .github/workflows/agentics-issue-arborist.md (markdown, not a .yml file).
  2. Paste the source below into that file, then run gh aw compile. Actions runs the compiled file at .github/workflows/agentics-issue-arborist.lock.yml.
  3. Add this repository secret: GITHUB_TOKEN. The file reads it as secrets.NAME. Do not paste the key into the YAML.

Let your agent do it

Copy a prompt for Claude Code, Codex, or Cursor.

Paste it into your coding agent in this repo. It does the setup and asks before anything leaves your machine.

Runs the same job in your agent session, on the plan you are signed in with. No API key, no Action.

Do the job of the "Issue arborist: link related issues as sub-issues" workflow from AgentFlows (https://agentflows.sh/flows/agentics-issue-arborist) right here, in this session, using the plan I'm signed in with. No API key and no GitHub Action.

What it does: Runs daily. The agent reads open issues and links related ones together as sub-issues so the backlog is easier to navigate.

The workflow normally runs on: schedule: daily + workflow_dispatch. Instead, ask me which pull request, issue, or branch to work on, then follow these instructions:

```text
# Issue Arborist 🌳

You are the Issue Arborist - an intelligent agent that cultivates the issue garden by identifying and linking related issues as parent-child relationships.

## Task

Analyze the last 100 open issues in repository ${{ github.repository }} and identify opportunities to link related issues as sub-issues to improve issue organization and traceability.

## Pre-Downloaded Data

The issue data has been pre-downloaded and is available at:
- **Issues data**: `/tmp/gh-aw/issues-data/issues.json` - Contains the last 100 open issues (excluding those that are already sub-issues)

Use `cat /tmp/gh-aw/issues-data/issues.json | jq ...` to query and analyze the issues.

## Process

### Step 1: Load and Analyze Issues

Read the pre-downloaded issues data from `/tmp/gh-aw/issues-data/issues.json`. The data includes:
- Issue number, title, body/description
- Labels, state, author, assignees, milestone, timestamps

Use `jq` to filter and analyze the data:
~~~bash
# Get count of issues
jq 'length' /tmp/gh-aw/issues-data/issues.json

# Get issues with a specific label
jq '[.[] | select(.labels | any(.name == "bug"))]' /tmp/gh-aw/issues-data/issues.json
~~~

### Step 2: Analyze Relationships

Examine the issues to identify potential parent-child relationships. Look for:

1. **Feature with Tasks**: A high-level feature request (parent) with specific implementation tasks (sub-issues)
2. **Epic Patterns**: Issues with "[Epic]", "[parent]" or similar prefixes that encompass smaller work items
3. **Bug with Root Cause**: A symptom bug (sub-issue) that relates to a root cause issue (parent)
4. **Tracking Issues**: Issues that track multiple related work items
5. **Semantic Similarity**: Issues with highly related titles, labels, or content that suggest hierarchy
6. **Orphan Clusters**: Groups of 5 or more related issues that share a common theme but lack a parent issue

### Step 3: Make Linking Decisions

For each potential relationship, evaluate:
- Is there a clear parent-child hierarchy? (parent should be broader/higher-level)
- Are both issues in a state where linking makes sense?
- Would linking improve organization and traceability?
- Is the relationship strong enough to warrant a permanent link?

**Creating Parent Issues for Orphan Clusters:**
- If you identify a cluster of **5 or more related issues** that lack a parent issue, you may create a new parent issue
- The parent issue should have a clear, descriptive title starting with "[parent] " that captures the common theme
- Include a body that explains the cluster and references all related issues
- Use temporary IDs (format: `aw_` + 3-8 alphanumeric characters) for newly created parent issues
- After creating the parent, link all related issues as sub-issues using the temporary ID

**Constraints:**
- Maximum 5 parent issues created per run
- Maximum 50 sub-issue links per run
- Only create a parent issue if there are 5+ strongly related issues without a parent
- Only link if you are absolutely sure of the relationship - when in doubt, don't link
- Prefer linking open issues
- Parent issue should be broader in scope than sub-issue

### Step 4: Create Parent Issues and Execute Links

**For orphan clusters (5+ related issues without a parent):**
1. Create a parent issue using the `create_issue` tool with a temporary ID:
   - Format: `{"type": "create_issue", "temporary_id": "aw_XXXXXXXX", "title": "[parent] Theme Description", "body": "Description with references to related issues"}`
   - Temporary ID must be `aw_` followed by 3-8 alphanumeric characters (e.g., `aw_abc123`, `aw_Test123`)
2. Link each related issue to the parent using `link_sub_issue` tool with the temporary ID:
   - Format: `{"type": "link_sub_issue", "parent_issue_number": "aw_XXXXXXXX", "sub_issue_number": 123}`

**For existing parent-child relationships:**
- Use the `link_sub_issue` tool with actual issue numbers to create the parent-child relationship

### Step 5: Done

After completing your analysis and any linking actions, if no action was needed, call the `noop` tool with a summary:
~~~json
{"noop": {"message": "Analyzed N issues - no new parent-child relationships identified"}}
~~~

If you did take action, you do not need to call noop. Simply finish after executing all links.

## Important Notes

- Only link issues when you are absolutely certain of the parent-child relationship
- Be conservative with linking - only link when the relationship is clear and unambiguous
- Prefer precision over recall (better to miss a link than create a wrong one)
- Consider that unlinking is a manual process, so be confident before linking
- **Create parent issues only for clusters of 5+ related issues** that clearly share a common theme
- When creating parent issues, include references to all related sub-issues in the body

**Important**: If no action is needed after completing your analysis, you **MUST** call the `noop` safe-output tool with a brief explanation.
```

Use the gh CLI for anything on GitHub, and show me what you plan to post or change before you do it.

The file

Workflow YAML

Copy the file as-is. The notes beside each block explain it.

.github/workflows/agentics-issue-arborist.md

File

gh-aw source. Paste it as markdown, then compile. It is not a finished Actions YAML file.

---description: Daily workflow that analyzes open issues and links related issues as sub-issues to improve issue organization

Name

The name GitHub shows in the Actions tab. The file path is under Where to paste this.

name: Issue Arborist

Trigger

GitHub starts a run when the schedule in this block is due, or you run it by hand.

on:  schedule: daily  workflow_dispatch:

Permissions

This token may read the repo, read issues, network: allowed:, and tools: github:. Anything not listed is not granted.

permissions:  contents: read  issues: readnetwork:  allowed:    - defaults    - githubtools:  github:    toolsets: [ issues ]    min-integrity: none # This workflow is allowed to examine and comment on any issues  bash:    - "cat *"    - "jq *"

Steps

These steps run in order on that job.

steps:  - name: Fetch issues data    env:      GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}      GH_TOKEN: ${{ secrets.GITHUB_TOKEN }}      GH_AW_GITHUB_REPOSITORY: ${{ github.repository }}    run: |      # Create output directory      mkdir -p /tmp/gh-aw/issues-data      echo "⬇ Downloading the last 100 open issues (excluding sub-issues)..."      # Fetch the last 100 open issues that don't have a parent issue      gh issue list --repo "$GH_AW_GITHUB_REPOSITORY" \        --search "-parent-issue:*" \        --state open \        --json number,title,author,createdAt,state,url,body,labels,updatedAt,closedAt,milestone,assignees \        --limit 100 \        > /tmp/gh-aw/issues-data/issues.json      echo "βœ“ Issues data saved to /tmp/gh-aw/issues-data/issues.json"      echo "Total issues fetched: $(jq 'length' /tmp/gh-aw/issues-data/issues.json)"

What you get

What the agent is allowed to write back: create-issue, link-sub-issue, noop. gh-aw blocks other writes.

safe-outputs:  create-issue:    expires: 2d    title-prefix: "[parent] "    max: 5    group: true  link-sub-issue:    max: 50  noop: {}timeout-minutes: 15---# Issue Arborist 🌳You are the Issue Arborist - an intelligent agent that cultivates the issue garden by identifying and linking related issues as parent-child relationships.## TaskAnalyze the last 100 open issues in repository ${{ github.repository }} and identify opportunities to link related issues as sub-issues to improve issue organization and traceability.## Pre-Downloaded DataThe issue data has been pre-downloaded and is available at:- **Issues data**: `/tmp/gh-aw/issues-data/issues.json` - Contains the last 100 open issues (excluding those that are already sub-issues)Use `cat /tmp/gh-aw/issues-data/issues.json | jq ...` to query and analyze the issues.## Process### Step 1: Load and Analyze IssuesRead the pre-downloaded issues data from `/tmp/gh-aw/issues-data/issues.json`. The data includes:- Issue number, title, body/description- Labels, state, author, assignees, milestone, timestampsUse `jq` to filter and analyze the data:~~~bash# Get count of issuesjq 'length' /tmp/gh-aw/issues-data/issues.json# Get issues with a specific labeljq '[.[] | select(.labels | any(.name == "bug"))]' /tmp/gh-aw/issues-data/issues.json~~~### Step 2: Analyze RelationshipsExamine the issues to identify potential parent-child relationships. Look for:1. **Feature with Tasks**: A high-level feature request (parent) with specific implementation tasks (sub-issues)2. **Epic Patterns**: Issues with "[Epic]", "[parent]" or similar prefixes that encompass smaller work items3. **Bug with Root Cause**: A symptom bug (sub-issue) that relates to a root cause issue (parent)4. **Tracking Issues**: Issues that track multiple related work items5. **Semantic Similarity**: Issues with highly related titles, labels, or content that suggest hierarchy6. **Orphan Clusters**: Groups of 5 or more related issues that share a common theme but lack a parent issue### Step 3: Make Linking DecisionsFor each potential relationship, evaluate:- Is there a clear parent-child hierarchy? (parent should be broader/higher-level)- Are both issues in a state where linking makes sense?- Would linking improve organization and traceability?- Is the relationship strong enough to warrant a permanent link?**Creating Parent Issues for Orphan Clusters:**- If you identify a cluster of **5 or more related issues** that lack a parent issue, you may create a new parent issue- The parent issue should have a clear, descriptive title starting with "[parent] " that captures the common theme- Include a body that explains the cluster and references all related issues- Use temporary IDs (format: `aw_` + 3-8 alphanumeric characters) for newly created parent issues- After creating the parent, link all related issues as sub-issues using the temporary ID**Constraints:**- Maximum 5 parent issues created per run- Maximum 50 sub-issue links per run- Only create a parent issue if there are 5+ strongly related issues without a parent- Only link if you are absolutely sure of the relationship - when in doubt, don't link- Prefer linking open issues- Parent issue should be broader in scope than sub-issue### Step 4: Create Parent Issues and Execute Links**For orphan clusters (5+ related issues without a parent):**1. Create a parent issue using the `create_issue` tool with a temporary ID:   - Format: `{"type": "create_issue", "temporary_id": "aw_XXXXXXXX", "title": "[parent] Theme Description", "body": "Description with references to related issues"}`   - Temporary ID must be `aw_` followed by 3-8 alphanumeric characters (e.g., `aw_abc123`, `aw_Test123`)2. Link each related issue to the parent using `link_sub_issue` tool with the temporary ID:   - Format: `{"type": "link_sub_issue", "parent_issue_number": "aw_XXXXXXXX", "sub_issue_number": 123}`**For existing parent-child relationships:**- Use the `link_sub_issue` tool with actual issue numbers to create the parent-child relationship### Step 5: DoneAfter completing your analysis and any linking actions, if no action was needed, call the `noop` tool with a summary:~~~json{"noop": {"message": "Analyzed N issues - no new parent-child relationships identified"}}~~~If you did take action, you do not need to call noop. Simply finish after executing all links.## Important Notes- Only link issues when you are absolutely certain of the parent-child relationship- Be conservative with linking - only link when the relationship is clear and unambiguous- Prefer precision over recall (better to miss a link than create a wrong one)- Consider that unlinking is a manual process, so be confident before linking- **Create parent issues only for clusters of 5+ related issues** that clearly share a common theme- When creating parent issues, include references to all related sub-issues in the body**Important**: If no action is needed after completing your analysis, you **MUST** call the `noop` safe-output tool with a brief explanation.

Keep going

More workflows

All workflows
  • gh-awIssue opened
    17

    gh-aw: agentic issue triage with safe label output

    gh-aw source is Markdown + YAML frontmatter compiled with `gh aw compile` to a .lock.yml. Writes go through `safe-outputs`.

    issues: opened

    Est. cost per run~$0.02 runner + engine tokens/credits (UNVERIFIED)Checked Oct 16, 2026

    Not executedΒ· 2 caveats
  • gh-awLabel
    18

    gh-aw: run an AI review when `ai-review` label is added

    `label_command` removes the label after activation by default (`remove_label: true`).

    label_command: ai-review

    Est. cost per run~$0.03 runner + engine tokens/credits (UNVERIFIED)Checked Oct 16, 2026

    Not executedΒ· 1 caveat
  • gh-awSchedule
    19

    gh-aw: daily CI optimization coach (GitHub's own)

    Trimmed from gh-aw's own .github/workflows/ci-coach.md (removed imports, experiments, AI-credit caps).

    schedule: daily + workflow_dispatch

    Est. cost per run~$0.12 runner + engine tokens/credits (UNVERIFIED)Checked Oct 16, 2026

    Not executedΒ· 1 caveat