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.

check-standards - Prompt - OpenSmartRoute

Name: check-standards
Author: mmarko88

Prompt file imported from mmarko88/mmarko88.github.io (.windsurf/workflows/check-standards.md). Copyright stays with the author.

Check post against writing standards

Usage: /check-standards <post> where <post> is a path, directory name, or slug under content/post/ (e.g. check-standards data_to_functions).

Steps

Resolve the post. If the argument isn't an existing path, search content/post/ for a directory or index.md/.md file whose name contains the argument (find_by_name with pattern *<arg>* or a directory listing). If ambiguous, ask which post.
Read the standards. Read ARTICLE_WRITING_STANDARDS.md at the repo root — it is the source of truth. Do not rely on memory of it; the doc may have changed.
Read the post fully, including front matter.
Evaluate every standard below against the post. For each, report PASS / WARN / FAIL with the specific line numbers or quoted text as evidence:
- Title: outcome/problem-driven, searchable phrasing, ~50–60 chars, keyword early; numbers/first-person framing when real data exists. description in front matter, 140–160 chars.
- Hook: first 2–4 sentences open a curiosity gap (scenario, consequence, surprising claim, question). FAIL if it opens with a definition, "In this post we will…", or a coverage summary.
- TL;DR: present for posts over ~1000 words.
- Front-loaded payoff: answer/recommendation appears early; structure follows problem → pain → solution → gotchas → takeaway.
- Brevity: no padding paragraphs, paragraphs ≤ ~5 lines; word count in the ~1200–1800 sweet spot (flag <500 or >2000 without justification).
- Specificity: numbers/versions/measurements back every performance or impact claim; flag vague hedging ("can be significant", "may impact") with no data.
- Benchmark claims: if the post cites measurements, it must state JDK/runtime, methodology, and where the code lives.
- Headings: descriptive, not bare concept labels; a scanner reading only headings gets the takeaways.
- One thing to remember: a single key takeaway is called out (blockquote or equivalent).
- Visuals: ≥1 visual beyond the feature image; a visual every few hundred words; evidence/receipts preferred over decoration.
- Chart choice: lightest tool used — Mermaid xychart for simple comparisons, chart block for interactive/multi-series, table/inline text under ~5 numbers (a chart showing what a sentence could = decoration).
- Benchmark visuals: if benchmark results exist, chart for the shape + table for exact numbers; methodology stated (JDK, iterations, code location); all numbers synced across TL;DR, table, chart, takeaways (no contradictions).
- Collapsible code: full implementations and long listings sit in <details> blocks, not inline walls.
- Accessibility: images have alt text; a diagram never carries information that exists nowhere else in the post.
- Code blocks: every fence has a language tag; ≤ ~30 lines each (longer ones split per concept); 2–3 focused blocks preferred over exhaustive dumps; omissions marked.
- Runnable code: no undefined variables, no forward references to types/signatures defined later, consistent arity and idioms across blocks (e.g., same constructor style), no placeholder logic, expected output shown where useful.
- Diagram styling: mermaid code stays semantic — classDef only for meaning (terminal/action nodes), Lucide icons where steps benefit; flag decorative per-diagram restyling that belongs in the global theme.
- Quizzes ({{< quiz >}} shortcode, when present):
  - Placement: distributed at natural section boundaries — after the concept each question tests, never at the top before context; blocked end-dumps FAIL. Max ~3 questions per checkpoint.
  - Count: 5–8 questions total (~60–90 s to complete); WARN >8 or questions that test trivia/single-sentence recall instead of concepts.
  - Distractors: plausible (common misconceptions work best), mutually exclusive, comparable length and grammar; WARN if the correct option is conspicuously the longest or the only qualified one, or if a distractor is arguably correct.
  - Answer position: correct indices spread across positions, not clustered at one index.
  - Feedback: every question has an explanation; framing stays low-stakes (redirects to the content, never punishing).
