altimate-code 0.4.7 → 0.5.0

package/skills/pii-audit/SKILL.md

@@ -0,0 +1,117 @@
+---
+name: pii-audit
+description: Classify schema columns for PII (SSN, email, phone, name, address, credit card) and check whether queries expose them. Use for GDPR/CCPA/HIPAA compliance audits.
+---
+
+# PII Audit
+
+## Requirements
+**Agent:** any (read-only analysis)
+**Tools used:** altimate_core_classify_pii, altimate_core_query_pii, schema_detect_pii, schema_inspect, read, glob
+
+## When to Use This Skill
+
+**Use when the user wants to:**
+- Scan a database schema for PII columns (SSN, email, phone, name, address, credit card, IP)
+- Check if a specific query exposes PII data
+- Audit dbt models for PII leakage before production deployment
+- Generate a PII inventory for compliance (GDPR, CCPA, HIPAA)
+
+**Do NOT use for:**
+- SQL injection scanning -> use `sql-review`
+- General SQL quality checks -> use `sql-review`
+- Access control auditing -> finops role tools in `cost-report`
+
+## Workflow
+
+### 1. Classify Schema for PII
+
+**Option A — From schema YAML/JSON:**
+
+```
+altimate_core_classify_pii(schema_context: <schema_object>)
+```
+
+Analyzes column names, types, and patterns to detect PII categories:
+- **Direct identifiers**: SSN, email, phone, full name, credit card number
+- **Quasi-identifiers**: Date of birth, zip code, IP address, device ID
+- **Sensitive data**: Salary, health records, religious affiliation
+
+**Option B — From warehouse connection:**
+
+First index the schema, inspect it, then classify:
+```
+schema_index(warehouse: <name>)
+schema_inspect(warehouse: <name>, database: <db>, schema: <schema>, table: <table>)
+schema_detect_pii(warehouse: <name>)
+```
+
+`schema_detect_pii` scans all indexed columns using pattern matching against the schema cache (requires `schema_index` to have been run).
+
+### 2. Check Query PII Exposure
+
+For each query or dbt model, check which PII columns it accesses:
+
+```
+altimate_core_query_pii(sql: <sql>, schema_context: <schema_object>)
+```
+
+Returns:
+- Which PII-classified columns are selected, filtered, or joined on
+- Risk level per column (HIGH for direct identifiers, MEDIUM for quasi-identifiers)
+- Whether PII is exposed in the output (SELECT) vs only used internally (WHERE/JOIN)
+
+### 3. Audit dbt Models (Batch)
+
+For a full project audit:
+```bash
+glob models/**/*.sql
+```
+
+For each model:
+1. Read the compiled SQL
+2. Run `altimate_core_query_pii` against the project schema
+3. Classify the model's PII risk level
+
+### 4. Present the Audit Report
+
+```
+PII Audit Report
+================
+
+Schema: analytics.public (42 tables, 380 columns)
+
+PII Columns Found: 18
+
+HIGH RISK (direct identifiers):
+  customers.email          -> EMAIL
+  customers.phone_number   -> PHONE
+  customers.ssn            -> SSN
+  payments.card_number     -> CREDIT_CARD
+
+MEDIUM RISK (quasi-identifiers):
+  customers.date_of_birth  -> DOB
+  customers.zip_code       -> ZIP
+  events.ip_address        -> IP_ADDRESS
+
+Model PII Exposure:
+
+| Model | PII Columns Exposed | Risk | Action |
+|-------|-------------------|------|--------|
+| stg_customers | email, phone, ssn | HIGH | Mask or hash before mart layer |
+| mart_user_profile | email | HIGH | Requires access control |
+| int_order_summary | (none) | SAFE | No PII in output |
+| mart_daily_revenue | zip_code | MEDIUM | Aggregation reduces risk |
+
+Recommendations:
+1. Hash SSN and credit_card in staging layer (never expose raw)
+2. Add column-level masking policy for email and phone
+3. Restrict mart_user_profile to authorized roles only
+4. Document PII handling in schema.yml column descriptions
+```
+
+## Usage
+
+- `/pii-audit` -- Scan the full project schema for PII
+- `/pii-audit models/marts/mart_customers.sql` -- Check a specific model for PII exposure
+- `/pii-audit --schema analytics.public` -- Audit a specific database schema

package/skills/query-optimize/SKILL.md

