Answers from the documentation; checking which model is on duty
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.
build-feature - Prompt - OpenSmartRoute
Promptv1.0.0
build-feature
Implement ONE feature end-to-end through the inner delivery loop — load its EARS spec, write the implementation plan, generate the plain-English QA file before coding, implement test-first, run a…
Prompt file imported from muzzamilhassan/automation (.github/prompts/build-feature.prompt.md). Copyright stays with the author.
Read and follow the 'build-feature' skill at .agents/skills/build-feature/SKILL.md (also at .claude/skills/build-feature/SKILL.md). Apply it to this request, keeping AGENTS.md non-negotiables. The user's request that invoked this prompt contains the arguments.
Use it
Copy one of these into your project. Installing also returns the manifest and these snippets.
Read and follow the 'build-feature' skill at .agents/skills/build-feature/SKILL.md (also at .claude/skills/build-feature/SKILL.md). Apply it to this request, keeping AGENTS.md non-negotiables. The user's request that invoked this prompt contains the arguments.
Manifest
The prompt text and its fill-in variables. Copy it or fetch it by URL from your own code.
{
"prompt": "Read and follow the 'build-feature' skill at .agents/skills/build-feature/SKILL.md (also at .claude/skills/build-feature/SKILL.md). Apply it to this request, keeping AGENTS.md non-negotiables. The user's request that invoked this prompt contains the arguments.",
"variables": [],
"notes": "Implement ONE feature end-to-end through the inner delivery loop — load its EARS spec, write the implementation plan, generate the plain-English QA file before coding, implement test-first, run a two-axis code review, then execute the QA file with real evidence. Use when the user asks to build, add, or implement a feature, or when the new-project pipeline hands off a feature to build.",
"metadata": {
"source": {
"provider": "github-prompts",
"repository": "https://github.com/muzzamilhassan/automation",
"path": ".github/prompts/build-feature.prompt.md",
"ref": "2f0fd3873ed1db745fcd1f62a8a4df84effa59ce",
"url": "https://github.com/muzzamilhassan/automation/blob/2f0fd3873ed1db745fcd1f62a8a4df84effa59ce/.github/prompts/build-feature.prompt.md",
"key": "muzzamilhassan/automation/.github/prompts/build-feature.prompt.md"
}
}
}
Installed into a catalogue, chosen by a router
Install build-feature 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.