DOCS/examples/multi-repo/caller-workflow.yml (1)

6-7: Consider removing synchronize from PR triggers.

The synchronize event fires every time commits are pushed to the PR branch. This could cause excessive workflow runs and redundant triage comments, since the PR's title/body typically don't change on push. Unless the intent is to re-analyze based on code changes, consider removing it to avoid noise.

Suggested change

  pull_request:
-    types: [opened, edited, reopened, synchronize]
+    types: [opened, edited, reopened]

internal/steps/action_executor.go (1)

44-46: Optional: Consider PR-aware dry-run logging.

The dry-run block logs "Would transfer to..." even for pull requests, which could be misleading since PRs won't actually be transferred. For consistency, consider adding the same EventType check here.

Suggested change

-		if ctx.TransferTarget != "" {
+		if ctx.TransferTarget != "" && ctx.Issue.EventType != "pull_request" {
 			log.Printf("[action_executor] DRY RUN: Would transfer to %s", ctx.TransferTarget)
 		}

internal/steps/response_builder_test.go (1)

13-85: Consider adding test coverage for PR-specific duplicate messaging.

The new logic in response_builder.go (Lines 270-274) dynamically uses "pull request" vs "issue" in duplicate warnings based on EventType, but this test doesn't cover that path. Consider adding a test case with EventType: "pull_request" and a mock duplicate result to verify the message says "This pull request might be a duplicate...".

Example test case to add

func TestResponseBuilder_buildDuplicateSection_PullRequest(t *testing.T) {
	deps := &pipeline.Dependencies{}
	builder := NewResponseBuilder(deps)

	ctx := &pipeline.Context{
		Issue: &pipeline.Issue{
			Org:       "similigh",
			Repo:      "simili-bot",
			Number:    456,
			EventType: "pull_request",
		},
		Config:   &config.Config{},
		Metadata: make(map[string]interface{}),
	}

	ctx.Metadata["duplicate_result"] = &gemini.DuplicateResult{
		IsDuplicate: true,
		DuplicateOf: 123,
		Confidence:  0.90,
		Reasoning:   "Same feature implementation",
	}

	section := builder.buildDuplicateSection(ctx)

	if !strings.Contains(section, "This pull request might be a duplicate") {
		t.Errorf("Expected 'pull request' in duplicate message, got: %s", section)
	}
}

action.yml (1)

34-35: Consider: --issue flag naming is now semantically misleading for PR events.

The --issue flag is used for both issues and PRs, which works functionally but may cause confusion. A future refactor could rename this to --event or --payload for clarity.

cmd/simili/commands/process_test.go (1)

1-84: Consider adding a test for plain issues events.

The current tests cover pull_request and issue_comment events. Adding a test for a standard issues event (without a comment) would complete coverage of the three main event paths in enrichIssueFromGitHubEvent.

📝 Example test case

func TestEnrichIssueFromGitHubEvent_Issues(t *testing.T) {
	issue := &pipeline.Issue{}
	raw := map[string]interface{}{
		"action": "opened",
		"issue": map[string]interface{}{
			"number":   float64(10),
			"title":    "Bug: something broken",
			"body":     "Details here",
			"state":    "open",
			"html_url": "https://github.com/similigh/simili-bot/issues/10",
			"user":     map[string]interface{}{"login": "reporter"},
		},
		"repository": map[string]interface{}{
			"name":  "simili-bot",
			"owner": map[string]interface{}{"login": "similigh"},
		},
	}

	enrichIssueFromGitHubEvent(issue, raw)

	if issue.EventType != "issues" {
		t.Fatalf("expected issues event type, got %q", issue.EventType)
	}
	if issue.Number != 10 {
		t.Fatalf("expected issue number 10, got %d", issue.Number)
	}
}