@@ -0,0 +1,86 @@
+---
+name: query-optimize
+description: Analyze and optimize SQL queries for better performance
+---
+
+# Query Optimize
+
+## Requirements
+**Agent:** any (read-only analysis)
+**Tools used:** sql_optimize, sql_analyze, sql_explain, altimate_core_equivalence, read, glob, schema_inspect, warehouse_list
+
+Analyze SQL queries for performance issues and suggest concrete optimizations including rewritten SQL.
+
+## Workflow
+
+1. **Get the SQL query** -- Either:
+   - Read SQL from a file path provided by the user
+   - Accept SQL directly from the conversation
+   - Read from clipboard or stdin if mentioned
+
+2. **Determine the dialect** -- Default to `snowflake`. If the user specifies a dialect (postgres, bigquery, duckdb, etc.), use that instead. Check the project for warehouse connections using `warehouse_list` if unsure.
+
+3. **Run the optimizer**:
+   - Call `sql_optimize` with the SQL, dialect, and schema context if available
+   - If the user has a warehouse connection, first call `schema_inspect` on the relevant tables to build schema context for better optimization (e.g., SELECT * expansion)
+
+4. **Run detailed analysis**:
+   - Call `sql_analyze` with the same SQL and dialect to get the full anti-pattern breakdown with recommendations
+
+5. **Get execution plan** (if warehouse connected):
+   - Call `sql_explain` to run EXPLAIN on the query and get the execution plan
+   - Look for: full table scans, sort operations on large datasets, inefficient join strategies, missing partition pruning
+   - Include key findings in the report under "Execution Plan Insights"
+
+6. **Verify rewrites preserve correctness**:
+   - If `sql_optimize` produced a rewritten query, call `altimate_core_equivalence` to verify the original and optimized queries produce the same result set
+   - If not equivalent, flag the difference and present both versions for the user to decide
+   - This prevents "optimization" that silently changes query semantics
+
+7. **Present findings** in a structured format:
+
+```
+Query Optimization Report
+=========================
+
+Summary: X suggestions found, Y anti-patterns detected
+
+High Impact:
+  1. [REWRITE] Replace SELECT * with explicit columns
+     Before: SELECT *
+     After:  SELECT id, name, email
+
+  2. [REWRITE] Use UNION ALL instead of UNION
+     Before: ... UNION ...
+     After:  ... UNION ALL ...
+
+Medium Impact:
+  3. [PERFORMANCE] Add LIMIT to ORDER BY
+     ...
+
+Optimized SQL:
+--------------
+SELECT id, name, email
+FROM users
+WHERE status = 'active'
+ORDER BY name
+LIMIT 100
+
+Anti-Pattern Details:
+---------------------
+  [WARNING] SELECT_STAR: Query uses SELECT * ...
+    -> Consider selecting only the columns you need.
+```
+
+8. **If schema context is available**, mention that the optimization used real table schemas for more accurate suggestions (e.g., expanding SELECT * to actual columns).
+
+9. **If no issues are found**, confirm the query looks well-optimized and briefly explain why (no anti-patterns, proper use of limits, explicit columns, etc.).
+
+## Usage
+
+The user invokes this skill with SQL or a file path:
+- `/query-optimize SELECT * FROM users ORDER BY name` -- Optimize inline SQL
+- `/query-optimize models/staging/stg_orders.sql` -- Optimize SQL from a file
+- `/query-optimize` -- Optimize the most recently discussed SQL in the conversation
+
+Use the tools: `sql_optimize`, `sql_analyze`, `sql_explain` (execution plans), `altimate_core_equivalence` (rewrite verification), `read` (for file-based SQL), `glob` (to find SQL files), `schema_inspect` (for schema context), `warehouse_list` (to check connections).

package/skills/schema-migration/SKILL.md

