Name: architecture-adr
Author: ynotfins

Imported from ynotfins/AI-Project-Manager (tri-project-chatgpt-handoff/open--claw/open-claw/AI_Employee_knowledgebase/AI_employees/code-reviewer/skills/architecture-adr/SKILL.md). Install upstream with npx skills add ynotfins/AI-Project-Manager --skill architecture-adr. Copyright stays with the author.

Architecture ADR

Status: READY

Purpose

Make architectural choices explicit, reversible where possible, and easy for future contributors to understand.

Requirements

State the problem, options, decision, and consequences.
Call out what gets easier and what gets harder.
Document rollback or migration paths for risky changes.
Keep boundaries explicit across ui, domain, data, and utils.

When To Use

New subsystem or service boundary.
New runtime or framework integration.
Non-trivial data model or API contract change.
Any decision likely to affect the next quarter of work.

# 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}'

Install architecture-adr 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": "ynotfins-ai-project-manager-architecture-adr", "kind": "skill", "name": "architecture-adr", "description": "Architecture decision record workflow for design choices, trade-offs, rollback paths, and modular boundaries.", "publisher": "ynotfins", "version": "1.0.0", "capabilities": { "domains": [ "general" ], "tags": [ "skill-md", "github" ], "languages": [ "en" ] }, "quality_prior": 0.6, "examples": [ "Architecture decision record workflow for design choices, trade-offs, rollback paths, and modular boundaries." ], "primary": false, "metadata": { "source": { "provider": "github", "repository": "https://github.com/ynotfins/AI-Project-Manager", "path": "tri-project-chatgpt-handoff/open--claw/open-claw/AI_Employee_knowledgebase/AI_employees/code-reviewer/skills/architecture-adr/SKILL.md", "ref": "43fdc29377046d830755c5ed1d55c01ce73474a7", "url": "https://github.com/ynotfins/AI-Project-Manager/blob/43fdc29377046d830755c5ed1d55c01ce73474a7/tri-project-chatgpt-handoff/open--claw/open-claw/AI_Employee_knowledgebase/AI_employees/code-reviewer/skills/architecture-adr/SKILL.md", "key": "ynotfins/AI-Project-Manager/tri-project-chatgpt-handoff/open--claw/open-claw/AI_Employee_knowledgebase/AI_employees/code-reviewer/skills/architecture-adr/SKILL.md" } }, "instructions": "# Architecture ADR\n\n## Status: READY\n\n## Purpose\nMake architectural choices explicit, reversible where possible, and easy for future contributors to understand.\n\n## Requirements\n- State the problem, options, decision, and consequences.\n- Call out what gets easier and what gets harder.\n- Document rollback or migration paths for risky changes.\n- Keep boundaries explicit across ui, domain, data, and utils.\n\n## When To Use\n- New subsystem or service boundary.\n- New runtime or framework integration.\n- Non-trivial data model or API contract change.\n- Any decision likely to affect the next quarter of", "cost": { "context_tokens": 151 } }

architecture-adr

About