HiroKata Claude Code Plugin Marketplace

A curated collection of Claude Code plugins for enhanced development workflows. Version 8.4.0 — View Changelog

Installation

There are two ways to install plugins from this marketplace: using Claude Code's built-in marketplace system (recommended), or cloning the repository and copying plugins manually.

1.a. Install Using the Claude Code Marketplace

This is the official method. Claude Code's marketplace system handles discovery, installation, and future updates automatically.

Step 1 — Add the marketplace

Run this inside a Claude Code session or from the CLI:

# Inside Claude Code
/plugin marketplace add HirogaKatageri/hirokata

# Or from the terminal
claude plugin marketplace add HirogaKatageri/hirokata

Step 2 — Install plugins

Once the marketplace is added, install individual plugins by name. The marketplace identifier is hirokata.

# Install the Guild plugin
/plugin install guild@hirokata

# Install the Software plugin
/plugin install software@hirokata

Step 3 — Keep plugins up to date

Pull the latest versions at any time:

/plugin marketplace update hirokata

For teams: Add the marketplace at project scope so it is shared automatically via .claude/settings.json:

claude plugin marketplace add HirogaKatageri/hirokata --scope project

1.b. Installing From a Local Clone

For offline environments, or when you want to modify a plugin before using it, clone the repo and point Claude Code at your copy. The clone is itself a marketplace — .claude-plugin/marketplace.json is at its root — so the same install flow works against a path.

Step 1 — Clone the marketplace

git clone https://github.com/HirogaKatageri/hirokata.git

Step 2 — Add the clone as a marketplace and install from it

# Inside Claude Code
/plugin marketplace add ./hirokata
/plugin install guild@hirokata

# Or from the terminal
claude plugin marketplace add ./hirokata
claude plugin install guild@hirokata

Add --scope project to the marketplace add if you want the path recorded in the project's .claude/settings.json so teammates pick it up — in which case use a path everyone will have, or keep the GitHub form from 1.a instead.

Edits you make in the clone reach your sessions the same way an upstream change does: re-run /plugin marketplace update hirokata.

Verify the plugins loaded by trying a trigger phrase after starting Claude Code:

guild status

Guild prerequisite: the guild board is a local Turso database, and tursodb is the tool the guild uses to reach it — there is no guild CLI. No account, token or network is required. Install it and put it on PATH:

brew install tursodatabase/tap/turso   # or: curl -sSfL https://get.tur.so/install.sh | bash
export PATH="$HOME/.turso:$PATH"

How to Use the Guild Plugin

The Guild plugin (v9.4.0) provides continuous agent orchestration through a persistent, database-backed work cycle. The guild tracks direction, requirements, tasks, bugs and quality coverage across sessions — no per-session setup required.

The plugin is a schema and a set of skills — not a program. tursodb already executes SQL, so the guild ships no second tool that does the same thing: members write their own SQL, and the guild's rules live in the database as CHECK constraints (the status vocabularies), views (the derived rules — the cursor, the review gate, readiness, the board, each with one definition) and triggers (the event record, written on every mutation). A member can forget to call a command; a member cannot bypass a trigger or a CHECK.

The one thing deliberately not in the database is the roster. Who the guild's members are and what each can do is the capabilities: frontmatter of the agent files, read at dispatch time across every subagent available to you — this plugin's, your project's .claude/agents/, your ~/.claude/agents/, and every other installed plugin's. A ticket names the capability it needs; adding an agent file that declares it is the whole of hiring, with nothing to sync.

guild:new-requirement — a live interview with the project-manager, then the strategist plans
    → developers / developer-svelte (parallel waves, disjoint files)
    → test-planner → test-writer (unit & integration)
    → 4 reviewers in parallel → a review report you act on

The v6/v7 line is a fresh rewrite, and its status is worth reading before you trust it. The v5 CLI it replaced had four adversarial review rounds and a 2,278-check suite; that code is deleted and none of that assurance carries over. It ships with no tests, by design. See the Status section in plugins/guild/README.md.

Upgrading an existing board? CREATE TABLE IF NOT EXISTS cannot rename or drop a table, so a live .guild/guild.db needs the migrations run once each, in order, with schema.sql re-applied at the end. Check SELECT version FROM schema_version first and run only the ones above it:

export PATH="$HOME/.turso:$PATH"
cp .guild/guild.db .guild/guild.db.bak
tursodb .guild/guild.db < plugins/guild/migrations/006-project-and-plan-approval.sql   # 5 → 6
tursodb .guild/guild.db < plugins/guild/migrations/007-roster-leaves-the-database.sql  # 6 → 7
tursodb .guild/guild.db < plugins/guild/migrations/008-the-library-becomes-a-graph.sql # 7 → 8
tursodb .guild/guild.db < plugins/guild/migrations/009-a-fix-need-not-be-a-ticket.sql  # 8 → 9
tursodb .guild/guild.db < plugins/guild/schema.sql