@@ -0,0 +1,119 @@
+---
+name: schema-migration
+description: Analyze DDL migrations for data loss risks — type narrowing, missing defaults, dropped constraints, breaking column changes. Use before applying schema changes to production.
+---
+
+# Schema Migration Analysis
+
+## Requirements
+**Agent:** any (read-only analysis)
+**Tools used:** altimate_core_migration, altimate_core_schema_diff, schema_diff, read, glob, bash (for git operations)
+
+## When to Use This Skill
+
+**Use when the user wants to:**
+- Analyze a DDL migration for data loss risks before applying it
+- Compare two schema versions to find breaking changes
+- Review ALTER TABLE / CREATE TABLE changes in a PR
+- Validate that a model refactoring doesn't break the column contract
+
+**Do NOT use for:**
+- Writing new models -> use `dbt-develop`
+- Analyzing downstream impact of SQL logic changes -> use `dbt-analyze`
+- Optimizing queries -> use `query-optimize`
+
+## Workflow
+
+### 1. Get the Schema Versions
+
+**For DDL migrations** (ALTER TABLE, CREATE TABLE):
+- Read the migration file(s) from disk
+- The "old" schema is the current state; the "new" schema is after applying the migration
+
+**For dbt model changes** (comparing before/after SQL):
+```bash
+# Get the old version from git
+git show HEAD:<path/to/model.sql> > /tmp/old_model.sql
+# The new version is the current file
+```
+
+**For schema YAML changes:**
+- Read both versions of the schema.yml file
+
+### 2. Analyze DDL Migration Safety
+
+Call `altimate_core_migration` to detect data loss risks:
+
+```
+altimate_core_migration(old_ddl: <old_ddl>, new_ddl: <new_ddl>, dialect: <dialect>)
+```
+
+This checks for:
+- **Type narrowing**: VARCHAR(100) -> VARCHAR(50) (truncation risk)
+- **NOT NULL without default**: Adding NOT NULL column without DEFAULT (fails on existing rows)
+- **Dropped columns**: Data loss if column has values
+- **Dropped constraints**: Unique/check constraints removed (data integrity risk)
+- **Type changes**: INTEGER -> VARCHAR (irreversible in practice)
+- **Index drops**: Performance regression risk
+
+### 3. Diff Schema Structures
+
+**For YAML/JSON schemas:** Call `altimate_core_schema_diff` to compare two schema definitions:
+
+```
+altimate_core_schema_diff(schema1: <old_schema>, schema2: <new_schema>)
+```
+
+Returns: added/removed/modified tables and columns, type changes, constraint changes, breaking change detection.
+
+**For SQL model changes:** Call `schema_diff` to compare two SQL models for column-level breaking changes:
+
+```
+schema_diff(old_sql: <old_sql>, new_sql: <new_sql>, dialect: <dialect>)
+```
+
+Returns: dropped columns (BREAKING), type changes (WARNING), potential renames (Levenshtein distance matching).
+
+### 4. Present the Analysis
+
+```
+Schema Migration Analysis
+=========================
+
+Migration: alter_orders_table.sql
+Dialect: snowflake
+
+BREAKING CHANGES (2):
+  [DATA LOSS] Dropped column: orders.discount_amount
+    -> Column has 1.2M non-NULL values. Data will be permanently lost.
+
+  [TRUNCATION] Type narrowed: orders.customer_name VARCHAR(200) -> VARCHAR(50)
+    -> 3,400 rows exceed 50 chars. Values will be truncated.
+
+WARNINGS (1):
+  [CONSTRAINT] Dropped unique constraint on orders.external_id
+    -> Duplicates may be inserted after migration.
+
+SAFE CHANGES (3):
+  [ADD] New column: orders.updated_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP
+  [ADD] New column: orders.version INTEGER DEFAULT 1
+  [WIDEN] Type widened: orders.amount DECIMAL(10,2) -> DECIMAL(18,2)
+
+Recommendation: DO NOT apply without addressing BREAKING changes.
+  1. Back up discount_amount data before dropping
+  2. Verify no values exceed 50 chars, or widen the target type
+  3. Confirm external_id uniqueness is no longer required
+```
+
+### 5. For dbt Model Refactoring
+
+When the user is refactoring a dbt model (renaming columns, changing types):
+1. Run `schema_diff` on old vs new compiled SQL
+2. Cross-reference with `dbt-analyze` to check downstream consumers
+3. Flag any downstream model that references a dropped/renamed column
+
+## Usage
+
+- `/schema-migration migrations/V003__alter_orders.sql` -- Analyze a DDL migration file
+- `/schema-migration models/staging/stg_orders.sql` -- Compare current file against last commit
+- `/schema-migration --old schema_v1.yml --new schema_v2.yml` -- Compare two schema files

package/skills/sql-review/SKILL.md

