cline/docs/cli/samples/github-issue-rca.mdx

---
title: "GitHub Issue RCA Sample"
description: "Automated GitHub issue analysis using Cline CLI to identify root causes."
---

Automated GitHub issue analysis using Cline CLI. This script uses Cline's autonomous AI capabilities to fetch, analyze, and identify root causes of GitHub issues, outputting clean, parseable results that can be easily integrated into your development workflows.

<Note>
**New to Cline CLI?** This sample assumes you have already completed the [Installation Guide](https://docs.cline.bot/getting-started/installing-cline) and authenticated with `cline auth`. If you haven't set up Cline CLI yet, please start there first.
</Note>

<Frame>
  <img src="https://storage.googleapis.com/cline_public_images/cli-rca.gif" alt="CLI Root Cause Analysis Demo" width="600" />
</Frame>

## Prerequisites

This sample assumes you have already:

- **Cline CLI** installed and authenticated ([Installation Guide](https://docs.cline.bot/getting-started/installing-cline))
- **At least one AI model provider** configured (e.g., OpenRouter, Anthropic, OpenAI)
- **Basic familiarity** with Cline CLI commands

Additionally, you'll need:

- **GitHub CLI** (`gh`) installed and authenticated
- **jq** installed for JSON parsing
- **bash** shell (or compatible shell)

### Installation Instructions

#### macOS

<Note>
These instructions require [Homebrew](https://brew.sh/) to be installed. If you don't have Homebrew, install it first by running:
```bash
/bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/HEAD/install.sh)"
```
</Note>

```bash
# Install GitHub CLI
brew install gh

# Install jq
brew install jq

# Authenticate with GitHub
gh auth login
```

#### Linux

```bash
# Install GitHub CLI (Debian/Ubuntu)
sudo apt install gh

# Or for other Linux distributions, see: https://cli.github.com/manual/installation

# Install jq (Debian/Ubuntu)
sudo apt install jq

# Authenticate with GitHub
gh auth login
```

## Getting the Script

Save this script as `analyze-issue.sh`:

<Accordion title="Click to view the complete analyze-issue.sh script">

```bash
#!/bin/bash
# Analyze a GitHub issue using Cline CLI

if [ -z "$1" ]; then
    echo "Usage: $0 <github-issue-url> [prompt]"
    echo "Example: $0 https://github.com/owner/repo/issues/123"
    echo "Example: $0 https://github.com/owner/repo/issues/123 'What is the root cause of this issue?'"
    exit 1
fi

# Gather the args
ISSUE_URL="$1"
PROMPT="${2:-What is the root cause of this issue?}"

# Fail if Cline fails, not only if jq does
set -o pipefail

# Ask Cline for its analysis, showing only the summary
cline --auto-approve true --json "$PROMPT: $ISSUE_URL" | \
    jq -r 'select(.type == "run_result") | .text'
```

</Accordion>

<Note>
**After creating the script**, make it executable by running:
```bash
chmod +x analyze-issue.sh
```
</Note>

## Quick Usage Examples

### Basic Usage

Run this command in your terminal from the directory where you saved the script to analyze an issue with the default root cause prompt:

```bash
./analyze-issue.sh https://github.com/owner/repo/issues/123
```

This will:
- Fetch issue #123 from the repository
- Analyze the issue to identify root causes
- Provide detailed analysis with recommendations

### Custom Analysis Prompt

Ask specific questions about the issue:

```bash
./analyze-issue.sh https://github.com/owner/repo/issues/456 "What is the security impact?"
```

<Note>
The script will automatically handle everything: fetching the issue, analyzing it with Cline, and displaying the results. The analysis typically takes 30-60 seconds depending on the issue complexity.
</Note>

## How It Works

Let's analyze each component of the script to understand how it works.

### Argument Validation

The script validates input and provides usage instructions:

```bash
if [ -z "$1" ]; then
    echo "Usage: $0 <github-issue-url> [prompt]"
    echo "Example: $0 https://github.com/owner/repo/issues/123"
    echo "Example: $0 https://github.com/owner/repo/issues/123 'What is the root cause?'"
    exit 1
fi
```

**Key Points:**
- Validates required GitHub issue URL
- Shows clear usage examples
- Supports optional custom prompt

### Argument Parsing

The script extracts and sets up the arguments:

```bash
# Gather the args
ISSUE_URL="$1"
PROMPT="${2:-What is the root cause of this issue?}"
```

**Explanation:**
- `ISSUE_URL="$1"` - First argument is always the issue URL
- `PROMPT="${2:-...}"` - Second argument is optional, defaults to root cause analysis

### The Core Analysis Pipeline

This is where the magic happens:

```bash
# Fail if Cline fails, not only if jq does
set -o pipefail

# Ask Cline for its analysis, showing only the summary
cline --auto-approve true --json "$PROMPT: $ISSUE_URL" | \
    jq -r 'select(.type == "run_result") | .text'
```

When a run fails, the `run_result` line holds the error message, so the script prints it. `set -o pipefail` makes the script exit with an error too, so that a calling script or workflow knows the analysis failed.

<Accordion title="Pipeline Breakdown: Understanding Each Component">

**1. `cline --auto-approve true --json "$PROMPT: $ISSUE_URL"`**
   - `cline` is the Cline CLI binary
   - Act mode is the default for prompt runs
   - `--auto-approve true` allows tool use without interactive prompts
   - `--json` emits newline-delimited JSON for parsing
   - Constructs prompt with issue URL

**2. `jq -r 'select(.type == "run_result") | .text'`**
   - Keeps the `run_result` line, which the CLI prints when the run finishes
   - Prints its `text` field, Cline's final answer
   - `-r` prints the text itself, with real line breaks and no JSON quotes

</Accordion>

## Sample Output

Here's an example analyzing a real Flutter issue:

```bash
$ ./analyze-issue.sh https://github.com/csells/flutter_counter/issues/2
```

**Output:**

```markdown
**Root Cause Analysis of Issue #2: "setState isn't cutting it"**

After examining the GitHub issue and analyzing the Flutter counter codebase, 
I've identified the root cause of why setState() is insufficient for this 
project's needs:

## Current Implementation Problems

The current Flutter counter app uses setState() for state management, which 
has several limitations:

1. **Local State Only**: setState() only works within a single widget, making 
   it difficult to share state across the app
2. **Rebuild Overhead**: Every setState() call rebuilds the entire widget tree, 
   causing performance issues with complex UIs
3. **No State Persistence**: State is lost when the widget is disposed
4. **Testing Challenges**: setState-based logic is tightly coupled to the UI, 
   making unit testing difficult

## Why This Matters

As the app grows beyond a simple counter, these limitations become critical:
- Multiple screens need to access the count
- State needs to persist across navigation
- Business logic should be testable independently
- UI should only rebuild when necessary

## Recommended Solutions

The issue mentions "Provider or Bloc" - both are excellent alternatives:

1. **Provider**: Simple, lightweight state management using InheritedWidget
   - Easy migration path from setState
   - Good for small to medium apps
   - Official Flutter recommendation

2. **Bloc**: More structured approach with clear separation between events, 
   states, and business logic
   - Better for complex apps
   - Excellent testability
   - Clear architectural patterns

3. **Riverpod**: Modern alternative to Provider with better performance and 
   developer experience
   - Compile-time safety
   - Better testing support
   - More flexible than Provider

4. **GetX**: Full-featured solution with state management, routing, and 
   dependency injection
   - Minimal boilerplate
   - Fast and lightweight
   - All-in-one solution

## Next Steps

The current codebase needs refactoring to implement proper state management 
architecture to handle more complex state scenarios effectively. Provider 
would be the easiest migration path while Bloc provides better long-term 
scalability.
```

## When to Use This Pattern

This script pattern is ideal for various development scenarios where automated GitHub issue analysis can accelerate your workflow.

### Bug Investigation

Quickly analyze bug reports and identify root causes without manual code exploration:

```bash
./analyze-issue.sh https://github.com/project/repo/issues/123 \
    "What is the root cause of this bug?"
```

### Feature Request Analysis

Understand context and implications of feature requests:

```bash
./analyze-issue.sh https://github.com/project/repo/issues/456 \
    "What are the implementation challenges?"
```

### Security Audits

Assess security implications of reported issues:

```bash
./analyze-issue.sh https://github.com/project/repo/issues/789 \
    "What are the security implications?"
```

### Documentation Generation

Generate detailed technical documentation from issues:

```bash
./analyze-issue.sh https://github.com/project/repo/issues/654 \
    "Provide detailed technical documentation for this issue"
```

### Code Review Assistance

Get second opinions on proposed changes:

```bash
./analyze-issue.sh https://github.com/project/repo/issues/987 \
    "Review the proposed solution approach"
```

## Conclusion

This sample demonstrates how to build an autonomous GitHub issue analysis tool using Cline CLI:

1. **Building autonomous CLI tools** using Cline's capabilities
2. **Parsing structured JSON output** from Cline CLI
3. **Creating flexible automation scripts** with custom prompting
4. **Integrating with GitHub** for issue analysis
5. **Handling command-line arguments** effectively

This pattern can be adapted for many other automation scenarios, from pull request reviews to documentation generation to code quality analysis.

## Related Resources

- [CLI Installation Guide](https://docs.cline.bot/getting-started/installing-cline)
- [CLI Reference Documentation](https://docs.cline.bot/cli/cli-reference)
- [Headless Mode](https://docs.cline.bot/usage/cli-overview#headless-mode)