Thalarch Router

Thalarch Router

Use thalarch-skill-intelligence before loading heavy instructions.

Decision

1. Inspect the skill inventory exposed by the current host session.
2. Shortlist skills by description without opening every full SKILL.md.
3. Identify the task's primary goal/failure type.
4. Detect the actual language/runtime/toolchain/framework from repository evidence.
5. Estimate risk: low / medium / high.
6. Identify evidence needed for completion.
7. Decide whether stale/large context requires thalarch-context.
8. Decide whether relevant prior project/general experience should be retrieved with thalarch-memory.
9. Decide whether version-sensitive external facts require thalarch-source-grounding.
10. Decide whether a working high-blast-radius subsystem needs thalarch-no-regression before mutation.
11. Decide whether a non-trivial D2+ decision needs an in-flight thalarch-doubt challenge.
12. Decide whether an independent teacher/judge loop adds real information.
13. Select the smallest compatible process + language + domain + platform stack.
14. Prefer project-local and current official platform/vendor skills when they are more specific than a generic Thalarch or community skill.
15. Remove redundant or conflicting skills instead of stacking everything.
16. Re-run selection after preflight when new stack/version/root-cause evidence changes the route.
17. For image inputs/outputs, classify inspect/generate/edit/vector/capture/compare/annotate/optimize.

Core process routing

• small safe edit → thalarch-code-craft + lightweight review;
• isolated bug/regression → thalarch-debug + language overlay + thalarch-test + review;
• working subsystem + risky targeted improvement → thalarch-no-regression + relevant domain/language skills + targeted test/review;
• broken feature/module with several dependent surfaces → bounded scope/trace/diagnose workflow using codebase intelligence + debug + relevant language/domain skills;
• feature → thalarch-spec + language overlay + thalarch-test + review;
• architecture/system design → thalarch-spec + thalarch-codebase-intel + thalarch-architecture + relevant language/domain + deep review;
• behavior-preserving refactor → thalarch-refactor + language overlay + test + review;
• performance → thalarch-performance + language overlay + performance review;
• API/service boundary → language overlay + thalarch-api + security/data skills as relevant;
• database/ORM/migration → language overlay + thalarch-data-sql + test/review;
• dependency/toolchain change → thalarch-dependency + affected language/domain + compatibility verification;
• production service/job/queue/external integration telemetry → thalarch-observability + relevant language/security/performance skills;
• security → thalarch-security + relevant language/domain + review council;
• CI → thalarch-ci + language/toolchain overlay + security when relevant;
• Git/publication → thalarch-git + review + remote-state verification.

thalarch-code-craft is the default universal coding overlay for meaningful mutation/review unless a stronger project-specific coding skill already covers the same concern without losing Thalarch's scope and verification invariants.

Cognitive routing

Do not load cognitive skills mechanically on every task.

• relevant verified prior experience may change the first hypothesis → thalarch-memory;
• repeatedly revisited repository with an authorized durable local knowledge sink → thalarch-project-brain + thalarch-memory;
• verified non-trivial task produced a reusable lesson → thalarch-compound + thalarch-experience;
• prompt/skill/router/agent behavior is being tuned against a stable evaluator → thalarch-teacher + thalarch-autoresearch;
• high-value implementation benefits from independent artifact feedback before final verification → thalarch-teacher, but reuse an existing independent reviewer/verifier when it already covers the need.

Memory retrieval happens before broad rediscovery only when relevance is plausible. Retrieved memory remains MEMORY trust until current evidence revalidates load-bearing claims.

Durable storage is never implied by retrieval. Persist project/general memory only through an authorized sink and the thalarch-memory evidence/privacy/generalization gates.

A generic Thalarch rule must not self-modify from one successful task. Use frozen evaluation, holdout/counterexamples, thalarch-autoresearch, and independent teacher/verifier evidence before promoting general behavior.

Epistemic process overlays

These are not loaded mechanically on every task.

Context hygiene

Add thalarch-context when:

• the repository/task area is unfamiliar;
• a large amount of source/log/docs/memory would otherwise enter the main context;
• the task switches modules/features;
• a long session/compaction risks stale assumptions;
• outputs start ignoring current project conventions or referencing unsupported facts.

Source grounding

Add thalarch-source-grounding when a load-bearing decision depends on:

• framework/library/runtime version behavior;
• exact external API/signature/configuration;
• deprecation/migration guidance;
• browser/platform compatibility;
• current official vendor recommendations.

Pure local logic does not need documentation ceremony merely because a dependency exists nearby.

No-regression contract

Add thalarch-no-regression when the target subsystem currently works and the task risks breaking adjacent behavior, especially cache, playback, persistence, sync, migration, concurrency, retries, networking, or stateful UI.

Use it to separate the suspected problem from must-preserve behavior and to force AUDIT ONLY when the suspected defect is still UNKNOWN/weak inference. A similar fix from another repository is a research lead, not proof of a local bug.

In-flight doubt

Add thalarch-doubt for D2+ decisions when at least one is true:

• branching/state semantics change materially;
• a service/module/data boundary changes;
• correctness relies on concurrency/idempotency/ordering/lifecycle/ownership;
• the codebase is unfamiliar and a mistaken premise would propagate;
• the decision is difficult to reverse or high-blast-radius;
• the leading answer is confident but not strongly disconfirmed.

A good failing regression/invariant test can serve as executable disconfirmation for the specific behavioral claim. Do not spawn reviewers for mechanical edits.