- Honest trade-offs: limitations section present for technique/pattern posts, quantified or compressed.
- Conclusion: synthesizes with a takeaway + next step; FAIL if it re-lists what the post already said.
- NOCAY: personal voice only where it serves content; no self-important padding.
- Internal links: ≥1 link to a related post, placed where the reader would want it.
- Publishing checklist: cross-check ARTICLE_IDEAS.md checklist items relevant to the post — PNG/JPG shareImage, sourceCode link, toc: true for long posts, series: if applicable, dev.to cover image + all 4 tags when cross-posting.
Output format — terse report, no preamble:

## Standards check: <post title>

- **PASS** [title] — reason
- **WARN** [hook] — what's weak, suggested fix
- **FAIL** [conclusion] — what's missing, suggested fix

Verdict: N/N passed, M warnings, K fails. Top fix: <single highest-impact change>.

Do not edit the post unless the user explicitly asks after seeing the report. The check is read-only.

Install check-standards and it becomes one more candidate the router can pick - when it fits.

A listing is a routing target with a manifest: what it does, which domains it covers, what it costs and who publishes it. Once installed it sits beside your own models and tools, is scored like any other candidate for each request, and shows up in the trace when it wins. Ratings come from workspaces that installed it, one per account.

# Check post against writing standards Usage: `/check-standards <post>` where `<post>` is a path, directory name, or slug under `content/post/` (e.g. `check-standards data_to_functions`). ## Steps 1. **Resolve the post.** If the argument isn't an existing path, search `content/post/` for a directory or `index.md`/`.md` file whose name contains the argument (`find_by_name` with pattern `*<arg>*` or a directory listing). If ambiguous, ask which post. 2. **Read the standards.** Read `ARTICLE_WRITING_STANDARDS.md` at the repo root — it is the source of truth. Do not rely on memory of it; the doc may have changed. 3. **Read the post** fully, including front matter. 4. **Evaluate every standard below** against the post. For each, report PASS / WARN / FAIL with the specific line numbers or quoted text as evidence: - **Title**: outcome/problem-driven, searchable phrasing, ~50–60 chars, keyword early; numbers/first-person framing when real data exists. `description` in front matter, 140–160 chars. - **Hook**: first 2–4 sentences open a curiosity gap (scenario, consequence, surprising claim, question). FAIL if it opens with a definition, "In this post we will…", or a coverage summary. - **TL;DR**: present for posts over ~1000 words. - **Front-loaded payoff**: answer/recommendation appears early; structure follows problem → pain → solution → gotchas → takeaway. - **Brevity**: no padding paragraphs, paragraphs ≤ ~5 lines; word count in the ~1200–1800 sweet spot (flag <500 or >2000 without justification). - **Specificity**: numbers/versions/measurements back every performance or impact claim; flag vague hedging ("can be significant", "may impact") with no data. - **Benchmark claims**: if the post cites measurements, it must state JDK/runtime, methodology, and where the code lives. - **Headings**: descriptive, not bare concept labels; a scanner reading only headings gets the takeaways. - **One thing to remember**: a single key takeaway is called out (blockquote or equivalent). - **Visuals**: ≥1 visual beyond the feature image; a visual every few hundred words; evidence/receipts preferred over decoration. - **Chart choice**: lightest tool used — Mermaid `xychart` for simple comparisons, `chart` block for interactive/multi-series, table/inline text under ~5 numbers (a chart showing what a sentence could = decoration). - **Benchmark visuals**: if benchmark results exist, chart for the shape + table for exact numbers; methodology stated (JDK, iterations, code location); all numbers synced across TL;DR, table, chart, takeaways (no contradictions). - **Collapsible code**: full implementations and long listings sit in `<details>` blocks, not inline walls. - **Accessibility**: images have alt text; a diagram never carries information that exists nowhere else in the post. - **Code blocks**: every fence has a language tag; ≤ ~30 lines each (longer ones split per concept); 2–3 focused blocks preferred over exhaustive dumps; omissions marked. - **Runnable code**: no undefined variables, no forward references to types/signatures defined later, consistent arity and idioms across blocks (e.g., same constructor style), no placeholder logic, expected output shown where useful. - **Diagram styling**: mermaid code stays semantic — `classDef` only for meaning (terminal/action nodes), Lucide icons where steps benefit; flag decorative per-diagram restyling that belongs in the global theme. - **Quizzes** (`{{< quiz >}}` shortcode, when present): - **Placement**: distributed at natural section boundaries — after the concept each question tests, never at the top before context; blocked end-dumps FAIL. Max ~3 questions per checkpoint. - **Count**: 5–8 questions total (~60–90 s to complete); WARN >8 or questions that test trivia/single-sentence recall instead of concepts. - **Distractors**: plausible (common misconceptions work best), mutually exclusive, comparable length and grammar; WARN if the correct option is conspicuously the longest or the only qualified one, or if a distractor is arguably correct. - **Answer position**: `correct` indices spread across positions, not clustered at one index. - **Feedback**: every question has an `explanation`; framing stays low-stakes (redirects to the content, never punishing). - **Honest trade-offs**: limitations section present for technique/pattern posts, quantified or compressed. - **Conclusion**: synthesizes with a takeaway + next step; FAIL if it re-lists what the post already said. - **NOCAY**: personal voice only where it serves content; no self-important padding. - **Internal links**: ≥1 link to a related post, placed where the reader would want it. - **Publishing checklist**: cross-check `ARTICLE_IDEAS.md` checklist items relevant to the post — PNG/JPG shareImage, `sourceCode` link, `toc: true` for long posts, `series:` if applicable, dev.to cover image + all 4 tags when cross-posting. 5. **Output format** — terse report, no preamble: ```markdown ## Standards check: <post title> - **PASS** [title] — reason - **WARN** [hook] — what's weak, suggested fix - **FAIL** [conclusion] — what's missing, suggested fix Verdict: N/N passed, M warnings, K fails. Top fix: <single highest-impact change>. ``` 6. **Do not edit the post** unless the user explicitly asks after seeing the report. The check is read-only.

