atxtechbro / atxtechbro/dotfiles

feat(github-mcp): add optional comment parameter to update_issue for atomic close-with-comment

Open
#777 1 comment 0 reactions 0 assignees View on GitHub
enhancement github-mcp optimization
Dominant language
Shell
Stars
27
Forks
2
PR merge metrics
No merged PRs in 30d

Description

## Problem
Currently closing an issue with a comment requires two separate API calls:
1. `mcp__github-write__add_issue_comment`
2. `mcp__github-write__update_issue` (state: "closed")

This creates unnecessary token usage and potential race conditions. Common pattern seen in `/close-issue` workflows.

## Proposed Solution
Add optional `comment` parameter to `mcp__github-write__update_issue` tool that automatically chains:
1. Add comment (if provided)
2. Update issue state

## Implementation Options

### Option 1: Extend update_issue tool
```typescript
// Add optional comment parameter
{
owner: string,
repo: string,
issue_number: number,
state?: "open" | "closed",
title?: string,
body?: string,
comment?: string, // NEW: optional closing comment
// ... other existing params
}
```

### Option 2: New dedicated tool
```typescript
// New tool: close_issue_with_comment
{
owner: string,
repo: string,
issue_number: number,
comment: string,
// Automatically sets state to "closed"
}
```

## Benefits
- **Token efficiency**: One tool call instead of two
- **Atomic operation**: Comment and close happen together
- **Common pattern**: Matches frequent workflow in issue management
- **Backward compatible**: Existing update_issue calls unaffected

## Usage Example
```typescript
// Current (2 calls) - from issue #769 closure
mcp__github-write__add_issue_comment(owner, repo, 769, "✅ Resolved in PR #773")
mcp__github-write__update_issue(owner, repo, 769, {state: "closed"})

// Proposed (1 call)
mcp__github-write__update_issue(owner, repo, 769, {
state: "closed",
comment: "✅ Resolved in PR #773"
})
```

## Implementation Notes
- GitHub API supports this pattern natively
- Should maintain existing parameter structure for backward compatibility
- Error handling: if comment fails, should issue still be closed?

**Principle**: Selective optimization - optimizing a high-frequency pattern that creates compounding token savings.

Contributor guide

No contributing guide indexed for this repository

Research direction

Start by locating the implementations and schemas for mcp__github-write__update_issue and mcp__github-write__add_issue_comment, then trace the /close-issue workflow and the usage described for issue #769 and PR #773. Define and verify the behavior for an optional comment, including what happens when adding the comment fails, while preserving existing update_issue calls.

Written by the indexing model from the issue text.

Assessment

Tech stack
github, typescript
Domain
api, tooling
Issue type
Feature
Difficulty
4/5
Estimated time
3-5 days
Activity status
Quiet
Clarity
Mostly clear
Newbie friendliness
45/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.