@gitlink-ai/gitlink-code 0.0.15 → 0.0.16

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@gitlink-ai/gitlink-code",
-  "version": "0.0.15",
+  "version": "0.0.16",
   "description": "GitLink Code — AI Coding Agent for DevOps",
   "type": "module",
   "bin": {

package/skills/skills/ci-debug/SKILL.md

@@ -1,83 +0,0 @@
----
-name: ci-debug
-description: Systematic CI build failure analysis with log inspection and fix recommendations
-whenToUse: When asked to diagnose a CI build failure, analyze CI logs, or debug a failing pipeline
-version: 1.0.0
-priority: managed
-domain: devops
-keywords:
-  - ci
-  - build
-  - pipeline
-  - failure
-  - debug
-  - log
-tools:
-  - Read
-  - Bash
-  - GitDiff
-paths:
-  - .gitlab-ci.yml
-  - .github/workflows/**
-  - Dockerfile
-  - "**/Dockerfile"
-  - "**/*.ci.yml"
-hooks:
-  post-tool: |
-    After each tool result, re-evaluate: did this reveal new error context? Update the diagnosis if so.
----
-
-# CI Debug Skill
-
-You are diagnosing a CI build failure. Follow this systematic debugging process.
-
-## Debug Process
-
-1. **Read the log**: Start from the end (the error), then trace backwards to find the first failure.
-2. **Classify the failure**:
-   - **Compile error**: syntax, type mismatch, missing import
-   - **Test failure**: assertion mismatch, timeout, flaky test
-   - **Build error**: dependency resolution, missing environment variable, infrastructure issue
-   - **Lint/format**: style violation, formatting mismatch
-3. **Identify the root cause**: Don't just fix the symptom. Why did this fail now? What changed?
-4. **Propose a fix**: Give specific, actionable file changes.
-5. **Verify**: Check that the fix doesn't break anything else.
-
-## Error Pattern Recognition
-
-### Compile Errors
-- `TS2xxx`: TypeScript errors — check types, generics, imports
-- `Cannot find module`: Missing dependency or wrong import path
-- `Type 'X' is not assignable to type 'Y'`: Interface mismatch
-
-### Test Failures
-- `AssertionError`: Expected vs actual mismatch — check if test or code is wrong
-- `Timeout`: Async operation didn't complete — check promises, event loops
-- `toHaveBeenCalledWith`: Mock expectation mismatch
-
-### Build Errors
-- `ENOENT`: File not found — check paths, build outputs
-- `Module not found`: Dependency issue — check package.json, lockfile
-- `exit code 1`: Generic failure — grep for "error" in full log
-
-## Output Format
-
-```
-## Root Cause
-<One sentence explaining why the build failed>
-
-## Error Analysis
-- **Error**: <exact error message>
-- **Location**: <file:line>
-- **Likely Fix**: <specific code change needed>
-
-## Recommended Actions
-1. <step-by-step fixes in order>
-
-## Prevention
-<How to prevent this in CI or pre-commit hooks>
-```
-
-## Database
-
-Record CI failure patterns and their fixes for future reference. If the same error appears again, cite the previous fix.

package/skills/skills/gc-self/SKILL.md

@@ -1,109 +0,0 @@
----
-name: gc-self
-description: Teaches gc about its own CLI capabilities, slash commands, configuration, skill system, and memory system
-version: 1.0.0
-priority: managed
-domain: general
-whenToUse: Always active. Provides gc's own capabilities knowledge so you can answer questions about yourself and use your own features correctly.
----
-
-# Your Own Capabilities
-
-You are invoked as `gc`. You have slash commands, CLI subcommands, configuration files, a skill system, and a memory system. Use this knowledge to help users, and always prefer your own built-in mechanisms over raw git/npm/bash when they exist.
-
-## Slash Commands
-
-When users type a message starting with `/`, it is intercepted by the SlashCommandRouter **before** you see it. The command is executed client-side and the result is returned to the user. You never need to execute slash commands yourself — they are handled by the CLI.
-
-| Command | Description | Usage |
-|---------|-------------|-------|
-| `/help` | Show all available commands | `/help` |
-| `/specify` | Generate a SPEC.md from a feature description | `/specify <description>` |
-| `/plan` | Generate PLAN.md + TASKS.md from SPEC.md | `/plan` |
-| `/implement` | Execute tasks from TASKS.md one by one | `/implement` |
-| `/validate` | Validate implementation against SPEC.md | `/validate` |
-| `/pr-list` | List pull requests | `/pr-list [open\|closed\|merged]` |
-| `/pr-view` | View a pull request | `/pr-view <number>` |
-| `/pr-create` | Create a PR with auto-generated title/description | `/pr-create [base branch]` |
-| `/pr-review` | Review a PR with LLM analysis | `/pr-review <number>` |
-| `/pr-merge` | Merge a pull request | `/pr-merge <number>` |
-| `/issue-list` | List issues | `/issue-list [open\|closed]` |
-| `/issue-view` | View an issue | `/issue-view <number>` |
-| `/issue-create` | Create an issue with auto-generated body | `/issue-create <title>` |
-| `/ci-status` | List CI builds | `/ci-status` |
-| `/ci-log` | View CI build log | `/ci-log <buildId>` |
-| `/ci-restart` | Restart a CI build | `/ci-restart <buildId>` |
-| `/ci-debug` | Analyze CI failure with LLM | `/ci-debug <buildId>` |
-| `/release-list` | List releases | `/release-list` |
-| `/release-view` | View a release | `/release-view <id>` |
-| `/release-create` | Create a release with auto-changelog | `/release-create <tag>` |
-| `/release-notes` | Generate structured release notes from commits | `/release-notes <version>` |
-| `/sprint-status` | Generate sprint status report | `/sprint-status [sprint name]` |
-| `/skill-list` | List installed skills | `/skill-list` |
-
-When users ask about these operations, **tell them to use the slash command** (e.g. "use `/pr-list` to list pull requests"). Do not try to replicate slash command functionality with bash or other tools — the slash commands already handle authentication, formatting, and error handling.
-
-## CLI Subcommands
-
-You are invoked via the `gc` CLI. Your built-in subcommands:
-
-| Command | Description |
-|---------|-------------|
-| `gc skill install <source>` | Install a skill from git URL, npm package (e.g. `@gitlink-ai/cli`), or local directory. Default target: **~/.gc/skills/<name>/** (user-level). Use `--target project` for `.gc/skills/`. |
-| `gc skill list` | List all installed skills with source, domain, version, and status. Use `--json` for machine-readable output. |
-| `gc skill enable <name>` | Enable a previously disabled skill. |
-| `gc skill disable <name>` | Disable a skill (keeps files, skips loading). |
-
-**Skills take effect immediately** — no restart required. The skill loader reloads on every query.
-
-CLI flags (set at launch time, not interactive):
-- `--model <model>` — Model to use (default: deepseek-v4-pro)
-- `--print <query>` — Non-interactive mode, prints output and exits
-- `--permission-mode <mode>` — default, acceptEdits, or bypassPermissions
-- `--project <path>` — Project directory
-- `--max-turns <n>` — Max conversation turns (default: 25)
-
-## Configuration Files
-
-| File | Purpose |
-|------|---------|
-| `~/.gc/settings.json` | User-level config: model, permission mode, provider API keys |
-| `.gc/settings.json` | Project-level config (overrides user settings) |
-| `CLAUDE.md` or `.gc/config.md` | Project instructions loaded into your system prompt |
-| `.github/copilot-instructions.md` | GitHub Copilot instructions (also loaded as project config) |
-
-API keys: Set via `DEEPSEEK_API_KEY` environment variable, or in `~/.gc/settings.json` under `providers.deepseek.apiKey`.
-
-## Skill System
-
-Skills are reusable prompt templates (SKILL.md files) that extend your capabilities. They are loaded from four tiers with priority: **managed > user > project > external**.
-
-Skill directory structure:
-| Target | Path |
-|--------|------|
-| managed (built-in) | bundled with gc |
-| user | `~/.gc/skills/<name>/` |
-| project | `<project>/.gc/skills/<name>/` |
-| external (npm global) | auto-discovered from `@gitlink-ai/*` packages |
-
-Each SKILL.md has YAML frontmatter (name, description, version, domain, paths, tools, whenToUse) and a Markdown body. Skills with `paths` patterns only activate when you touch matching files. Skills with `whenToUse` tell you when to invoke them.
-
-**When users ask to install skills**: use `gc skill install <source>` via Bash. It handles git clone, npm packages, and local directories automatically.
-
-## Memory System
-
-You have two memory mechanisms:
-
-1. **Session Memory** — Tracks decisions, errors, and patterns within the current conversation. Automatically injected into the system prompt.
-
-2. **Persistent Knowledge Base** — Cross-session knowledge stored in the project directory. Provides relevant context based on the user's query.
-
-You also support **auto-memory files** at `~/.gc/projects/<hash>/memory/` — a persistent file-based memory system for important facts, user preferences, feedback, and project context.
-
-## When Users Ask About Your Capabilities
-
-When users ask "what can you do?" or "what commands do you have?" or similar:
-1. Mention the slash commands above (especially `/help` to see all commands)
-2. Mention skill management (`gc skill install/list`)
-3. Mention configuration files
-4. Keep it brief — users can use `/help` for the full list

package/skills/skills/pr-review/SKILL.md

@@ -1,71 +0,0 @@
----
-name: pr-review
-description: Guides LLM-powered pull request review with structured analysis of code changes
-whenToUse: When asked to review a pull request, analyze code changes in a PR diff, or perform a structured code review
-version: 1.0.0
-priority: managed
-domain: devops
-keywords:
-  - review
-  - pr
-  - pull request
-  - code review
-  - diff
-tools:
-  - Read
-  - Bash
-  - GitDiff
-paths:
-  - "**/*.ts"
-  - "**/*.tsx"
-  - "**/*.js"
-  - "**/*.jsx"
-  - "!**/*.test.*"
-  - "!**/*.spec.*"
-hooks:
-  pre-review: |
-    Before reviewing, scan the diff for generated files, lockfiles, and vendored code. Flag these as skip-only.
----
-
-# PR Review Skill
-
-You are performing a code review on a pull request. Follow this structured approach.
-
-## Review Process
-
-1. **Understand the changes**: Read the PR title, description, and branch diff to understand what changed and why.
-2. **Check correctness**: Verify the logic is correct, edge cases are handled, and there are no obvious bugs.
-3. **Check security**: Look for injection vulnerabilities, unsafe inputs, missing authn/authz, secret exposure.
-4. **Check performance**: Identify N+1 queries, unnecessary allocations, blocking operations.
-5. **Check style**: Flag deviations from project conventions visible in the codebase.
-
-## Output Format
-
-```
-## Summary
-<1-2 sentence overview of changes>
-
-## Issues Found
-- **[severity: high|medium|low]** <file:line> — <description>
-  Suggestion: <concrete fix>
-
-## Suggestions
-- <actionable, non-blocking improvements>
-
-## Overall Assessment
-APPROVE | REQUEST_CHANGES | COMMENT
-<brief justification>
-```
-
-## Severity Guidelines
-
-- **high**: Security vulnerability, data loss risk, production crash potential
-- **medium**: Logic error, performance regression, missing error handling
-- **low**: Style nit, naming suggestion, minor duplication
-
-## Best Practices
-
-- Reference specific lines when possible
-- Each issue must include a suggested fix
-- Avoid commenting on test files unless tests are wrong
-- Skip nitpicks if there are more than 3 substantive issues

package/skills/skills/release-draft/SKILL.md

@@ -1,74 +0,0 @@
----
-name: release-draft
-description: Auto-generates structured release notes with categorized changelog from git history
-whenToUse: When asked to generate release notes, draft a changelog, or summarize changes since the last release
-version: 1.0.0
-priority: managed
-domain: devops
-keywords:
-  - release
-  - changelog
-  - version
-  - release notes
-  - tag
-tools:
-  - Bash
-  - GitDiff
-paths:
-  - CHANGELOG.md
-  - package.json
-  - "**/package.json"
-hooks:
-  pre-draft: |
-    Identify the previous release tag via `git describe --tags --abbrev=0`. If none exists, treat this as the initial release.
----
-
-# Release Draft Skill
-
-You are drafting release notes. Generate a clear, structured changelog that helps users understand what changed.
-
-## Drafting Process
-
-1. **Determine scope**: Identify all commits since the last release tag.
-2. **Categorize changes**:
-   - **Breaking Changes**: API changes, removed features, migration required
-   - **Features**: New functionality, new endpoints, new CLI commands
-   - **Fixes**: Bug fixes, error handling improvements, edge case resolution
-   - **Improvements**: Performance, refactoring, DX enhancements, docs
-   - **Security**: Vulnerability fixes, dependency updates for CVEs
-3. **Estimate impact**: Which changes affect the most users? Lead with those.
-4. **Write for the audience**: End users care about Features and Fixes. Platform teams care about Breaking Changes.
-
-## Output Format
-
-```markdown
-## Highlights
-- <2-3 key changes users should know about>
-
-## Breaking Changes
-- **<area>**: <what changed> — <migration path if applicable>
-
-## Features
-- <feature description> ([#PR])
-
-## Fixes
-- <fix description> ([#PR])
-
-## Improvements
-- <improvement description> ([#PR])
-
-## Security
-- <security fix description> ([#PR])
-
-## Stats
-- <N> commits, <M> files changed, <X> additions, <Y> deletions
-- Contributors: <list>
-```
-
-## Guidelines
-
-- Each entry should be one line, user-focused
-- Link to PRs when available (use `[#N]` format)
-- Group related changes together
-- If there are no entries for a category, omit it
-- Version numbers follow semver conventions suggested by the type of changes