Tzeusy

7-step Conversational Fact Extraction Pipeline — resolve person mentions to entities, apply disambiguation policy, extract and store facts, log interactions, and update domain records. Includes question answering flow and 8 complete examples.

Extract structured relationship data from incoming messages. Teaches the Switchboard's runtime instance how to identify contacts, interactions, life events, dates, facts, sentiments, gifts, and loans — and produce structured JSON that maps directly to Relationship butler tools.

Orchestrate a UX redesign of a Butlers dashboard page (or sub-page set) using /project-direction as the spec+beads engine, with redesign-specific upfront phases for vision capture, asset ingestion, impact analysis, backend-contract derivation, LLM-cost feasibility, and manifesto/identity preservation. Use when handed a redesign bundle under pr/overview/SLUG-redesign/ (for example ingestion, qa, settings, butler-detail) and asked to plan integration into the live Butlers stack. Triggers on "redesign the X page", "plan the Y redesign", "integrate the redesign in pr/overview/...", "what would it take to ship the SLUG redesign", "design language integration for AREA".

Emit a structured investigation_notes.json artifact at terminal state. Load when you are an investigation agent finishing a fix or unfixable verdict. The dispatcher reads this file before worktree teardown and persists it into qa_findings.structured_evidence.investigation_notes.

Guide for discovering, analyzing, and pruning the Butlers test suite. Use when working on test condensation beads (Phase 1 epic bu-rhztl closed; Phase 2 epic bu-hg8rl active), assessing test bloat, identifying pruning targets, or rewriting tests to be contract-driven. Triggers on test reduction, test pruning, test consolidation, or condensation tasks for this project. Also use when a fresh session needs to assess test health, create new condensation beads, or resume in-progress condensation work.

Plan curricula by decomposing topics into prerequisite graphs and ordered learning paths.

Run adaptive pre-teaching probes to estimate current knowledge and seed mastery.

Generate weekly learning progress digests from analytics snapshots and recent trends.

Use when creating or updating a skill or superskill and you need a concrete quality bar for triggers, project grounding, metadata, authorship, routing, context efficiency, and validation.

Use when you need to inspect a target repository and generate a repo-grounded prerequisite curriculum in `curriculum/` that teaches the fundamental technical concepts someone must know before the codebase will make sense or be safe to change.

Use when creating or decomposing Beads issues for a project backlog, including new features, bugs, epics, backlog grooming, or converting vague asks into actionable Beads work in a Beads-backed repository.

Analyze and bootstrap the five-pillar knowledge architecture of a software project: about/heart-and-soul (doctrine), about/legends-and-lore (RFCs/design contracts), about/lay-and-land (topology), about/craft-and-care (execution-quality standards), and openspec/ (capability specs at root). Use when: starting a new project's knowledge structure, auditing documentation health, onboarding, deciding where ideas should be documented, translating ideas into requirements, or mapping system topology. Triggers: "project shape", "bootstrap docs", "where should this go", "what's this project about", "project pillars", "heart and soul", "spec structure", "knowledge architecture", "system map", "topology", "lay of the land", "set up project structure".

Use when a coordinator dispatches a dedicated `pr-review-task` bead for an open GitHub PR that needs review follow-up, thread triage, merge assessment, or retry handling in an isolated worktree.

Use when testing.

Use when synchronizing canonical ai-bootstrap prompt assets into tool-specific folders or enforcing prompt mirror consistency in CI.

Use when working with Bitwarden Secrets Manager CLI (bws) to run commands with injected secrets, manage secret-manager environment variables, or explain bws usage. Essential for wrapping processes with `bws run --project-id ${BWS_TZEHOUSE_ID_PROD or BWS_TZEHOUSE_ID_DEV} -- {command}`.

Use when validating a cross-machine HUD flow where Butler deploys/runs the full Windows app over SSH+SCP (tailnet default host), then publishes configurable test messages to HUD zones via MCP `publish_to_zone`.

Use when running deep performance and throughput investigations for HUD publishing paths (widgets/zones/tiles), including MCP HTTP benchmarks and gRPC bidi stream benchmarks. The canonical gRPC widget publish-load benchmark is `examples/widget_publish_load_harness` (Rust); the Python `grpc_widget_publish_perf.py` script is a secondary alternative.

Use when an already-running Codex, Claude, opencode, or other LLM session should cooperatively project itself into tze_hud, publish status/output, poll HUD-originated input, acknowledge input, detach, or clean up through an external projection daemon. Do not use for terminal capture, PTY attachment, tmux scraping, process hosting, or direct runtime v1 MCP zone publishing.

Archive a completed change in the experimental workflow. Use when the user wants to finalize and archive a change after implementation is complete.

Load the project's engineering quality bar before writing, reviewing, or merging code. The about/craft-and-care/ directory defines testing standards, performance budgets, code quality conventions, review expectations, observability requirements, and dependency hygiene for tze_hud. Consult before: writing tests, reviewing PRs, adding dependencies, designing error types, or making performance-sensitive changes. Triggers: "quality bar", "review checklist", "performance budget", "testing standards", "code conventions", "dependency policy".

Load the project's topology maps to understand where components live, how they connect, and what boundaries exist. The about/lay-and-land/ directory contains component inventories, data flow diagrams, dependency maps, deployment topology, and operational docs. Consult before adding new components, modifying integration points, changing deployment, or when unsure where something lives in the system.

Load tze_hud RFC design contracts to contextualize implementation work. The about/legends-and-lore/ directory contains 13 RFCs that define the wire-level contracts, data models, state machines, protobuf schemas, and quantitative budgets for the tze_hud presence engine. Consult relevant RFCs before implementing features, writing protobuf definitions, designing state machines, choosing field numbers, setting performance budgets, or resolving cross-subsystem integration questions. Use this skill proactively when the task touches: scene graph, runtime kernel, timing/clocks, input handling, session protocol, configuration, system shell/chrome, leases, policy arbitration, events, or resource storage. Selectively load ONLY the RFCs relevant to your current task — do not load all 13 at once.

Ground all tze_hud implementation work in the v1 MVP capability specifications (openspec/). The 13 capability specs are the single source of truth for feature planning and development. Use this skill: (1) before implementing any feature — to identify and load relevant specs, (2) when detecting or resolving spec-code divergence, (3) when evolving specs as features change, (4) when planning new work to ensure spec coverage, (5) when reconciling after implementation chunks. Triggers: "check the spec", "what does the spec say", "ground this in specs", "spec drift", "divergence", "reconcile", "does the code match the spec", "write a spec for this", "which spec covers", "spec-first", any implementation task touching a v1 subsystem.

Use when the task is about technical contracts, subsystem design decisions, mutation boundaries, or RFC-level architecture.

Use when the task is about requirements, acceptance criteria, capability scope, or implementation sequencing from OpenSpec changes.

Use when the task is about product thesis, scope boundaries, non-goals, doctrine principles, or non-negotiable rules.

Use when the task is about system boundaries, runtime data flow, deployment topology, or component integration shape.