ctox

Create, edit, redline, review, and comment on .docx documents through the CTOX documents engine (Euro-Office port), with a strict render-and-verify workflow. Authoring and layout changes run as editor flows; deterministic OOXML batch operations run as native office-engine ops. Never assume a document is correct without rendering and visually inspecting every page.

Authorized deployment readiness and go-live security audit for software projects and running apps. Use as the final app go-live gate to assess release readiness, validate evidence, run scanner coverage, verify authorization boundaries, prove release blockers, and produce a deployment audit report. Provides one Rust CLI boundary for Pi/CTOX agents running in a sandbox.

Create, edit, analyze, and verify .xlsx workbooks through the CTOX spreadsheets engine (Euro-Office port). Formula-driven, auditable models with typed values, invariant number formats, and a mandatory visual verification pass. Authoring capabilities are gated on the engine's feature matrix; read/render/analyze paths are available first.

Use when tasks involve reading, reviewing, or verifying PDF files where rendering and layout matter. Prefer visual checks by rendering pages to PNGs (Poppler, same path as the CTOX report pipeline). PDF creation routes through the CTOX documents engine, not ad-hoc PDF generator libraries.

Use whenever CTOX, Business OS, App Creator, App Store, chat, CLI, or an inbound Business OS workflow asks an agent to build, modify, repair, review, or install a CTOX Business OS app/module. The agent builds the app itself as no-build vanilla HTML/CSS/browser ESM, persists through the shell-provided CTOX Sync Engine/RxDB handle, sends automation through commandBus, studies shipped Business OS app examples, and validates the result with CTOX app validation.

Use when an external agent should connect to CTOX Business OS through the Business OS MCP Channel to query modules, records, runs, artifacts, approvals, or delegate validated Business OS actions. Trigger when setting up or using CTOX from ChatGPT, Codex, another MCP-capable agent, or an agent runtime that can install GitHub-hosted skills.

Use when CTOX needs to communicate with the owner through TUI, email, or Jami, choose the correct communication path, continue an existing owner thread, or decide how proactive outbound owner contact should work.

Review mechanical technical drawings, engineering drawing PDFs, CAD exports, and manufacturability handoff drawings; produce localized issue lists with pins, severity, evidence, and follow-up checks.

Optimize local LLM inference engines for a specific model and platform. Use when CTOX must improve prefill, decode, attention, recurrent state, quantized matmul, memory layout, CPU/GPU/NPU backend use, cache/bandwidth behavior, or reference performance against llama.cpp, MLX, Core ML, TensorRT, vLLM, or another local inference baseline.

Systematic research with a common discovery phase and two output modes. Library mode (record-shape `ctox knowledge data` table) is for tasks framed as "build a library of X / catalog / dataset / matrix / lookup", spanning research-data libraries (papers, standards, measurement data, load cases, parameter tables), engineering reference libraries, and operational record sets (CRM entities, vendor comparisons, parts catalogs, scraping outputs). For technical, engineering, scientific, or regulatory topics the discovery phase prioritizes primary research data (NASA NTRS, scholar, arXiv, IEEE, agency reports, dataset repositories) and standards before OEM datasheets — generic `web search` ranks marketing pages above measurement data and must not be the first move. Decision-report mode (Word document via `ctox report`) is for feasibility study (Machbarkeitsstudie), market research (Marktanalyse), competitive analysis (Wettbewerbsanalyse), technology screening, whitepaper, source review (Quellenreview), literature re

Create a reusable custom skill from a concrete dataset or from dataset-derived analysis artifacts. Use when CTOX should turn a data source into an operational Codex skill with SKILL.md, references, optional scripts/assets, and validation instead of leaving the result as raw knowledge bundles, RAG files, or one-off summaries.

Parse a source CV/résumé document into the unified CTOX print profile (ctox.cv_print_profile.v1) for the Business OS cv-print-builder module.

Use when CTOX handles a Business OS Support conversation and must summarize, classify, draft, or propose the next support action through typed Business OS writeback.

Use when the deliverable is the COMPLETE Intersolar exhibitor/company list as an .xlsx with a PLZ column. Declares the spreadsheet deliverable contract (minimum row count + required columns) that the review gate enforces by hard keys instead of a hardcoded company literal.

Use when CTOX must reconstruct the relevant communication state before replying on email, Jami, or TUI, especially when approvals, blockers, prior promises, or cross-channel context may change the answer.

Use a real browser through js_repl-backed Playwright when CTOX needs live DOM state, client-side JavaScript execution, auth/session behavior, screenshots, or true UI interaction instead of search, source reading, or durable scraping.

Use when CTOX is mentioned in a live meeting chat (@CTOX), when processing a post-meeting transcript, or when a scheduled meeting task fires. This skill governs how the agent participates in meetings, responds to live questions, and extracts actionable knowledge from meeting content.

Plan, build, revise, schedule, and operate reusable scraping workflows when CTOX must extract structured data from websites, APIs, feeds, documents, or browser-backed portals without reinventing the storage, script, and run-management model each time.

Diagnose and repair CTOX's browser stealth stack when bot detection blocks `ctox web search`, `ctox web browser-automation`, or scraping. Reads the failing detection-site source, maps the failing check to a patch in `stealth_init.js` / `google_browser_runner.mjs` / `tools/web-stack/src/browser.rs`, applies it, rebuilds, retests against the four baseline probes (sannysoft, antoinevastel, creepjs, incolumitas), and commits.

