القائمة
Automatically pulls new Fathom call transcripts for the engagement's client into .wire/engagement/calls/ once per session, when fathom_sync is enabled for the engagement.
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
استنادا إلى تصنيف SOC المهني
Proactive skill for building Dagster orchestration layers. Auto-activates when creating or modifying Dagster assets, schedules, sensors, or components, or when working on the orchestration artifact in a Wire project. Covers the assets-first pattern, dagster-dbt integration, automation (schedules, sensors, declarative automation), the component framework, and CLI usage (dg dev, dg launch, dg check, dg scaffold).
Proactive skill for answering business analytics questions using dbt's Semantic Layer, Discovery API, or direct SQL. Auto-activates when a user asks a data or metrics question against a dbt project (e.g. "What were total sales last quarter?", "Show me top customers by revenue"). Uses a 4-level escalation: Semantic Layer first, modified compiled SQL, model discovery, manifest analysis. Always exhausts all options before saying "cannot answer."
Proactive skill for generating Mermaid flowchart diagrams of dbt model lineage. Auto-activates when a user asks to visualise dbt model dependencies, create a lineage diagram, or show the dbt DAG. Uses MCP get_lineage tools first, then manifest.json parsing, then direct code parsing as fallbacks. Produces colour-coded diagrams matching Wire's naming conventions.
Proactive skill for validating dbt models against coding conventions. Auto-activates when creating, reviewing, or refactoring dbt models in staging, integration, or warehouse layers. Validates naming, SQL structure, field conventions, testing coverage, and documentation. Supports project-specific convention overrides and sqlfluff integration.
Generate an Oracle Analytics Cloud (OAC) semantic model in SMML (Semantic Modeler Markup Language) from a dbt project. Use when the user wants to build, convert, or scaffold an OAC semantic model from dbt models — generate SMML, the physical/logical/presentation layers, measures, hierarchies and role-playing dimensions — driven by dbt metadata plus `meta.oac` annotations in schema.yml. Triggers: "generate SMML", "dbt to OAC semantic model", "build the OAC semantic layer from dbt", "create logical/physical/presentation layer from dbt". For hand-authoring, editing, or reviewing SMML directly (no dbt project), use the sibling `smml-semantic-modeling` skill instead — this skill's `meta.oac` vocabulary and generator are built on that skill's modeling knowledge.
Proactive skill for creating dbt unit tests. Auto-activates when working with dbt model testing, mock inputs/outputs, or transformation validation. Covers the Model-Inputs-Outputs pattern, format selection (dict/CSV/SQL), BigQuery-specific caveats, and production deployment guidance.
| name | Fathom Sync |
| description | Automatically pulls new Fathom call transcripts for the engagement's client into .wire/engagement/calls/ once per session, when fathom_sync is enabled for the engagement. |
| triggers | ["The start of a conversation in a repository containing a .wire/ directory, immediately after the Engagement Context skill has loaded context, when .wire/engagement/context.md has fathom_sync.enabled set to true"] |
Append a one-line entry to .wire/execution_log.md (or the active release's log, matching Engagement Context's own convention):
| YYYY-MM-DD HH:MM | skill | fathom-sync | activated | Checked for new Fathom calls |
Fires once per new conversation, immediately after the Engagement Context skill has loaded (so engagement state is already known) — never mid-conversation, never more than once per session.
Do not fire if any of these are true:
.wire/engagement/context.md doesn't exist, or fathom_sync.enabled is not trueAll of the above are silent skips: no message, no note, nothing different about how the conversation proceeds. This is the expected outcome for most sessions and for any engagement that hasn't opted in.
specs/utils/fathom_sync.md in automatic mode — no flags, defaults for --after (from fathom_sync.last_synced), --before (today), --limit (50). Findings extraction runs (not skipped) unless a prior session left --no-findings-equivalent state, which automatic mode never does.This skill is deliberately separate from the Engagement Context skill rather than folded into it, even though they share the same "once per session" trigger: Engagement Context is meant to be fast (read a couple of files, summarize) and Fathom Sync can be genuinely slow (MCP calls, writing multiple files, a real analytical findings pass per new call). Keeping them separate means a heavy Fathom sync never makes the fast context-load feel sluggish, and either can be reasoned about independently.
specs/utils/meeting_context.md)Different job. Meeting Context does a live, ad-hoc Fathom search at review time, scoped to one artifact, and doesn't persist anything. Fathom Sync persists every new call as a durable, committed file once, unscoped to any particular artifact — so the whole team has it later without re-querying Fathom, and Meeting Context's own searches can find it locally instead of hitting the API again.