Skillget

tx

mcp
Security Audit
Fail
Health Warn
  • License — License: MIT
  • Description — Repository has a description
  • Active repo — Last push 0 days ago
  • Low visibility — Only 5 GitHub stars
Code Fail
  • execSync — Synchronous shell command execution in .claude/hooks/post-lint-check.sh
  • fs.rmSync — Destructive file system operation in .claude/hooks/post-lint-check.sh
  • process.env — Environment variable access in .claude/hooks/post-lint-check.sh
  • eval() — Dynamic code execution via eval() in .claude/hooks/pre-safety.sh
  • rm -rf — Recursive force deletion command in .claude/hooks/pre-safety.sh
Permissions Pass
  • Permissions — No dangerous permissions requested

No AI report is available for this listing yet.

SUMMARY

Headless agent infrastructure. Memory + Tasks + Orchestration.

README.md

tx

Primitives, not frameworks. Headless, local infrastructure for AI agents.

tx gives you a small set of reusable primitives for task state, docs-first specs, memory, coordination, and observability. You keep the orchestration loop.

Install

# Standalone binary (recommended)
curl -fsSL https://raw.githubusercontent.com/jamesaphoenix/tx/main/install.sh | sh

# Or via npm (requires bun)
npm install -g @jamesaphoenix/tx-cli

Start Small

The recommended first path is:

  1. Task Management
  2. Spec-Driven Development
  3. Memory & Context
  4. Bounded Autonomy
  5. Coordination
  6. Observability

Most users should start with just the first two.

Day 1: Task Management

tx init --codex                  # or: --claude, or plain tx init
tx add "Write auth PRD" --json
tx add "Implement auth flow" --json
tx dep block <implement-task-id> <prd-task-id>
tx ready
tx show <prd-task-id>
tx done <prd-task-id>
tx ready
tx sync export

This proves the basic loop:

  • the queue works
  • dependencies affect readiness
  • completion advances the queue
  • state exports cleanly to .tx/streams

Day 2: Spec-Driven Development

tx doc add prd auth-flow-prd --title "Auth Flow PRD"
tx doc add design auth-flow-design --title "Auth Flow Design"
tx doc link auth-flow-prd auth-flow-design
# add or update tests with [INV-*], _INV_*, @spec, or .tx/spec-tests.yml
tx spec discover
tx spec status --doc auth-flow-design
tx decompose auth-flow-design --dry-run
tx decompose auth-flow-design
vitest run --reporter=json | tx spec batch --from vitest
tx spec complete --doc auth-flow-design --by you

Use the spec primitives like this:

  • tx spec fci: compact machine score for agents and automation
  • tx spec status: human-readable blocker view for one scope
  • tx spec health: repo rollup, not part of the minimum day-1 loop

Human-in-Loop Example

task=$(tx ready --limit 1 --json | jq -r '.[0].id')
codex "Read AGENTS.md. For task $task: run tx show $task, make sure a paired PRD/design doc is linked, then decompose the work into tx subtasks and dependency edges."
echo "Review tx show $task, tx dep tree $task, and the linked PRD/DD docs, then press Enter to continue..."
read
codex "Read AGENTS.md. For task $task: execute the approved ready work from the linked PRD/DD docs and keep tx updated."

The Six Layers

1. Task Management

Core queue and persistence:

  • tx init
  • tx add
  • tx ready
  • tx show
  • tx done
  • tx dep block
  • tx sync

2. Spec-Driven Development

Docs-first intent and closure:

  • tx doc
  • tx decompose
  • tx spec
  • tx decision

3. Memory & Context

Durable knowledge and prompt context:

  • tx memory
  • tx pin

4. Bounded Autonomy

Controls for agents with more freedom:

  • tx auto label
  • tx auto guard
  • tx auto verify
  • tx auto reflect
  • tx auto gate

5. Coordination

Multi-worker and multi-actor primitives:

  • tx claim
  • tx msg send / tx msg inbox
  • tx group-context

6. Observability

Operational visibility once the earlier layers are in place:

  • tx trace
  • tx spec health
  • tx diag stats
  • dashboard

Interfaces

Interface Best For
CLI Shell scripts, human operators, local loops
MCP Server Claude Code, Cursor, IDE integrations
TypeScript SDK Custom Node/Bun agents
REST API Language-agnostic HTTP clients
Dashboard Visual monitoring and management

Optional Later

Watchdog is intentionally not part of the main getting-started path.

Use it only if you need detached, long-running supervision:

tx init --watchdog --watchdog-runtime auto
./scripts/watchdog-launcher.sh start

Runbook:

Why tx

Native Tasks Static Agent Docs tx
Persistence Session-scoped Manual file edits SQLite + git-backed streams
Multi-agent safety Easy collisions Manual coordination Claims, dependencies, messaging
Intent tracking Weak Weak Docs-first specs + decision capture
Knowledge reuse Lost each session Static dump Searchable memory + pins
Orchestration Fixed by tool None You own the loop

Docs

Principle

tx should stay small.

It is not an agent framework, not a hosted memory product, and not a prescribed workflow. It is a local set of primitives you can compose into your own loop.

Reviews (0)

No results found