crux

Produces a weekly CISO management briefing as a Marp-compatible Markdown presentation. Use when: weekly cybersecurity notes, KPI/KRI data, incidents, vulnerabilities, threat intelligence, regulatory updates, or management decision needs must become an executive-ready cyber risk and security management brief.

Operating protocol for a Crux project. Use when: an agent or IDE needs to understand Crux layout, locate framework-home definitions, locate project `.crux` state, route work to the right agent, run onboarding, manage task continuity, or decide which files are read-only versus writable.

Enforces a disciplined implementation posture before coding or broad refactors: surface assumptions, narrow scope, prefer the simplest complete fix, define verification targets, and avoid speculative cleanup. Use when: a developer agent is about to implement, refactor, review, or change non-trivial code and there is meaningful ambiguity, risk, or temptation to over-engineer.

Analyses a live Kubernetes cluster and produces .crux/docs/kubernetes.md and .crux/summaries/kubernetes.md. Read-only — does not modify any cluster resources. Use when: (1) .crux/docs/kubernetes.md is missing during onboarding, (2) user requests an architecture review, (3) cluster configuration has significantly changed.

Audits all cluster namespaces against tenant naming conventions defined in decisions/tenant-naming-conventions.md. Checks label compliance, missing resource quotas, and naming pattern violations. Use when: naming convention question, pre-release namespace review, SOC Type 2 audit, or periodic drift check.

Applies or updates Kubernetes NetworkPolicy resources for a target namespace. Supports standard policy templates (deny-all-ingress, allow-same-namespace, allow-ingress-controller, allow-monitoring) and custom policies from user input. Requires explicit user approval before applying any change. Use when: hardening a namespace, onboarding a new tenant, policy drift repair.

Inspects cluster storage health: PersistentVolumes, PersistentVolumeClaims, StorageClasses, and volume-related events. Identifies unbound PVCs, full or near-full volumes, and provisioner errors. Use when: storage questions, PVC issues, pre-release storage review, or on-demand capacity check.

Kubernetes-specific step of tenant onboarding. Creates namespace(s) with correct labels, applies ResourceQuota and LimitRange from the tier preset, enforces NetworkPolicy defaults (default-deny, allow-same-namespace, allow-monitoring), sets up RBAC for the tenant team, registers the tenant in Grafana (if enabled), and updates docs/tenants.md. Part of the multi-step tenant onboarding workflow (.crux/workflows/tenant-onboarding.md). Use when: Kubernetes provisioning step of tenant onboarding, or re-applying standards to a drifted tenant namespace (reconcile mode).

Initializes or repairs the starter structure for a private LLM Wiki: raw root, wiki root, index, overview, glossary, log, source and analysis directories, and schema guidance. Use when: the user asks to create an LLM Wiki, configure a Karpathy-style wiki, set up markdown knowledge-base scaffolding, or restore missing starter files.

Evolves the LLM Wiki schema when the user's domain needs new page types, frontmatter fields, output formats, naming rules, or workflow changes. Use when: repeated wiki work no longer fits the current schema, the user asks to customize the LLM Wiki, or new domain-specific categories are needed.

Reviews MySQL or MariaDB backup posture, dump strategy, and restore-readiness signals. Use when: the user asks whether backups exist, whether backup posture is acceptable, or whether MySQL recovery preparedness needs a quick review.

Reviews MySQL or MariaDB instance-level health signals such as connections, core settings, and operational pressure. Use when: the user wants a broad instance health check, config posture review, or an explanation of whether the database looks stable enough before deeper tuning work.

Reviews MySQL or MariaDB query behaviour using available explain plans, slow-query context, and schema awareness. Use when: the user reports slow queries, asks for index/performance review, or wants a practical MySQL query tuning direction without premature over-optimization.

Evaluates whether MySQL or MariaDB backup posture is actually recoverable in practice. Use when: the user asks if recovery is realistic, RPO/RTO readiness needs review, or backup evidence exists but restore confidence is weak.

Reviews MySQL or MariaDB replication posture, lag, and role state. Use when: replication health is questioned, lag needs interpretation, or the user wants a concise summary of primary/replica status before operational action.

Analyses a MySQL or MariaDB instance and produces a database architecture and schema overview. Use when: `.crux/docs/mysql.md` is missing, onboarding needs a live schema scan, or the user wants a concise MySQL topology and object inventory summary.

Reviews MySQL or MariaDB tables for naming consistency, key structure, and basic schema hygiene. Use when: the user wants a MySQL table audit, naming check, or a quick review of whether table structure looks disciplined enough for ongoing operations.

Provisions tenant-level MySQL resources such as database, user, and grants in a controlled way. Use when: coordinator routes a MySQL tenant provisioning step, or the user explicitly asks for database-per-tenant or account-per-tenant setup on MySQL or MariaDB.

Reviews or plans MySQL/MariaDB user, authentication, and grant changes with least-privilege discipline. Use when: the user wants to inspect access posture, plan grants/revokes, review broad permissions, or manage database access outside tenant provisioning.

Verifies PostgreSQL backup health: checks last successful backup timestamp, backup size, WAL archiving status, and retention policy compliance. Supports pgBackRest, pg_basebackup, and WAL-G. Reports SOC Type 2 relevant findings (backup age, gap detection, restore-readiness). Use when: backup status question, SOC Type 2 audit, incident prep, or scheduled backup health check.

