openfront-dealership-custom-dashboard

Plan and build a custom Openfront Dealership operator dashboard from verified source code.

27|5|Updated Aug 10, 2022
One-click install
npx skills add https://github.com/openshiporg/docs --skill openfront-dealership-custom-dashboard-openshiporg
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: openfront-dealership-custom-dashboard
Source: https://github.com/openshiporg/docs/tree/main/public/skills/openfront-dealership-custom-dashboard
Command: npx skills add https://github.com/openshiporg/docs --skill openfront-dealership-custom-dashboard-openshiporg

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Customizing the Openfront Dealership operator dashboard is risky without knowing the actual source architecture, GraphQL contract, and access rules. This Skill guides a structured process—source orientation, user interview, and rigorous code inspection—so dashboard changes are grounded in the real product rather than assumptions borrowed from other verticals like Ecommerce. ## Core Features & Use Cases - Source-Grounded Planning: Explains the features/dashboard shell versus features/platform product layer, then interviews the user about goals, roles, and constraints before any code is written. - Contract Verification: Traces routes, screens, server actions, GraphQL operations, and schema.graphql access rules to produce a capability matrix marking each feature as verified, presentation-only, backend-blocked, or absent. - Two Delivery Modes: Supports adapting the built-in dashboard client or building a separately deployed client with pinned schemas, strict types, and server-side credential handling. - Use Case: A dealership operator wants a redesigned deals and finance intake screen. The Skill inspects the actual Keystone models and mutations, confirms which lifecycle transitions are authorized, and only then proposes UI changes or requests a backend contract. ## Quick Start Ask the assistant to plan a custom Openfront Dealership operator dashboard and point it at your source checkout so it can inspect the routes, screens, and GraphQL contract before proposing changes.

Frequently Asked Questions about openfront-dealership-custom-dashboard

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I customize the Openfront Dealership dashboard?

Start by inspecting the actual source: `features/dashboard` holds the generic Keystone admin shell while `features/platform` contains dealership-specific screens and workflows. Decide whether to adapt the built-in client or deploy a separate one, then verify every operation against `schema.graphql` before coding.

Should I adapt the built-in dashboard or build a separate client?

Adapt the built-in client when you can reuse existing session handling, design tokens, and named server operations safely. Build a separate client when you need independent deployment, but pin the schema, generate strict types, and keep privileged credentials server-side behind a BFF.

Can I reuse Ecommerce GraphQL operations in the Dealership dashboard?

No, not without validation. The Dealership vertical has its own models for vehicles, leads, deals, and service, and Ecommerce roots may not exist or be authorized. Always verify operations against the product's actual `schema.graphql` and access rules.

What must be verified before adding a consequential dashboard action?

Each consequential action needs one bounded server projection or command validating actor, tenant scope, record ownership, state transition, idempotency, and audit evidence. If that contract does not exist, request the backend work and show the feature as unavailable.

Why is a generated GraphQL schema not proof a dashboard flow works?

A schema-valid document only proves syntax, not that access rules permit the operation for a given actor or tenant. The Skill requires tracing actual call sites, access control, and lifecycle authority, and testing wrong-user and wrong-tenant cases against disposable data.