tcx-build

TCX Build

Use this skill only when the original root user prompt places $tcx-build on its first meaningful line. Accept the plain token or a Markdown skill link only when its label and target match this workspace's projected tcx-build/SKILL.md. Ignore leading blank lines and normalized line-ending variants. The concrete non-empty request may share the invocation line or follow it.

Turn Contract

• Treat the marker as current-turn user intent, not filesystem permission.
• Codex's active native permission profile still decides what tools can reach. The marker and hook do not elevate the default trading-research profile. Ordinary user-owned files outside trading/ can be changed in Research and are not Build work. Start controlled trading/, managed lifecycle, or connector work in a new root turn with trading-build selected; canonical DB calls remain separately proof-protected and service-owned.
• Do not wrap $tcx-brain or $tcx-strategy work in this marker. Those skills use separate capability-scoped turns in the normal trading-research profile. If the request is actually Brain or Strategy management, stop and return the corresponding direct first-meaningful-line prompt.
• Do not issue or use a Build grant while Codex is in platform Plan mode. Start a new root turn in trading-build when the requested work must edit files. The grant is bound to the permission mode in which it was issued, so switching profiles does not carry authority forward.
• Use the grant only in the root native Codex turn. Subagents cannot inherit or use it.
• The grant is multi-use within this turn so editing and validation can finish. A follow-up turn that mutates state must invoke $tcx-build first again.
• For recurring Automation, require the saved prompt to start with the marker on every run. File-mutating work also requires trading-build; prefer an isolated worktree or workspace and retain a reviewable diff.
• Keep direct edits and commands workspace-local. Use typed TradingCodex MCP services for connector state. User-installed Codex capabilities remain outside Build ownership.
• Keep local work in the native Build lane: use apply_patch for every edit. Shell access is an intentionally narrow review lane: credential-free public HTTP(S) GET/HEAD, enumerated read-only HTTPS Git retrieval, limited workspace pwd/cat/ls, inert provider-source reads/hash/diff/Git inspection, exact isolated python -I -S -m py_compile, and allowlisted workspace-launcher commands. General interpreters, helper scripts, test runners, build systems, shell composition, and model-authored POST are blocked throughout an active Build turn/profile. The profile permits ordinary workspace writes through admitted edit/service surfaces, the dedicated $TRADINGCODEX_SCRATCH path, and credential-free public HTTP(S) and HTTPS Git retrieval, but denies TradingCodex runtime/DB state, credentials, protected ledgers, local/private destinations, authenticated requests, uploads, network package installation, remote mutation, and global Codex config. Native web_search remains disabled. The native proxy uses full HTTP transport only for the protocol POST required by read-only Git Smart HTTP; model-authored HTTP remains GET/HEAD-only and general POST is blocked. Trusted workspace-launcher lifecycle commands remain allowlisted and proof-gated.