JLugagne

go-bootstrap

Bootstraps a new Go project from scratch with hexagonal architecture, testcontainers, CI pipeline, and the full skill/agent suite installed. Use when starting a new project or microservice.

Strict product manager that interrogates the user about feature specifications, detects maturity gaps, delegates to go-architect once the spec is solid, and arbitrates spec disputes during implementation.

go-product-manager

Decomposes a product specification into ordered features with dependencies, tracks progress, and drives sequential execution through the go-hexagonal pipeline. Use when building a full product from a spec document.

Testing & QA Listed

go-retrospective

Analyzes .feedback/ data across features to detect recurring pipeline issues and proposes skill improvements via interactive questionnaire. MANUAL ONLY — the user invokes this when they want a retrospective, never triggered automatically.

doc-project

ALWAYS LOAD THIS SKILL when working on agents-mercato. Comprehensive project documentation: purpose, how it works end-to-end, architecture, all packages, data models, and key workflows. Required context for any code change, review, or question about this codebase.

4 Updated 2 weeks ago

doc-project

Project map — read this before scanning the codebase. Provides bounded context inventory, entity relationships, infrastructure wiring, and conventions. Always check this first — it's faster than grep.

0 Updated 2 weeks ago

agile-project

Use this skill whenever you are working on a Go project following this agile workflow — features in .features/, sprints in .sprints/, ADRs in .adrs/, global architecture in .architecture/, per-feature ARCHITECTURE.md written by the Architect, tasks under .features/<slug>/tasks/ with scaffolding-first plus red/green triples (TASK.md shared + TASK-red.md + TASK-green.md), spec isolation between paired teammates, dispute arbitration by the sprint-planner, complexity-based agent assignment (scaffolder, red-opus/sonnet/haiku, green-opus/sonnet/haiku, e2e-tester, reviewer), PM and Architect roles for feature definition, and retro-driven sub-sprints for private-helper test coverage. Triggers: mention of sprint planning, feature breakdown, TASK.md / TASK-red.md / TASK-green.md / SCAFFOLD.md, SPRINT.md, REVIEW.md, RETRO.md, Definition of Ready, Definition of Done, blockers, questions, ADRs with revisit flag, dispute files in .disputes/, any of the sprint-planner/product-manager/architect/scaffolder/red-*/green-*/revie

decisions-and-adrs

Use this skill whenever you create, write, modify, or statue an entry under `.decisions/` or `.adrs/`, or when you need to know the difference between a tactical DECISION and a strategic ADR, the two-zone frontmatter format of DECISION-NNN-*.md (zone author + zone review with `revisit`/`reviewed_by`/`reviewed_at`/`outcome` fields), the R2 strict rules under which green is allowed to author a tactical DECISION (scope=tactical, revisit=true at creation, necessary to unblock current task, DECISION-NNN referenced in code or commit message), or the R6 three-level defence around the `Authored-By:` commit trailer (pre-commit format, CI git-blame ↔ trailer cross-check, reviewer pass DoD sanity check). Also covers the architect's three statuing outcomes (confirm / reformulate / supersede) for tactical DECISIONS surfaced in RETRO.md `decisions_to_statue:` from the previous sprint, and the strategic ADR format. Loaded only by `architect` (writes strategic, statues tactical, both ADRs and DECISIONS), `green` (writes tact

markers

Use this skill whenever you need the exact format, lifecycle, or strict rules for the agile-team-v2 code markers — `// AC: <criterion>` + `// TODO(impl-<feature-slug>, ac-<NNN>)` + `panic("not implemented")` (inlined by the architect during scaffolding above each scaffolded function body that maps to an acceptance criterion) and `// SCENARIO: <narrative>` + `// TODO(impl-<feature-slug>, scenario-<NNN>)` + `t.Skip("not implemented")` (inlined by the PM in passe 2 inside business test skeletons under `pm_test_territories`). Covers the strict marker format that `check.sh` enforces (kebab-case feature-slug, three-digit zero-padded NNN, exact `ac-` or `scenario-` prefix), the `pm_test_territories` glob block declared in `.architecture/CONVENTIONS.md` (where `// SCENARIO:` markers may live), the seven-step marker lifecycle (architect scaffolds → PM passe 2 �� red → green → e2e-tester → reviewer pass 2 → TODO removed when feature done while `// AC:` stays as permanent record), and the marker-based task lookup procedu

task-complexity-routing

Use this skill when classifying a feature or task complexity (mechanical, standard, architectural), when deciding which pipeline level applies to a given work item, when escalating a task to a higher complexity level during execution, or when reviewing classification accuracy during retro. Triggers on FEATURE.md DoR review, sprint planning, task escalation via dispute or blocker, and RETRO.md classification accuracy sections. Consult this skill before setting a complexity field, before deciding whether to skip PM/Architect/scaffolder phases, before downgrading a pipeline, and when analyzing past sprints for routing calibration. Do NOT load this skill for routine feature implementation — it is only needed at classification and routing decision points.

Testing & QA Listed

tdd-pattern

Use this skill whenever you are running as the `red` or `green` agent on an agile-team-v2 task. Covers the discipline-based spec isolation between red and green (no private TASK*.md files exist; the only handoff is committed code/tests), the in-scope vs out-of-scope rules of the red/green pattern (applies to standard and architectural complexity features only — mechanical maintenance is a mono-agent task), the mono-assistant safeguard when one Claude instance must wear both hats sequentially (commit red first, fresh session before reading green-side material — `check.sh` audits this at sprint review), and the marker-based task lookup procedure (grep for `TODO(impl-<slug>, ac-<NNN>)` to locate the scaffolded body and its sibling test file). Loaded only by `red` and `green`. Other agents (architect, PM, sprint-planner, e2e-tester, reviewer, bug-detective) operate outside the live red/green isolation flow and do not need these rules.

