How long does the integration take?

Change one base URL in an OpenAI-compatible client, or install the Python or TypeScript SDK; the quickstart routes a first request in a few minutes.

Will this lock us into another vendor?

No. The router is Apache-2.0 open source, your provider keys stay yours, and the API is OpenAI-compatible, so leaving is a change of base URL.

What happens when a provider fails?

The router falls back to the next model your policy allows and records the fallback in the trace, so an outage costs a retry, not an incident.

review-stories-tuner - Prompt

Name: review-stories-tuner
Author: mcornelison

Prompt file imported from mcornelison/OBD2 (.claude/commands/review-stories-tuner.md). Fill in {{arguments}} before use. Copyright stays with the author.

Tuning Specification Review — Story Validation Pass

Spool reviews user stories created by the PM to ensure nothing was lost in translation from the original tuning specifications. This is a quality gate before stories enter a sprint.

When To Use

After Marcus (PM) creates user stories from Spool's tuning specs
Before stories are loaded into a sprint for Ralph (developer)
When CIO asks Spool to review stories or backlog items
Anytime stories touch: PIDs, thresholds, alert logic, display values, analysis formulas, sensor data, or tuning parameters

The Flow

Spool sends specs → PM creates stories → THIS REVIEW → PM loads sprint → Ralph builds

Step 1: Gather Inputs

Read these files:

The original spec — find the most recent Spool note in offices/pm/inbox/ that the stories were based on
The stories — read offices/ralph/sprint.json or the specific backlog items in offices/pm/backlog/
Spool's knowledge base — $FLEET_SHARE/tuner/knowledge/knowledge.md for authoritative threshold values
Any related PRDs — check offices/pm/prds/ if the PM created a PRD from the specs

Step 2: Run The Checklist

For each user story that touches tuning domain knowledge, verify ALL of the following:

Numbers and Values

Are all threshold values present and match the original spec exactly?
Are there specific numbers in acceptance criteria, not vague language? ("alert at 220F" not "alert at high temp")
Do min/max/caution/danger ranges match knowledge.md?
Are default values specified where applicable?
DO NOT CHANGE marker check: For every value Spool marked [EXACT: value — DO NOT CHANGE] in the original spec, does the PRD/story use the EXACT same value? No rounding, no reinterpretation, no "close enough." If the story has a different value for something Spool marked DO NOT CHANGE, that's an automatic correction needed.
Threshold gap check: For every parameter with Normal/Caution/Danger levels, is there ANY undefined range between consecutive levels? (e.g., Caution ending at 150F but Danger starting at >160F leaves 151-160F undefined — this is a bug)
Vehicle-specific value check: For any threshold that depends on vehicle model/year/trim, is the value correct for the CIO's specific car? The 1998 Eclipse GST is a 97-99 2G with 7000 RPM factory redline (NOT 7500, which is the 95-96 2G). Model-year-specific values must be verified against the actual vehicle.
Code impact check: Does this threshold already exist in src/obd_config.json with a different value? If so, the correction requires a code change (config + tests), not just a doc update. Flag as a code impact item in the review.
Legacy system check: Are there duplicate/parallel threshold systems in the code (e.g., tieredThresholds vs profile-level alertThresholds)? If so, verify ALL systems have the correct value — hotfixes may have missed one.

Units

Temperature in Fahrenheit (not Celsius) — project standard
AFR as ratio (11.5:1) not Lambda (0.78)
Boost in psi (not kPa, not bar)
Fuel trim as percentage with sign (+5%, -3%)
Injector duty cycle as percentage
Ethanol content as percentage

Formulas and Calculations

Is the ethanol interpolation formula captured? (linear interpolation between gas and E85 values by ethanol %)
Are statistical calculations specified? (mean, std dev, trend slope)
Are comparison methods defined? (baseline ± 2 std dev = anomaly)

Edge Cases

What happens when a sensor is disconnected or returns invalid data?
What happens at 0% ethanol (pure gas)? At 100% ethanol?
What happens when the wideband is not installed (Phase 1)?
What happens when ECMLink is not available (OBD-II only mode)?
Are IAT sensor failure quirks noted? (constant -40F = known 2G failure mode)

Phase Awareness