@@ -0,0 +1,118 @@
+---
+name: sql-review
+description: Pre-merge SQL quality gate — lint 26 anti-patterns, grade readability/performance A-F, validate syntax, and scan for injection threats. Use before committing or reviewing SQL changes.
+---
+
+# SQL Review
+
+## Requirements
+**Agent:** any (read-only analysis)
+**Tools used:** altimate_core_check, altimate_core_grade, sql_analyze, read, glob, bash (for git operations)
+
+## When to Use This Skill
+
+**Use when the user wants to:**
+- Review SQL quality before merging a PR
+- Get a quality grade (A-F) on a query or model
+- Run a comprehensive lint + safety + syntax check in one pass
+- Audit SQL files in a directory for anti-patterns
+
+**Do NOT use for:**
+- Optimizing query performance -> use `query-optimize`
+- Fixing broken SQL -> use `dbt-troubleshoot`
+- Translating between dialects -> use `sql-translate`
+
+## Workflow
+
+### 1. Collect SQL to Review
+
+Either:
+- Read SQL from a file path provided by the user
+- Accept SQL directly from the conversation
+- Auto-detect changed SQL files from git:
+
+```bash
+git diff --name-only HEAD~1 | grep '\.sql$'
+```
+
+For dbt models, compile first to get the full SQL:
+```bash
+altimate-dbt compile --model <name>
+```
+
+### 2. Run Comprehensive Check
+
+Call `altimate_core_check` — this is the single-call code review that composes:
+- **Syntax validation**: Parse errors with line/column positions
+- **Lint (26 anti-patterns)**: SELECT *, unused CTEs, implicit casts, NULL comparisons, missing WHERE on DELETE/UPDATE, cartesian joins, non-sargable predicates, missing partition filters, and more
+- **Injection scan**: Tautology attacks, UNION injection, stacked queries, comment injection, Jinja template injection
+- **PII exposure**: Flags queries accessing columns classified as PII
+
+```
+altimate_core_check(sql: <sql>, schema_context: <schema_object>)
+```
+
+### 3. Grade the SQL
+
+Call `altimate_core_grade` to get an A-F quality score with per-category breakdown:
+
+```
+altimate_core_grade(sql: <sql>, schema_context: <schema_object>)
+```
+
+Categories scored:
+- **Readability**: Naming, formatting, CTE structure
+- **Performance**: Anti-patterns, index usage, scan efficiency
+- **Correctness**: NULL handling, join logic, type safety
+- **Best Practices**: Explicit columns, proper materialization hints
+
+### 4. Run Anti-Pattern Analysis
+
+Call `sql_analyze` for the detailed anti-pattern breakdown with severity levels and concrete recommendations:
+
+```
+sql_analyze(sql: <sql>, dialect: <dialect>)
+```
+
+### 5. Present the Review
+
+```
+SQL Review: <file_or_query_name>
+==============================
+
+Grade: B+ (82/100)
+  Readability:  A  (clear CTEs, good naming)
+  Performance:  B- (missing partition filter on large table)
+  Correctness:  A  (proper NULL handling)
+  Best Practices: C (SELECT * in staging model)
+
+Issues Found: 3
+  [HIGH]   SELECT_STAR — Use explicit column list for contract stability
+  [MEDIUM] MISSING_PARTITION_FILTER — Add date filter to avoid full scan
+  [LOW]    IMPLICIT_CAST — VARCHAR compared to INTEGER on line 23
+
+Safety: PASS (no injection vectors detected)
+PII: PASS (no PII columns exposed)
+
+Verdict: Fix HIGH issues before merging. MEDIUM issues are recommended.
+```
+
+### 6. Batch Mode
+
+When reviewing multiple files (e.g., all changed SQL in a PR):
+- Run the check on each file
+- Present a summary table:
+
+```
+| File | Grade | Issues | Safety | Verdict |
+|------|-------|--------|--------|---------|
+| stg_orders.sql | A | 0 | PASS | Ship |
+| int_revenue.sql | B- | 2 | PASS | Fix HIGH |
+| mart_daily.sql | C | 5 | WARN | Block |
+```
+
+## Usage
+
+- `/sql-review models/marts/fct_orders.sql` -- Review a specific file
+- `/sql-review` -- Review all SQL files changed in the current git diff
+- `/sql-review --all models/` -- Review all SQL files in a directory

package/skills/sql-translate/SKILL.md

