Getting it into your agent
One page per mod, every tool's command on it. A separate URL per tool would split the same page into five that compete with each other.
npx agentmods add rules/jrpribs/smarterstarter/950-angular-data-flowgit clone --depth 1 https://github.com/JrPribs/SmarterStarterWhat it costs to keep this loaded
Counted locally with the o200k_base tokenizer, which is exact for GPT models; Claude uses its own tokenizer and its counts differ. Treat this as one consistent yardstick across the catalogue rather than a bill. Prices are per million input tokens.
| Model | Per session | Once invoked |
|---|---|---|
| Fable 5 | $0.00011 | $0.03198 |
| Opus 5 | $0.00005 | $0.01599 |
| Sonnet 5 | $0.00002 | $0.00640 |
| Haiku 4.5 | $0.00001 | $0.00320 |
Grade A, and why
950-angular-data-flow scanned grade A with 0 findings against 26 rules in 11 categories — prompt injection, anti-refusal, data exfiltration, privilege escalation, supply chain, agent snooping, system-prompt leakage, SSRF and excessive agency — measured 2d ago.
A static scan of the body, not an audit. Every finding is printed with the line that produced it so you can judge whether it matters here. A mod is markdown that instructs an agent; that is exactly why what it instructs is worth reading.
Nothing flagged
None of the 26 patterns this scan looks for appear in this file: no shell pipes, no recursive deletes, no credential paths, no hidden text, no instruction-override or anti-refusal phrasing, no agent-config snooping. That is not a guarantee, it is the absence of the things that are checkable.
How it starts
The opening of the file, as written. The whole thing — 513 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Angular Data Flow Patterns
- Bi-directional Data Flow Architecture: Follow a consistent data flow pattern in the application:
READ (Direct)
┌─────────────────────────┐
│ │
▼ │
┌───────────────────┐ ┌───────────────────┐
│ │ │ │
│ Components │ │ Global State │
│ (Consumers) │ │ (Storage) │
│ │ │ │
└───────────────────┘ └───────────────────┘
│ ▲
▼ │
┌───────────────────┐ │
│ │ │
│ Services │────────────────┘
│ │
└───────────────────┘
- Read Operations (Global State to Component): Components read directly from the global state via store signals.
@Component({
selector: 'app-product-detail',
template: `
@if (isLoading()) {
<app-spinner></app-spinner>
} @else if (product()) {
<h1>{{ product()?.name }}</h1>
<p>{{ product()?.description }}</p>
<p>Price: {{ product()?.price | currency }}</p>
<button (click)="addToCart(product()!.id)">Add to Cart</button>
} @else {
<p>Product not found</p>
}
`
})
export class ProductDetailComponent {
// Read directly from store signals
product = inject(ProductStore).selectedProduct;
isLoading = inject(ProductStore).loading;
constructor(private cartService: CartService) {}
// Action through service
addToCart(productId: string): void {
this.cartService.addToCart(productId);
}
}
- Write Operations (Component to Global State): Components write to global state through services, not directly.
// ❌ AVOID: Component manipulating state directly
@Component({...})
export class BadComponent {
constructor(private userStore: UserStore) {}
updateUser() {
// Direct store manipulation from component is an anti-pattern
this.userStore.setUser({
id: '123',
name: 'John Doe',
email: '[email protected]'
});
}
}
// ✅ GOOD: Component using service as mediator
@Component({...})
export class GoodComponent {
// Reading from store is fine
user = inject(UserStore).user;
// Writing goes through service
constructor(private userService: UserService) {}
updateUser() {
// Service handles validation, API calls, and store updates
this.userService.updateUser({
id: '123',
name: 'John Doe',
email: '[email protected]'
});
}
}
- Service as Mediator: Services handle business logic, API communication, and state updates.
@Injectable({
providedIn: 'root'
})
export class ProductService {
constructor(
private http: HttpClient,
private productStore: ProductStore
) {}
loadProducts(): Observable<Product[]> {
// Update loading state
this.productStore.setLoading(true);
// Call API
return this.http.get<Product[]>('/api/products').pipe(
tap(products => {
// Update state with returned data
this.productStore.setProducts(products);
this.productStore.setLoading(false);
}),
catchError(error => {
// Update error state
this.productStore.setError(error.message);
this.productStore.setLoading(false);
return throwError(() => error);
})
);
}
addProduct(product: Product): Observable<Product> {
// Validate product
if (!this.validateProduct(product)) {
return throwError(() => new Error('Invalid product'));
}
// Call API
return this.http.post<Product>('/api/products', product).pipe(
tap(newProduct => {
// Update store with new product
this.productStore.addProduct(newProduct);
})
);
}
private validateProduct(product: Product): boolean {
// Business logic validation
return !!product.name && product.price > 0;
}
}
What this file has done since we first saw it
Hashed on every crawl. A supply-chain change to an agent config is a question of when, not whether, so the history is kept rather than the latest state alone.
- 2d ago First seen · 513 lines · 11 tokens per session scan A 0739f683f9f9
950-angular-data-flow is a cursor rule published in the GitHub repository JrPribs/SmarterStarter (2 stars, last pushed 1y ago), licensed MIT. It adds 11 tokens to every session and 3,198 once invoked, about $0.0001 per session on Opus 5. A static security scan graded it A with 0 findings. No closer match exists in the catalogue, so it is treated as the original; first seen 2026-08-31.
Other cursor rules, from other repositories
angular-20
This rule provides comprehensive best practices and coding standards for Angular development, focusing on modern TypeScript, standalone components, signals, and performance optimizations.
dev-standard
Apache Superset development standards and guidelines for Cursor IDE.
cli-error-handling
CLI command error handling patterns.
prefer-direct-imports-over-module-mocks
Prefer extracting a testable core over vi.mock / vi.resetModules when unit tests need to reach production logic entangled with config, env, or singletons.
control-plane-descriptors
Control plane descriptor and instance implementation patterns.
family-instance-domain-actions
Family instance domain action implementation patterns.