alkampfergit

Fix a GitHub bug issue end-to-end — analyze the codebase, write failing tests, commit them to a bugfix/<id> branch, implement the fix, and open a PR with a full investigation log. After the PR opens, poll it for owner feedback at configurable intervals until stood down. Trigger on a single issue (/bugfix

Routine repository security-maintenance pass. Create a fresh branch, use the gh CLI to enumerate security problems (Dependabot, code scanning, secret scanning), fix the actionable ones, verify, open a pull request, then hand off to /github-pr-fixer. Use when the user says "run maintainer", "do a security maintenance pass", "fix the security problems and open a PR", or similar.

Drive a single GitHub issue through the full speckit pipeline (specify → clarify → plan → tasks → PR-report → draft PR → implement → test → ready → CI → review) using the `gh` CLI. Fully human-in-the-loop — every speckit phase posts its artefact on the issue and polls for owner approval. All user communication stays on the issue / PR threads, never the console. Use when the user says "implement issue

Use when the user wants to find SonarCloud issues for the current branch pull request, fix them in the local repo, verify with local checks, push the branch, and confirm whether SonarCloud has reanalyzed the PR.

Analyze and fix SonarCloud issues on pull requests. Use when the user mentions SonarCloud, quality gate, code smells, duplication, or wants to check PR quality status. Reads issues via GitHub API, creates fix plans, and applies fixes with awareness of parallel agent safety.

Keep a slim, human-readable CHANGELOG. The root CHANGELOG.md holds only a short stanza per release (theme + a few brief bullets + a link); full per-release detail lives in docs/changelogs/<version>.md, with docs/changelogs/unreleased.md accumulating the next release. Versions follow the tags on master — if master is at 0.11.x, unreleased work on develop belongs to 0.12.0. Use when the user says "record a changelog entry", "update the changelog", "finalise the changelog for a release", or "split the changelog".

Drive a gitflow release end-to-end — resolve the current version from the latest tag on master, compute the next version (minor bump by default, or caller-specified), run `git flow release start/finish`, and push `master`, `develop`, and the new tag. Use when the user says "release X.Y.Z", "cut a release", or when speckit-full picks up a release issue.

Repair common "repo is not in a clean state" situations so another skill (e.g. `speckit-full`) can proceed. Use when the caller reports pending/uncommitted changes on develop/master, a branch that hasn't been pushed, or a push that was rejected because the remote has newer commits. Does NOT touch state that looks intentional (merge in progress, detached HEAD, untracked files that look like secrets, etc.) — surfaces those to the user instead.

Re-analyze the template/ folder for internal consistency, keep template/structure.md (an annotated map of the template layout) up to date, and keep the meta/skill-list.md index in sync with the template skills. Use when checking template consistency, after adding/renaming/removing files under template/, when verifying internal links and skill tables resolve, or when asked to "run the maintainer", "check the template", "audit the template", or "update the template structure". Do NOT use for ingesting external sources (use ingest-link) or for editing project content unrelated to template consistency.

Author, update, or remove a Claude Code skill inside the template (template/.claude/skills/), following meta/skill-guide.md as the design rubric, and keep the meta/skill-list.md index table in sync. Use when asked to create a new template skill, write a skill, add a skill to the template, update or rename an existing template skill, or regenerate the template skill list. Do NOT use to author authoring-repo skills under the root .claude/skills/ (those are not part of the template product).

Ingest an external URL as a knowledge source: fetch and analyse it, record an entry in knowledge/links.md, write detailed notes under knowledge/sources/, then patch the affected template docs and structure. Use when a new article, paper, blog post, documentation page, or talk transcript should inform the harness engineering template, or when the user provides a URL to "ingest", "add to the knowledge base", or runs "/ingest-link <url>".

Scan the repository for stale, broken, or missing documentation and repair the highest-priority issues. Use when auditing docs, checking AGENTS links, reconciling docs with code, or running periodic documentation maintenance.

Bootstrap a new business domain or bounded context with scaffolding, architecture updates, and structural tests. Use when adding a new domain, introducing a new business capability, creating a new module under src/domains, defining a bounded context, or establishing domain boundaries.

Reproduce and fix reported bugs with test-first verification and root-cause analysis. Use when debugging a defect, investigating unexpected behavior, triaging a regression, or implementing a minimal corrective fix.

Capture reusable agent behavior and best practices as a skill update or a new skill after task completion. Use when a task reveals a repeatable workflow, exposes missing instructions, or surfaces a pattern worth preserving for future tasks. Examples: update an existing skill, create a skill for a new workflow, document guidance the agent should reuse, or refine repository skills after delivery. Review existing skills first, create new only when the scope is clearly distinct, and do not use this skill for one-off fixes with no reuse value. After the first draft, launch a subagent to refine the skill against meta/skill-guide.md.

End-to-end workflow for adding a new feature from a task or prompt description. Use when implementing a new capability, adding an endpoint, introducing a new service method, or building a new UI component.

Take a single GitHub issue (by number or URL) and drive it through an end-to-end flow (branch → plan → build → test → PR) using the `gh` CLI. All user interaction happens through issue comments, never the console. Use when the user says "implement issue

Triage and fix GitHub-reported security and quality findings — Dependabot alerts, code-scanning (CodeQL) alerts, and secret / malware scanning alerts — for this repository using `gh`, `npm`, and language-specific toolchains. Use when the user asks to review the Security tab, clear open alerts across any of the three surfaces, merge Dependabot PRs, or explain why an alert is safe to dismiss. Pairs with the `gh-cli-guide` skill for the underlying API calls. Does NOT auto-invoke `github-pr-fixer` — once a fix PR is opened, this skill stops and the owner chooses whether to run `/github-pr-fixer` manually.

Poll GitHub for open issues carrying a user-specified label and drive each one through gstack's end-to-end flow (plan → build → test → ship) via the `gstack-gh` skill. Use when the user says "watch GH for issues with label X and implement them", "auto-process the backlog", or "poll for ready stories". Supports three scheduling modes — in-session loop, self-paced loop, or cron (remote trigger).

Reproduce and fix reported bugs with test-first verification and root-cause analysis. Use when debugging a defect, investigating unexpected behavior, triaging a regression, or implementing a minimal corrective fix.

Scan the repository for stale, broken, or missing documentation and repair the highest-priority issues. Use when auditing docs, checking AGENTS links, reconciling docs with code, or running periodic documentation maintenance.

End-to-end workflow for adding a new feature from a task or prompt description. Use when implementing a new capability, adding an endpoint, introducing a new service method, or building a new UI component.

Improve code structure without changing behavior using safe, test-preserving refactoring steps. Use when extracting helpers, splitting files, reducing duplication, aligning with repository patterns, or cleaning up code.

End-to-end workflow for implementing a small scoped change while preserving every harness engineering invariant (dependency rules, tests, lint, structural checks, boundary validation, docs, ADRs, quality grades, versioning). Use for scoped single-domain tweaks that touch only a handful of files: tightening a validation, correcting a config default, adjusting a log line, updating a small piece of documented behavior, or making a narrow non-bug behavior adjustment. Not for defect investigation or corrective bug fixes (use `bug-fix`), not for multi-domain features (use `new-feature`), not for behavior-preserving restructure (use `refactor`).

Expert guidance for the Cisharpai .NET library — a unified HttpClient-based interface for OpenAI, Azure OpenAI, Azure AI Inference, Anthropic, and Cohere LLM providers. Use when writing, debugging, or architecting code that uses Cisharpai clients, features, DTOs, DI registration, or provider-specific integrations. Activates on mentions of "Cisharpai", "IChatCompletionClient", "IEmbeddingClient", provider setup, tool calling, streaming, JSON output, grounded chat, vision, embeddings, or fake clients for testing.

Reverse-engineer speckit specification files (spec.md, plan.md, and supporting artifacts) from an already-implemented feature in the codebase. Use when the code exists but no speckit specs do. Tasks.md generation is skipped by default (add '--tasks' to include it).

Analyze and fix SonarCloud issues on pull requests. Use when the user mentions SonarCloud, quality gate, code smells, duplication, or wants to check PR quality status. Reads issues via GitHub API, creates fix plans, and applies fixes with awareness of parallel agent safety.

Use when the user wants to find SonarCloud issues for the current branch pull request, fix them in the local repo, verify with local checks, push the branch, and confirm whether SonarCloud has reanalyzed the PR.

Drive a single GitHub issue through the full speckit pipeline (specify → clarify → plan → tasks → PR-report → draft PR → implement → test → ready → CI → review) using the `gh` CLI. Fully human-in-the-loop — every speckit phase posts its artefact on the issue and polls for owner approval. All user communication stays on the issue / PR threads, never the console. Use when the user says "implement issue

Diagnose failing pull request checks across GitHub Actions and external status providers such as SonarCloud and CodeQL. Use when a user asks why a PR is red, which check is blocking merge, why CI passed but the pull request still fails, why branch protection is not satisfied, or what file needs to change to fix a failing status. Determines whether the failing check belongs to github-actions or an external app, traces the exact root cause, and identifies the smallest correct fix.

Write a short three-line haiku when the user asks for a haiku or a tiny poem.

Turn an existing plan or review into a short verification checklist when the user explicitly asks for one.

Capture verified learnings after completing one or more repository samples or a learning session. Use when the user asks to update AGENTS.md, document sample progress, preserve session decisions, maintain the docs course, record user preferences, or improve future sessions from what was just learned.

Encode or decode a short ASCII message with the ROT13 example scripts, using either bash or PowerShell.

Write a short three-line haiku when the user asks for a haiku or a tiny poem.

Capture stable lessons from a speckit run into persistent project memory and create/update helper skills when repeated repo-specific workflows emerge.

Autonomous end-to-end speckit pipeline: specify → clarify (self-answered) → plan → tasks → implement → open PR. No human input required.

Investigate SonarCloud quality gate failures for the current GitHub pull request. Use when a PR has a failing SonarCloud check, when the user asks where duplication or other Sonar failures come from, or when you need to trace a GitHub Sonar check into SonarCloud file-level and block-level details.

Use when the user wants to work through the automata CLI feature-delivery loop: pick up the next GitHub issue with `automata implement-next`, monitor PR status and CI checks with `automata git get-pr-info`, inspect unresolved review threads with `automata git get-pr-comments`, address reviewer feedback, and finish a merged feature with `automata git finish-feature`. Also use when the user asks how automata works for day-to-day implementation flow in this repository.

Create a new blog post skeleton for either the English (codewrecks) or Italian (itablog) Hugo site. Use when the user asks to create a new post, scaffold a post, or start a new article.

This skill should be used when the user mentions "go template", "hugo template", "partial", "shortcode", "template syntax", "layout", "baseof", "block define", "{{ range }}", "{{ if }}", "{{ with }}", "{{ partial }}", "template lookup", "layout hierarchy", or any Hugo templating concepts. Provides comprehensive guidance on Go template syntax, layouts, partials, shortcodes, and template debugging.

This skill should be used when the user mentions "go template", "hugo template", "partial", "shortcode", "template syntax", "layout", "baseof", "block define", "{{ range }}", "{{ if }}", "{{ with }}", "{{ partial }}", "template lookup", "layout hierarchy", or any Hugo templating concepts. Provides comprehensive guidance on Go template syntax, layouts, partials, shortcodes, and template debugging.

Maintain the architecture documentation set so it stays a living map of the repo. Use when a feature has just merged, when the user asks to refresh or audit the architecture doc, when a folder is added/moved/renamed, or when a tasks file has a non-empty "Pending arch updates" section. Do NOT use to write new architecture from scratch — for that, draft a spec/plan first.

Spec-driven development workflow. Use whenever the user wants to add, change, or remove behavior — i.e. anything that would normally start with "implement…", "add a feature for…", "change the way X works", "fix the behavior of…". Walks the spec → plan → tasks → implement → arch-update loop, reading and writing files under docs/specs, docs/plans, docs/tasks. Do NOT use for pure refactors with no behavior change, dependency bumps, or typo fixes.

Add, modify, or remove MCP tools in the vscode-mcp-hook extension following the harness engineering pattern. Use when the user asks to add a new MCP tool, remove an existing one, or modify a tool's schema, handler, or documentation.

Monitor the status of a pull request — its GitHub Actions checks (build/test), review and mergeable state, and SonarCloud pull-request analysis (quality gate + new-code issues and hotspots). Use when the user asks about PR status, whether a PR is green/mergeable, failing checks/build on a PR, or SonarCloud issues on a PR.

Keep the DotNetCoreCryptography README and wiki documentation synchronized with code changes. Use when changing public APIs, encryption formats, key wrapping behavior, security guidance, build/test setup, or examples.

Use this skill whenever the user wants to create, import, organize, or refine a backlog in Beads (Steve Yegge's issue tracking tool). Trigger for ANY of these situations: writing new issues from scratch, importing backlog from a markdown file, converting requirements or specs into Beads issues, analyzing a codebase to generate or enrich a backlog, setting up issue dependencies (blocks/depends-on), defining priorities and labels, or generating a Claude Code prompt to automate backlog import. Also trigger when the user says "add to backlog", "create issues", "write the backlog", "convert this to beads", or when they share a markdown/text list and want it turned into trackable issues.