@@ -0,0 +1,68 @@
+---
+name: sql-translate
+description: Translate SQL queries between database dialects (Snowflake, BigQuery, PostgreSQL, MySQL, etc.)
+---
+
+# SQL Translate
+
+## Requirements
+**Agent:** builder or migrator (may write translated SQL to files)
+**Tools used:** sql_translate, read, write, sql_validate
+
+Translate SQL queries from one database dialect to another using sqlglot's transpilation engine.
+
+## Workflow
+
+1. **Determine source and target dialects** — If the user did not specify both dialects, ask which source and target dialects to use. Common dialects: `snowflake`, `bigquery`, `postgres`, `mysql`, `tsql`, `hive`, `spark`, `databricks`, `redshift`, `duckdb`.
+
+2. **Get the SQL to translate** — Either:
+   - Read from a file path provided by the user (use `read`)
+   - Accept inline SQL from the user's message
+   - Read from clipboard or stdin if mentioned
+
+3. **Call `sql_translate`** with:
+   - `sql`: The SQL query text
+   - `source_dialect`: The source dialect
+   - `target_dialect`: The target dialect
+
+4. **Review the result**:
+   - If `success` is true, present the translated SQL
+   - If there are `warnings`, explain each one and what may need manual adjustment
+   - If `success` is false, explain the error and suggest fixes
+
+5. **Format the output** showing:
+   - Original SQL (labeled with source dialect)
+   - Translated SQL (labeled with target dialect)
+   - Any warnings about lossy translations or features that need manual review
+
+6. **Offer next steps** if applicable:
+   - Suggest running `sql_validate` on the translated SQL to verify syntax
+   - Offer to write the translated SQL to a file
+   - Offer to translate additional queries
+
+## Usage
+
+The user invokes this skill with optional dialect and SQL arguments:
+- `/sql-translate` — Interactive: ask for source dialect, target dialect, and SQL
+- `/sql-translate snowflake postgres` — Translate from Snowflake to PostgreSQL (will ask for SQL)
+- `/sql-translate snowflake postgres SELECT DATEADD(day, 7, CURRENT_TIMESTAMP())` — Full inline translation
+
+## Supported Dialects
+
+| Dialect | Key |
+|---------|-----|
+| Snowflake | `snowflake` |
+| BigQuery | `bigquery` |
+| PostgreSQL | `postgres` |
+| MySQL | `mysql` |
+| SQL Server | `tsql` |
+| Hive | `hive` |
+| Spark SQL | `spark` |
+| Databricks | `databricks` |
+| Redshift | `redshift` |
+| DuckDB | `duckdb` |
+| SQLite | `sqlite` |
+| Oracle | `oracle` |
+| Trino/Presto | `trino` / `presto` |
+
+Use the tools: `sql_translate`, `read`, `write`, `sql_validate`.

package/skills/teach/SKILL.md

@@ -0,0 +1,54 @@
+---
+name: teach
+description: Teach your AI teammate a pattern by showing it an example file from your codebase
+---
+
+# Teach
+
+## Purpose
+Learn a reusable pattern from an example file. The user shows you a well-written artifact (model, query, config), and you extract the patterns worth following.
+
+## Workflow
+
+1. **Identify the file**: The user provides a file reference (e.g., `@models/staging/stg_orders.sql`). Read the file.
+
+2. **Analyze patterns**: Extract the structural patterns, NOT the specific content. Focus on:
+   - File structure and organization (sections, ordering)
+   - Naming conventions (prefixes, suffixes, casing)
+   - SQL patterns (CTE vs subquery, join style, column ordering)
+   - dbt conventions (materialization, tests, config blocks)
+   - Common boilerplate (headers, comments, imports)
+   - Data type choices
+   - Error handling patterns
+
+3. **Present findings**: Show the user what you learned in a structured list. Be specific:
+   - Good: "Column order: keys first, then dimensions, then measures, then timestamps"
+   - Bad: "Good column ordering"
+
+4. **Ask for confirmation**: Let the user confirm, modify, or reject your findings before saving.
+
+5. **Save via training_save**: Use the `training_save` tool with:
+   - `kind`: "pattern"
+   - `name`: A descriptive slug (e.g., "staging-model", "incremental-config")
+   - `content`: The extracted patterns as a concise, actionable checklist
+   - `scope`: "project" (default — shared with team via git)
+   - `source`: The file path you learned from
+   - `citations`: Reference to the source file
+
+## Important Guidelines
+
+- Extract PATTERNS, not content. "Use `{{ source() }}` macro" is a pattern. "Query the orders table" is content.
+- Keep it concise — max 10 bullet points per pattern. If more are needed, split into multiple patterns.
+- Use the file's actual conventions, don't impose your own preferences.
+- If the file doesn't have clear patterns worth learning, say so honestly.
+- Do NOT make any LLM calls beyond the normal conversation flow — pattern extraction happens in your analysis, not via separate API calls.
+
+## Usage Examples
+
+```
+/teach @models/staging/stg_orders.sql
+/teach staging-model @models/staging/stg_customers.sql
+/teach @dbt_project.yml
+```
+
+If the user provides a name (first argument before the @file), use that as the pattern name. Otherwise, infer a name from the file type and purpose.

