TMCP

TMCP turns scattered agent instructions into task-specific operating packets. The user describes the work in natural language. TMCP infers task identity, compiles the strongest current packet from skills/rules/evidence, recompiles as the work changes, and leaves an audit trail.

Skill names are provenance, not the user interface. Power users can still force a route; the default is natural prompting.

AIOS is optional storage and adapter support. TMCP runs standalone from a repo checkout, copied plugin package, Codex plugin cache, Claude plugin cache, or any MCP host that can launch the bundled Node entrypoint.

See docs/ADAPTIVE_PACKET_RUNTIME.md for the adaptive packet runtime design.

Quickstart

From a TMCP checkout or plugin root:

node scripts/tmcp_launcher.mjs doctor
node scripts/tmcp_launcher.mjs status
node scripts/tmcp_launcher.mjs compose-packet "Improve this agent run" --project-path . --phase start
node scripts/tmcp_launcher.mjs harvest skills --limit 5 --no-write-artifacts
node scripts/tmcp_launcher.mjs recommend skills --candidate-workflows release_readiness --candidate-workflows developer_experience --min-confidence 0.1 --compose --no-write-artifacts

With no arguments, the same launcher starts the MCP stdio server:

node scripts/tmcp_launcher.mjs

Related MCP server: @focus-mcp/cli

Install Layouts

• Skill-only install: copy skills/tmcp into a skills directory. Use the skill for routing and manual packet synthesis unless the host also exposes the bundled launcher.

• Repo checkout: clone the repo and run node scripts/tmcp_launcher.mjs doctor from the checkout root.

• Codex plugin cache: install as a Codex plugin; MCP config launches relative scripts/tmcp_launcher.mjs from the plugin root.

• Shared local runtime: install a verified archive with scripts/tmcp_runtime.mjs so all agent hosts use one pinned active release with offline rollback. See Central runtime.

• AIOS-backed install: set AIOS_ROOT explicitly only when you want optional AIOS storage/adapter behavior.

Claude Desktop users can add the launcher as a local stdio MCP server. See docs/CLAUDE_DESKTOP.md.

Stability Scopes

TMCP labels three independent surfaces:

• Skill packages: tmcp, skill-harvest, workflow-recommendation, release-readiness, and dx-audit are stable routing packages.

• Curated workflow templates: release-readiness and dx-audit are the stable templates in the recommendation catalog.

• MCP tool contracts: doctor, status, explain, compose-packet, and runtime-next are stable. Harvest, evaluation, recommendation, promotion, receipt, and expert-rubric tools remain experimental.

Experimental templates and tools remain shipped and callable. They are labeled experimental in their own outputs and frontmatter so users do not confuse a stable package route with a stable tool contract or curated template.

Experimental workflows include UI rubric, security/privacy, test strategy, adaptive workflow pack, custom rubric generation, routing policy, skill gap analysis, incident postmortem, architecture decision, migration readiness, agent handoff, PR risk, performance readiness, data integrity, public-sector readiness, and repo behavior spec loop.

Tools

Safety

Harvest redacts sensitive-looking values and secret-like provenance paths by default and treats harvested instructions as untrusted text. Default harvest behavior excludes .env*, credentials, tokens, browser profiles, private caches, dependency trees, build outputs, VCS data, and generated TMCP/AIOS artifacts. It does not follow source symlinks unless follow_symlinks is explicitly enabled; enabled links must still resolve inside the selected source root.

On hosts with secure descriptor-relative filesystem operations, harvest artifacts are written as one staged, atomic bundle through a symlink-safe destination. Leave output_dir unset for a unique .tmcp/harvest-* directory, or provide an output directory that is new or empty.

Skill evaluation accepts explicit regular SKILL.md inputs, can confine them to a supplied project root, and redacts source, plan, and evidence values before deriving reports. Its initial plan artifact is a staged bundle in a new or empty directory; evidence scoring may safely add its report to that same directory.

Artifact persistence is deliberately unavailable where those secure filesystem operations do not exist. doctor and status report the capability; use --no-write-artifacts for portable analysis and see Compatibility for the boundary.

tmcp_record_receipt has no non-persisting preview because the receipt is the artifact itself. Run it only when status reports artifact persistence available.

Packet sessions are equally explicit: compose-packet --session-id writes one redacted, project-local latest-packet record only when secure persistence is available. They are for a single serialized run, not a global history or coordination service. See the CLI session contract.