Prove that a deployed service is actually usable, not merely running, by checking layered acceptance gates such as process, listener, HTTP, authenticated admin/API access, safe mutating smoke checks, and persistence. Use when CTOX must decide whether a deployment truly passed or still needs repair.

Plan and execute controlled admin changes such as patches, config edits, restarts, upgrades, and rollbacks. Use when CTOX must stage a host or service change, compare current versus target config, verify preconditions, prepare rollback, or drive a maintenance-window task from dry run through post-change verification.

Triage active incidents from alerts or failures into explicit hypotheses, mitigations, evidence, and next actions. Use when CTOX must react to outages, latency spikes, bad deploys, disk pressure, failing jobs, or repeated alert clusters and keep a crisp incident timeline grounded in concrete system state.

Condense queue state, plans, schedules, incidents, resource pressure, and change results into operational scorecards and decision briefs. Use when CTOX needs to summarize ongoing operations, highlight risk, rank backlog, or produce evidence-based daily or weekly ops reviews from the existing CTOX substrate and concrete host facts.

Verify backup and restore readiness for hosts and services. Use when CTOX needs to inspect snapshot or backup coverage, retention, restore procedures, database dump validity, off-host copies, or disaster recovery confidence after a critical change or as a recurring assurance check.

Evaluate live service health, anomalies, capacity pressure, and host resource behavior using concrete observability commands and logs. Use when services are slow, failing, resource-bound, or need recurring health review, including CPU, memory, disk, network, or GPU investigation with htop, btop, top, vmstat, iostat, ss, journalctl, nvidia-smi, and service-specific checks.

Install, configure, start, verify, and hand off a local or external-backed service using inspectable helper scripts, explicit secret classification, and durable completion or blocked state. Use when CTOX must bring a service to a working deployed state rather than only plan a generic change.

Build or refresh a concrete infrastructure inventory from real host, network, service, storage, runtime, journal, and repo discovery commands. Use when CTOX needs to inspect a machine or repo, gather raw discovery evidence, translate it into the shared CTOX discovery model, and leave behind explicit entities, relations, evidence, and rerunnable discovery runs instead of ad hoc shell output.

Use when CTOX should turn a bounded knowledge source such as a PDF, table, manual, or exported document set into a main skill, one or more skillbooks, and standardized runbook items that can be embedded and retrieved reliably.

Use when CTOX is working with any external system (codebase, platform, API, ticket system, database, CRM, infrastructure) and must build a knowledge base, skillbooks, runbooks, and operator-visible review tickets through generic primitives. This is the default onboarding path, not a special case.

Build reusable knowledge from tabular or record-shaped source systems such as ticket exports, CMDB tables, monitoring inventories, CSV/XLSX sheets, SQL query results, or JSON arrays by first normalizing them into the shared CTOX discovery store and only then projecting them into domain-specific knowledge planes.

Build a real ticket knowledge base from a large ticket export or record list by deriving a source profile, promoted taxonomies, representative examples, and reusable projections instead of stopping at counts or flat summaries.

Learn how a concrete helpdesk actually handles tickets by deriving recurring ticket families, handling playbooks, state norms, note-style references, and fast retrieval artifacts from a historical ticket dataset.

Replace repeated manual operational work with safe scripts, queued tasks, or scheduled CTOX work. Use when the same host or admin procedure keeps recurring, an incident pattern should become automation, or a manual checklist should be turned into tested repo-managed automation without bypassing the existing CTOX queue and schedule flow.

Use at the end of a meaningful multi-step turn to decide whether the work is actually complete, blocked, needs replanning, or should produce a concrete follow-up task proposal.

Use when a task first needs explicit decomposition or revalidation before execution, especially when Codex should produce a compact plan artifact without leaking planning traces into the later execution context.

Use when the CTOX service queue is under pressure, duplicate scheduled work is piling up, pending prompts are growing too fast, or CTOX risks blocking itself behind repeated queue or scheduler work. This skill investigates queue pressure, pauses flooding schedules when needed, deduplicates future work, and restores a stable queue before normal execution resumes.

Use when work should be added to, inspected in, reprioritized within, or otherwise managed through the explicit CTOX queue that feeds the normal inbound routing path.

Use when a heavy or long-running CTOX task should be modeled as dynamic ticket workflow phases while preserving the existing serial queue, review gate, and responsiveness.

Build or review new software products with UI, database, and agentic/AI automation as state-driven products instead of mockups. Use for greenfield CRM, ticketing, workflow, marketplace, dashboard, internal tool, or automation-heavy apps where objects move through states, gates, transitions, persisted runs, logs, progress, chat, and audit.

Use when the operator asks to research one or more companies / Ansprechpartner for sales pipeline work — fill the Sellify / Master-AT field set (Firmierung, Anschrift, Register-ID, Status, Tel/Fax/E-Mail/Website, USt-Id, Branche WZ, Geschäftsführung, Gegenstand, Tickers, Finanzkennzahlen, Mitarbeiter, etc.) using the CTOX web-stack source modules (zefix.ch, northdata.de, firmenabc.at, bundesanzeiger.de, handelsregister.de, companyhouse.de, optional Tier-C: linkedin.com / xing.com / dnbhoovers.com / leadfeeder.com). Trigger phrases (DE/EN) — "recherchier (mir) Firma X", "Stammdaten zu …", "Master-AT für …", "Sellify-Eintrag bauen", "Ansprechpartner finden für …", "Nachrecherche …", "Neurecherche …", "company research", "fill the prospect record for …".