cedricziel

iOS code signing and provisioning profile management via fastlane match. Use when debugging CI signing failures, adding new app extensions or targets, rotating certificates, or troubleshooting match decryption errors.

Enforces OpenAPI spec discipline when working on REST API endpoints in this project. Triggers whenever adding, modifying, or removing HTTP routes, request/response types, or API handlers in the Rust web-ui crate (`crates/web-ui`). Reminds the agent to (1) update the committed `openapi.json` spec, (2) run `make dump-openapi` to re-export the spec from the running server, and (3) run `make generate-flutter-client` to regenerate the Dart/dio client in `app/packages/assistant_api/`. Also applies when changing route parameters, status codes, or authentication on existing endpoints.

Test Driven Development discipline for this workspace. Use whenever writing new features, fixing bugs, or refactoring — the test must be written and confirmed failing before any implementation code is added.

CI organization principles and workflow structure for this project. Use whenever modifying, adding, or reviewing GitHub Actions workflows — including adding jobs, changing job order, updating action versions, modifying cache keys, adding build targets, or debugging CI failures.

Playwright visual regression testing for the assistant Flutter SPA. Covers test structure, screenshot baselines, cross-platform diff tolerance, CI workflow with inline diff comments, and baseline management. Use when adding screens, changing layouts, or debugging visual test failures.

Checklist and architectural rules for implementing new assistant interfaces (CLI, Slack, web, etc.). Every interface MUST use the Orchestrator to ensure consistent behaviour: system prompt, tools, skills, memory, and the full ReAct loop. Use this skill when adding, reviewing, or fixing an interface.

Flutter UX/UI principles for the assistant app. Covers dark-theme colour tokens, responsive breakpoints (Flutter adaptive layouts), accessibility, Riverpod state patterns for loading/error/empty states, and platform conventions for web and macOS. Use when building or reviewing any Flutter screen or widget in app/.

Rust dependency management principles for this workspace. Use whenever adding, updating, removing, or reviewing dependencies in any Cargo.toml — including deciding which version to use, where to declare a dep, or auditing for duplicates.

SignalDB Tempo API compatibility - implemented/stub endpoints, query flow, admin API, Grafana native plugin, and built-in Tempo datasource support. Use when working with HTTP API, Grafana integration, or query endpoints.

SignalDB architecture reference - FDAP stack, write/query data flow, service components, deployment models, and dual catalog system. Use when understanding how components fit together, data flow, or system design.

SignalDB crate map - workspace members, module locations within common/writer/querier/router crates, and key root files. Use when navigating the codebase, finding where code lives, or understanding module boundaries.

SignalDB multi-tenancy and authentication - tenant model, auth flow, isolation layers, slug-based naming, API keys, admin API, and CLI. Use when working with tenant isolation, authentication, API keys, or dataset management.

SignalDB configuration reference - all TOML sections, environment variables, database/discovery/storage/WAL/schema/auth/queue settings, and service ports. Use when working with configuration, environment variables, or TOML settings.

Step-by-step guide for adding a new signal type or table to SignalDB - schema definition, Flight schema, OTLP conversion, WAL operation, acceptor/writer/querier/router updates, and testing. Use when adding new signal types, metric types, or tables.

SignalDB development workflow - build, test, lint, format, run services, Docker, Grafana plugin, health checks, and semantic commits. Use when building, testing, running, or deploying SignalDB.

SignalDB documentation routing - where docs live, the audience taxonomy (users/operations/architecture/contributing), required frontmatter, and when a code change owes a doc update. Use when adding or editing documentation, deciding where a doc belongs, or settling doc debt after finishing a feature.

Expert knowledge for instrumenting Rust applications with OpenTelemetry. Use when working with Rust code instrumentation, adding observability to Rust applications, or when asked about OpenTelemetry in Rust, tracing in Rust, metrics, spans, distributed tracing, OTLP exporters, or instrumentation for Rust HTTP servers/clients, async runtime integration, databases, or any Rust application.

Expert knowledge for instrumenting Go applications with OpenTelemetry. Use when working with Go code instrumentation, adding observability to Go applications, or when asked about OpenTelemetry in Go, tracing in Go, metrics, spans, distributed tracing in Golang, OTLP exporters, or instrumentation for Go HTTP servers/clients, gRPC, databases, goroutines, context propagation, or any Go application.

Expert knowledge for instrumenting Java applications with OpenTelemetry. Use when working with Java code instrumentation, adding observability to Java applications, Spring Boot applications, or when asked about OpenTelemetry in Java, tracing in Java, metrics, spans, distributed tracing, Java agent, OTLP exporters, or instrumentation libraries for Java, Spring, Hibernate, JDBC, HTTP clients/servers, or any Java framework.

Expert knowledge for instrumenting JavaScript, TypeScript, React, and Node.js applications with OpenTelemetry. Use when working with JavaScript/TypeScript code instrumentation, adding observability to Node.js applications, Express.js servers, React frontends, Next.js applications, or when asked about OpenTelemetry in JavaScript/TypeScript, tracing, metrics, spans, distributed tracing in JS/TS, OTLP exporters, or instrumentation libraries for Node.js, React, Express, Next.js, GraphQL, databases (PostgreSQL, MongoDB, MySQL), or browser-based applications.

Force test-driven development for code changes. Use when implementing a feature, fixing a bug, changing behavior, refactoring logic, or when the user asks for TDD, test-first, red-green-refactor, or to write a failing test before code. Require the agent to start with the smallest failing automated test or executable characterization check, then make the minimum production change to pass, rerun focused verification, and only then broaden validation.