@gitlink-ai/gitlink-code 0.0.13 → 0.0.14

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@gitlink-ai/gitlink-code",
-  "version": "0.0.13",
+  "version": "0.0.14",
   "description": "GitLink Code — AI Coding Agent for DevOps",
   "type": "module",
   "bin": {
@@ -10,7 +10,8 @@
   },
   "files": [
     "dist/",
-    "bin/"
+    "bin/",
+    "skills/"
   ],
   "engines": {
     "node": ">=18"

package/skills/ci-debug/SKILL.md

@@ -0,0 +1,76 @@
+---
+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
+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/gc-self/SKILL.md

@@ -0,0 +1,109 @@
+---
+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/pr-review/SKILL.md

@@ -0,0 +1,65 @@
+---
+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
+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/release-draft/SKILL.md

@@ -0,0 +1,68 @@
+---
+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
+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