AI Motorcycle Assistant
Developed by Concept Web World - Prakash Meghani
RIDEOPS
AI MOTORCYCLE ASSISTANT
|
┌─────────┴─────────┐
| |
CORE CAPABILITIES OPTIONAL CONNECTORS
| |
| ┌──────┴──────┐
| | |
| RideVerse Future
| (community) integrations
|
Trip planning
Route intelligence
GPX analysis
Fuel planning
Motorcycle intelligence
Motorcycle maintenance
Ride analytics
Ride readiness
Safety preparation
Group ride planning
Rider and motorcycle profile
RideOps plans rides, analyses routes and GPX files, models fuel and range, prepares motorcycles, coordinates group rides, and analyses completed rides.
It works on its own. Every capability above runs with nothing connected. Connectors - including RideVerse - are optional additions that give RideOps reach it cannot compute for itself.
It prepares. It does not publish, send or create anything without an explicit human yes.
Four properties, each enforced in code rather than described in prose:
It will not make things up. Weather, roads, fuel stations, hotels and
manufacturer specifications require a source. With no source, RideOps writes
"Current information could not be verified." and moves the affected value into
an ITEMS TO VERIFY list. The deterministic engines return None for figures
they cannot derive, and no code path substitutes an estimate.
It will not write without approval. Four independent layers guard every
external write: WRITE permission is off by default; the agent that touches
community data has no write tools in its frontmatter; a PreToolUse hook forces
a runtime confirmation; and the server refuses any write without a single-use
approval token plus a digest matching the payload the human was shown. Change
one field after approval and the write aborts.
It will not say a ride is safe. Readiness returns a planning verdict -
READY, READY WITH CONDITIONS, NEEDS ATTENTION or INSUFFICIENT INFORMATION - and a domain with no data is a gap, never a pass.
It does not depend on anything. No connector is required. A core skill never probes one, never mentions one, and cannot be blocked by one. The structural validator fails the build if a core skill so much as references a connector tool.
Install the .plugin file in Cowork, or point Claude Code at this directory.
Verify:
claude plugin validate .claude-plugin/plugin.json --strict
python3 -m pytest tests/ -q # requires pytest
python3 tests/validate_structure.py # zero dependenciesNothing else is required. No account, no API key, no connector.
Working on RideOps itself? Opening this repository as a project - rather
than installing it as a plugin - makes the RideVerse MCP server fail to start
with CONNECTION_CLOSED. That is expected and affects only the connector.
${CLAUDE_PLUGIN_ROOT} in .mcp.json is substituted for plugin-scope MCP
configs; read at project scope the variable stays literal, so the launcher path
never resolves. Nothing is wrong with the server - run it directly to confirm:
printf '%s\n' '{"jsonrpc":"2.0","id":1,"method":"initialize","params":{}}' \
'{"jsonrpc":"2.0","id":2,"method":"tools/list","params":{}}' \
| node bin/py.js servers/rideverse/server.pyRideOps Core is unaffected either way, and installed users never see this.
Full details: docs/installation.md.
| Command | What it does | Needs a connector |
|---|---|---|
/rideops:plan-ride |
Plan a ride or multi-day trip | No |
/rideops:route-analyze |
Analyse a route or GPX file (read-only) | No |
/rideops:ride-itinerary |
Day-by-day itinerary detail | No |
/rideops:ride-weather |
Weather along a route, from a source or not at all | A weather source, for figures |
/rideops:fuel-plan |
Usable range, refuelling points, gaps, buffer | No |
/rideops:group-ride |
Group ride plan; optionally prepares a RideVerse ride | No |
/rideops:ride-ready |
Pre-ride readiness assessment | No |
/rideops:bike-check |
Motorcycle preparation checklist | No |
/rideops:ride-report |
Analyse a completed ride from GPX or CSV | No |
/rideops:rider-profile |
View, create or update profile and garage | No |
/rideops:connectors |
What is connected, and what each one would add | No |
/rideops:ask-rideops |
Natural-language router into all of the above | No |
/rideops:find-ride |
Find authorized community rides | RideVerse |
/rideops:community-summary |
Summarise authorized discussions | RideVerse |
Twelve of fourteen commands need nothing connected. Natural language works too -
ask-rideops routes it and says where it routed.
This is the default, and it is not a degraded mode. Install the plugin, and everything below works immediately with no account and nothing connected:
/rideops:rider-profile "Max 300 km a day, no riding after sunset,
my bike does about 27 km/l on a 17 litre tank"
/rideops:plan-ride "Plan a 3-day trip from Jaipur to Udaipur"
-> daily stages inside both your ceilings, fuel
plan per day, stop spacing, preparation list
/rideops:route-analyze drop in a GPX
-> distance, elevation, segments, remote stretches
/rideops:fuel-plan "Will I make it 474 km on one tank?"
-> usable range, refuelling points, longest gap
/rideops:group-ride "Sunday, Jaipur to Pushkar, six riders"
-> full plan, roles, comms, emergency and
contingency planning, and the announcement text
to send yourself
/rideops:ride-ready "Am I ready for this?"
-> gap analysis across six domains, planning verdict
/rideops:ride-report drop in yesterday's GPX
-> distance, moving time, stops, elevation, and a
privacy-reduced shareable summary
RideOps never mentions RideVerse during any of this. It has no reason to.
What you do not get without a connector: community ride discovery, group and club data, and community discussion summaries. Those are the only three.
Connecting the optional RideVerse connector adds a community layer on top of everything above. Nothing in the core changes.
| Adds | Command |
|---|---|
| Find rides you are authorized to see, ranked against your profile | /rideops:find-ride |
| Read authorized group, club and rider information | /rideops:find-ride, /rideops:group-ride |
| Summarise authorized ride, group and club discussions | /rideops:community-summary |
| Prepare a ride and announcement for approval, then create them | /rideops:group-ride |
The group-ride flow shows the shape of it. Mode A produces the complete plan with no connector. Mode B - only when you ask for the ride to be published - prepares the ride object and the announcement, renders the full proposed-action block, and stops until you approve it explicitly.
RideVerse ships in mock mode: a bundled synthetic community for demonstration and testing. It is not the real RideVerse platform, and RideOps labels it as demonstration data wherever it appears.
Check what you have: /rideops:connectors.
| Component | Count | Where |
|---|---|---|
| Command skills | 14 | skills/<name>/SKILL.md |
| Knowledge skills | 11 | skills/<name>/SKILL.md + references/ |
| Core-tier skills | 20 | never touch a connector |
| Connector-tier skills | 3 | require RideVerse |
| Mixed-tier skills | 2 | work alone, optionally publish |
| Subagents | 6 | agents/*.md |
| Guardrail rules | 10 | rules/*.md |
| Analysis engines | 7 | lib/*.py |
| Connector registry | 1 | connectors/registry.json |
| MCP servers | 1 (optional) | servers/rideverse/ |
| Hooks | 1 | hooks/hooks.json |
| JSON schemas | 6 | schemas/ |
| Unit tests | 284 | tests/ |
| Structure checks | 781 | tests/validate_structure.py |
| Eval cases | 25 | evals/ |
781 is what a clean clone and the distributed bundle both report. The total
tracks the files present - the validator emits one check per JSON file it parses
and one per file it scans for absolute paths - so a working tree carrying
.pytest_cache/ and local harness output reports a few more. OK with no
failures is the result that matters, not the total.
The 11 knowledge skills hold the domain logic. The 14 command skills orchestrate and contain none of it - so a rule lives in exactly one place.
The 10 files in rules/ are the single source of truth for data accuracy,
evidence labelling, safety, privacy, permissions, approval, error handling,
output structure, source availability and the connector model. Every skill loads
them rather than carrying its own copy.
connectors/registry.json declares every connector: how its presence is
detected, what it adds, and exactly how RideOps behaves without it.
lib/connectors.py implements the logic, and imports nothing from any
connector.
| Category | Status | Without it |
|---|---|---|
| RideVerse (community) | Bundled, optional | Community features unavailable; everything else unaffected |
| Weather | Declared, not implemented | No weather figure of any kind; moved to VERIFY |
| Maps / routing | Declared, not implemented | Works from GPX and waypoints; no road names asserted |
| Places | Declared, not implemented | Stop types and spacing only; no business named |
| Calendar | Declared, not implemented | Drafts the event; creates nothing |
| Communication | Declared, not implemented | Drafts the message; sends nothing |
Only RideVerse has an implementation. The rest are declared so they can be added without touching RideOps Core - not faked with placeholder servers.
Details: docs/connector-architecture.md.
Your data lives in your folder, not in the plugin - a plugin directory is replaced on update:
<your working folder>/rideops/
├── profile.json rider profile
├── garage/<slug>.json one file per motorcycle
└── analysis/ generated output only
The optional RideVerse connector is configured by environment. All defaults are safe and nothing needs setting:
| Variable | Default | Meaning |
|---|---|---|
RIDEOPS_RV_MODE |
mock |
mock demonstration data; live needs a real backend; off disables the connector entirely |
RIDEOPS_RV_PERMISSION |
prepare |
read / prepare / write. WRITE is off by default |
RIDEOPS_RV_ACTOR |
RV-R-001 |
Which demo rider is "you" - drives every authorization decision |
RIDEOPS_RV_TOKEN |
(unset) | Auth token. Set to INVALID to exercise the auth-failure path |
Details: docs/configuration.md.
Twelve riders, ten motorcycles, four groups, three clubs, fourteen rides, a ride discussion with real decisions and unanswered questions to find, six join requests, two ride-log CSVs and three GPX files - one clean, one without timestamps, one deliberately truncated.
All of it is synthetic demonstration data. It is not the real RideVerse platform and represents no real person. The motorcycle manufacturers and models are invented, because putting a real manufacturer next to an invented fuel capacity is exactly the fabrication RideOps forbids - and it would be strange to break that rule inside its own fixtures. City names are real, because a city existing is not a claim that needs a source; no fuel station, hotel, restaurant or road condition is named anywhere in the data, because those are.
Regenerate deterministically: python3 demo/generate_demo_data.py.
RideOps has no live data of its own. Weather, traffic, road closures, permits, fuel availability and accommodation availability are external or absent, and "could not be verified" is a first-class output rather than an error.
It is not a mechanic, not a source of legal or permit authority, and not a real-time service. It produces planning information and risk awareness.
The rider is responsible for every riding decision.
RideOps - AI Motorcycle Assistant Developed by Concept Web World - Prakash Meghani MIT licensed. RideVerse is an optional community integration.