> ## Documentation Index
> Fetch the complete documentation index at: https://docs.overcut.ai/llms.txt
> Use this file to discover all available pages before exploring further.

# Repository Identify Action

> Learn how to use the repo.identify action to automatically determine the most relevant code repositories for your workflow context using AI-powered analysis and repository correlations.

The `repo.identify` action is a **critical automation tool** that intelligently determines which code repositories are most relevant to your workflow context. In multi-repository workspaces where tickets (Jira, GitHub Issues) are managed separately from code repositories, this action is essential for bridging the gap and ensuring your automation workflows target the correct codebases.

***

## Why This Action is Critical

### **The Multi-Repository Challenge**

In modern development environments, you often have:

* **Ticket Systems**: Jira projects, GitHub Issues, Linear tickets
* **Code Repositories**: Multiple Git repositories across different providers (GitHub, GitLab, Azure DevOps)
* **Complex Relationships**: One ticket might affect code in 3-5 different repositories

Without `repo.identify`, you'd need to:

* Manually specify repository names in every workflow
* Update workflows when repository structures change
* Risk targeting the wrong repositories for critical operations
* Maintain complex mapping logic across multiple systems

### **The Solution**

The `repo.identify` action automatically bridges this gap by:

* **Analyzing ticket context** to understand what needs to be done
* **Mapping to code repositories** using AI and explicit correlations
* **Providing confidence scores** to ensure accuracy
* **Enabling dynamic workflows** that adapt to your repository structure

***

## Overview

The `repo.identify` action analyzes your workflow context and automatically determines which code repositories are most relevant to the current task. It's particularly useful in multi-repository workspaces where you need to dynamically select the appropriate repositories based on ticket content, labels, and explicit correlations.

<CardGroup cols={2}>
  <Card title="AI-Powered Analysis" icon="brain-circuit">
    Uses intelligent analysis of ticket content, labels, and context to identify relevant repositories.
  </Card>

  <Card title="Repository Correlations" icon="link">
    Leverages explicit correlations between ticket repositories and code repositories for reliable identification.
  </Card>

  <Card title="Dynamic Selection" icon="arrows-rotate">
    Automatically selects the most appropriate repositories without manual configuration.
  </Card>

  <Card title="Multi-Repository Support" icon="list-check">
    Can identify multiple repositories for complex workflows that span multiple codebases.
  </Card>
</CardGroup>

***

## Chaining with Git Clone

The `repo.identify` action output is designed to work seamlessly with `git.clone` for dynamic multi-repository workflows:

### **Basic Chaining Pattern**

```yaml theme={null}
steps:
  - id: "identify-repos"
    name: "Identify Relevant Repositories"
    action: "repo.identify"
    params:
      maxResults: 3
      minConfidence: 0.7
  
  - id: "clone-repos"
    name: "Clone Identified Repositories"
    action: "git.clone"
    params:
      repoFullName: "{{outputs.identify-repos}}"
      branch: "main"
```

### **Single Repository Selection**

```yaml theme={null}
steps:
  - id: "identify-repos"
    action: "repo.identify"
    params:
      maxResults: 1
      minConfidence: 0.8
  
  - id: "clone-primary"
    action: "git.clone"
    params:
      repoFullName: "{{outputs.identify-repos.[0].repoFullName}}"
      branch: "{{trigger.pullRequest.headBranch}}"
```

***

## Critical Use Cases

### **Jira Workflow Automation**

When a Jira issue is created or updated, you need to know which code repositories contain the affected code:

```yaml theme={null}
steps:
  - id: "identify-repos"
    name: "Identify Affected Repositories"
    action: "repo.identify"
    params:
      maxResults: 3
      minConfidence: 0.7
      identificationHints: "Focus on repositories containing the components mentioned in the issue"
  
  - id: "clone-repos"
    name: "Clone Identified Repositories"
    action: "git.clone"
    params:
      repoFullName: "{{outputs.identify-repos}}"
      branch: "main"
  
  - id: "analyze-issue"
    name: "Analyze Issue in Code Context"
    action: "agent.session"
    params:
      goal: "Analyze the Jira issue and provide technical recommendations"
      agentIds: ["senior-developer"]
      instruction: "Review the issue in context of the cloned repositories"
```