Reviews PostgreSQL instance-level health signals such as connections, settings, extension posture, and operational pressure. Use when: the user wants a broad database instance health check, config posture review, or an explanation of whether the database looks stable enough before deeper tuning work.

Analyses slow and expensive queries using pg_stat_statements. Identifies top queries by total time, mean time, and call frequency. Runs EXPLAIN ANALYZE on selected queries with user approval. Produces a prioritised list of optimisation candidates with index suggestions. Use when: performance complaint, slow query report, pre-release perf review, or pg_stat_statements review.

Evaluates whether PostgreSQL backup posture is actually recoverable in practice. Use when: the user asks if recovery is realistic, RPO/RTO readiness needs review, restore evidence is unclear, or backup status alone is not enough for confidence.

Reviews PostgreSQL replication posture, lag, sender/receiver state, and failover risk. Use when: replication health is questioned, lag needs interpretation, a primary/replica topology should be reviewed, or the user wants a concise replication status summary before operational action.

Connects to a live PostgreSQL cluster and produces .crux/docs/postgresql.md and .crux/summaries/postgresql.md. Collects cluster topology, databases, schemas, extensions, roles, and connection stats. Read-only — does not modify any database objects. Use when: (1) .crux/docs/postgresql.md is missing during onboarding, (2) user requests a schema or database review, (3) cluster configuration has significantly changed.

Audits table naming conventions and structural standards within tenant schemas. Checks snake_case compliance, required audit columns (created_at, updated_at), missing primary keys, and RLS policy coverage. Reads naming conventions from decisions/tenant-naming-conventions.md as the normative source. Use when: tenant schema compliance check, pre-release audit, SOC Type 2 review preparation, onboarding a new tenant with existing tables, or investigating naming drift across schemas.

PostgreSQL-specific step of tenant onboarding. Creates database or schema for the tenant (per isolation model), provisions a dedicated role with least-privilege access, applies connection limits, and updates docs/db-tenants.md. Part of the multi-step tenant onboarding workflow (.crux/workflows/tenant-onboarding.md). Use when: PostgreSQL provisioning step of tenant onboarding, or re-applying standards to a drifted tenant database/schema (reconcile mode).

Reviews or plans PostgreSQL role, login, and privilege changes with least-privilege discipline. Use when: the user wants to inspect role posture, plan grants/revokes, review broad permissions, or manage database access outside tenant provisioning.

Diagnoses non-running or unhealthy pods across the cluster or a target namespace. Collects pod status, recent events, container logs, and resource pressure signals to produce a prioritised issue list with remediation hints. Use when: pods are CrashLooping, Pending, OOMKilled, or Evicted; user reports a deployment issue; or non-running pods detected at session start.

Compiles raw source documents into a persistent interlinked markdown wiki. Use when: the user says ingest, process a raw source, compile documents into the wiki, summarize a source into wiki pages, update wiki pages from new evidence, or integrate new knowledge into the LLM Wiki.

Converts non-markdown source files into LLM-ready markdown or text artifacts for the LLM Wiki ingest pipeline. Prefer Microsoft MarkItDown when installed; otherwise use local fallback tools by file type. Use when: a raw source is PDF, DOCX, PPTX, XLSX, HTML, CSV, JSON, XML, image, audio, ZIP, EPUB, or another format that cannot be directly ingested as markdown/text.

Health-checks an LLM Wiki for contradictions, stale claims, orphan pages, missing cross-references, inconsistent terminology, missing provenance, and schema drift. Use when: the user says lint the wiki, health-check the wiki, find contradictions, find stale pages, repair links, or review wiki quality.

Answers questions from the compiled LLM Wiki and optionally saves useful answers as durable analysis pages. Use when: the user asks a question about accumulated wiki knowledge, wants synthesis with citations to wiki pages, or asks to save an answer back into the wiki.

Prepares a board-level or senior-management security update that highlights status, key risks, decisions, and ownership without operational noise. Use when: a board pack note is needed, senior management wants a security update, or a quarterly status message must be made decision-oriented.

Produces a short executive cyber risk brief that translates technical or operational security content into business risk, impact, recommendation, owner, and next step. Use when: leadership needs a concise security view, a report must be compressed for management, or a decision note is needed.

Prepares a calm executive incident brief that separates facts, assumptions, impact, containment status, decisions, and communication needs. Use when: an incident needs management framing, an executive update must be sent, or a customer-safe summary needs controlled wording.

Writes a formal, management-ready note for residual risk, delayed remediation, or exception handling that identifies the risk, business impact, compensating controls, owner, and sign-off need. Use when: remediation is delayed, a control gap remains, or formal risk acceptance wording is needed.

Clarifies ownership, next action, dependency, and follow-up date for open cybersecurity issues using practical CISO and monkey-management logic. Use when: issues are stuck, everyone thinks security owns everything, or a short action-oriented follow-up note is needed.

Prioritises vulnerabilities in business terms using exposure, asset criticality, exploitability, compensating controls, and operational impact rather than CVSS alone. Use when: remediation urgency is unclear, leadership needs a priority view, or delayed remediation must be justified.

Identifies and ranks practical AI opportunities based on value, effort, data readiness, and operating risk. Use when: the user asks where AI should be used, which pilot should come first, or how to avoid vague AI strategy work without a realistic starting point.