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.
git clone --depth 1 https://github.com/Srajangpt1/agent-rule-syncWrote this? Show the measurements
A badge with what this costs and how it scanned, read live from this page, so it follows the numbers instead of freezing them. Markdown for a README, HTML for a documentation site or a project page.
[](https://agentmods.dev/rules/srajangpt1/agent-rule-sync/structure)<a href="https://agentmods.dev/rules/srajangpt1/agent-rule-sync/structure"><img src="https://agentmods.dev/badge/rules/srajangpt1/agent-rule-sync/structure/github.svg" alt="Measured on agentmods" height="20"></a>Or the 80×15 button, for a site that already has a row of RSS and ATOM ones. Only the verdict fits; the numbers stay here.
<a href="https://agentmods.dev/rules/srajangpt1/agent-rule-sync/structure"><img src="https://agentmods.dev/badge/rules/srajangpt1/agent-rule-sync/structure.svg" alt="Reviewed on agentmods" width="80" height="20"></a>What 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.1 | $0.00010 | $0.00641 |
| Opus 5.5 | $0.00004 | $0.00256 |
| Sonnet 5.5 | $0.00002 | $0.00128 |
| Haiku 4.5 | $0.00001 | $0.00064 |
Grade A, and why
structure 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 1mo 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.
What it actually says
-
Directory Organization: Source code in src/ directory. Compiled output in dist/ directory. Configuration files (package.json, tsconfig.json) at root. Documentation (README.md, LICENSE) at root. Use .cursor/rules/ for generated rules output.
- src/ ├── types.ts ├── analyzer.ts ├── rules-manager.ts ├── cli.ts └── index.ts
- dist/ (generated) .cursor/ rules/ (generated)
-
File Naming Conventions: Use kebab-case for file names: analyzer.ts, rules-manager.ts, cli.ts. Use descriptive names that indicate file purpose. Keep file names short but clear. Use .ts extension for TypeScript source files.
- analyzer.ts - cursor-agent integration
- rules-manager.ts - rules file management
- cli.ts - command-line interface
-
Module Structure: Each file should represent a single module with a clear responsibility. index.ts serves as the main entry point and re-exports public APIs. Group related functionality together. Keep modules focused and cohesive.
- index.ts - main API, re-exports types
- analyzer.ts - all cursor-agent interaction logic
- rules-manager.ts - all file system operations for rules
-
Import/Export Patterns: Use relative imports for local modules (./types, ./analyzer). Use absolute imports for node_modules. Export public API from index.ts. Keep internal implementation details private (don't export utility functions unless needed by other modules).
- import { generateRules } from './index';
- import { checkCursorAgent } from './analyzer';
- export * from './types';
-
Entry Points: index.ts is the main library entry point exporting public API. cli.ts is the CLI entry point (has shebang #!/usr/bin/env node). Package.json defines main (dist/index.js) and bin (dist/cli.js) entry points. Build script should set executable permissions on CLI (chmod +x dist/cli.js).
- // index.ts export async function generateRules(...) { }
- #!/usr/bin/env node // cli.ts import { Command } from 'commander';
- "scripts": { "build": "tsc && chmod +x dist/cli.js" }
-
Configuration Files: tsconfig.json at root with strict settings. package.json defines scripts, dependencies, and metadata. Keep configuration files at root level. Use standard naming conventions for config files.
- tsconfig.json - TypeScript compiler options
- package.json - npm/yarn package configuration
-
Type Definition Centralization: All TypeScript interfaces and types should be defined in types.ts. This provides a single source of truth for type definitions and makes them easily importable across modules.
- // types.ts export interface GenerateRulesConfig { ... } export interface AnalysisResult { ... }
- // Other files import { GenerateRulesConfig, AnalysisResult } from './types';
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.
- 1mo ago First seen · 53 lines · 10 tokens per session scan A fd193abb1efe
structure is a cursor rule published in the GitHub repository Srajangpt1/agent-rule-sync (12 stars, last pushed 7mo ago), licensed MIT. It adds 10 tokens to every session and 641 once invoked, about $0.0000 per session on Opus 5.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-30.
Other cursor rules, from other repositories
ponytail
Ponytail, lazy senior dev mode. Always pick the simplest solution that works.
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.
prefer-assertions-over-defensive-checks
Prefer assertions over defensive checks when data is guaranteed to be valid.
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.
config-validation-and-normalization
Config validation and normalization responsibilities (defineConfig normalizes, the orm section schema validates and resolves paths, the loader reports per-section diagnostics).