### **Cross-Repository Bug Investigation**

For bugs that might span multiple repositories:

```yaml theme={null}
steps:
  - id: "identify-repos"
    name: "Identify Related Repositories"
    action: "repo.identify"
    params:
      maxResults: 5
      minConfidence: 0.5
      identificationHints: "Include frontend, backend, shared libraries, and database schemas"
  
  - id: "clone-repos"
    name: "Clone Investigation Repositories"
    action: "git.clone"
    params:
      repoFullName: "{{outputs.identify-repos}}"
  
  - id: "investigate-bug"
    name: "Cross-Repository Bug Investigation"
    action: "agent.session"
    params:
      goal: "Investigate the bug across all affected repositories"
      agentIds: ["debugging-agent", "architect-agent"]
      instruction: "Analyze the bug in these repositories: {{#each outputs.identify-repos}}{{.repoFullName}} {{/each}}"
```

### **Feature Development Planning**

When planning new features that touch multiple systems:

```yaml theme={null}
steps:
  - id: "identify-repos"
    name: "Identify Feature Repositories"
    action: "repo.identify"
    params:
      maxResults: 4
      minConfidence: 0.6
      identificationHints: "Include user interface, business logic, API endpoints, and data models"
  
  - id: "clone-repos"
    name: "Clone Feature Repositories"
    action: "git.clone"
    params:
      repoFullName: "{{outputs.identify-repos}}"
      branch: "main"
  
  - id: "plan-feature"
    name: "Multi-Repository Feature Planning"
    action: "agent.session"
    params:
      goal: "Create implementation plan across all affected repositories"
      agentIds: ["product-manager", "senior-developer", "architect-agent"]
      instruction: "Plan the feature implementation across: {{#each outputs.identify-repos}}{{.repoFullName}} {{/each}}"
```

***

## Basic Usage

### Simple Repository Identification

The most basic usage identifies a single repository:

```yaml theme={null}
steps:
  - id: "identify-repos"
    name: "Identify Repositories"
    action: "repo.identify"
    params:
      maxResults: 1
```

### Multi-Repository Identification

Identify multiple repositories for complex workflows:

```yaml theme={null}
steps:
  - id: "identify-repos"
    name: "Identify Repositories"
    action: "repo.identify"
    params:
      maxResults: 3
      minConfidence: 0.7
```

### With Identification Hints

Provide additional context to guide the identification process:

```yaml theme={null}
steps:
  - id: "identify-repos"
    name: "Identify Repositories"
    action: "repo.identify"
    params:
      maxResults: 2
      minConfidence: 0.6
      identificationHints: "Focus on frontend components and user interface code"
```

***

## Parameters

### Required Parameters

None - all parameters have sensible defaults.

### Optional Parameters

<ParamField path="maxResults" type="number" required={false}>
  Maximum number of repositories to return (top-K). Controls how many candidate repositories are returned. Use 1 for single-repo workflows, higher values for multi-repo scenarios.
</ParamField>

<ParamField path="minConfidence" type="number" required={false}>
  Minimum confidence threshold (0..1). Filters out low-confidence matches. Higher values (0.7+) ensure only strong matches are returned.
</ParamField>

<ParamField path="identificationHints" type="string" required={false}>
  Optional hints to bias identification. Additional context that can help the AI make better decisions, especially when correlations are unclear.
</ParamField>

***

## How Identification Works

The identification process follows a sophisticated multi-step logic:

### 1. Correlation Check

First, the system looks for explicitly correlated repositories between your ticket repository and code repositories. These explicit correlations take precedence over all other identification methods.

### 2. Context Analysis

The AI analyzes the ticket content including:

* **Title and description**: Keywords, technologies, and domain-specific terms
* **Labels and components**: Project-specific categorization
* **Assignee and reporter**: Team and ownership context
* **Project structure**: Related tickets and dependencies

### 3. Repository Hints

Considers repository-level identification hints configured in your repository settings, such as:

* Key technologies and frameworks
* Domain-specific components
* Team ownership and responsibilities
* Project scope and boundaries

### 4. Scoring and Ranking

Combines all signals to produce confidence scores:

* **Correlation strength**: Explicit correlations get highest scores
* **Content relevance**: AI analysis of ticket-repository alignment
* **Repository activity**: Recent commits and development activity
* **Team alignment**: Developer and team associations

### 5. Filtering and Selection

Applies the minimum confidence threshold and returns the top-ranked repositories up to the specified `maxResults`.

***

## Output and Context

### Step Output

The `repo.identify` action provides output that can be used by subsequent steps:

<ResponseField name="repositories" type="array" required>
  Array of identified repositories with confidence scores and reasoning.
</ResponseField>

<ResponseField name="repositories.[].repoFullName" type="string" required>
  Full repository name in "owner/repo" format.
</ResponseField>

<ResponseField name="repositories.[].confidence" type="number" required>
  Confidence score (0-1) indicating how well the repository matches the context.
</ResponseField>

<ResponseField name="repositories.[].reasoning" type="string" required>
  Explanation of why this repository was selected, including correlation details and AI analysis.
</ResponseField>

### Available Variables

Use these variables in subsequent steps:

* **`{{outputs.identify-repos}}`**: Complete array for multi-repository operations (use with git.clone)
* **`{{outputs.identify-repos.[0].repoFullName}}`**: First identified repository
* **`{{outputs.identify-repos.[0].confidence}}`**: Confidence score for first repository
* **`{{outputs.identify-repos.[0].reasoning}}`**: Reasoning for first repository selection

### Template Examples

**Multi-Repository Clone:**

```yaml theme={null}
repoFullName: "{{outputs.identify-repos}}"
```

**Single Repository Clone:**

```yaml theme={null}
repoFullName: "{{outputs.identify-repos.[0].repoFullName}}"
```

**Conditional Fallback:**

```yaml theme={null}
repoFullName: "{{#if outputs.identify-repos.[0]}}{{outputs.identify-repos.[0].repoFullName}}{{else}}{{trigger.repository.fullName}}{{/if}}"
```

<Warning>
  **Important**: If your step ID contains hyphens (e.g., `identify-repos`), use bracket notation: `{{outputs.[identify-repos].[0].repoFullName}}`
</Warning>

***

## Integration with Other Actions

### Following with Git Clone

After identifying repositories, you can clone them using the `git.clone` action:

```yaml theme={null}
steps:
  - id: "identify-repos"
    name: "Identify Repositories"
    action: "repo.identify"
    params:
      maxResults: 1
      minConfidence: 0.7
  
  - id: "clone-repo"
    name: "Clone Repository"
    action: "git.clone"
    params:
      repoFullName: "{{outputs.identify-repos.[0].repoFullName}}"
      branch: "{{trigger.pullRequest.headBranch}}"
```

### Multi-Repository Workflows

For workflows that need to work with multiple repositories:

```yaml theme={null}
steps:
  - id: "identify-repos"
    name: "Identify Repositories"
    action: "repo.identify"
    params:
      maxResults: 3
      minConfidence: 0.6
  
  - id: "clone-repos"
    name: "Clone All Repositories"
    action: "git.clone"
    params:
      repoFullName: "{{outputs.identify-repos}}"
  
  - id: "analyze-repos"
    name: "Analyze Repositories"
    action: "agent.session"
    params:
      goal: "Analyze the identified repositories for cross-dependencies and integration points"
      agentIds: ["architect-agent", "senior-developer"]
```

***

## Best Practices

### 1. Set Up Explicit Correlations