{ "prompt": "# Check post against writing standards\r\n\r\nUsage: `/check-standards <post>` where `<post>` is a path, directory name, or slug under `content/post/` (e.g. `check-standards data_to_functions`).\r\n\r\n## Steps\r\n\r\n1. **Resolve the post.** If the argument isn't an existing path, search `content/post/` for a directory or `index.md`/`.md` file whose name contains the argument (`find_by_name` with pattern `*<arg>*` or a directory listing). If ambiguous, ask which post.\r\n\r\n2. **Read the standards.** Read `ARTICLE_WRITING_STANDARDS.md` at the repo root — it is the source of truth. Do not rely on memory of it; the doc may have changed.\r\n\r\n3. **Read the post** fully, including front matter.\r\n\r\n4. **Evaluate every standard below** against the post. For each, report PASS / WARN / FAIL with the specific line numbers or quoted text as evidence:\r\n\r\n - **Title**: outcome/problem-driven, searchable phrasing, ~50–60 chars, keyword early; numbers/first-person framing when real data exists. `description` in front matter, 140–160 chars.\r\n - **Hook**: first 2–4 sentences open a curiosity gap (scenario, consequence, surprising claim, question). FAIL if it opens with a definition, \"In this post we will…\", or a coverage summary.\r\n - **TL;DR**: present for posts over ~1000 words.\r\n - **Front-loaded payoff**: answer/recommendation appears early; structure follows problem → pain → solution → gotchas → takeaway.\r\n - **Brevity**: no padding paragraphs, paragraphs ≤ ~5 lines; word count in the ~1200–1800 sweet spot (flag <500 or >2000 without justification).\r\n - **Specificity**: numbers/versions/measurements back every performance or impact claim; flag vague hedging (\"can be significant\", \"may impact\") with no data.\r\n - **Benchmark claims**: if the post cites measurements, it must state JDK/runtime, methodology, and where the code lives.\r\n - **Headings**: descriptive, not bare concept labels; a scanner reading only headings gets the takeaways.\r\n - **One thing to remember**: a single key takeaway is called out (blockquote or equivalent).\r\n - **Visuals**: ≥1 visual beyond the feature image; a visual every few hundred words; evidence/receipts preferred over decoration.\r\n - **Chart choice**: lightest tool used — Mermaid `xychart` for simple comparisons, `chart` block for interactive/multi-series, table/inline text under ~5 numbers (a chart showing what a sentence could = decoration).\r\n - **Benchmark visuals**: if benchmark results exist, chart for the shape + table for exact numbers; methodology stated (JDK, iterations, code location); all numbers synced across TL;DR, table, chart, takeaways (no contradictions).\r\n - **Collapsible code**: full implementations and long listings sit in `<details>` blocks, not inline walls.\r\n - **Accessibility**: images have alt text; a diagram never carries information that exists nowhere else in the post.\r\n - **Code blocks**: every fence has a language tag; ≤ ~30 lines each (longer ones split per concept); 2–3 focused blocks preferred over exhaustive dumps; omissions marked.\r\n - **Runnable code**: no undefined variables, no forward references to types/signatures defined later, consistent arity and idioms across blocks (e.g., same constructor style), no placeholder logic, expected output shown where useful.\r\n - **Diagram styling**: mermaid code stays semantic — `classDef` only for meaning (terminal/action nodes), Lucide icons where steps benefit; flag decorative per-diagram restyling that belongs in the global theme.\r\n - **Quizzes** (`{{< quiz >}}` shortcode, when present):\r\n - **Placement**: distributed at natural section boundaries — after the concept each question tests, never at the top before context; blocked end-dumps FAIL. Max ~3 questions per checkpoint.\r\n - **Count**: 5–8 questions total (~60–90 s to complete); WARN >8 or questions that test trivia/single-sentence recall instead of concepts.\r\n - **Distractors**: plausible (common misconceptions work best), mutually exclusive, comparable length and grammar; WARN if the correct option is conspicuously the longest or the only qualified one, or if a distractor is arguably correct.\r\n - **Answer position**: `correct` indices spread across positions, not clustered at one index.\r\n - **Feedback**: every question has an `explanation`; framing stays low-stakes (redirects to the content, never punishing).\r\n - **Honest trade-offs**: limitations section present for technique/pattern posts, quantified or compressed.\r\n - **Conclusion**: synthesizes with a takeaway + next step; FAIL if it re-lists what the post already said.\r\n - **NOCAY**: personal voice only where it serves content; no self-important padding.\r\n - **Internal links**: ≥1 link to a related post, placed where the reader would want it.\r\n - **Publishing checklist**: cross-check `ARTICLE_IDEAS.md` checklist items relevant to the post — PNG/JPG shareImage, `sourceCode` link, `toc: true` for long posts, `series:` if applicable, dev.to cover image + all 4 tags when cross-posting.\r\n\r\n5. **Output format** — terse report, no preamble:\r\n\r\n```markdown\r\n## Standards check: <post title>\r\n\r\n- **PASS** [title] — reason\r\n- **WARN** [hook] — what's weak, suggested fix\r\n- **FAIL** [conclusion] — what's missing, suggested fix\r\n\r\nVerdict: N/N passed, M warnings, K fails. Top fix: <single highest-impact change>.\r\n```\r\n\r\n6. **Do not edit the post** unless the user explicitly asks after seeing the report. The check is read-only.", "variables": [], "notes": "Check a blog post against ARTICLE_WRITING_STANDARDS.md", "metadata": { "source": { "provider": "github-windsurf-workflows", "repository": "https://github.com/mmarko88/mmarko88.github.io", "path": ".windsurf/workflows/check-standards.md", "ref": "b5193c0eb497a892eecae9c1fdf668e8129dff16", "url": "https://github.com/mmarko88/mmarko88.github.io/blob/b5193c0eb497a892eecae9c1fdf668e8129dff16/.windsurf/workflows/check-standards.md", "key": "mmarko88/mmarko88.github.io/.windsurf/workflows/check-standards.md" } } }

check-standards

About

Check post against writing standards

Steps

Install check-standards and it becomes one more candidate the router can pick - when it fits.

What it costs to adopt - in engineering time.

One base URL

No vendor lock-in

Failover built in

Use it

Manifest

Reviews