• 006 (v6.2) renames phase to project and splits plan.status from plan.approval.
• 007 (v7.0) drops the agent, agent_capability and capability_request tables — the roster moved to the agent files.
• 008 (v8.0) gives doc a kind and a status, and adds knowledge_edge and doc_revision — the library becomes a knowledge graph. Check the version reads 7 first: a second run does not fail safely, it resets every document's tagging.
• 009 (v8.1.2) adds bug.fix_ref and review_finding.fix_ref, so a defect fixed by a direct commit rather than a ticket can still satisfy G6.

None is idempotent, and 006 and 007 fail safely on a second run. A fresh board needs none of this.

v8.1.0 and v9.0.0–v9.4.0 need no migration. Removing guild:clear-board (8.1.0), renaming the roster to project-manager/strategist and splitting the architecture capability into planning and software-architecture (9.0.0–9.1.0), dropping the on-disk review/release markdown mirrors (9.1.1), and removing guild:discuss while making new-requirement's interview sequential rather than a concurrent 3-way (9.2.0), deciding per piece of work whether it is tested and reviewed (9.3.0), and adding the Kumiai backend as a second door to the same warehouse (9.4.0) changed skills, agents and documentation only; schema.sql is untouched and schema_version stays at 9.

Setting Up

The guild requires no manual initialization. On your first check-in it creates a .guild/ directory in your project:

.guild/
├── config.yaml       # committed — storage mode; env var NAMES only, never a credential
├── guild.db          # gitignored — THE BOARD
├── docs/  qa/        # evergreen knowledge base and QA artifacts
├── reviews/          # per-requirement review reports
└── dashboard.html    # gitignored — regenerated wholesale

The board is a database: there is no BOARD.md, no ticket file, no state.yaml and no status directory — an artifact's status is a column, and the "board" is a live view rendered from SQL. Local mode needs no account, token or network; it does need the tursodb binary. Cloud mode is unverified end to end.

There is no journal, so guild.db is not disposable. event rows written by triggers are the record, and they live in the same database as everything else. What git carries is the human-readable residue: config.yaml, docs/, qa/, reviews/ and the repo's own CHANGELOG.md. Back the file up before clearing the board — a DELETE is final.

Open a Claude Code session in your project and say:

check in

The guild will greet you, create the board, and ask what you want to work on.

Upgrading from a v4 guild? The check-in offers to move the old directory board to .guild/v4-archive/ — never deletes, never parses — and there is no history import. .guild/docs/ and .guild/qa/ carry over because they are evergreen. Unfinished v4 work is re-entered through new requirement, reading the archived plan.

Creating Requirements

Requirements are the starting point for all guild work. There are two ways to add them.

During check-in — describe the feature in plain language when the guild asks what you want to work on:

I want to add user authentication with email and password login

Directly at any time using the guild:new-requirement skill:

new requirement

or with inline context:

I need a feature: dark mode toggle for the settings page

guild:new-requirement runs a live interview, then a plan: the project-manager is spawned directly (not queued as a ticket) and interviews you until the requirement is final, then the strategist plans from that finished requirement. By the time the skill returns, the requirement, the implementation plan and every developer / test-planner / reviewer ticket already exist on the board. You do not write the requirement document manually.

Between the two, the guild offers to place the requirement on a project — an existing one, a new project, a new goal and its first project, or left unaffiliated. A project can be marked concurrent (it runs beside its siblings instead of waiting its turn) and can be cut into its own git worktree. Direction is yours to set: no agent creates a goal or a project on its own.

project was called phase through guild v6.1. If you see PHASE-NNN anywhere, that board predates the rename — run the migrations above.

Multiple requirements can be queued. Each is fully planned at the moment it is filed, so the board only ever holds work that is ready to run.

Checking In

Checking in resumes the guild exactly where it left off. Run it at the start of each session:

check in

It opens with the brief — direction, what is in flight and for how long, open bugs, quality areas due for inspection, what moved since last time, and what v_next_task says goes out next:

Guild Brief
===========

Generated: 2026-08-14T02:59:04Z
Since:     2026-08-13 (last check-in)
Next:      TASK-004
Summary:   2 requirement(s), 0 done · 1 in flight · 2 open bounty(ies) · 1 open bug(s) (1 critical)