* **Always create explicit correlations** between ticket repositories and code repositories
* This provides the most reliable identification results
* Correlations take precedence over AI-based heuristics
* Use the repository mapping interface to establish these relationships

### 2. Use Descriptive Repository Hints

* Include key technologies, domains, and components in repository configuration
* Use consistent terminology across related repositories
* Update hints when repository scope changes
* Consider team ownership and project boundaries

### 3. Configure Appropriate Confidence Thresholds

* **0.2-0.4**: Low threshold, includes more candidates (default)
* **0.5-0.7**: Medium threshold, balanced selection
* **0.8-1.0**: High threshold, only strong matches
* Start with default (0.2) and adjust based on results

### 4. Position in Workflow

* Place `repo.identify` early in your workflow, right after the trigger
* Use identified repositories in subsequent `git.clone` or agent steps
* Consider fallback logic for cases where no repositories are identified

### 5. Monitor and Refine

* Review identification results regularly
* Adjust correlation settings based on accuracy
* Update repository hints as projects evolve
* Use workflow logs to understand identification reasoning

***

## Common Use Cases

### Issue Triage Workflows

Automatically identify relevant repositories for issue analysis:

```yaml theme={null}
steps:
  - id: "identify-repos"
    name: "Identify Repositories"
    action: "repo.identify"
    params:
      maxResults: 1
      minConfidence: 0.6
  
  - id: "analyze-issue"
    name: "Analyze Issue"
    action: "agent.session"
    params:
      goal: "Analyze the issue and provide technical recommendations"
      agentIds: ["senior-developer"]
      instruction: "Review the issue in context of repository: {{outputs.identify-repos.[0].repoFullName}}"
```

### Cross-Repository Analysis

Identify multiple repositories for comprehensive analysis:

```yaml theme={null}
steps:
  - id: "identify-repos"
    name: "Identify Repositories"
    action: "repo.identify"
    params:
      maxResults: 3
      minConfidence: 0.5
      identificationHints: "Include frontend, backend, and shared libraries"
  
  - id: "cross-repo-analysis"
    name: "Cross-Repository Analysis"
    action: "agent.session"
    params:
      goal: "Analyze dependencies and integration points between repositories"
      agentIds: ["architect-agent"]
```

### Feature Development

Identify repositories for new feature implementation:

```yaml theme={null}
steps:
  - id: "identify-repos"
    name: "Identify Repositories"
    action: "repo.identify"
    params:
      maxResults: 2
      minConfidence: 0.7
      identificationHints: "Focus on user interface and business logic components"
  
  - id: "plan-feature"
    name: "Plan Feature Implementation"
    action: "agent.session"
    params:
      goal: "Create implementation plan for the new feature"
      agentIds: ["product-manager", "senior-developer"]
```

***

## Advanced Configuration

### Repository-Level Hints

Configure identification hints in your repository settings:

1. **Access Repository Settings**: Go to repository configuration
2. **Set Identification Hints**: Add descriptive text about the repository's purpose
3. **Use Consistent Terminology**: Align with ticket labels and project terminology
4. **Update Regularly**: Keep hints current with repository evolution

### Correlation Management

Manage explicit correlations between repositories:

1. **Map Ticket Repositories**: Connect Jira projects to code repositories
2. **Establish Relationships**: Define which code repositories relate to which ticket systems
3. **Review Accuracy**: Regularly validate correlation effectiveness
4. **Adjust as Needed**: Update correlations when project structure changes

***

## Next Steps

Now that you understand the `repo.identify` action, explore these related topics:

* **[Repository Mapping](/docs/repositories/repository-mapping)**: Learn how to set up explicit correlations
* **[Git Clone Action](/docs/workflows/git-clone)**: Use identified repositories in clone operations
* **[Building Blocks](/docs/building-blocks)**: Explore other workflow actions and components
* **[Quick Starts](/docs/quick-starts)**: See complete workflow examples

Ready to automate repository selection? Start by setting up explicit correlations and then add the `repo.identify` action to your workflows for intelligent, context-aware repository identification.