package/skills/train/SKILL.md

@@ -0,0 +1,51 @@
+---
+name: train
+description: Train your AI teammate on team standards from a document or style guide
+---
+
+# Train
+
+## Purpose
+Learn team standards and conventions from a document (style guide, review checklist, coding standards, etc.). Extracts actionable rules and saves them as training.
+
+## Workflow
+
+1. **Get the document**: The user provides either:
+   - A file reference: `@docs/sql-style-guide.md`
+   - A URL: The full URL to fetch (use webfetch tool)
+   - Inline text: Pasted directly in the chat
+
+2. **Read and analyze**: Parse the document and extract:
+   - Specific, enforceable rules (naming, formatting, prohibited patterns)
+   - Review criteria and checklists
+   - Glossary terms and definitions
+   - Architectural standards
+
+3. **Categorize**: Group findings by training kind:
+   - `rule` — Specific do/don't rules (e.g., "Never use SELECT *")
+   - `standard` — Broader conventions (e.g., "SQL style guide compliance")
+   - `glossary` — Term definitions (e.g., "ARR = Annual Recurring Revenue")
+
+4. **Present summary**: Show the user what you extracted:
+   - Number of rules, standards, and glossary terms found
+   - Preview of each item
+   - Ask for confirmation before saving
+
+5. **Save via training_save**: Save each item using the `training_save` tool. For documents with many rules, consolidate related rules into logical groups (e.g., "sql-naming-rules" with 5 rules, rather than 5 separate entries).
+
+## Important Guidelines
+
+- Only extract ACTIONABLE items. Skip vague guidance like "write clean code."
+- Consolidate related rules into single training entries to avoid clutter.
+- Preserve the original wording when it's specific and clear.
+- If the document is too large, focus on the most impactful rules.
+- Always use `scope: project` unless the user specifies global.
+- Do NOT make any extra LLM calls — analysis happens in the normal conversation flow.
+
+## Usage Examples
+
+```
+/train @docs/sql-style-guide.md
+/train https://wiki.company.com/data-team/review-checklist
+/train   (then paste content inline)
+```

package/skills/training-status/SKILL.md

@@ -0,0 +1,45 @@
+---
+name: training-status
+description: Show what your AI teammate has learned — patterns, rules, glossary, and standards
+---
+
+# Training Status
+
+## Purpose
+Display a comprehensive overview of everything your AI teammate has been trained on.
+
+## Workflow
+
+1. **Fetch all training**: Use the `training_list` tool with no filters to get all training entries.
+
+2. **Present the dashboard**: Format the output as a clean status report:
+
+```
+Training Status
+
+Patterns:   X  (staging-model, incremental-config, ...)
+Rules:      X  (no-float, no-select-star, ...)
+Glossary:   X  (arr, mrr, churn-date, ...)
+Standards:  X  (sql-style-guide, review-checklist, ...)
+
+Recent Training:
+  - 2 days ago: Learned rule "no-float" (from user correction)
+  - 5 days ago: Learned pattern "staging-model" (from stg_orders.sql)
+  - 1 week ago: Loaded standard "sql-style-guide" (from docs/sql-style.md)
+
+Most Applied:
+  - "staging-model" pattern — applied 12 times
+  - "no-float" rule — applied 8 times
+```
+
+3. **Offer actions**: After showing status, suggest:
+   - `/teach` to learn new patterns
+   - `/train` to load standards from documents
+   - `training_remove` to remove outdated entries
+   - `training_list` with filters for detailed views
+
+## Usage
+
+```
+/training-status
+```