GitHub Agentic Workflows

GitHub Agentic Workflows bring AI-powered automation to your repository. Unlike traditional GitHub Actions that follow rigid if/then rules, agentic workflows use coding agents to read, reason, and act — making them perfect for support tasks that require judgment.

Scitor provides the structured data layer — labels like category:bug-report, sentiment:negative, and priority:high, plus commands like /send — that give agentic workflows the context they need to make intelligent decisions.

How it works

1. You create a .md file in .github/workflows/ describing the task in plain language
2. A lock file (.lock.yml) is generated with gh aw compile
3. The workflow runs in GitHub Actions using a coding agent (Copilot, Claude, etc.)
4. The agent reads Scitor’s labels and issue content, then takes action within defined permissions

Why Scitor + Agentic Workflows

The existing GitHub Actions guide shows deterministic automation: if label X is applied, do Y. Agentic workflows add AI judgment on top of Scitor’s data:

Prerequisites

Before using these workflows, ensure you have:

• Scitor installed on your repository with AI triage enabled (Pro plan)
• The gh-aw CLI extension installed: gh extension install github/gh-aw
• A coding agent configured (e.g., Copilot, Claude Code, or OpenAI Codex)
• Access to the GitHub Agentic Workflows technical preview

Example 1: AI-Powered Smart Triage

This workflow triggers when Scitor creates a new issue from an inbound email. The agent reads the ticket content, analyzes it in context of your codebase and docs, and posts a triage recommendation.

Create .github/workflows/smart-triage.md:

---
on:
  issues:
    types: [opened]
  bots:
    - "scitor-customerops[bot]"

permissions:
  contents: read
  issues: read

safe-outputs:
  create-comment:
    body-prefix: "## 🏷️ Triage Recommendation\n"

tools:
  github:
---

# Smart Triage for Support Tickets

When a new issue is created by scitor-customerops[bot], analyze the ticket
and provide a triage recommendation.

## Steps

1. Check if the issue was created by `scitor-customerops[bot]`. If not, skip.
2. Read the full issue body — this is the customer's email converted to a GitHub issue.
3. Look at the labels Scitor has already applied (category, sentiment, spam score).
4. Search the repository's documentation and recent issues for similar problems.
5. Post a comment with your triage recommendation including:
   - **Suggested priority** (critical/high/medium/low) with reasoning
   - **Suggested assignee** based on the category and your analysis
   - **Similar issues** if you find any related open or recently closed tickets
   - **Recommended first response** — a brief outline of what to address
   - **Knowledge base match** — link to relevant docs if the answer exists

Keep the recommendation concise and actionable. Focus on saving the support
agent time by front-loading the analysis.

Then compile and commit:

gh aw compile
git add .github/workflows/smart-triage.*
git commit -m "Add AI smart triage agentic workflow"
git push

Example 2: AI Draft Reply for Questions

When Scitor labels a ticket as category:question, this workflow searches your knowledge base and drafts a contextual reply. The draft is posted as a comment with /send — but it requires a human to review and approve before Scitor emails it.

Create .github/workflows/draft-reply.md:

---
on:
  issues:
    types: [labeled]
  bots:
    - "scitor-customerops[bot]"

permissions:
  contents: read
  issues: read

safe-outputs:
  create-comment:
    body-prefix: "### 📝 AI Draft Reply\n_Review this draft, edit if needed, then remove this header and approve._\n\n"

tools:
  github:
---

# Draft Reply for Customer Questions

When an issue is labeled `category:question`, draft a helpful reply
for the support agent to review.

## Steps

1. Only proceed if the label is `category:question` and the issue was
   created by `scitor-customerops[bot]`.
2. Read the customer's question from the issue body.
3. Search the repository for documentation, READMEs, and code that might
   answer the question.
4. Search recent closed issues for similar questions that were already answered.
5. Draft a clear, friendly reply that:
   - Directly addresses the customer's question
   - Links to relevant documentation pages
   - Provides step-by-step instructions if applicable
   - Uses a professional, helpful tone
6. Post the draft as a comment. Do NOT include `/send` — the human agent
   will add that after reviewing and approving the draft.

If you cannot find a good answer, say so and suggest the agent escalate
to the relevant team.

Example 3: AI Escalation Analyst

When a ticket has negative sentiment, this workflow analyzes the full conversation and posts an internal analysis to help the support team understand what went wrong and how to respond.

Create .github/workflows/escalation-analyst.md:

---
on:
  issues:
    types: [labeled]

permissions:
  contents: read
  issues: read

