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.
coding-rules - Skill - OpenSmartRoute
Skillv1.0.0
coding-rules
– Always prefer simple solutions – Avoid duplication of code whenever possible, which means checking for other areas of the codebase that might already have similar code and functionality – Write code
Instruction file imported from Pall00/midi-keyboard (.cursor/rules/coding-rules.mdc). Copyright stays with the author.
Coding pattern preferences
– Always prefer simple solutions
– Avoid duplication of code whenever possible, which means checking for other areas of the codebase that might already have similar code and functionality
– Write code that takes into account the different environments: dev, test, and prod
– You are careful to only make changes that are requested or you are confident are well understood and related to the change being requested
– When fixing an issue or bug, do not introduce a new pattern or technology without first exhausting all options for the existing implementation. And if you finally do this, make sure to remove the old implementation afterwards so we don’t have duplicate logic.
– Keep the codebase very clean and organized
– Avoid writing scripts in files if possible, especially if the script is likely only to be run once
– Avoid having files over 200–300 lines of code. Refactor at that point.
– Mocking data is only needed for tests, never mock data for dev or prod
– Never add stubbing or fake data patterns to code that affects the dev or prod environments
– Never overwrite my .env file without first asking and confirming
Use it
Copy one of these into your project. Installing also returns the manifest and these snippets.
yaml
targets:
- https://api.opensmartroute.ai/api/v1/registry/pall00-midi-keyboard-coding-rules-rule/manifest # or paste the manifest below
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": "pall00-midi-keyboard-coding-rules-rule",
"kind": "skill",
"name": "coding-rules",
"description": "– Always prefer simple solutions – Avoid duplication of code whenever possible, which means checking for other areas of the codebase that might already have similar code and functionality – Write code that takes into account the different environments: dev, test, and prod – You are careful to only make changes that are requested or you are confident are well understood and related to the change being requested – When fixing an issue or bug, do not introduce a new pattern or technology without first exhausting all options for the existing implementation. And if you finally do this, make sure to remove the old implementation afterwards so we don’t have duplicate logic. – Keep the codebase very clean and organized – Avoid writing scripts in files if possible, especially if the script is likely only to be run once – Avoid having files over 200–300 lines of code. Refactor at that point. – Mocking data is only needed for tests, never mock data for dev or prod – Never add stubbing or fake data patterns to code that ",
"publisher": "Pall00",
"version": "1.0.0",
"capabilities": {
"domains": [
"coding"
],
"tags": [
"skill-md",
"github-cursor-rules"
],
"languages": [
"en"
]
},
"quality_prior": 0.6,
"examples": [
"– Always prefer simple solutions – Avoid duplication of code whenever possible, which means checking for other areas of the codebase that might already have similar code and functionality – Write code that takes into account the different environments: dev, test, and prod – You are careful to only make changes that are requested or you are confident are well understood and related to the change being requested – When fixing an issue or bug, do not introduce a new pattern or technology without first exhausting all options for the existing implementation. And if you finally do this, make sure to remove the old implementation afterwards so we don’t have duplicate logic. – Keep the codebase very clean and organized – Avoid writing scripts in files if possible, especially if the script is likely only to be run once – Avoid having files over 200–300 lines of code. Refactor at that point. – Mocking data is only needed for tests, never mock data for dev or prod – Never add stubbing or fake data patterns to code that "
],
"primary": false,
"metadata": {
"source": {
"provider": "github-cursor-rules",
"repository": "https://github.com/Pall00/midi-keyboard",
"path": ".cursor/rules/coding-rules.mdc",
"ref": "541d32dba4aecbc445311eec2a6f5cc1b95dd78a",
"url": "https://github.com/Pall00/midi-keyboard/blob/541d32dba4aecbc445311eec2a6f5cc1b95dd78a/.cursor/rules/coding-rules.mdc",
"key": "Pall00/midi-keyboard/.cursor/rules/coding-rules.mdc"
}
},
"instructions": "# Coding pattern preferences\n\n– Always prefer simple solutions \n– Avoid duplication of code whenever possible, which means checking for other areas of the codebase that might already have similar code and functionality \n– Write code that takes into account the different environments: dev, test, and prod \n– You are careful to only make changes that are requested or you are confident are well understood and related to the change being requested \n– When fixing an issue or bug, do not introduce a new pattern or technology without first exhausting all options for the existing implementation. An",
"cost": {
"context_tokens": 294
}
}
Fetch it by URL: GET /api/v1/registry/pall00-midi-keyboard-coding-rules-rule/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.