fakoli-crew

Show available fakoli-crew agents and team compositions

Use this agent when you need a thorough code review — line-by-line analysis of code quality, naming, safety, and TypeScript correctness. Reviews as a Staff Engineer at a FAANG company would. Critics report; they don't fix. <example> Context: You've finished implementing a new provider module. user: "Review this code before I merge it." assistant: "I'll use the critic agent to do a full code review of the implementation." </example> <example> Context: You want a senior perspective on a new module. user: "Review this code for TypeScript best practices." assistant: "I'll use the critic agent to evaluate the code against TypeScript best practices." </example> <example> Context: You're checking overall code quality before a release. user: "Do a code review of the fakoli-crew plugin." assistant: "I'll use the critic agent to review the full plugin for code quality issues." </example>

Use this agent when you need design guidance for TypeScript, Python, or Rust — interface design, type system patterns, project structure, error handling, or naming conventions. Auto-detects the project language and applies the matching battle-tested style guide. <example> Context: You're designing a TTS abstraction layer. user: "How should I design an interface for multiple TTS providers?" assistant: "I'll use the guido agent to design a clean, well-typed interface for your TTS providers." </example> <example> Context: You're unsure about your error handling approach. user: "What's the right way to structure errors for this project?" assistant: "I'll use the guido agent to design a proper error hierarchy following idiomatic conventions." </example> <example> Context: You have a package with several modules and need structure advice. user: "How should I structure this package so it's easy to import from?" assistant: "I'll use the guido agent to recommend a clean package structure with proper public API control." </example>

Use this agent when you need documentation that makes people actually want to use a project. Triggers include "improve the README", "rewrite descriptions", "make this appealing", or "better branding". <example> Context: A new plugin was just shipped with a minimal placeholder README. user: Make this README appealing to first-time visitors. assistant: I'll read the plugin source, commands, and existing README, then rewrite it starting with a concrete value proposition, add CI/license badges, and include a copy-paste Quick Start section. </example> <example> Context: The plugin marketplace listing has a generic one-liner description. user: Rewrite the description for the marketplace entry. assistant: Let me read what the plugin actually does — its commands, outputs, and use cases — then write a specific description that tells a developer exactly what problem this solves and what they get, not just "A tool for X". </example> <example> Context: A project has grown and its README still reads like draft notes. user: Better branding for the project. assistant: I'll read all source files, the current README, and any existing docs, then restructure: title with tagline, badges row, 3-line value proposition, install block, features table, commands reference, config section, requirements, and author footer. </example>

Use this agent when you need to maintain or update repository infrastructure. Triggers include "update CLAUDE.md", "fix CI workflows", "update contributor docs", or "sync the registry". <example> Context: Three new agents were added to the plugin and CLAUDE.md still lists only the original five. user: Update CLAUDE.md to reflect the new agents. assistant: I'll read CLAUDE.md, read the new agent files, then update the agent table and any checklists that reference them. I'll also check whether the registry and marketplace.json are in sync. </example> <example> Context: A new required field was added to plugin.json but the contributor checklist doesn't mention it. user: Update contributor docs with the new plugin.json requirement. assistant: I'll read the current contributor docs, the plugin.json schema, and the CI workflow that validates it, then add the new field to the checklist and update the validation step description. </example> <example> Context: The project was restructured and the CI workflow references paths that no longer exist. user: Fix CI workflows after the restructure. assistant: I'll read the current workflow files, map the old paths to new ones using Glob, then update only the paths that actually changed — not a wholesale rewrite. </example>

Use this agent when you need to research an API or service and produce a structured reference document — endpoints, auth, schemas, pricing, rate limits, and code examples. <example> Context: You're adding ElevenLabs TTS support to the plugin. user: "Research the ElevenLabs API for text-to-speech." assistant: "I'll use the scout agent to gather full documentation for the ElevenLabs TTS API." </example> <example> Context: You need to understand what endpoints a service exposes. user: "What endpoints does the OpenAI audio API have?" assistant: "I'll use the scout agent to document the OpenAI audio API endpoints and their schemas." </example> <example> Context: You want structured docs before writing an integration. user: "Document the Google Cloud TTS service before we build the provider." assistant: "I'll use the scout agent to research and write a reference file for the Google Cloud TTS API." </example>

Use this agent when you need comprehensive validation before shipping or merging. Triggers include "validate everything", "run all tests", "verify the changes", or "check if this is ready". <example> Context: Three agents have finished their work on a new plugin release. user: Validate everything before we tag the release. assistant: Running full validation suite now. I will check version sync across plugin.json, package.json, and src/index.ts; run npx vitest with verbose output; verify README counts match marketplace.json; and produce a binary pass/fail scorecard for each check with exact error output for any failures. </example> <example> Context: welder just wired a new abstraction into the codebase. user: Verify the changes are safe. assistant: I'll read all modified files, run the test suite, grep for any remaining references to the old import paths, and check that re-exports are in place. I will report pass/fail for each check. I will not make any changes — that is welder's job. </example> <example> Context: A contributor submitted a PR adding a new agent file. user: Check if this is ready to merge. assistant: Validating the PR: checking frontmatter fields (name, description, model, color, allowed-tools), verifying the agent is listed in CLAUDE.md and marketplace.json, running the validation script, and confirming the README agent table is updated. Producing a scorecard — each line is PASS or FAIL with the exact finding. </example>

Use this agent when you need to fix, validate, or modify Claude Code plugin structure — manifests, hooks, command frontmatter, paths, or version bumps. <example> Context: You added a new hook and the plugin is rejected on load. user: "Fix the plugin structure — the hooks aren't being recognized." assistant: "I'll use the smith agent to inspect and correct the hooks configuration." </example> <example> Context: You're renaming the plugin and need all references updated. user: "Rename this plugin from fakoli-tts to fakoli-crew." assistant: "I'll use the smith agent to rename the plugin and update all manifest references consistently." </example> <example> Context: You want to confirm everything is correct before committing. user: "Validate the plugin before I commit." assistant: "I'll use the smith agent to validate the plugin manifest, hooks, and command frontmatter." </example>

Use this agent when you need to integrate new abstractions into existing code without breaking anything. Triggers include phrases like "refactor to use the new", "integrate with", "wire up", or "connect these modules". <example> Context: guido has created a new ProviderProtocol and smith has updated the manifest. user: Wire up the new ProviderProtocol into the existing plugin loader. assistant: I'll read all files created by the upstream agents first, then refactor the plugin loader to delegate through the new interface while re-exporting the old names. </example> <example> Context: A new caching module was introduced alongside the existing fetch layer. user: Integrate the cache with the existing API client. assistant: Let me read the cache module, the API client, and every import site before touching anything. I'll wrap the client with a thin facade that consults the cache first and re-exports the original class name unchanged. </example> <example> Context: A CLI command was split into two sub-commands by another agent. user: Connect these modules so the old `run` entry-point still works. assistant: I'll read the new sub-command modules, the CLI entry-point, and the config, then add a backward-compatible shim that delegates `run` to the appropriate sub-command and bumps the patch version. </example>

Orchestrate fakoli-crew agents as coordinated teams for complex multi-step projects

Systematic 4-phase debugging for root cause analysis — investigate, analyze patterns, form hypothesis, fix with test