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
{
"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.