Multi-Agent Plugins

Every plugin splits knowledge from procedure, so the model loads only what a task needs.

• •index - a router: reads the request, names the skills that apply, and stops
• •reference (descriptive) - how this stack is built: architecture, component contract, state, navigation, forms, styling, file placement. Read before writing code
• •workflow (imperative) - numbered procedures with gates: create, evolve, fix, review, branch-and-pr. Read while doing the work
• •knowledge - vendor and API depth, generated from the pipeline's shared skill tree
• •Nothing project-specific is hardcoded: scheme names, token namespaces, module paths and test runners come from config

The flagship: a full SwiftUI engineering lifecycle, native-first.

• •Reference (15): architecture, component (Configuration/View/+Modifiers), data-model (entities, request/response models, mappers), networking (generated OpenAPI client), navigation, overlays, bottom-sheets, forms, state (@Observable), styling/design tokens, previews, file-placement, code-style, build-and-test
• •Workflow (23): create-component (Figma → SwiftUI, 1:1 with the mapped Code Connect component), create-screen (Entity → Repository → Mapper → UseCase → ViewModel → Scene), evolve-component, fix-bug, branch-and-pr, backlog, the figma-* family and the performance-* tour
• •Tools (5): figma-utility, figma-setup, code-connect, component-docs, component-wiki
• •Knowledge (98): SwiftUI, Swift concurrency, SwiftData, Swift Testing, HIG, App Store review, WidgetKit, Live Activities, StoreKit, security, Xcode build analysis

The Compose counterpart, same anatomy and the same workflow names.

• •Reference (8): component, state, navigation, forms, styling, overlays, bottom-sheets, build-and-test, written for Compose (MutableStateFlow + collectAsStateWithLifecycle, type-safe routes, Material 3 tokens)
• •Workflow (4): create-component, evolve-component, fix-bug, branch-and-pr
• •Tools (3): figma-utility, code-connect (Compose), component-docs
• •Knowledge (13): Kotlin coroutines, Compose components/navigation/testing, Room, Retrofit, Gradle KTS, Play Store compliance, performance, security
• •Deliberately name-identical to the iOS toolkit: the pipeline's phases stay platform-agnostic and only the enabled plugin changes

React/TSX engineering lifecycle: create, evolve, fix, review, ship.

• •Reference (6): component architecture, state (hooks + Query), forms (React Hook Form + Zod), styling (design tokens), routing (Next.js / React Router), build-and-test (Vitest + Testing Library + Storybook)
• •Workflow (4): create-component (Figma → React), evolve-component (drift-heal + extend, human-gated), fix-bug, branch-and-pr
• •Tools (3): figma-utility, code-connect (React), component-docs (Storybook)
• •Knowledge (10): Next.js App Router, modern CSS, Tailwind, semantic HTML, web performance, web accessibility, web testing, TypeScript patterns

Service-side lifecycle with the endpoint as the unit of work.

• •Reference (6): api (REST/GraphQL/tRPC selection, response shape, versioning, pagination), auth, data, validation, security, testing
• •Workflow (4): create-endpoint, evolve-endpoint, fix-bug, branch-and-pr
• •Tools (2): openapi-utility (spec as source of truth), api-docs
• •Knowledge (21): FastAPI, Node backend patterns, database patterns, REST API design, API security, Docker, CI/CD, observability, Python patterns
• •Pairs with the mobile toolkits: the same OpenAPI spec that generates the iOS service client is the one this toolkit evolves

The genuinely stack-agnostic set, enabled alongside a stack plugin so each stack toolkit stays lean.

• •council - structured disagreement for go/no-go calls and ambiguous tradeoffs
• •search-first - check what already exists before writing a custom implementation
• •backlog - a registry for deferred-but-approved work, so \"later\" never means lost
• •agent-introspection-debugging - capture, diagnose, contained recovery when an agent loops or keeps failing
• •humanizer - strips AI writing tells from PR bodies, commits and docs
• •skill-creator - the house rules for authoring skills
• •accessibility audit and Firebase, used across mobile, web and backend

The marketplace is a build output, which is why the plugin set never drifts from the pipeline.

• •Vendor/knowledge skills are authored once in the pipeline repo and consumed by the pipeline's own phases
• •The generator rebuilds each plugin's knowledge/, regenerates plugin.json, and bumps a patch version only when that plugin's skill set actually changed
• •Cross-stack skills route to the common toolkit; Apple/Xcode-only skills route to iOS alone
• •Authoring directly in a plugin's knowledge/ is a mistake by construction: the next rebuild overwrites it
• •The pipeline's sync command runs this rebuild and pushes the marketplace in the same pass

Enable a stack's plugin in the repo's .claude/settings.json.

• •No runtime toggle needed; the multi-agent pipeline detects the stack and uses whatever is enabled
• •Consumers pick up new plugin versions through the pipeline's update command, which refreshes the marketplace
• •Collaborators aligned with multi-agent-pipeline / multi-agent-toolkit-mcp so access is bundled, not requested per-repo