Language detection and routing

Use source files plus build manifests. Do not infer from repository name alone.

• Java (.java, Maven/Gradle JVM Java source) → thalarch-java;
• Kotlin (.kt, .kts, Kotlin Gradle plugins) → thalarch-kotlin;
• Python (.py, pyproject.toml, Python package metadata) → thalarch-python;
• TypeScript/JavaScript (.ts, .tsx, .js, .jsx, package scripts) → thalarch-typescript;
• Go (.go, go.mod) → thalarch-go;
• Rust (.rs, Cargo.toml) → thalarch-rust.

When the current host exposes a matching language specialist/subagent, use it for substantial language-specific implementation or review. If that named specialist is unavailable, use the canonical language skill in the strongest compatible host-native context instead of inventing an agent name.

If an installed project-local or official language/framework skill is more specific, use it with or instead of the generic language overlay as judged by thalarch-skill-intelligence.

For mixed-language changes, choose the minimum set that covers the changed boundary. Use separate specialists for independent implementation surfaces and an explicit integration stage for the shared contract.

If no dedicated language skill exists, use thalarch-code-craft, project-native conventions, and current primary documentation for version-sensitive APIs.

JVM specialization

Add only when evidence proves the surface:

• Java/Kotlin shared-state, threads, executors, futures, virtual threads, proxy async, locks or thread-safety → thalarch-jvm-concurrency plus the language skill;
• Kotlin + JPA/Hibernate/Spring Data entity/repository/fetch/transaction work → thalarch-kotlin-jpa, while preferring an available official Kotlin JPA skill for exact facts;
• Java → Kotlin or Kotlin/tooling conversion where semantic compatibility matters → thalarch-kotlin-migration, plus the most specific installed official Kotlin migration skill;
• ordinary Java/JVM JPA work → language skill + thalarch-data-sql, and an installed focused JPA skill when it adds current framework-specific evidence;
• major JDK/framework migration → thalarch-dependency + thalarch-java + thalarch-source-grounding and a focused installed migration skill when compatible.

Do not activate every JVM skill for every JVM repository.

Platform routing

When installed and relevant, automatically consider current official/vendor platform skills exposed by the host — for example Kotlin/JetBrains tooling, Android, browser/Chrome tooling, Firebase, Modern Web, cloud/vendor SDKs, or other curated integrations. Do not require the user to remember their names.

Platform skills supply current platform expertise; Thalarch supplies scope, causal debugging, source grounding, review, evidence, memory discipline, and cold verification.

Android routing

Kotlin/Java Android work normally combines the language layer with thalarch-android and the smallest specialist stack that matches the proven surface:

• Media3/ExoPlayer/session/service/Android Auto/queue/cache/preload/recovery/audio processors → thalarch-media3;
• Compose product UI/redesign/settings/media surfaces → thalarch-compose-ui, with thalarch-design-system when substantial visual-system extraction is useful;
• fuzzy automatic provider/catalog/media identity matching → thalarch-entity-matching;
• locale resources/translated UI/RTL/placeholders → thalarch-localization;
• memory/cache/hot-path work → thalarch-performance, and thalarch-no-regression when the current subsystem is working;
• Room pagination/query shape → thalarch-data-sql plus the Android paging playbook;
• deprecated AndroidX/Compose/Media3 APIs → thalarch-source-grounding plus the Android deprecation playbook.

For Android runtime/device behavior require runtime/device evidence appropriate to the claim. For visually consequential Compose work require actual rendered pixels/interaction evidence rather than source-only confidence.

Do not activate every Android specialist for every Android task.

Web / visual routing

• full website, open art direction → design system + thalarch-web-design + best installed frontend design/platform skill + language overlay + browser QA + design review;
• screenshot/mockup/reference matching is central → add thalarch-image-to-code;
• redesign existing product → spec + existing-system audit + UI/web design + best installed redesign skill + browser/device QA + visual review;
• new raster image → thalarch-image + thalarch-imagegen + thalarch-visual-qa;
• precise image edit → thalarch-image + thalarch-imagegen + thalarch-visual-qa;
• inspect/compare image → thalarch-image + thalarch-visual-qa;
• exact logo/icon/diagram → thalarch-image + deterministic vector/code path + thalarch-visual-qa;
• UI with generated artwork → UI/web stack + thalarch-imagegen + runtime QA + visual QA.

Do not force image-first generation when visual reference creation is not actually useful.

Risk signals

Raise risk for auth/security/privacy, shared concurrency, persistence/schema migration, network/protocol parsing, public API/ABI/wire compatibility, build/release/signing/toolchain, broad refactor, user data, hard-to-reproduce runtime behavior, cross-language/service interfaces, unsafe/FFI/native code, unmeasured hot paths, architecture boundary changes, exact brand preservation, “change only X” image edits, production assets with exact text/transparency/dimensions, and durable memory containing sensitive/stale/high-impact project knowledge.

For working high-blast-radius systems, the risk response is not automatically “more refactoring”; it is usually a narrower preservation contract plus stronger evidence.

Output

Return a compact routing decision:

Mode: <...> Languages/stack: <detected evidence> Risk: <...> Skills: <ordered minimal stack> Agents: <only specialists actually available and needed> Memory: <retrieval/persistence decision when relevant> Evidence required: <...> Deferred/rejected: <only close alternatives when useful>