tricore_skill

Overview

This skill provides the TriCore Architecture: a deterministic, code-first three-layer memory and cognitive framework for low-resource agents and servers. It bundles the memctl engine, a system linter for policy compliance, and refactored cognitive templates for planning, ReAct reasoning, and self-evolution. The design enforces strict memory access patterns and tooling to avoid token bloat and unauthorized file writes.

How this skill works

All state modifications and queries are routed through tools/memctl.py, which exposes commands like capture, work_upsert, kb_append, and lint. Storage is split into three layers (Brief: root MEMORY.md pointers, Living: memory/state/WORKING.md for active tasks, Stable/Volatile: memory/kb and memory/daily for knowledge and logs). A retrieval-first rule requires semantic memory_search for reads; direct file dumps are forbidden. The built-in linter prevents illegal disk-write patterns and invalid cron/automation changes.

When to use it

• When running autonomous agents on low-resource hosts where token and file bloat must be minimized.
• When you need deterministic, auditable memory operations routed through a single engine.
• When enforcing strict policy/lint checks for automated scripts, cron jobs, or skill changes.
• When preparing an agent to perform planning, reasoning, or automated self-modification with safe controls.

Best practices

• Always use python3 tools/memctl.py commands to write or mutate memory; never create ad hoc text files in the root.
• Use memory_search for retrieval-first access to avoid loading large files and preserve tokens.
• Run memctl.py lint on any cron entry or automation script before enabling it in production.
• Migrate legacy MEMORY.md contents by archiving and redistributing facts via kb_append instead of pasting whole documents.
• Enable agent-browser and web tools if you plan to use the self-evolution templates for real external code discovery.

Example use cases

• Bootstrapping a constrained agent that must never exceed token limits and requires strict audit trails of state changes.
• Standardizing task lifecycle tracking for multiple skills using work_upsert to maintain a single living-state file.
• Building a KB-driven troubleshooting playbook by appending discovered facts and playbooks into memory/kb.
• Deploying self-evolution experiments where code changes are permitted only after lint verification and controlled execution.