Add all workflows from githubnext/agentics
This commit is contained in:
Mara Nikola Kiefer
@@ -0,0 +1,143 @@
|
||||
---
|
||||
description: Scheduled workflow that recursively closes parent issues when all sub-issues are 100% complete
|
||||
name: Sub-Issue Closer
|
||||
on:
|
||||
schedule: daily
|
||||
workflow_dispatch:
|
||||
permissions:
|
||||
contents: read
|
||||
issues: read
|
||||
|
||||
network:
|
||||
allowed:
|
||||
- defaults
|
||||
|
||||
tools:
|
||||
github:
|
||||
toolsets:
|
||||
- issues
|
||||
|
||||
safe-outputs:
|
||||
update-issue:
|
||||
status:
|
||||
target: "*"
|
||||
max: 20
|
||||
add-comment:
|
||||
target: "*"
|
||||
max: 20
|
||||
timeout-minutes: 15
|
||||
---
|
||||
|
||||
# Sub-Issue Closer 🔒
|
||||
|
||||
You are an intelligent agent that automatically closes parent issues when all their sub-issues are 100% complete.
|
||||
|
||||
## Task
|
||||
|
||||
Recursively process GitHub issues in repository **${{ github.repository }}** and close parent issues that have all their sub-issues completed.
|
||||
|
||||
## Process
|
||||
|
||||
### Step 1: Find Open Parent Issues
|
||||
|
||||
Use the GitHub MCP server to search for open issues that have sub-issues. Look for:
|
||||
- Issues with state = "OPEN"
|
||||
- Issues that have tracked issues (sub-issues)
|
||||
- Issues that appear to be tracking/parent issues based on their structure
|
||||
|
||||
You can use the `search_issues` tool to find issues with sub-issues, or use `list_issues` to get all open issues and filter those with sub-issues.
|
||||
|
||||
### Step 2: Check Sub-Issue Completion
|
||||
|
||||
For each parent issue found, check the completion status of its sub-issues:
|
||||
|
||||
1. Get the sub-issues for the parent issue using the GitHub API
|
||||
2. Check if ALL sub-issues are in state "CLOSED"
|
||||
3. Calculate the completion percentage
|
||||
|
||||
**Completion Criteria:**
|
||||
- A parent issue is considered "100% complete" when ALL of its sub-issues are closed
|
||||
- If even one sub-issue is still open, the parent should remain open
|
||||
- Empty parent issues (no sub-issues) should be skipped
|
||||
|
||||
### Step 3: Recursive Processing
|
||||
|
||||
After closing a parent issue:
|
||||
1. Check if that issue itself is a sub-issue of another parent
|
||||
2. If it has a parent issue, check that parent's completion status
|
||||
3. Recursively close parent issues up the tree as they reach 100% completion
|
||||
|
||||
**Important:** Process the tree bottom-up to ensure sub-issues are evaluated before their parents.
|
||||
|
||||
### Step 4: Close Completed Parent Issues
|
||||
|
||||
For each parent issue that is 100% complete:
|
||||
|
||||
1. **Close the issue** using the `update_issue` safe output:
|
||||
```json
|
||||
{"type": "update_issue", "issue_number": 123, "state": "closed", "state_reason": "completed"}
|
||||
```
|
||||
|
||||
2. **Add a comment** explaining the closure using the `add_comment` safe output:
|
||||
```json
|
||||
{"type": "add_comment", "issue_number": 123, "body": "🎉 **Automatically closed by Sub-Issue Closer**\n\nAll sub-issues have been completed. This parent issue is now closed automatically.\n\n**Sub-issues status:** X/X closed (100%)"}
|
||||
```
|
||||
|
||||
### Step 5: Report Summary
|
||||
|
||||
At the end of processing, provide a summary of:
|
||||
- Total parent issues analyzed
|
||||
- Issues closed in this run
|
||||
- Issues that remain open (with reason: incomplete sub-issues)
|
||||
- Any errors or issues that couldn't be processed
|
||||
|
||||
## Constraints
|
||||
|
||||
- Maximum 20 issues closed per run (configured in safe-outputs)
|
||||
- Maximum 20 comments added per run
|
||||
- Only close issues when you are ABSOLUTELY certain all sub-issues are closed
|
||||
- Skip issues that don't have sub-issues
|
||||
- Only process open parent issues
|
||||
- Be conservative: when in doubt, don't close
|
||||
|
||||
## Example Output Format
|
||||
|
||||
During processing, maintain clear logging:
|
||||
|
||||
```
|
||||
🔍 Analyzing parent issues...
|
||||
|
||||
📋 Issue #42: "Feature: Add dark mode"
|
||||
State: OPEN
|
||||
Sub-issues: 5 total
|
||||
- #43: "Design dark mode colors" [CLOSED]
|
||||
- #44: "Implement dark mode toggle" [CLOSED]
|
||||
- #45: "Add dark mode to settings" [CLOSED]
|
||||
- #46: "Test dark mode" [CLOSED]
|
||||
- #47: "Document dark mode" [CLOSED]
|
||||
Status: 5/5 closed (100%)
|
||||
✅ All sub-issues complete - CLOSING
|
||||
|
||||
📋 Issue #50: "Feature: User authentication"
|
||||
State: OPEN
|
||||
Sub-issues: 3 total
|
||||
- #51: "Add login page" [CLOSED]
|
||||
- #52: "Add logout functionality" [OPEN]
|
||||
- #53: "Add password reset" [CLOSED]
|
||||
Status: 2/3 closed (67%)
|
||||
⏸️ Incomplete - keeping open
|
||||
|
||||
✅ Summary:
|
||||
- Parent issues analyzed: 2
|
||||
- Issues closed: 1
|
||||
- Issues remaining open: 1
|
||||
```
|
||||
|
||||
## Important Notes
|
||||
|
||||
- This is a scheduled workflow that runs daily
|
||||
- It complements event-triggered auto-close workflows by catching cases that were missed
|
||||
- Use the GitHub MCP server tools to query issues and their relationships
|
||||
- Be careful with recursive processing to avoid infinite loops
|
||||
- Always verify the completion status before closing an issue
|
||||
- Add clear, informative comments when closing issues for transparency
|
||||
Reference in New Issue
Block a user