WAME Claude Code Plugins

A marketplace of Claude Code plugins by WAME — developer productivity tools for teams.

Installation

Add the WAME marketplace:

/plugin marketplace add wamesk/claude-code

Then install any plugin:

/plugin install git-commits-history@wamesk

Available Plugins

Plugin	Description	Repo
git-commit	Turn the current working tree into one or more logical git commits using the TYPE(scope): Message convention from your global ~/.claude/CLAUDE.md. Title and body always in English; TYPE and scope inferred from the changes. When the run is tied to a task, the task ID is appended in square brackets — TYPE(scope)[<task-id>]: Message — detected from $ARGUMENTS, --task=<id>, or current branch name (feature/teamwork-task-<id>, task/<id>, …). When no task ID is detected, the brackets are omitted entirely (never empty []). Groups related changes into one commit each; pass --all-in-one to skip grouping. Never adds Co-Authored-By lines, never pushes, never amends. Singular git-commit — distinct from git-commits-history which summarises historical commits.	wamesk/claude-code-plugin-git-commit
git-commits-history	Fetch and summarize git commits history across all repositories for a date range. AI-powered summaries, file changes, project breakdown. Renamed from git-commits in v2.0.0 — existing users: /plugin uninstall git-commits@wamesk && /plugin install git-commits-history@wamesk; config in ~/.claude/plugins/data/git-commits-wamesk/ is preserved automatically.	wamesk/claude-code-plugin-git-commits-history
git-commits	[DEPRECATED] Renamed to git-commits-history. Installing this package shows migration instructions only; it contains no executable logic.	wamesk/claude-code-plugin-git-commits
laravel-docs	Generate Laravel project documentation (technical, business, admin navigation) for individual models or modules. Auto-detects modular (wamesk/*, Modules/*) vs flat (app/Models) layout. Per-project config with replaceable prompts per type.	wamesk/claude-code-plugin-laravel-docs
dnr-business	Generate a WAME Detailný návrh riešenia (DNR) — the binding pre-development project document — as a branded .docx. Inputs: a folder of supporting materials, individual files (.docx/.pdf/.md/.txt), or a free-form description; when invoked inside a project repository, the skill additionally deep-scans the codebase (modules, Laravel/wamesk/* layout, package files, README) so the resulting DNR reflects the existing state. Output is a Word document in the client's language (sk/cs/en) styled in WAME identity (green #20E87A, navy #091145, Inter font), with 12 mandatory sections plus 5 optional ones. Sections Fázy and Riziká (min. 5) are schema-enforced. Never invents client data — uses [DOPLNIŤ] placeholders and reports them as open follow-ups at the end. Stdlib-only OOXML generator, no external Python deps.	wamesk/claude-code-plugin-dnr-business
teamwork-tasks-from-dnr	Generate a Teamwork.com import-ready XLSX plus a companion Markdown plan from a "Detailný návrh riešenia" (DNR) document. LLM extraction of task lists, business-friendly task names, acceptance criteria (checkbox list), goal, and technical plan. Multi-language (sk/en/cs), DOCX/PDF/MD input, stdlib-only XLSX writer. Single repo serves both Claude Code (plugin) and Claude.ai (skill). Since 1.6.0 a task that adds a screen carries cross-cutting acceptance criteria under ### Prierezové požiadavky — reachability (a menu entry and links from the parent screen, enforced by the validator) plus the applicable security, performance and UI/UX items, keyed like teamwork-task-test's QA dimensions — and every code task's technical plan ends with a Framework line naming the versions detected from the repository's lock files (plan only, never an acceptance criterion).	wamesk/claude-code-plugin-teamwork-tasks-from-dnr
teamwork-tasks-from-desk	The bridge between customer support and engineering. Turns a Teamwork Desk ticket into a structured Teamwork Projects task (and optional subtasks) without leaving the terminal. Fetches the ticket (subject, customer, chronological thread of replies + internal notes, email attachments) via the Desk REST API, asks for a target Projects URL + assignee email (per role when the task splits into BE/FE/QA/Migration/DevOps), drafts the main task in the canonical WAME format ([preamble] → HR → ## Akceptačné kritériá → HR → ## Cieľ → HR → ## Technický popis), proposes a split into subtasks when the estimate exceeds 240 min and AC have natural cut points, and asks per attachment where it belongs. After preview + confirmation creates the task + subtasks via /projects/api/v3, uploads attachments via the pending-file flow, and links the main task back to the Desk ticket — native deskTicketId attribute when supported, otherwise URL embedded in the description footer. Closes the loop by posting an internal note in the Desk thread (link to the new Projects task + structured summary of what was prepared: title, AC count, subtasks list, estimate, attachments uploaded, goal) and offers to draft a customer-facing reply — the draft is always posted as an internal note for review, never sent to the customer (plugin never touches the Desk /replies.json endpoint). Since 1.3.0 the drafted task carries a ### Prierezové požiadavky block with the cross-cutting requirements that apply (reachability via a menu entry and links from related screens, security, performance, UI/UX — the keys teamwork-task-test checks) and a technical-plan line naming the installed framework versions and their idioms (plan only); none of it reaches the customer-facing draft. The same release makes every snippet zsh-safe — attachments, subtask attachments, the customer and inbox names and threads over 100 messages had been silently lost — and stops the retry guard from creating a duplicate task. Reuses the shared API token config; Desk token stored alongside the Projects token under teamwork.desk_token. Never replies to the customer, never sends email, never moves the Desk ticket between statuses, never moves the new Projects task on its board, never logs time.	wamesk/claude-code-plugin-teamwork-tasks-from-desk
teamwork-tasks-from-session	The inverse of teamwork-task — instead of "pull a task and implement it", it is "I already solved this in a Claude Code session, now create and bill the task for it". For the common case where you start fixing something directly in Claude Code before any task exists. Reconstructs what the session did from the git commits + working-tree diff made since the session started, the changed files, the repo shape, and the live conversation context, then drafts a main task in the canonical WAME format ([preamble] → HR → ## Akceptačné kritériá → HR → ## Cieľ → HR → ## Technický popis) with a ### Zdroj footer recording the branch + session commits, optional 2–6 atomic subtasks (only above 240 min with natural cut points), and a wame-estimate-v2 estimate. Logs the real session time back to Teamwork: the session start comes from a bundled SessionStart hook that records each session's wall-clock start into the shared config dir, falling back to the end of today's last timelog → the newest session transcript's first timestamp → asking — always shown as an editable proposal and clamped so the entry never overlaps an existing timelog (one sequential, non-overlapping, 5-minute-aligned, business-tone entry with an optional (commit: <hash>) suffix). No URL → asks where to file it; a project/tasklist URL makes a new main task, a single-task URL files the work as a subtask of that task. Asks via AskUserQuestion which Teamwork email to assign to (you by default, unassigned, or a colleague's email resolved via people.json). Full preview + confirmation gate before any write (--write-back=never = dry-run); after creation asks per run what to do with the board (leave / move to the done column — the shared board_workflow target, Done - Local with fallbacks Internal testing → Testing / complete). Since 1.3.0 the drafted task carries the cross-cutting requirements shared with teamwork-task-test (reachability, security, performance, UI/UX — claimed as delivered only when the diff proves it) and a framework line recording the installed versions and the idioms the session actually used; task creation works again in zsh and macOS bash 3.2, subtask mode finds the parent's project, and an explicit false in the shared config (e.g. is_billable_by_default) is no longer flipped back to true. Shares the API token config with the Teamwork plugin family; hardened Projects writes carried over from teamwork-tasks-from-desk (Python-encoded payloads, estimatedMinutes write field, idempotency guard). Never runs git, never logs time without confirmation, never writes an overlapping log, never silently overwrites an estimate.	wamesk/claude-code-plugin-teamwork-tasks-from-session
teamwork-task-analyze	The analytical step between a PM handing a task over and the engineer starting to implement it. Fetches a Teamwork.com task (or whole tasklist) by URL — including description, attachments, comments, comment-attached files and subtasks — then deep-scans the current repo for related specs/code and interactively rewrites the description into the canonical WAME format: [preamble] → HR → ## Akceptačné kritériá → HR → ## Cieľ → HR → ## Technický popis where the technical section is full Claude Code Plan-Mode output (files, functions, DB schema, step-by-step, edge cases, tests to add). Asks clarifying questions via AskUserQuestion in batches and folds the answers in; preserves anything unresolved as [OTVORENÉ] markers. Reviews subtasks and (for tasks above 240 min with naturally separable AC) proposes a split into 2–6 atomic subtasks. Checks the time estimate using the WAME estimate methodology wame-estimate-v2 — sets one when missing, warns + asks before overwriting a diverging existing value. Every Teamwork write is gated by a preview + confirmation; --write-back=never gives a full dry-run. For tasklists reuses the teamwork-task filter — a start column (Ready for Development or To Do by default) + assigned to me; tasks not on the board and teammates' tasks are listed read-only. Since 1.3.0 the rewritten acceptance criteria gain a ### Prierezové požiadavky block with the cross-cutting requirements that apply — menu entry and inbound links for a new screen, object-scoped authorization, data volume, UI states — under the ui_ux / performance / security / reachability keys teamwork-task-test verifies, and the technical plan names the installed framework versions and the idiom to use (plan only, never an AC). Comments, attachments, subtasks, the board column and the project link now come from fields and endpoints Teamwork v3 actually has — the old ones had silently produced no comments, no eligible tasks and a /projects/null link. Read-only against the board (never moves it) and the timesheet (never logs time). Shares the API token config with the rest of the Teamwork plugin family.	wamesk/claude-code-plugin-teamwork-task-analyze
teamwork-task	Fetch a Teamwork.com tasklist or single task by URL (including task comments — the newest one always, the full thread when the description is thin or points to it), render a plan for approval, then implement each task in the current repository, commit per task using TYPE(scope)[<task-id>]: Message, and log spent time back to Teamwork via REST API v3 as sequential, non-overlapping entries (both start time and duration aligned to the 5-minute rounding step). Time-log descriptions are written in a business tone — what was delivered for the user/business — technical detail only when needed for identification. Reads the acceptance criteria from the ## Akceptačné kritériá block of the canonical WAME description (first-HR split as the fallback). Configurable plan mode (overview / per_task / none), time tracking (real time rounded to 5 min, or ask) and branching (current branch or new feature branch). Since 1.1.1, when the companion teamwork-task-test skill is installed, hands off to it at the end of the run so each task's acceptance criteria get individually verified before push (default ON, disable with --test-after=false). Since 1.5.0 comments, subtasks, attachments, the tasklist filter and board moves really work — four independent defects reported in a colleague's "Štyri cesty k nule" analysis (an invalid comment sort key answered with HTTP 400, a commentsCount gate on a field v3 never returns, a non-existent timestamp field, JSON piped through echo breaking in zsh) each let a run continue on empty context without an error; failures now print a ⚠ line, and an explicit false in the config is respected. It follows the new WAME board: a tasklist run implements only tasks in a start column (tasklist_filter.todo_stages, default Ready for Development and To Do) assigned to you, a task not on the board is analyse-only, and finished work moves to Done - Local (fallbacks Internal testing → Testing); a completed task behind a single-task URL is reworked only after you confirm. Every task is planned, built and self-checked against five build-time quality dimensions shared with teamwork-task-test — UI/UX, performance, security, page reachability (a new screen ships with its menu entry and inbound links) and framework best practices (the idioms of the versions in the project's lock files, checked in current docs). Persistent config — API token survives plugin updates; the config migration only moves values still at their old defaults. Push is left to the user.	wamesk/claude-code-plugin-teamwork-task
teamwork-task-test	Verify a Teamwork.com task or whole tasklist against the current repo — the QA sibling of teamwork-task. Extracts every acceptance criterion from the task description (the ## Akceptačné kritériá block of the canonical WAME format, HR-split otherwise; supports HTML/markdown bullets and checkboxes), then for each criterion: runs an existing matching test (Pest, PHPUnit, Laravel Dusk, Cypress, Playwright, Vitest, Jest, Selenium), drives a real browser via the chrome-devtools MCP for UI-shaped criteria, or writes a concrete numbered manual scenario. Since 1.1.0 it does two more things that turn a checklist pass into a real QA pass. It reviews four cross-cutting dimensions over the task's own diff — UI/UX & accessibility (a disabled control must carry aria-disabled and a reason; a new translation key must resolve to text, not to itself), performance (real LCP/CLS/INP/TTFB against budgets, plus N+1 and unchunked batches named with the row count at which they start to matter), security (authorization and tenant isolation on new routes, injection, unhandled 500s on reachable routes), and reachability (every registered screen must be reachable by clicking — screens enumerated from the filesystem, menu links read from the live rendered navigation, relation tabs subtracted; what is left is findable only by typing the URL). And it puts every green test through a negative control — revert the fix, confirm the test goes red, restore — so a test that passes with and without the change downgrades its criterion to ⚠️ partial instead of quietly vouching for it. Since 1.2.0 a fifth, advisory dimension — framework — recommends the idioms of the framework versions the project actually has installed (read from its lock files, checked in current docs, at most five per task, in their own Odporúčania section); it never edits code and never fails, downgrades or blocks a criterion. The same release makes QA really read the task comments (a commentsCount gate on a field v3 never returns and a sort key the API rejects with HTTP 400 had left it on none — a failure now says comments unavailable, never no comments) and makes every snippet zsh-safe. Output is a per-task report with every AC marked ✅ verified / ⚠️ partial / ❌ failed / 📋 manual / 📝 proposed, plus findings and negative-control tables and a tasklist roll-up. Ticks the met criteria to [x] in the Teamwork description under a byte-exact safety contract that preserves inline images (inline images live only in that markdown — a careless rewrite deletes the screenshot for good). No board moves, no comments, no task completion unless you opt in. Sequential, non-overlapping time logs share the same cursor as teamwork-task so back-to-back runs leave a clean timesheet. Shares the API token config — set it up once.	wamesk/claude-code-plugin-teamwork-task-test
laravel-agents	Seven specialized Laravel subagents (laravel-backend, sql-database, api-architect, pest-tester, code-reviewer-laravel, security-auditor, performance-optimizer) plus four companion skills. The agents are thin personas of under 100 lines that defer to progressively-disclosed reference skills instead of inlining examples: wame-laravel-standards (API response format with BaseCollection pagination, database conventions — ULID/enums/sort/dateTimeTz, data via migrations not seeders, service layer, testing), wame-package-development (clean composer package/module creation per laravelpackage.com with stubs + composer.json path-repository wiring), wame-security-checklist (OWASP Top 10 + Laravel), and wame-performance-playbook. Since 1.1.0 a shared cross-cutting quality reference brings the keys teamwork-task-test reviews at QA time to the build side: laravel-backend ships every new screen with its menu entry and inbound links, a policy and a FormRequest on every new entry point, and eager-loaded, paginated, indexed lists; new or changed code follows the idioms of the installed Laravel / PHP / Pest versions (read from composer.lock, looked up via Laravel Boost search-docs or context7); pest-tester proves reachability and authorization; code-reviewer-laravel reviews the same keys, with framework as advisory recommendations. Nova-free — for Laravel Nova install laravel-nova-agents alongside.	wamesk/claude-code-plugin-laravel-agents
laravel-nova-agents	The laravel-nova subagent for building Laravel Nova admin panels (BaseResource, custom Fields/Actions/Lenses/Filters/Metrics, CSV/Excel export, Dusk browser tests) plus the wame-nova-patterns skill. Install alongside laravel-agents; the pest-tester agent then picks up wame-nova-patterns for Nova/Dusk browser testing only when this plugin is present, keeping non-Nova projects clean. Since 1.1.0 a Nova cross-cutting quality reference applies the keys teamwork-task-test checks while building: every new resource, lens, dashboard or tool is reachable from Nova::mainMenu() or a relation field on its parent, policies and tenant scope cover every query hook, search stays index-friendly, help is translated and destructive actions confirmed, and Dusk tests reach new screens through the menu. New code follows the installed Nova major (laravel/nova read from composer.lock, a Nova 4 vs Nova 5 table checked against the vendor source), because Nova 5 code fatals in a Nova 4 project.	wamesk/claude-code-plugin-laravel-nova-agents
laravel-filament-agents	[PLACEHOLDER] Reserved for WAME's Filament agents/skills — coming after the first real Filament work (WAME Reality Phase 1). Ships no agents today; the filament-resource agent and wame-filament-patterns skill will be written from that work, not blindly from docs.	wamesk/claude-code-plugin-laravel-filament-agents

Adding a New Plugin

1. Create a new repo with your plugin (must have .claude-plugin/plugin.json)
2. Add an entry to .claude-plugin/marketplace.json in this repo
3. Push — users run /plugin marketplace add wamesk/claude-code to get the update

License

MIT