safe-outputs:
  create-comment:
    body-prefix: "## 🔍 Escalation Analysis\n_Internal — not sent to customer._\n\n"

tools:
  github:
---

# Escalation Analysis for Negative Sentiment Tickets

When an issue is labeled `sentiment:negative`, perform a thorough
analysis to help the support team respond effectively.

## Steps

1. Only proceed if the label is `sentiment:negative`.
2. Read the full issue body and all comments in the thread.
3. Analyze:
   - **Root cause**: What is the customer frustrated about?
   - **Customer impact**: How severely is this affecting them?
   - **History**: Are there similar recent issues from this customer or about this topic?
   - **Priority assessment**: Should this be escalated beyond the current priority?
4. Post an internal analysis comment with:
   - A one-sentence summary of the situation
   - Root cause analysis
   - Recommended response strategy (empathy points, concrete actions to offer)
   - Suggested priority adjustment if warranted
   - Links to related issues or documentation

Keep the tone factual and solution-oriented. This analysis is for the
support agent, not the customer.

Example 4: Weekly AI Support Report

A scheduled workflow that runs every Monday morning, analyzing the past week’s support activity and generating actionable insights.

Create .github/workflows/weekly-support-report.md:

---
on:
  schedule: weekly

permissions:
  contents: read
  issues: read

safe-outputs:
  create-issue:
    title-prefix: "[Support Report] "
    labels: [report, automated]

tools:
  github:
---

# Weekly Support Report

Generate a comprehensive weekly support report every Monday.

## Analysis

Review all issues from the past 7 days and create a report covering:

### Volume & Resolution
- Total new tickets, closed tickets, and current backlog
- Average time to first response (based on first non-bot comment)
- Issues still open without any response

### Category Breakdown
- Count by category label (bug-report, question, feature-request, billing, account)
- Trend comparison: is any category increasing week over week?

### Sentiment Analysis
- Distribution of sentiment labels (positive, neutral, negative)
- List any negative-sentiment issues still open

### SLA Performance
- Issues with `sla:warning` or `sla:breached` labels
- Average resolution time by priority level

### Recurring Themes
- Identify topics or keywords appearing in 3+ tickets
- Flag potential product issues or documentation gaps

### Recommendations
- Top 3 actionable items for the team this week
- Documentation pages that should be created or updated
- Staffing suggestions based on volume trends

Keep the report concise and scannable. Use tables, bullet points,
and link to specific issues. Focus on what's actionable.

Example 5: Knowledge Gap Detector

A daily workflow that reviews recent question tickets and identifies topics not covered by your documentation, helping you proactively improve your knowledge base.

Create .github/workflows/knowledge-gap-detector.md:

---
on:
  schedule: daily

permissions:
  contents: read
  issues: read

safe-outputs:
  create-issue:
    title-prefix: "[Docs Gap] "
    labels: [documentation, automated]

tools:
  github:
---

# Knowledge Gap Detector

Analyze recent support questions to find gaps in documentation.

## Steps

1. Find all issues from the past 7 days labeled `category:question`.
2. For each question:
   - Extract the core topic or feature being asked about
   - Search the repository's documentation for coverage of that topic
   - Note whether the question was answered with a docs link or required custom explanation
3. Group questions by topic and identify:
   - **Undocumented topics**: Questions about features with no matching docs
   - **Poorly documented topics**: Questions where docs exist but didn't prevent the question
   - **Frequently asked**: Topics with 3+ questions in the period
4. Create an issue with:
   - A prioritized list of documentation gaps
   - For each gap: the topic, how many questions it triggered, and links to those issues
   - Suggested doc page titles and brief outlines
   - Which existing docs pages need expansion

Only create an issue if there are meaningful gaps to report.
Skip if all questions were well-covered by existing documentation.

Getting Started

1. Pick one workflow to start with — we recommend the Smart Triage or Weekly Report
2. Create the .md file in .github/workflows/
3. Compile the lock file: gh aw compile
4. Commit and push both files
5. Monitor the first few runs and refine the instructions based on output quality

Tips

• Allow the Scitor bot — add bots: ["scitor-customerops[bot]"] to the on: section of any workflow that should trigger from Scitor-created issues or labels. Without this, the workflow’s permission check will block bot-triggered runs.
• Start with read-only outputs (comments, reports) before enabling pull request creation
• Be specific about what good output looks like — include format, tone, and length guidance
• Keep humans in the loop — use draft comments that agents review, not auto-sent emails
• Iterate on instructions — treat the workflow .md file as code that improves over time
• Combine with existing workflows — agentic workflows complement, not replace, your deterministic GitHub Actions automations from the GitHub Actions guide