atxtechbro / atxtechbro/dotfiles
spike: evaluate GitLab support for /close-issue slash command
- Dominant language
- Shell
- Stars
- 27
- Forks
- 2
- PR merge metrics
- No merged PRs in 30d
Description
## Summary
Investigate the feasibility and implementation approach for adding GitLab issue support to the `/close-issue` slash command, enabling the same workflow for GitLab-hosted repositories.
## Key Insight: Git Remote Detection
Instead of requiring users to specify the platform, we can detect it from the current repository's git remote configuration:
```bash
# In a GitHub repo:
$ git remote get-url origin
git@github.com:owner/repo.git
# In a GitLab repo:
$ git remote get-url origin
git@gitlab.com:owner/project.git
```
## Proposed Approach: Context-Aware Detection
### Primary Implementation Path
```bash
/close-issue 123 # Detects platform from git remote in current directory
```
**Logic flow:**
1. Check `git remote get-url origin` in current working directory
2. Parse the URL to detect GitHub vs GitLab (vs Bitbucket, etc.)
3. Route to appropriate MCP tools based on detected platform
4. Fall back to GitHub if no git repo or unclear remote
### Benefits
- **Zero configuration**: Works immediately when you `cd` into any repo
- **Natural workflow**: Aligns with how developers already work
- **Platform agnostic**: Same command works everywhere
- **OSE principle**: System adapts to context, not user adapting to system
## Research Questions
1. **MCP Tool Availability**: Are there existing MCP tools for GitLab, or would we need to create them?
2. **Edge cases**: What about repos with multiple remotes? Non-origin remotes?
3. **Authentication**: How to handle different auth mechanisms between platforms?
4. **URL patterns**: Comprehensive regex for detecting various Git hosting platforms
## Implementation Notes
- Parse remote URL formats: SSH (`git@`), HTTPS (`https://`), custom domains
- Handle edge cases: multiple remotes, no remotes, non-standard remote names
- Consider: Should we support a platform override for edge cases?
## Success Criteria
- Command "just works" when in a GitLab repo directory
- Clear error messages when platform can't be detected
- Maintains backward compatibility with existing GitHub-focused usage
- Implementation effort <8 hours
## Principle Alignment
- **OSE**: Leverage existing system state (git config) instead of requiring manual input
- **Developer Experience**: Natural, context-aware behavior
- **Subtraction Creates Value**: Remove the need to specify platform explicitly
Contributor guide
No contributing guide indexed for this repository
Research direction
Start by locating the existing /close-issue command and its GitHub/MCP integration. Investigate git remote get-url origin, platform URL patterns, available GitLab tools, authentication, and multiple-remote behavior. Done means a documented implementation approach covering GitLab support, fallback behavior, clear errors, backward compatibility, and the stated effort constraint.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- bash, git, shell
- Domain
- cli, developer-experience, tooling
- Issue type
- Feature
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 30/100