kanban

Manage a local file-based kanban for software projects worked on with an LLM. Use this skill whenever the user wants to add a feature, work on an existing task, see project status, decide what to do next, or resume work mid-task. Also use it when the user mentions milestones, epics, tasks, "the kanban", "the board", or asks "what's next" / "where were we". Persists context across sessions through Markdown files with YAML front matter, append-only decision logs, and verifiable Definition of Done.

ask-user-questions

Use whenever you need clarifications, decisions, or preferences from the user before proceeding on a task. Instead of asking inline in chat, materialize the questions as a structured QCM markdown file in `.questions/` at the project root. The user answers by editing the file (replacing `[-]` with `[x]` or `[ ]`). Trigger on any ambiguity, missing decision, technical choice, or "should I do A or B" moment — especially during planning, triage, or before sprint kickoff. Do NOT use for trivial confirmations or for questions the project context already answers.

go-surgeon-edit

ALWAYS load when browsing or editing go project. Use this skill whenever you need to read, navigate, explore, or modify Go source code in a project that has `go-surgeon` installed (check for the binary or `go-surgeon` in go.mod). This includes adding, updating, or deleting functions, methods, structs, and interfaces; generating mocks; implementing interface stubs; generating test skeletons; manipulating struct tags; extracting interfaces from structs; and exploring codebase structure. Trigger this skill for ANY Go code editing task — even simple ones like "add a method" or "rename this function" — because go-surgeon produces deterministic, AST-correct results that avoid indentation errors, import issues, and context window waste. Also trigger when the user says "explore the codebase", "find symbol X", "show me the function", "list packages", or wants to understand Go project structure. Do NOT use generic text tools (cat, sed, grep, diff) for Go code editing when go-surgeon is available.

Web & Frontend Listed

go-surgeon-scaffold

Use this skill whenever the user wants to scaffold, bootstrap, or generate architectural components in a Go project that has `go-surgeon` installed with scaffolding templates (`.surgeon-templates/` directory). This includes bootstrapping new projects, adding features, creating new domain entities, generating HTTP handlers, adding repositories, or any request involving project structure generation. Trigger when the user mentions "scaffold", "bootstrap", "generate feature", "add a new entity/handler/repository", "create project structure", "hexagonal architecture", "DDD setup", or asks to create multiple related files following a pattern. Also trigger when hints from a previous scaffold execution suggest running another scaffold command. Always check for available templates before improvising file creation — the templates encode best practices and produce contextual hints that guide the next steps.

mct-cli

Reference guide for mct (claude-mercato), a Git-based package manager for Claude agent and skill definitions. Use this skill whenever the user asks how to use mct, asks about mct commands, wants to install/update/search/export agents or skills, asks about markets, drift, sync, pinning, import/export, or any other mct workflow. Also trigger when the user is looking for skills or agents to add to their project, wants to find a skill for a specific task, asks "is there a skill for X", "find me a skill that does Y", "what skills are available", or wants to browse or discover available Claude skills and agents. Trigger even if the user says "claude-mercato", "mct add", "mct sync", or just asks "how do I install an agent from a market?"

API & Backend Listed

go-api-designer

Designs HTTP API endpoints - routes, request/response types, validation rules, error codes. Called by go-architect when the feature includes an API surface.

go-architect

Designs implementation architecture following hexagonal patterns, produces TASKS.md and individual task-N.md files for the orchestrator to execute using red-green TDD.

go-brainstorm

You MUST use this before starting any feature with go-pm. Explores user intent, alternative approaches, and domain design through Socratic questioning before locking a spec. Prevents building the wrong thing.

go-debugger

Use when encountering any bug, test failure, or unexpected behavior in Go code — before proposing fixes. Enforces root cause investigation through the hexagonal layers. Also use when go-fixer circuit breaker has fired and the root cause is still unclear.

go-dev

Green phase TDD - implements code to make failing tests pass. Never touches test files. Reports disagreements with test expectations.

go-finish

Use when a feature pipeline is fully complete — all tasks green, all reviews passed, acceptance criteria met. Guides final verification, cleanup of .plan/ artifacts, and branch integration (merge, PR, or keep).

go-fixer

Fresh-perspective agent invoked by circuit breakers when another skill is stuck. Reads the error context and attempts to fix the problem without the bias of previous failed attempts.

go-migrator

Writes zero-downtime, reversible, batched data migrations tested with testcontainers. Use for backfills, data transforms, column splits, and schema-level data moves.

go-refactor

Safe refactoring agent. First documents all inbound surfaces (HTTP, gRPC, message queues, etc.), creates exhaustive e2e tests with testcontainers to lock behavior, then plans and executes the rewrite with type-level compatibility guarantees. Use when restructuring, rewriting, or migrating existing code.

go-reviewer

Orchestrates dual code review with consensus — two Sonnet reviewers (architecture+performance and security+data) run in parallel, Opus arbitrates only when they diverge. Creates fix/test task files.

go-runner

Thin task runner that executes .plan/<feature-slug>/TASKS.md by dispatching subagents for each task. Validates green phases by running tests. Does not inline skill files — agents must have skills installed.

go-scaffolder

Creates all scaffolding files for a feature - stubs, interfaces, typed IDs, mocks, skipped tests - ensuring the project compiles and all tests pass or skip.

Testing & QA Listed

go-test-writer

Red phase TDD - writes failing unit tests, contract tests, and e2e API tests. Covers all test levels in a single pass. Never touches implementation code.