GearGenius FlatRate Pro

View saved version →

---
name: repair-reference
description: "Use when a FlatRate Pro technician requests a grounded repair labor estimate or diagnostic trouble-code reference for a described vehicle and repair."
---

# Repair reference

Provide tool-backed reference information, not an authoritative diagnosis,
manufacturer procedure, safety certification, or automatic job entry. The
user's actual request determines which lookup to run.

1. Identify whether the request is for labor time or a DTC explanation.
   Ask for the repair description or code if missing. Use only vehicle details
   the user supplies; clarify where year, make, model, or trim affects the answer.
2. For labor time, call `estimateJob` with `jobDescription` and optional
   supplied category and `vehicleInfo`. Attribute hours to the returned estimate;
   never invent times or present an estimate as an OEM labor guide.
3. For code reference, call `lookupDtc` with the code and optional supplied
   year/make/model. Distinguish the returned description, possible causes,
   common fixes, and severity from a confirmed root cause.
4. Summarize the actual result and its limitations. A code alone does not prove
   a part failed. Do not recommend replacing a component solely on that basis.
5. Do not improvise dangerous repair procedures, bypass safety systems, or
   fabricate torque specifications or high-voltage instructions. For procedural
   work, refer to the applicable manufacturer service information and qualified
   personnel rather than guessing.
6. If the service fails or returns no result, say so. Do not silently substitute
   a made-up tool result. Authentication must happen through client OAuth;
   never collect credentials, VINs, or unrelated personal data in the lookup.
7. Do not create a job, save a note, or buy parts unless the user separately
   requests a supported action with explicit details.

Examples: "Estimate front pad replacement on a 2018 Civic" activates the labor
lookup; "What does P0301 mean?" activates DTC reference; "Log my work" belongs
to the job-log workflow instead.

Referenced files: 1 — file references are metadata, not package contents.

View saved version →

---
name: structured-job-log
description: "Use when a FlatRate Pro technician wants to find repair jobs, log explicitly described work, update job hours or vehicle details, or change a specific job's status."
---

# Structured job log

Work only with the connected technician's jobs. A request to search or estimate
is not permission to create or update records. Follow the user's explicit scope
and preserve every unspecified field.

1. For retrieval, call `listRecentJobs` with a limit of 1-20 or
   `searchJobsByVehicle` with the user's title/vehicle query and supplied
   `date`, `startDate`, or `endDate`. Summarize actual matches and returned IDs.
2. For creation, collect a job name or description and explicit relevant
   category, hours, vehicle, and date. Ask for missing or ambiguous details.
   Do not infer book time, actual time, or a category from vague repair notes.
3. If the user requests a labor estimate, call `estimateJob` for the repair.
   Present it as an estimate and ask whether to use it before creating a record.
4. Call `createJob` only for an explicitly requested structured entry. Use
   `updateJob` for requested partial edits or `updateJobStatus` for a status
   change (`pending`, `in_progress`, or `complete`). Resolve a real job ID first;
   clarify multiple matches rather than selecting one arbitrarily.
5. Respect client confirmations before writes. Locked or verified jobs cannot
   be changed. Never bypass a denial or alter a different record to work around it.
6. Report only server-confirmed changes, including the actual ID and fields.
   Surface errors and uncertain responses; check existing records before retrying
   a create. Do not claim success from a timeout.
7. Do not perform bulk fuzzy edits, organization verification, billing, or file
   uploads through this workflow. If authentication is needed, direct the user
   to the client's OAuth connection flow. Never ask for credentials in chat.

Examples: "Find my brake jobs from February 10, 2025" is read-only;
"Log the repair I finished" requires clarification; "Mark that job complete"
requires a uniquely identified editable job.

Referenced files: 1 — file references are metadata, not package contents.

View saved version →

---
name: technician-work-reports
description: "Use when a FlatRate Pro technician asks for earnings, performance analytics, efficiency trends, or a completed-work portfolio from their connected account."
---

# Technician work reports

Use this workflow for account-backed reporting, not payroll, tax advice,
certification, or another technician's records. Explicit user requests determine
the report and reporting window; do not call unrelated tools or add writes.

1. Identify the requested report and window. Supported rolling UTC windows are
   `week` (7 days), `month` (30 days), and `year` (365 days), including today.
   Clarify unsupported exact-date requests rather than claiming those filters exist.
2. Call `showEarningsReport`, `showAnalyticsReport`, or `showPortfolioReport`
   with the requested `range`. Call multiple report tools only when requested.
3. Use the returned card when the client supports MCP Apps. Otherwise summarize
   its structured/text result; do not claim a card rendered when it did not.
4. State the period and returned totals. Earnings are estimated gross pay at the
   saved rate, not payroll or take-home pay. Missing timing or rate is unavailable,
   not zero. Do not invent data to fill a chart.
5. Portfolio entries are limited to 20. Recorded verification is not professional
   certification. Do not enrich portfolios with pay, VINs, contacts, or attachments.
6. Report empty results, permission failures, or service errors explicitly.
   Ask the user to reconnect through client OAuth if authentication is required;
   never request passwords, API keys, or connection tokens in conversation.

Examples: "How did I perform this week?" activates analytics; "Show my
completed-work portfolio" activates portfolio. "Upgrade my subscription" does
not activate this reporting workflow.

Referenced files: 1 — file references are metadata, not package contents.

View saved version →

---
name: toolbox-records
description: "Use when a FlatRate Pro technician asks to view their toolbox inventory, record an owned tool, or update a specific tool's condition, status, location, or purchase details."
---

# Toolbox records

Use the connected technician's inventory only. This is recordkeeping, not
purchasing, payments, loan enforcement, or proof that equipment is safe to use.
Explicit user instructions control which records and fields may change.

1. Call `listMyTools` for inventory questions or to identify a requested item.
   Report stored properties only; do not invent serial numbers, condition,
   calibration records, assignments, or checkout history.
2. Before an update, resolve the actual tool ID. Ask the user to distinguish
   duplicate names. Viewing inventory does not authorize a change.
3. For an explicitly requested new record, call `logTool` with the tool name
   and only supplied brand, cost/price, category, purchase date, or notes.
   Do not infer price or execute a purchase.
4. For an explicitly requested edit, call `updateTool` with that ID and only
   the supplied fields. `status` supports `available`, `checked_out`,
   `maintenance`, `retired`; `condition` supports `excellent`, `good`, `fair`,
   `needs_service`. "Needs service" is a condition, not a status.
5. Respect client write confirmations. State the server-confirmed changed
   fields and leave other properties untouched. Surface errors; do not retry
   non-idempotent `logTool` after an uncertain response without checking inventory.
6. Decline other-account inventory requests. If sign-in is needed, direct the
   user to client OAuth, never to credential sharing in chat.

Examples: "What's in my toolbox?" is read-only; "Move my wrench to Bay 2"
requires a unique item; "Buy a new scan tool" is outside this workflow.

Referenced files: 1 — file references are metadata, not package contents.