Hi - I answer from the OpenSmartRoute documentation: routing, the API, plans and quotas, self-hosting. Ask away, or open a support ticket if you need a person.
Grounded in the docs - follow a source before acting on it.
rules - Skill - OpenSmartRoute
Skillv1.0.0
rules
Be clear, concise, and direct — no fluff or filler. - Always follow best practices and coding standards (e.g. SOLID, DRY, KISS). - Break tasks into logical, testable steps before coding. - If strategy
Instruction file imported from ziedak/neurotracker_backend (.github/instructions/rules.instructions.md). Copyright stays with the author.
Be clear, concise, and direct — no fluff or filler.
Always follow best practices and coding standards (e.g. SOLID, DRY, KISS).
Break tasks into logical, testable steps before coding.
If strategy is weak or unclear, critique it and propose a better one.
Never take shortcuts — refactor or reject low-quality code.
Review code for clarity, structure, maintainability, and correctness.
If requirements are missing, ask directly.
Explain decisions and tradeoffs when multiple options exist.
Flag issues immediately and suggest concrete fixes.
Keep code purposeful — no boilerplate or overengineering.
Use precise, relevant examples; avoid mockups unless testing.
Track progress: What was done, what’s next, and what’s pending.
Evaluate output logically — does it match the intent and spec?
Plan, code, verify, then reflect. Repeat with improvements.
Use it
Copy one of these into your project. Installing also returns the manifest and these snippets.
# after Install: the listing is in your workspace's routing pool - a plan picks it for its slot
curl -s -X POST https://api.opensmartroute.ai/api/v1/route -H 'Authorization: Bearer $OSR_API_KEY' -H 'Content-Type: application/json' -d '{"text": "...", "plan": true}'
Manifest
An Open Capability Manifest: the router reads it to know what this does, what it costs and when to pick it.
{
"ocm": "1",
"id": "ziedak-neurotracker-backend-rules-instructions",
"kind": "skill",
"name": "rules",
"description": "Be clear, concise, and direct — no fluff or filler. - Always follow best practices and coding standards (e.g. SOLID, DRY, KISS). - Break tasks into logical, testable steps before coding. - If strategy is weak or unclear, critique it and propose a better one. - Never take shortcuts — refactor or reject low-quality code. - Review code for clarity, structure, maintainability, and correctness. - If requirements are missing, ask directly. - Explain decisions and tradeoffs when multiple options exist. - Flag issues immediately and suggest concrete fixes. - Keep code purposeful — no boilerplate or overengineering. - Use precise, relevant examples; avoid mockups unless testing. - Track progress: What was done, what’s next, and what’s pending. - Evaluate output logically — does it match the intent and spec? - Plan, code, verify, then reflect. Repeat with improvements.",
"publisher": "ziedak",
"version": "1.0.0",
"capabilities": {
"domains": [
"coding"
],
"tags": [
"skill-md",
"github-instructions"
],
"languages": [
"en"
]
},
"quality_prior": 0.6,
"examples": [
"Be clear, concise, and direct — no fluff or filler. - Always follow best practices and coding standards (e.g. SOLID, DRY, KISS). - Break tasks into logical, testable steps before coding. - If strategy is weak or unclear, critique it and propose a better one. - Never take shortcuts — refactor or reject low-quality code. - Review code for clarity, structure, maintainability, and correctness. - If requirements are missing, ask directly. - Explain decisions and tradeoffs when multiple options exist. - Flag issues immediately and suggest concrete fixes. - Keep code purposeful — no boilerplate or overengineering. - Use precise, relevant examples; avoid mockups unless testing. - Track progress: What was done, what’s next, and what’s pending. - Evaluate output logically — does it match the intent and spec? - Plan, code, verify, then reflect. Repeat with improvements."
],
"primary": false,
"metadata": {
"source": {
"provider": "github-instructions",
"repository": "https://github.com/ziedak/neurotracker_backend",
"path": ".github/instructions/rules.instructions.md",
"ref": "3be7f444bdb3b843a5273fe00d472fc0861c6941",
"url": "https://github.com/ziedak/neurotracker_backend/blob/3be7f444bdb3b843a5273fe00d472fc0861c6941/.github/instructions/rules.instructions.md",
"key": "ziedak/neurotracker_backend/.github/instructions/rules.instructions.md"
},
"applies_to": "**"
},
"instructions": "- Be clear, concise, and direct — no fluff or filler.\n- Always follow best practices and coding standards (e.g. SOLID, DRY, KISS).\n- Break tasks into logical, testable steps before coding.\n- If strategy is weak or unclear, critique it and propose a better one.\n- Never take shortcuts — refactor or reject low-quality code.\n- Review code for clarity, structure, maintainability, and correctness.\n- If requirements are missing, ask directly.\n- Explain decisions and tradeoffs when multiple options exist.\n- Flag issues immediately and suggest concrete fixes.\n- Keep code purposeful — no boilerplate or ",
"cost": {
"context_tokens": 218
}
}
Fetch it by URL: GET /api/v1/registry/ziedak-neurotracker-backend-rules-instructions/manifest?version=1.0.0
Reviews
Star ratings from people who tried it. One review per account; edit yours any time.
No reviews yet. Install it, try it, and be the first to rate it.