If a harvested source tries to override system, developer, or user instructions, TMCP reports a warning. See SECURITY.md.

Examples

Harvest a local skills folder:

node scripts/tmcp_launcher.mjs harvest ./skills --objective "Harvest reusable skill behavior" --limit 20 --no-write-artifacts

Recommend workflows for a project:

node scripts/tmcp_launcher.mjs recommend . --candidate-workflows release_readiness --candidate-workflows developer_experience --min-confidence 0.1 --compose --no-write-artifacts

Compose a current-task packet and recompile during the run. This session flow requires status to report artifact persistence available:

node scripts/tmcp_launcher.mjs compose-packet \
  "Redesign these pages. Make them visually striking, interactive, modern, motion-rich, and production-ready." \
  --project-path "$PWD" --phase start --session-id redesign-run

node scripts/tmcp_launcher.mjs recompile-packet \
  "Redesign these pages..." \
  --project-path "$PWD" \
  --current-phase runtime \
  --session-id redesign-run \
  --files-changed app/page.tsx

node scripts/tmcp_launcher.mjs record-receipt packet-123 --activated-atoms ui-browser-verification --outcome passed

When session persistence is unavailable, preserve the compatibility path by passing the prior composed JSON inline through --previous-packet instead.

Legacy delta-only runtime routing:

node scripts/tmcp_launcher.mjs compose-packet "Fix the dashboard UI bug" --project-path . --phase start
node scripts/tmcp_launcher.mjs runtime-next "Fix the dashboard UI bug" --current-phase verification --files-changed app/page.tsx --failures "vitest failed"
node scripts/tmcp_launcher.mjs record-receipt packet-123 --activated-atoms ui-browser-verification --outcome passed

Promote reviewed harvest signals into durable routing artifacts:

node scripts/tmcp_launcher.mjs promote-harvest . --selected-workflows release_readiness_workflow --output-dir .tmcp/promoted-harvests/release-readiness

On secure-persistence hosts, promotions also persist a redacted advisory graph under TMCP_HOME/promoted-harvests/<opaque-promotion-key>/, or ~/.tmcp/promoted-harvests/<opaque-promotion-key>/ when TMCP_HOME is unset. Receipts live under TMCP_HOME/receipts/<yyyy-mm>/. Global cache content is advisory and cannot override system, developer, user, or project instructions. Packet composition and runtime routing do not read that cache unless the caller explicitly passes --cache-policy global; their default policy is none.

Run an expert rubric review from evidence snippets:

node scripts/tmcp_launcher.mjs review-plan "Review release portability" \
  --project-path . \
  --evidence-json '[{"dimension_id":"source_grounding","severity":"warning","summary":"Release claims need fresh package evidence.","evidence":["python3 scripts/check_release_package.py ."],"recommended_fix":"Run and cite the release package check before publishing."}]' \
  --no-write-artifacts

More examples live in examples. Developer onboarding and release readiness exercise stable curated templates; skill-harvest and recommendation examples remain available through experimental tool contracts.

Validation

Before release:

python3 -m unittest discover -s tests
python3 scripts/release_package_compile.py .
node --check scripts/tmcp_launcher.mjs
python3 scripts/check_contracts.py .
python3 scripts/check_install.py .
python3 scripts/check_release_package.py . --verify-reproducible

The release package check builds from a clean, reviewed Git revision rather than the working directory. It ships only an explicit allowlist of committed files, rejects unsafe paths, symlinks, and secret-like content, then emits a deterministic RELEASE_MANIFEST.json plus archive digest. The CI release gate repeats the build from the same Git tree and requires both digests to match. It also validates frontmatter, hardcoded local paths, private example names, links, extracted-package install shape, doctor, sample harvest, sample workflow recommendation, sample expert rubric planning, composition/runtime/receipt smoke coverage, and stable/experimental workflow labeling. It is a DOI blocker until existing absolute user paths in release evidence docs are redacted or normalized.

DOI-Ready Research Release

TMCP is prepared as an independent software-methods artifact. See RESEARCH_READY.md and docs/release-notes/v0.3.3-doi.md for the citable artifact boundary, validation path, data-availability policy, and claim limits.

References

• Quickstart

• CLI

• Install and package check

• Distribution

• Central runtime

• Packet stability

• Adaptive packet runtime

• Tier One release rubric