Direction:
  GOAL-001  [p1 in-progress]  Ship the notifications overhaul  ·  2 of 3 projects runnable
            PROJ-002 Preferences UI (next in sequence)  ·  PROJ-003 Docs refresh (concurrent, worktree)  ·  0/2 req done

In Flight:
  TASK-004  Build the preferences API  ·  developer  ·  REQ-002  ·  just now

Bugs:
  BUG-001  critical  open  Preference toggles silently revert after save  ·  found by qa-tester

A section with nothing in it is not printed — an absent section is good news stated by its absence.

A work-intent phrase ("let's get to work", "start working", "continue") resumes immediately with zero routing questions. An ambiguous one ("check in", "standup", "I'm here") asks once: continue working / new requirement / review completed work / adjust the backlog.

From there the work cycle flows continuously — one-line updates between tickets, pausing only on a failure, an escalation, or a completed requirement:

TASK-003 done: Implement auth service → 2 follow-ups created
TASK-005 done: Implement login endpoint → 1 follow-up created

Development runs in parallel waves by default: the strategist groups dev tickets whose file sets it has verified disjoint, and the orchestrator dispatches each wave concurrently in the shared working tree.

Reading the board without starting work

guild status          # → the guild:brief skill; narrates the same brief, read-only
show me the dashboard # → .guild/dashboard.html: six views, offline, no server

The dashboard is one self-contained file — all CSS and JS inline, deterministic bytes — with Roadmap, Board, Graph, Bugs, Coverage and Activity views.

Skills Reference

Agent-facing skills that specialists pre-load rather than users invoking: guild:qa-mindset, guild:qa-artifacts, the four guild:svelte-* reference skills, and guild:svelte-env-vars-check.

Agents

View Full Guild Documentation

Other Plugins & Useful Skills

Software Plugin (v1.1.1)

A collection of standalone skills for software development workflows.

software:conventional-commit — Generates properly formatted conventional commits by analyzing changes, grouping related modifications, and creating semantic commit messages.

Trigger phrases: "create a conventional commit", "generate conventional commits", "commit with conventional format", "group my changes for commits"

software:daily-handoff — Gathers the last 24 hours of pull requests, review comments, AI coding sessions and uncommitted local work into one plain-language end-of-day handoff document.

Trigger phrases: "daily handoff", "write my handoff", "end of day summary", "EOD report", "what did I work on today"

software:split-plan — Analyzes a master plan file and splits it into 8 phase-specific implementation plans organized by feature tracks (Foundational → Models → Services → Data → Rules → State Management → UI → Tests).

software:categorize-task — Reference guide for classifying development tasks into the 8-phase clean architecture structure.

View Software Plugin Documentation

Research Plugin (v1.0.0)

PhD-level, multi-perspective research inspired by Stanford's STORM method. Instead of the majority view a single prompt returns, it analyzes a topic from five independent expert lenses, maps where they disagree, synthesizes a cited briefing, and red-teams its own output — each phase delegated to a dedicated sub-agent so the heavy reading stays off your main context window.

How it works:

1. Say storm research <topic> to run the full pipeline
2. Phase 1 fans out five persona agents in parallel (practitioner, skeptic, economist, historian, academic)
3. Phase 2 maps their contradictions, agreements, and blind spots
4. Phase 3 synthesizes a cited research briefing with reliability ratings
5. Phase 4 peer-reviews the briefing and assigns a reliability grade
6. All artifacts land in a reusable .storm/{topic-slug}/ workspace (gitignored)

Skills:

Agents:

View Research Plugin Documentation

Storytelling Plugin (v1.0.0)

Turn any idea, pitch, update, or decision into a message that lands — using six proven storytelling frameworks. Most communication fails because it's delivered in the wrong shape: a board wants the answer first, a team wants a reason to care, a customer wants to be the hero. The plugin diagnoses the situation, picks the framework that fits, drafts the message in it, and — when the framing is uncertain — drafts it several ways in parallel so you can pick the version that lands. Inspired by Eric Partaker's rundown of six CEO storytelling frameworks.

How it works:

1. Say help me tell the story of <X> (or invoke a framework skill directly)
2. It captures your message, audience, desired outcome, and medium
3. It recommends the framework that fits the job and drafts the message
4. Panel mode: when the frame is uncertain, it drafts 2–3 frameworks in parallel via the story-drafter agent for side-by-side comparison
5. Sharpening: for high-stakes messages, the story-critic agent scores and tightens the draft

Skills:

Agents:

View Storytelling Plugin Documentation

License

MIT License — see LICENSE for details.

Copyright (c) 2026 Gian Patrick Quintana

Author

Gian Patrick Quintana

• Email: [email protected]
• GitHub: @hirogakatageri