rudder-design-first-instrumentation — independently scanned and version-tracked by SaferSkills.
SaferSkills independently audited rudder-design-first-instrumentation (Agent Skill) and scored it 100/100 (green). The audit ran 55 deterministic rules across Security, Supply Chain, Maintenance, Transparency, and Community; it found 0 high-severity and 0 lower-severity findings. The full rule-by-rule trace and per-finding evidence are below. Free, methodology-open.
Findings & checks · 0 flagged
Every scanned point with the score it earned and what moved between them.
First recorded scan — no prior version to compare against.
The primary manifest — the file an agent reads to learn what this artifact does.
This skill guides instrumentation planning for new features where events are defined during product definition, before implementation begins.
| Scenario | Use This Skill? |
|---|---|
| Building a new feature, events not yet defined | Yes |
| Product requirements include analytics needs | Yes |
| PM and engineering collaborating on what to track | Yes |
| Existing product needs instrumentation | No — use rudder-code-first-instrumentation |
| Restructuring existing tracking | No — use rudder-code-first-instrumentation |
┌─────────────────────────────────────────────────────────────────────┐
│ DESIGN-FIRST INSTRUMENTATION │
└─────────────────────────────────────────────────────────────────────┘
│
▼
┌─────────────────┐
│ 1. REQUIREMENTS │ ← What questions must the data answer?
└────────┬────────┘
▼
┌─────────────────┐
│ 2. EVENT DESIGN │ ← Define events (names only, no properties yet)
└────────┬────────┘
▼
┌─────────────────┐
│ 3. HUMAN │ ← PM/Eng review: Are these the right events?
│ CHECKPOINT │
└────────┬────────┘
▼
┌─────────────────┐
│ 4. PROPERTY │ ← Define properties for approved events
│ DESIGN │
└────────┬────────┘
▼
┌─────────────────┐
│ 5. BUILD YAML │ ← Create tracking plan definitions
└────────┬────────┘
▼
┌─────────────────┐
│ 6. IMPLEMENT │ ← Code the feature with instrumentation
└─────────────────┘Start with the questions the data must answer:
## Feature: [Feature Name]
### Business Questions
- [ ] What is the conversion rate through this feature?
- [ ] Where do users drop off?
- [ ] How long does it take users to complete the flow?
- [ ] What variations do users prefer?
### Success Metrics
- Primary: _______________
- Secondary: _______________
### Funnel Stages
1. Entry point: _______________
2. Key action: _______________
3. Completion: _______________
### Stakeholders
- PM: _______________
- Engineering: _______________
- Data/Analytics: _______________Define events as user stories or behavioral descriptions first — no properties yet.
Use clear, behavioral language:
## Events for [Feature Name]
### Event: Feature Opened
- **When:** User opens the feature for the first time in a session
- **Why track:** Measures feature discovery and initial engagement
- **Funnel position:** Entry
### Event: Configuration Started
- **When:** User begins configuring the feature
- **Why track:** Measures intent to use feature
- **Funnel position:** Middle
### Event: Configuration Completed
- **When:** User successfully completes configuration
- **Why track:** Measures successful adoption
- **Funnel position:** Completion
### Event: Configuration Failed
- **When:** User encounters an error during configuration
- **Why track:** Identifies friction points
- **Funnel position:** Error state| Pattern | Example | Use For |
|---|---|---|
| Feature + Action (Past Tense) | Audience Created | Completed actions |
| Feature + State | Checkout Started | State transitions |
| Object + Action | Product Viewed | Standard interactions |
Critical: Before defining properties, get alignment on events.
## Event Review Sign-Off
Feature: _______________
Date: _______________
Approved Events:
- [ ] Event 1: _______________
- [ ] Event 2: _______________
- [ ] Event 3: _______________
Rejected/Deferred:
- [ ] _______________
Approved by:
- PM: _______________
- Engineering: _______________After events are approved, define properties for each.
For each event, ask:
## Event: Audience Created
### Required Properties
| Property | Type | Description | Example |
|----------|------|-------------|---------|
| audience_id | string | Unique identifier | "aud_123" |
| audience_name | string | User-provided name | "High Value Users" |
| condition_count | integer | Number of conditions | 3 |
### Optional Properties
| Property | Type | Description | Example |
|----------|------|-------------|---------|
| template_used | string | If created from template | "ecommerce-buyers" |
| creation_method | string | How it was created | "wizard" \| "manual" |
### Context (Auto-included)
- workspace_id (from session context)
- user_id (from identify)Look for properties used across multiple events — these become custom types:
## Shared Patterns Identified
### AudienceType (used by: Created, Updated, Deleted)
- audience_id
- audience_name
- audience_type
### ConditionType (used by: Created, Updated)
- condition_id
- condition_type
- condition_operatorConvert approved designs to tracking plan YAML.
1. Custom Types ← Reusable patterns identified in Phase 4
2. Properties ← Individual property definitions
3. Categories ← Organize events by feature/domain
4. Events ← Reference properties and custom types
5. Tracking Plan ← Bundle events for the sourceversion: "rudder/v1"
kind: "custom-type"
metadata:
name: "custom-types"
spec:
name: "AudienceType"
type: "object"
description: "Core audience information"
config:
properties:
- property: "urn:rudder:property/audience_id"
required: true
- property: "urn:rudder:property/audience_name"
required: true
- property: "urn:rudder:property/audience_type"
required: trueversion: "rudder/v1"
kind: "event"
metadata:
name: "events"
spec:
name: "Audience Created"
description: "User successfully created a new audience"
category: "urn:rudder:category/audiences"
rules:
- property: "urn:rudder:property/audience"
required: true
customType: "urn:rudder:custom-type/audience-type"
- property: "urn:rudder:property/condition_count"
required: true
- property: "urn:rudder:property/template_used"
- property: "urn:rudder:property/creation_method"# Validate definitions
rudder-cli validate -l ./
# Preview changes
rudder-cli apply --dry-run -l ./
# Apply to workspace
rudder-cli apply -l ./With tracking plan applied, implement the feature with instrumentation.
// Feature implementation with instrumentation
async function createAudience(config: AudienceConfig): Promise<Audience> {
const audience = await audienceService.create(config);
// Instrumentation
analytics.track('Audience Created', {
audience_id: audience.id,
audience_name: audience.name,
audience_type: audience.type,
condition_count: config.conditions.length,
template_used: config.templateId || null,
creation_method: config.method,
});
return audience;
}PM writes event descriptions (Phase 2)
↓
Engineering reviews for feasibility
↓
Joint checkpoint (Phase 3)
↓
Engineering leads property design (Phase 4)
↓
PM validates properties answer questions
↓
Engineering implementsEngineering drafts events based on feature spec
↓
PM reviews for analytics completeness
↓
Joint refinement
↓
Engineering completes properties + implementationFor complete end-to-end examples including RudderStack Audiences and Transformations features, see references/real-world-examples.md.
| Mistake | Problem | Fix |
|---|---|---|
| Skipping human checkpoint | Events don't answer business questions | Always get sign-off before properties |
| Properties before events | Scope creep, over-instrumentation | Define event names first, properties second |
| Too granular events | Data bloat, high costs | Use properties for variations, not separate events |
| Missing error states | Can't diagnose failures | Always include failure/error events |
| No shared patterns | Duplicate properties, inconsistency | Identify custom types early |
| Enum values don't match code | Type mismatches, glue code needed | Check existing code types before defining properties |
Before implementation:
rudder-cli validate passes~30 seconds. Free. No account. Every finding cites a rule and a line of evidence.