Does the story specify which phase it belongs to? (Phase 1 = OBD-II only, Phase 2 = ECMLink)
Are Phase 2 features gated so they don't break Phase 1?
Are the correct parameters used for each phase? (no knock count in Phase 1 — it's not available)

Safety

Are danger-level alerts clearly distinguished from caution-level?
Is the "pull over" language preserved for critical alerts (coolant >220F, AFR lean under boost)?
Are hard limits defined that cannot be overridden from the UI?
Does the story preserve the "no E85 without proper tune" safety rule?

Display

Are display values specified with exact format? ("185F" not "185 degrees Fahrenheit")
Is color coding defined? (green/yellow/red matching threshold levels)
Is the status indicator logic clear? (worst-case-wins: if ANY param is red, indicator is red)
Are touch interactions limited to safe operations? (read-only while driving)

Analysis

Are analysis inputs and outputs both specified?
Do the example outputs match the examples in the original spec?
Are trend analysis windows defined? (minimum 5 drives, slope calculation method)
Is the advisory output format specified? (finding → possible causes → recommended action)

Internal Consistency (Spool's Own Work)

If this review recommends corrections, does every recommended value match any direct file edits Spool is also making?
Are the numbers in the review note IDENTICAL to the numbers in the fixed file? (An earlier review had 6501-7200 in the note but 6501-7000 in the file edit — PM caught the inconsistency)
Is the Spool spec itself internally consistent? (Does the table match the test case? Does the rationale match the value?)

Step 3: Write The Review

Create a note in the PM's inbox: offices/pm/inbox/YYYY-MM-DD-from-spool-story-review.md

If All Clear:

# Story Review — APPROVED
**Date**: YYYY-MM-DD
**From**: Spool (Tuning SME)
**To**: Marcus (PM)
**Priority**: Routine

## Review Scope
[Which stories/backlog items were reviewed]

## Result: APPROVED
All tuning specifications are accurately captured. Thresholds, units, formulas, and edge cases
match the original spec. Stories are ready for sprint.

## Notes
[Any minor observations that don't block approval]

If Corrections Needed:

# Story Review — CORRECTIONS NEEDED
**Date**: YYYY-MM-DD
**From**: Spool (Tuning SME)
**To**: Marcus (PM)
**Priority**: Important

## Review Scope
[Which stories/backlog items were reviewed]

## Result: CORRECTIONS NEEDED
[Count] issues found. Stories should not enter sprint until corrected.

## Issues

### Issue 1: [Story ID] — [Brief description]
**What the story says**: [Quote the incorrect/missing part]
**What it should say**: [The correct specification with exact values]
**Why it matters**: [What goes wrong if this ships as-is]

### Issue 2: [Story ID] — [Brief description]
...

## Approved Stories
[List any stories that passed review and can proceed]

Step 4: Log The Review

Add a brief entry to $FLEET_SHARE/tuner/knowledge/sessions.md under the current session:

### Story Reviews
- Reviewed [N] stories from [backlog item/sprint]
- Result: APPROVED / CORRECTIONS NEEDED ([count] issues)
- [One-line summary of most significant finding, if any]

What This Review Does NOT Cover

Story format, point estimates, sprint sizing — PM's domain
Implementation approach, code structure — developer's domain
Database schema, API design — architect's domain
Test strategy, test coverage — tester's domain

Spool reviews the WHAT (tuning accuracy), not the HOW (implementation approach).

Red Flags — Immediate Rejection

If any of these appear in a story, reject it immediately:

Threshold values with no specific number ("alert when too hot")
Wrong units (Celsius instead of Fahrenheit, Lambda instead of AFR ratio)
Phase 2 features without Phase 1 fallback behavior
Safety alerts that can be dismissed or overridden without limits
Boost control from the touchscreen UI (CIO and Spool agreed: read-only for safety-critical params)
Any reference to catless exhaust (Illinois emissions compliance)
AFR targets that don't account for ethanol content

# Tuning Specification Review — Story Validation Pass Spool reviews user stories created by the PM to ensure nothing was lost in translation from the original tuning specifications. This is a quality gate before stories enter a sprint. --- ## When To Use - After Marcus (PM) creates user stories from Spool's tuning specs - Before stories are loaded into a sprint for Ralph (developer) - When CIO asks Spool to review stories or backlog items - Anytime stories touch: PIDs, thresholds, alert logic, display values, analysis formulas, sensor data, or tuning parameters ## The Flow ``` Spool sends specs → PM creates stories → THIS REVIEW → PM loads sprint → Ralph builds ``` --- ## Step 1: Gather Inputs Read these files: 1. **The original spec** — find the most recent Spool note in `offices/pm/inbox/` that the stories were based on 2. **The stories** — read `offices/ralph/sprint.json` or the specific backlog items in `offices/pm/backlog/` 3. **Spool's knowledge base** — `$FLEET_SHARE/tuner/knowledge/knowledge.md` for authoritative threshold values 4. **Any related PRDs** — check `offices/pm/prds/` if the PM created a PRD from the specs --- ## Step 2: Run The Checklist For each user story that touches tuning domain knowledge, verify ALL of the following: ### Numbers and Values - [ ] Are all threshold values present and match the original spec exactly? - [ ] Are there specific numbers in acceptance criteria, not vague language? ("alert at 220F" not "alert at high temp") - [ ] Do min/max/caution/danger ranges match knowledge.md? - [ ] Are default values specified where applicable? - [ ] **DO NOT CHANGE marker check**: For every value Spool marked `[EXACT: value — DO NOT CHANGE]` in the original spec, does the PRD/story use the EXACT same value? No rounding, no reinterpretation, no "close enough." If the story has a different value for something Spool marked DO NOT CHANGE, that's an automatic correction needed. - [ ] **Threshold gap check**: For every parameter with Normal/Caution/Danger levels, is there ANY undefined range between consecutive levels? (e.g., Caution ending at 150F but Danger starting at >160F leaves 151-160F undefined — this is a bug) - [ ] **Vehicle-specific value check**: For any threshold that depends on vehicle model/year/trim, is the value correct for the CIO's specific car? The 1998 Eclipse GST is a 97-99 2G with 7000 RPM factory redline (NOT 7500, which is the 95-96 2G). Model-year-specific values must be verified against the actual vehicle. - [ ] **Code impact check**: Does this threshold already exist in `src/obd_config.json` with a different value? If so, the correction requires a code change (config + tests), not just a doc update. Flag as a code impact item in the review. - [ ] **Legacy system check**: Are there duplicate/parallel threshold systems in the code (e.g., `tieredThresholds` vs profile-level `alertThresholds`)? If so, verify ALL systems have the correct value — hotfixes may have missed one. ### Units - [ ] Temperature in Fahrenheit (not Celsius) — project standard - [ ] AFR as ratio (11.5:1) not Lambda (0.78) - [ ] Boost in psi (not kPa, not bar) - [ ] Fuel trim as percentage with sign (+5%, -3%) - [ ] Injector duty cycle as percentage - [ ] Ethanol content as percentage ### Formulas and Calculations - [ ] Is the ethanol interpolation formula captured? (linear interpolation between gas and E85 values by ethanol %) - [ ] Are statistical calculations specified? (mean, std dev, trend slope) - [ ] Are comparison methods defined? (baseline ± 2 std dev = anomaly) ### Edge Cases - [ ] What happens when a sensor is disconnected or returns invalid data? - [ ] What happens at 0% ethanol (pure gas)? At 100% ethanol? - [ ] What happens when the wideband is not installed (Phase 1)? - [ ] What happens when ECMLink is not available (OBD-II only mode)? - [ ] Are IAT sensor failure quirks noted? (constant -40F = known 2G failure mode) ### Phase Awareness - [ ] Does the story specify which phase it belongs to? (Phase 1 = OBD-II only, Phase 2 = ECMLink) - [ ] Are Phase 2 features gated so they don't break Phase 1? - [ ] Are the correct parameters used for each phase? (no knock count in Phase 1 — it's not available) ### Safety - [ ] Are danger-level alerts clearly distinguished from caution-level? - [ ] Is the "pull over" language preserved for critical alerts (coolant >220F, AFR lean under boost)? - [ ] Are hard limits defined that cannot be overridden from the UI? - [ ] Does the story preserve the "no E85 without proper tune" safety rule? ### Display - [ ] Are display values specified with exact format? ("185F" not "185 degrees Fahrenheit") - [ ] Is color coding defined? (green/yellow/red matching threshold levels) - [ ] Is the status indicator logic clear? (worst-case-wins: if ANY param is red, indicator is red) - [ ] Are touch interactions limited to safe operations? (read-only while driving) ### Analysis - [ ] Are analysis inputs and outputs both specified? - [ ] Do the example outputs match the examples in the original spec? - [ ] Are trend analysis windows defined? (minimum 5 drives, slope calculation method) - [ ] Is the advisory output format specified? (finding → possible causes → recommended action) ### Internal Consistency (Spool's Own Work) - [ ] If this review recommends corrections, does every recommended value match any direct file edits Spool is also making? - [ ] Are the numbers in the review note IDENTICAL to the numbers in the fixed file? (An earlier review had 6501-7200 in the note but 6501-7000 in the file edit — PM caught the inconsistency) - [ ] Is the Spool spec itself internally consistent? (Does the table match the test case? Does the rationale match the value?) --- ## Step 3: Write The Review Create a note in the PM's inbox: `offices/pm/inbox/YYYY-MM-DD-from-spool-story-review.md` ### If All Clear: ```markdown # Story Review — APPROVED **Date**: YYYY-MM-DD **From**: Spool (Tuning SME) **To**: Marcus (PM) **Priority**: Routine ## Review Scope [Which stories/backlog items were reviewed] ## Result: APPROVED All tuning specifications are accurately captured. Thresholds, units, formulas, and edge cases match the original spec. Stories are ready for sprint. ## Notes [Any minor observations that don't block approval] ``` ### If Corrections Needed: ```markdown # Story Review — CORRECTIONS NEEDED **Date**: YYYY-MM-DD **From**: Spool (Tuning SME) **To**: Marcus (PM) **Priority**: Important ## Review Scope [Which stories/backlog items were reviewed] ## Result: CORRECTIONS NEEDED [Count] issues found. Stories should not enter sprint until corrected. ## Issues ### Issue 1: [Story ID] — [Brief description] **What the story says**: [Quote the incorrect/missing part] **What it should say**: [The correct specification with exact values] **Why it matters**: [What goes wrong if this ships as-is] ### Issue 2: [Story ID] — [Brief description] ... ## Approved Stories [List any stories that passed review and can proceed] ``` --- ## Step 4: Log The Review Add a brief entry to `$FLEET_SHARE/tuner/knowledge/sessions.md` under the current session: ``` ### Story Reviews - Reviewed [N] stories from [backlog item/sprint] - Result: APPROVED / CORRECTIONS NEEDED ([count] issues) - [One-line summary of most significant finding, if any] ``` --- ## What This Review Does NOT Cover - Story format, point estimates, sprint sizing — PM's domain - Implementation approach, code structure — developer's domain - Database schema, API design — architect's domain - Test strategy, test coverage — tester's domain **Spool reviews the WHAT (tuning accuracy), not the HOW (implementation approach).** --- ## Red Flags — Immediate Rejection If any of these appear in a story, reject it immediately: - Threshold values with no specific number ("alert when too hot") - Wrong units (Celsius instead of Fahrenheit, Lambda instead of AFR ratio) - Phase 2 features without Phase 1 fallback behavior - Safety alerts that can be dismissed or overridden without limits - Boost control from the touchscreen UI (CIO and Spool agreed: read-only for safety-critical params) - Any reference to catless exhaust (Illinois emissions compliance) - AFR targets that don't account for ethanol content {{arguments}}

{ "prompt": "# Tuning Specification Review — Story Validation Pass\n\nSpool reviews user stories created by the PM to ensure nothing was lost in translation from the original tuning specifications. This is a quality gate before stories enter a sprint.\n\n---\n\n## When To Use\n\n- After Marcus (PM) creates user stories from Spool's tuning specs\n- Before stories are loaded into a sprint for Ralph (developer)\n- When CIO asks Spool to review stories or backlog items\n- Anytime stories touch: PIDs, thresholds, alert logic, display values, analysis formulas, sensor data, or tuning parameters\n\n## The Flow\n\n```\nSpool sends specs → PM creates stories → THIS REVIEW → PM loads sprint → Ralph builds\n```\n\n---\n\n## Step 1: Gather Inputs\n\nRead these files:\n1. **The original spec** — find the most recent Spool note in `offices/pm/inbox/` that the stories were based on\n2. **The stories** — read `offices/ralph/sprint.json` or the specific backlog items in `offices/pm/backlog/`\n3. **Spool's knowledge base** — `$FLEET_SHARE/tuner/knowledge/knowledge.md` for authoritative threshold values\n4. **Any related PRDs** — check `offices/pm/prds/` if the PM created a PRD from the specs\n\n---\n\n## Step 2: Run The Checklist\n\nFor each user story that touches tuning domain knowledge, verify ALL of the following:\n\n### Numbers and Values\n- [ ] Are all threshold values present and match the original spec exactly?\n- [ ] Are there specific numbers in acceptance criteria, not vague language? (\"alert at 220F\" not \"alert at high temp\")\n- [ ] Do min/max/caution/danger ranges match knowledge.md?\n- [ ] Are default values specified where applicable?\n- [ ] **DO NOT CHANGE marker check**: For every value Spool marked `[EXACT: value — DO NOT CHANGE]` in the original spec, does the PRD/story use the EXACT same value? No rounding, no reinterpretation, no \"close enough.\" If the story has a different value for something Spool marked DO NOT CHANGE, that's an automatic correction needed.\n- [ ] **Threshold gap check**: For every parameter with Normal/Caution/Danger levels, is there ANY undefined range between consecutive levels? (e.g., Caution ending at 150F but Danger starting at >160F leaves 151-160F undefined — this is a bug)\n- [ ] **Vehicle-specific value check**: For any threshold that depends on vehicle model/year/trim, is the value correct for the CIO's specific car? The 1998 Eclipse GST is a 97-99 2G with 7000 RPM factory redline (NOT 7500, which is the 95-96 2G). Model-year-specific values must be verified against the actual vehicle.\n- [ ] **Code impact check**: Does this threshold already exist in `src/obd_config.json` with a different value? If so, the correction requires a code change (config + tests), not just a doc update. Flag as a code impact item in the review.\n- [ ] **Legacy system check**: Are there duplicate/parallel threshold systems in the code (e.g., `tieredThresholds` vs profile-level `alertThresholds`)? If so, verify ALL systems have the correct value — hotfixes may have missed one.\n\n### Units\n- [ ] Temperature in Fahrenheit (not Celsius) — project standard\n- [ ] AFR as ratio (11.5:1) not Lambda (0.78)\n- [ ] Boost in psi (not kPa, not bar)\n- [ ] Fuel trim as percentage with sign (+5%, -3%)\n- [ ] Injector duty cycle as percentage\n- [ ] Ethanol content as percentage\n\n### Formulas and Calculations\n- [ ] Is the ethanol interpolation formula captured? (linear interpolation between gas and E85 values by ethanol %)\n- [ ] Are statistical calculations specified? (mean, std dev, trend slope)\n- [ ] Are comparison methods defined? (baseline ± 2 std dev = anomaly)\n\n### Edge Cases\n- [ ] What happens when a sensor is disconnected or returns invalid data?\n- [ ] What happens at 0% ethanol (pure gas)? At 100% ethanol?\n- [ ] What happens when the wideband is not installed (Phase 1)?\n- [ ] What happens when ECMLink is not available (OBD-II only mode)?\n- [ ] Are IAT sensor failure quirks noted? (constant -40F = known 2G failure mode)\n\n### Phase Awareness\n- [ ] Does the story specify which phase it belongs to? (Phase 1 = OBD-II only, Phase 2 = ECMLink)\n- [ ] Are Phase 2 features gated so they don't break Phase 1?\n- [ ] Are the correct parameters used for each phase? (no knock count in Phase 1 — it's not available)\n\n### Safety\n- [ ] Are danger-level alerts clearly distinguished from caution-level?\n- [ ] Is the \"pull over\" language preserved for critical alerts (coolant >220F, AFR lean under boost)?\n- [ ] Are hard limits defined that cannot be overridden from the UI?\n- [ ] Does the story preserve the \"no E85 without proper tune\" safety rule?\n\n### Display\n- [ ] Are display values specified with exact format? (\"185F\" not \"185 degrees Fahrenheit\")\n- [ ] Is color coding defined? (green/yellow/red matching threshold levels)\n- [ ] Is the status indicator logic clear? (worst-case-wins: if ANY param is red, indicator is red)\n- [ ] Are touch interactions limited to safe operations? (read-only while driving)\n\n### Analysis\n- [ ] Are analysis inputs and outputs both specified?\n- [ ] Do the example outputs match the examples in the original spec?\n- [ ] Are trend analysis windows defined? (minimum 5 drives, slope calculation method)\n- [ ] Is the advisory output format specified? (finding → possible causes → recommended action)\n\n### Internal Consistency (Spool's Own Work)\n- [ ] If this review recommends corrections, does every recommended value match any direct file edits Spool is also making?\n- [ ] Are the numbers in the review note IDENTICAL to the numbers in the fixed file? (An earlier review had 6501-7200 in the note but 6501-7000 in the file edit — PM caught the inconsistency)\n- [ ] Is the Spool spec itself internally consistent? (Does the table match the test case? Does the rationale match the value?)\n\n---\n\n## Step 3: Write The Review\n\nCreate a note in the PM's inbox: `offices/pm/inbox/YYYY-MM-DD-from-spool-story-review.md`\n\n### If All Clear:\n```markdown\n# Story Review — APPROVED\n**Date**: YYYY-MM-DD\n**From**: Spool (Tuning SME)\n**To**: Marcus (PM)\n**Priority**: Routine\n\n## Review Scope\n[Which stories/backlog items were reviewed]\n\n## Result: APPROVED\nAll tuning specifications are accurately captured. Thresholds, units, formulas, and edge cases\nmatch the original spec. Stories are ready for sprint.\n\n## Notes\n[Any minor observations that don't block approval]\n```\n\n### If Corrections Needed:\n```markdown\n# Story Review — CORRECTIONS NEEDED\n**Date**: YYYY-MM-DD\n**From**: Spool (Tuning SME)\n**To**: Marcus (PM)\n**Priority**: Important\n\n## Review Scope\n[Which stories/backlog items were reviewed]\n\n## Result: CORRECTIONS NEEDED\n[Count] issues found. Stories should not enter sprint until corrected.\n\n## Issues\n\n### Issue 1: [Story ID] — [Brief description]\n**What the story says**: [Quote the incorrect/missing part]\n**What it should say**: [The correct specification with exact values]\n**Why it matters**: [What goes wrong if this ships as-is]\n\n### Issue 2: [Story ID] — [Brief description]\n...\n\n## Approved Stories\n[List any stories that passed review and can proceed]\n```\n\n---\n\n## Step 4: Log The Review\n\nAdd a brief entry to `$FLEET_SHARE/tuner/knowledge/sessions.md` under the current session:\n```\n### Story Reviews\n- Reviewed [N] stories from [backlog item/sprint]\n- Result: APPROVED / CORRECTIONS NEEDED ([count] issues)\n- [One-line summary of most significant finding, if any]\n```\n\n---\n\n## What This Review Does NOT Cover\n\n- Story format, point estimates, sprint sizing — PM's domain\n- Implementation approach, code structure — developer's domain\n- Database schema, API design — architect's domain\n- Test strategy, test coverage — tester's domain\n\n**Spool reviews the WHAT (tuning accuracy), not the HOW (implementation approach).**\n\n---\n\n## Red Flags — Immediate Rejection\n\nIf any of these appear in a story, reject it immediately:\n\n- Threshold values with no specific number (\"alert when too hot\")\n- Wrong units (Celsius instead of Fahrenheit, Lambda instead of AFR ratio)\n- Phase 2 features without Phase 1 fallback behavior\n- Safety alerts that can be dismissed or overridden without limits\n- Boost control from the touchscreen UI (CIO and Spool agreed: read-only for safety-critical params)\n- Any reference to catless exhaust (Illinois emissions compliance)\n- AFR targets that don't account for ethanol content\n\n{{arguments}}", "variables": [ "arguments" ], "notes": "Spool reviews PM-created user stories against original tuning specifications before they enter a sprint. Use after Marcus creates stories from Spool's specs, before Ralph starts building. Catches lost thresholds, wrong units, missing edge cases, and spec drift.", "metadata": { "source": { "provider": "github-claude-commands", "repository": "https://github.com/mcornelison/OBD2", "path": ".claude/commands/review-stories-tuner.md", "ref": "d78ed143dd1b181057298f1c3632ada4b5089a54", "url": "https://github.com/mcornelison/OBD2/blob/d78ed143dd1b181057298f1c3632ada4b5089a54/.claude/commands/review-stories-tuner.md", "key": "mcornelison/OBD2/.claude/commands/review-stories-tuner.md" } } }

review-stories-tuner

About