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.
Imported from vamseeachanta/workspace-hub (.claude/skills/workspace-hub/learned/boundary-policy-classification-by-role/SKILL.md). Install upstream with npx skills add vamseeachanta/workspace-hub --skill boundary-policy-classification-by-role. Copyright stays with the author.
Boundary Policy Classification by Role
When defining durable vs transient artifact boundaries within a multi-layer architecture, classify by role not path. Same directory can contain both types (e.g., reports/ has one-shot audits and durable assessments). Ground classification in concrete examples from each layer, validate consistency with parent architecture, and use adversarial review to test for loose language ('it depends') and implementability gaps.
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 slotcurl-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}'
Installed into a catalogue, chosen by a router
Install boundary-policy-classification-by-role 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.
{
"ocm": "1",
"id": "vamseeachanta-workspace-hub-boundary-policy-classificati-7815a3",
"kind": "skill",
"name": "boundary-policy-classification-by-role",
"description": "Classify artifacts as durable vs transient by their functional role rather than directory path, using multi-layer architectural validation",
"publisher": "vamseeachanta",
"version": "1.0.0",
"capabilities": {
"domains": [
"general"
],
"tags": [
"skill-md",
"architecture",
"policy-design",
"classification",
"artifact-management",
"github"
],
"languages": [
"en"
]
},
"quality_prior": 0.6,
"examples": [
"Classify artifacts as durable vs transient by their functional role rather than directory path, using multi-layer architectural validation"
],
"primary": false,
"metadata": {
"source": {
"provider": "github",
"repository": "https://github.com/vamseeachanta/workspace-hub",
"path": ".claude/skills/workspace-hub/learned/boundary-policy-classification-by-role/SKILL.md",
"ref": "74c4da02ef46ff088cfb224348934aac5b43b82a",
"url": "https://github.com/vamseeachanta/workspace-hub/blob/74c4da02ef46ff088cfb224348934aac5b43b82a/.claude/skills/workspace-hub/learned/boundary-policy-classification-by-role/SKILL.md",
"key": "vamseeachanta/workspace-hub/.claude/skills/workspace-hub/learned/boundary-policy-classification-by-role/SKILL.md"
}
},
"instructions": "# Boundary Policy Classification by Role\n\nWhen defining durable vs transient artifact boundaries within a multi-layer architecture, classify by *role* not *path*. Same directory can contain both types (e.g., reports/ has one-shot audits and durable assessments). Ground classification in concrete examples from each layer, validate consistency with parent architecture, and use adversarial review to test for loose language ('it depends') and implementability gaps.",
"cost": {
"context_tokens": 116
}
}
Fetch it by URL: GET /api/v1/registry/vamseeachanta-workspace-hub-boundary-policy-classificati-7815a3/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.
