fix: support custom Git hosts in getOwnerRepo for lockfile tracking

[renehernandez]

Summary

• Updated getOwnerRepo() to support any HTTPS Git host with an owner/repo URL structure
• Skills installed from self-hosted Git servers (e.g., GitLab CE, Gitea, Forgejo) are now tracked in the lockfile
• Handle query strings, URL fragments, and GitLab subgroups

Problem

The getOwnerRepo() function only recognized github.com and gitlab.com URLs:

const match = parsed.url.match(/(?:github|gitlab)\.com\/([^/]+)\/([^/]+?)(?:\.git)?$/);

This caused skills installed from self-hosted Git servers to return null, which skipped the lockfile update in add.ts:1827:

if (successful.length > 0 && installGlobally && normalizedSource) {

Solution

Replaced the regex with URL parsing for cleaner handling:

const url = new URL(parsed.url);
let path = url.pathname.slice(1);
path = path.replace(/\.git$/, '');
if (path.includes('/')) {
  return path;
}

This approach:

• Uses native URL parsing to automatically handle query strings and fragments
• Supports GitLab nested paths (e.g., group/subgroup/repo)
• Validates that path has at least owner/repo structure

Test plan

• Updated existing tests for custom Git hosts to expect owner/repo instead of null
• Added test cases for URLs with query strings (?ref=main)
• Added test cases for URLs with fragments (#readme)
• Added test cases for GitLab subgroups (2-3 levels deep)
• All 261 tests pass

🤖 Generated with Claude Code

[renehernandez]

@quuu Ran into this issue when using npx skills update against an our own internal skills repo in our self-hosted GitLab instance

[renehernandez]

Local Testing

Tested the fix locally against a self-hosted GitLab instance:

# Build from source
pnpm build

# Install skills from self-hosted GitLab
node dist/cli.mjs add https://git.example.io/team/skills.git --agent claude-code -y -g

Before fix: Lockfile remained empty ("skills": {})

After fix: Lockfile correctly tracks all installed skills:

{
  "version": 3,
  "skills": {
    "skill-1": {
      "source": "team/skills",
      "sourceType": "git",
      "sourceUrl": "https://git.example.io/team/skills.git",
      "skillPath": "skill-1/SKILL.md",
      "skillFolderHash": "",
      "installedAt": "2026-01-30T17:29:08.822Z",
      "updatedAt": "2026-01-30T17:29:08.822Z"
    },
    ...
  }
}

The source field now correctly extracts team/skills from the custom Git host URL, enabling lockfile tracking.

Note: skillFolderHash remains empty for non-GitHub hosts since fetchSkillFolderHash() uses GitHub's Trees API. This is expected behavior and a separate limitation.

[renehernandez]

Addressed Review Feedback

Thanks for the review! I've pushed changes to address the feedback:

Fixed: Query strings and URL fragments (Issue #1)

URLs like https://git.example.com/owner/repo?ref=main or https://git.example.com/owner/repo#readme are now handled correctly by using native URL parsing instead of regex.

Added: GitLab subgroups support (Issue #2)

The function now supports nested GitLab paths:

• https://gitlab.com/group/subgroup/repo → group/subgroup/repo
• https://gitlab.com/org/team/project/repo.git → org/team/project/repo

Implementation

Replaced the regex approach with URL parsing which cleanly handles all edge cases:

• Query strings are automatically stripped by URL.pathname
• Fragments are automatically stripped
• Arbitrary path depth is supported
• .git suffix is stripped with a simple replace

Added 7 new test cases covering these scenarios.

[quuu]

thanks! works well