General skills stay general — no SDLC-project carve-outs in upstream code

Status: open/active

Summary

A change under solutions/ontological/ must help any consuming project, not just this dev repo; SDLC-only carve-outs live under .sdlc/.

Rule

A change to a general SDLC skill (anything under solutions/ontological/) must be useful to any consuming project, not only to the SDLC plugin’s own dev repo. SDLC-only carve-outs (logic that detects SDLC-shaped inputs and only ever fires when the consuming project IS the SDLC plugin) live under .sdlc/ in this repo, not in solutions/ontological/.

Why

A general skill grows a code path gated on detecting SDLC-shaped inputs. The gate only ever fires when the consuming project IS the SDLC plugin. Every downstream consumer carries the code without ever exercising it, and the upstream skill’s prose grows around a use case the distributor’s audience doesn’t share. The post-mortem-spawned task reads like a real improvement to a general skill, but the actual change gates behavior on SDLC plugin paths and only ever executes in the dev repo.

How to apply

Recognition flags — watch for these in a proposed change to an solutions/ontological/ file:

Hard-coded solutions/ontological/skills/, solutions/ontological/lib/model/entities/, or other solutions/ontological/-rooted path patterns inside a general skill’s logic.
“When the task touches a SKILL.md…” or similar shape-detection for SDLC artifacts.
A motivation that reduces to “this would have helped when I was developing the SDLC plugin’s own skills.”

The home for carve-outs — when the friction is real but the fix is shaped like a carve-out, the fix lives under .sdlc/ in this repo (project-local SDLC hook, project-local SDLC extension, project-local SDLC script) — not in solutions/ontological/. Claude-specific helpers still live under .claude/, but SDLC-owned extension/runtime behavior belongs to .sdlc/. The project-local home keeps the upstream skills clean for downstream consumers and gives the dev repo’s own ergonomic fixes a clean place to land.

See T-R4XL-project-local-skill-extension-mechanism for the mechanism that formalizes this routing (hooks vs project-local skill extensions vs both).

Anti-examples

Concrete shapes that trip the antipattern:

task-work scanning ## Files to touch for solutions/ontological/skills/*/SKILL.md matches, to print a runtime/worktree note. The path pattern only matches when developing inside the SDLC plugin’s own repo.
task-define detecting tasks touching solutions/ontological/skills/<X>/SKILL.md and prompting for the skill’s test harness — both hard-coded SDLC shapes.

Notes

Legitimate exception: general improvements surfaced by dogfooding. General improvements that SDLC-on-SDLC dogfooding surfaces are fine — they’re general improvements, not carve-outs. The distinction is whether the fix would help any consuming project with the same workflow (general, keep in solutions/ontological/) versus only the SDLC plugin’s own dev repo (carve-out, move to .sdlc/).

Examples of legitimate general fixes that did NOT trip the antipattern:

task-work-rebase-frontmatter-conflict — fixes a structural rebase conflict that fires on every task-work run, regardless of project.
task-work-preflight-permissions-probe — scans for tool families (npm/node/cargo/uv/pnpm/yarn/pytest); the signal table is general dev tools, not SDLC paths.
pr-check-mock-state-flag — adds a generic --mock-state fixture mechanism; useful in any consumer’s eval harness.

The same rule runs one tier lower. D-VSLI-distributed-work-runner-architecture extends this arrow below the plugin: the work-runner engine and flowline carry no SDLC entity, no corpus schema, and never import the substrate. SDLC is one adapted instance bound in through their ports. Here the carve-out test is “would this help another consuming project”; there it is stricter — “if a change only makes sense for SDLC, it belongs in the adapter, not the engine.” Same failure mode, one tier down, enforced at the import boundary by S-0008-apps-consume-substrate-through-published-surfaces.

← Back to Standards