// Preserve TSZ architecture boundaries while changing checker, solver, binder, emitter, LSP, WASM, or CLI code. Use when planning semantic fixes, moving logic across query boundaries, handling architecture guard failures, ratcheting boundary debt, or reviewing changes for solver-first and no hardcoding rules.
| name | tsz-architecture |
| description | Preserve TSZ architecture boundaries while changing checker, solver, binder, emitter, LSP, WASM, or CLI code. Use when planning semantic fixes, moving logic across query boundaries, handling architecture guard failures, ratcheting boundary debt, or reviewing changes for solver-first and no hardcoding rules. |
Use this skill when a change touches ownership boundaries. The default direction is solver-first semantics, thin checker orchestration, syntax-only parser, symbol/flow-only binder, and output-only emitter.
AGENTS.md and docs/plan/ROADMAP.md before conformance, emit,
performance, architecture, LSP/WASM, Sound Mode, or DRY cleanup work.When <structural condition>, tsc does X; tsz should do X through <owner>.Classify the change as WHAT or WHERE.
WHAT: type semantics belong in solver or a solver-backed boundary.WHERE: diagnostics and source locations belong in checker.Search for an existing boundary before adding one:
rg "struct .*Request|RelationRequest|query_boundaries|TypeData" crates/tsz-checker/src crates/tsz-solver/src
Put new checker-facing semantic facts under a narrow
crates/tsz-checker/src/query_boundaries/ module when the checker needs an
orchestration adapter.
Keep raw solver internals crate-private where possible. Do not introduce new
checker TypeKey matching, direct CompatChecker construction, direct raw
interning, or type-shape recursion when a query can own it.
Add focused unit tests in the owning crate and adjacent cases that vary names and wrappers.
Run targeted architecture checks when the touched area can trip them:
python3 scripts/arch/arch_guard.py
scripts/arch/check-checker-boundaries.sh
python3 scripts/arch/test_arch_guard.py
Use cargo nextest run for Rust tests; avoid cargo test. Wrap long,
multi-worker, or memory-heavy commands with scripts/safe-run.sh.
Architecture-sensitive PRs should include:
AgentName.Drive TSZ GitHub PRs through review, CI, and the merge queue. Use when checking PR status, debugging failing GitHub Actions, deciding whether a PR is WIP, marking draft PRs ready, enqueueing or verifying the queue, landing a PR, or interpreting TSZ CI gates.
Create, refresh, and publish TSZ pull requests with correct coordination state. Use when opening a draft PR, updating a PR body, applying canonical agent labels, changing WIP/draft/ready state, acknowledging review, handing off readiness to a manager agent, or making sure a TSZ PR satisfies AgentName, Project Corpus Impact, verification, and overlap rules.
Prevent TSZ machines and worktrees from running out of disk while preserving useful build caches. Use before creating worktrees, running large builds/tests, diagnosing low disk, cleaning artifacts, deciding whether to delete caches, or recovering space without slowing future Rust/TypeScript builds.
Audit TSZ repo iteration speed and quality. Use when asked to deep-dive repo health, identify avoidable delays, improve agent workflows, reduce CI/PR churn, add guardrails, choose skills to install or create, or turn recurring TSZ process failures into focused tooling/docs PRs.
Use when planning, implementing, reviewing, or interpreting TSZ performance work, including benchmark regressions, cache/residency changes, timing claims, perf counters, hotspot investigations, OOM/timeout/stack-overflow blockers, or optimization PR evidence.
Start TSZ work safely in a crowded multi-agent checkout. Use when beginning a TSZ task, resuming a goal, switching or creating branches/worktrees, recovering from a merged or stale branch, checking disk/cache state, reading lane goals, or deciding whether local dirty files belong to the requested work.