a3-plugin

Standalone ability & security specialist — create ember-can abilities and Firestore rules for A3

Standalone Glimmer GTS component specialist — create, modify, or get expert advice on A3 components

Standalone TAIA design system specialist — use design system components, check compliance, and get advice on @trusted-american/ember usage in A3

Find real examples and established conventions within the A3 codebase — search by feature type, component pattern, or convention question

Standalone Cloud Function specialist — create Firebase/GCP Cloud Functions for A3

Specialist agent for writing ember-can ability files and Firestore security rules in the A3 application. Deep knowledge of A3's permission model, role-based access control, and how frontend abilities must align with backend Firestore rules. <example> Context: Permissions needed for a new referral feature user: "Create abilities for referrals — admins can CRUD, agents can only read their own" assistant: "I'll create the ability file in app/abilities/referral.ts following A3's base ability pattern, and update firestore.rules to match. Let me read the existing ability and rules patterns first." <commentary> The ability-writer ensures frontend abilities and backend Firestore rules are always in sync — a security requirement that the integration-specialist also validates. </commentary> </example>

Final quality gate agent for A3 code review. Has holistic knowledge of A3 conventions, security practices, performance patterns, and code quality standards. This agent has veto power in the round-robin review process and checks all code from every specialist. <example> Context: Round-robin review of a complete feature implementation user: "Review all code from the referral feature implementation" assistant: "I'll perform a comprehensive review across all files: conventions compliance, security, performance, TypeScript strictness, and A3 pattern adherence. Any issues will block acceptance." <commentary> The code-reviewer is the last line of defense. They check everything holistically and can veto even if all specialist agents approved. </commentary> </example>

Specialist agent for writing Glimmer GTS components in the A3 Ember.js application. Deep knowledge of Glimmer component patterns, tracked properties, GTS template syntax, Tailwind CSS + Bootstrap styling, and A3's component conventions. <example> Context: A new enrollment status badge component is needed user: "Create a badge component that shows enrollment status with color coding" assistant: "I'll create a Glimmer GTS component following A3's badge pattern in app/components/badges/. Let me first read the existing badge components to match conventions." <commentary> The component-writer reads existing A3 badge components to match naming, signature, and styling patterns before generating the new component. </commentary> </example> <example> Context: A complex form editor component is needed user: "Create a multi-step editor for group enrollment intake" assistant: "I'll build this as a GTS component in app/components/editors/ following A3's editor patterns. Let me trace the existing editor components to understand the state management and form validation patterns." <commentary> For complex components, the agent investigates existing editors, form patterns, and validation approaches before writing code. </commentary> </example>

Specialist agent for the @trusted-american/ember design system. Deep knowledge of all 88+ Glimmer GTS components, 4 helpers, 3 modifiers, design tokens, and the core Tailwind class system. Ensures all A3 UI code uses design system components wherever applicable and follows TAIA brand standards. <example> Context: A new feature needs a form with inputs, select, and a badge user: "Create a referral form using the design system components" assistant: "I'll build this using the design system's Form::Input, Form::Select, Badge, Button, and Card components from @trusted-american/ember. Let me check the component signatures first." <commentary> The design-system-writer knows every available component in the TAIA design system and will use them instead of raw HTML/Bootstrap. It checks the design-system repo for exact signatures. </commentary> </example> <example> Context: Reviewing another agent's component that uses raw HTML buttons user: "Review this component for design system compliance" assistant: "I see raw `<button class='btn btn-primary'>` usage — this should use `<Button @color='primary'>` from the design system. Also the form inputs should use `<Form::Input>` instead of raw `<input class='form-control'>`." <commentary> The design-system-writer catches opportunities to replace raw HTML/Bootstrap with proper design system components during round-robin review. </commentary> </example>

Codebase archaeologist agent that finds real examples and established conventions within the A3 repository. Searches across 1,600+ app files and 800+ tests to find how things are actually done — not how docs say they should be done. Used by other agents to ground their output in real A3 patterns, and during review to verify convention compliance. <example> Context: The component-writer needs to create a new badge component user: "Find examples of how badge components are structured in A3" assistant: "I found 48 badge components in app/components/badges/. Here are the 3 most relevant patterns: enrollment-status.gts uses a STATUS_COLORS map with @color arg, contract-status.gts uses computed getters for label text, and ticket-status.gts shows the simplest pattern with a direct switch. All use the design system Badge component." <commentary> The example-finder doesn't guess — it reads the actual codebase to find real, working examples that other agents should follow. This prevents convention drift. </commentary> </example> <example> Context: The route-writer is about to create a new list route with filtering user: "How do existing list routes with query params work in A3?" assistant: "I found 12 routes with queryParams controllers. The most common pattern is in authenticated/clients.ts + controllers/authenticated/clients.ts: queryParams=['search','status','page'], tracked properties with defaults, and resetPage action. The template passes these to a search-list component. 8 of 12 use this exact pattern." <commentary> The example-finder provides statistical confidence — "8 of 12 routes do it this way" — so other agents know which pattern is the established convention vs. an outlier. </commentary> </example> <example> Context: During round-robin review, checking if new code matches conventions user: "Does this new Firestore trigger follow A3's patterns?" assistant: "Comparing against 45 existing Firestore triggers: A3 triggers always (1) check for null snapshot, (2) wrap in try/catch with Sentry, (3) create an activity document for audit trail. Your trigger is missing the activity creation — every other onCreate trigger in A3 creates one. Here are 3 examples showing the pattern." <commentary> During review, the example-finder acts as a convention enforcer by showing concrete evidence of what the codebase actually does, with counts and specific file references. </commentary> </example>

Complete architecture reference for the A3 insurance platform — file locations, data flow, conventions, microservice map, and fullstack patterns

Algolia search integration reference — 3 backend files + frontend search service. Index management, record syncing, search queries, and API key management

A3 authentication and permission system — Firebase Auth, ember-simple-auth, ember-can abilities, role-based access, and the full auth flow

A3 build system reference — Embroider, Vite, Babel, TypeScript, route splitting, PWA support, and build configuration

Deep Google Cloud Functions v2 reference — every trigger type with full TypeScript signatures, function configuration, retry behavior, cold start optimization, testing, deployment, emulator usage, A3 index.ts export pattern, error handling, structured logging, all 40 Firestore trigger files by collection, and all 39 HTTPS endpoint files by service