Cursor Agent’s iterate on lint feature is great.
I have a question, is it possible to change the details of the lint rule? If so, please let me know how to change it!
If not, such a feature would make modifications by the cursor agent more dependable!
have you tried using the .cursorrules file?
Try some of this – take the terminology from here and have it provide prompt snips for linting directives:
I took my original post above and had Composer add some additional info, which you may enjoy:
---
title: "AI Agent Linting Directives and Examples"
author: "Claude"
date: "`r Sys.Date()`"
output: html_document
---
## Core Linting Directives
### 1. Style Enforcement
ENFORCE: style=[guide] indent=[2|4] line_max=[80|120] case=[camel|snake|pascal] quotes=[single|double]
### 2. Error Prevention
CHECK: unused=true unreachable=true types=strict null_safety=true memory_leaks=true
ORGANIZE: group_methods=true sort_imports=true max_length=[function:20|class:100] extract_duplicates>3
DOCUMENT: public=required private=recommended todos=flag format=[jsdoc|numpy|google]
TYPES: annotations=required null_check=strict generics=enforce interfaces=validate
Input Prompt:
Review this code with:
ENFORCE: style=pep8 indent=4 line_max=80 case=snake
Sample Code:
def calculateUserScore(userName, userAge):
userScore=userAge*2+len(userName)*3
return userScore
Expected Output:
def calculate_user_score(user_name, user_age):
"""Calculate user score based on age and name length."""
user_score = user_age * 2 + len(user_name) * 3
return user_score
Input Prompt:
Analyze with:
CHECK: unused=true unreachable=true types=strict
Sample Code:
function processData(data: any) {
const temp = "unused";
if (false) {
return "never";
}
return data;
}
Expected Output:
// Violations:
// 1. Unused variable 'temp'
// 2. Unreachable code in if block
// 3. Unsafe 'any' type
function processData(data: unknown) {
return data;
}
Input Prompt:
Refactor using:
ORGANIZE: group_methods=true sort_imports=true max_length=20
Sample Code:
import { z } from 'zod';
import { useState } from 'react';
import { query } from './db';
function validateAndProcessAndTransformAndStoreDataInMultipleSteps(data) {
// ... 50 lines of code ...
}
Expected Output:
import { query } from './db';
import { useState } from 'react';
import { z } from 'zod';
function validateData(data) {
// ... validation logic
}
function processData(validData) {
// ... processing logic
}
function transformData(processedData) {
// ... transformation logic
}
function storeData(transformedData) {
// ... storage logic
}
OPTIMIZE: complexity=[O(n)] memory=[linear] async=true cache=recommended
SECURE: input=sanitize sql=parameterize auth=validate csrf=check
TEST: coverage=80 unit=required integration=recommended e2e=optional
{
"extends": ["eslint:recommended"],
"rules": {
"max-len": ["error", { "code": 80 }],
"indent": ["error", 4],
"quotes": ["error", "single"]
}
}
{
"printWidth": 80,
"tabWidth": 4,
"singleQuote": true,
"trailingComma": "es5"
}
"Apply strict linting with: ENFORCE + CHECK + ORGANIZE directives"
"Focus on type safety and error prevention first, then style"
"Apply all standard linting rules EXCEPT line length limits"
"Provide violation explanations with line numbers and severity levels"
ENFORCE: modern=[es6|py3] deprecate=warn upgrade=suggest
DOCUMENT: verbose=true examples=required context=full
CHECK: all=strict security=high performance=required
REVIEW: style=strict logic=analyze complexity=flag duplication=warn
Effective linting directives should be:
And here is:
| Project Type | Linting Focus | Directive Example | Expected Outcome |
|-------------|---------------|-------------------|------------------|
| Production Web App |
| React Frontend | Type Safety & Performance | ENFORCE: types=strict jsx=recommended bundle=optimize | - Strict TypeScript checking
- Optimized React patterns
- Bundle size warnings |
| Node.js Backend | Security & Error Handling | CHECK: security=high async=strict error=comprehensive | - Security vulnerability checks
- Proper async/await usage
- Complete error handling |
| Express API | Input Validation & Documentation | VALIDATE: params=strict docs=openapi security=high | - Route parameter validation
- OpenAPI compliance
- Security headers |
| Project Type | Linting Focus | Directive Example | Expected Outcome |
|-------------|---------------|-------------------|------------------|
| Data Science |
| Jupyter Notebooks | Reproducibility & Documentation | ENFORCE: imports=top docs=cells memory=optimize | - Organized imports
- Documented cells
- Memory usage warnings |
| ML Pipeline | Type Hints & Error Handling | CHECK: types=numpy tensor=validate data=sanitize | - NumPy type validation
- Tensor shape checking
- Data validation |
| Data Processing Scripts | Performance & Memory | OPTIMIZE: memory=strict parallel=suggest io=efficient | - Memory leak detection
- Parallelization hints
- I/O optimization |
| Project Type | Linting Focus | Directive Example | Expected Outcome |
|-------------|---------------|-------------------|------------------|
| Mobile Development |
| iOS/Swift | Memory & UI Performance | CHECK: memory=arc ui=main_thread lifecycle=validate | - ARC compliance
- UI thread validation
- Lifecycle checks |
| Android/Kotlin | Null Safety & Coroutines | ENFORCE: null=strict coroutines=best_practice compose=recommended | - Null safety warnings
- Coroutine pattern checks
- Compose optimization |
| React Native | Cross-Platform & Performance | OPTIMIZE: platform=both bundle=size battery=efficient | - Platform-specific code checks
- Bundle optimization
- Battery usage warnings |
| Project Type | Linting Focus | Directive Example | Expected Outcome |
|-------------|---------------|-------------------|------------------|
| DevOps & Infrastructure |
| Terraform | Security & Best Practices | SECURE: iam=strict secrets=encrypt state=validate | - IAM policy validation
- Secrets handling
- State file checks |
| Docker | Security & Efficiency | OPTIMIZE: layer=minimal security=rootless size=compress | - Layer optimization
- Security best practices
- Image size reduction |
| GitHub Actions | Security & Efficiency | CHECK: secrets=mask parallel=optimize timeout=suggest | - Secrets usage validation
- Parallel job suggestions
- Timeout recommendations |
| Project Type | Linting Focus | Directive Example | Expected Outcome |
|-------------|---------------|-------------------|------------------|
| Testing Projects |
| Unit Tests | Coverage & Isolation | TEST: coverage=90 mock=pure isolation=strict | - Coverage requirements
- Pure mock usage
- Test isolation |
| E2E Tests | Reliability & Performance | TEST: flaky=detect parallel=enable retry=smart | - Flaky test detection
- Parallel execution
- Smart retry logic |
| Integration Tests | Configuration & Setup | TEST: setup=isolated env=validate cleanup=required | - Isolated test setup
- Environment validation
- Cleanup verification |
| Project Type | Linting Focus | Directive Example | Expected Outcome |
|-------------|---------------|-------------------|------------------|
| Legacy Code |
| Modernization | Compatibility & Deprecation | MODERNIZE: syntax=target deprecate=warn upgrade=suggest | - Modern syntax checks
- Deprecation warnings
- Upgrade suggestions |
| Migration | Breaking Changes & Types | MIGRATE: breaking=detect types=add compatibility=check | - Breaking change detection
- Type addition suggestions
- Compatibility validation |
| Maintenance | Documentation & Stability | MAINTAIN: docs=update stability=strict deps=audit | - Documentation updates
- Stability checks
- Dependency audits |
ENFORCE: style=standard
CHECK: security=high
OPTIMIZE: performance=strict
PRIORITY: security=1 performance=2 style=3
ENFORCE: all=standard
EXCLUDE: line_length max_params
ENV: development
ENFORCE: strict=false
ENV: production
ENFORCE: strict=true
strict: Highest level of enforcement
recommended: Standard best practices
warn: Issue warnings instead of errors
suggest: Provide suggestions only
auto: Attempt automatic fixes
validate: Check without fixing
ignore: Skip specific rules
ENFORCE: style=standard
ENFORCE: style=standard
CHECK: project=custom_rules
PHASE: development
ENFORCE: style=relaxed
PHASE: production
ENFORCE: style=strict
DOCUMENT: public=required private=recommended
This cheatsheet can be expanded based on specific needs and technologies. Always consider:
Project requirements
Team preferences
Performance implications
Maintenance overhead
I implemented cursorrules, but not as thoroughly as SoMaCoSF suggests.
Now I just have improved the output somewhat by including in the cursorrules what I wanted to be verified during implementation.
However, this is a kind of prompt engineering, so it is not as reliable as lint like pylint and eslint.
I still feel the need to customize the details of the lint rules .
Heh - Ive been working my bot in over time on wrangling my understanding on how to granularly control attention to context:
---
title: "YOLOREN.AI Context Inventory"
subtitle: "A Comprehensive Guide to Project Structure and Development Practices"
date: "`r format(Sys.time(), '%B %d, %Y')`"
author: "YOLOREN.AI Development Team"
output:
html_document:
theme: darkly
toc: true
toc_float: true
code_folding: hide
df_print: paged
---
```{r setup, include=FALSE}
knitr::opts_chunk$set(
echo = FALSE,
message = FALSE,
warning = FALSE,
fig.width = 10,
fig.height = 6
)
# Load required libraries
library(knitr)
library(kableExtra)
library(ggplot2)
library(dplyr)
library(tidyr)
library(viridis)
library(plotly)
This document provides a comprehensive inventory of the YOLOREN.AI project context, including file structure, linting directives, feature toggles, and development personas. It serves as a central reference for understanding the project’s architecture and development practices.
YOLOREN.AI is a sophisticated platform that combines React-based frontend development with powerful backend services. The project emphasizes:
The project’s file structure is organized into several key categories, each serving specific purposes in the development workflow.
files_df <- data.frame(
File = c(
"fix-react-structure.ps1",
"setup-react-components.ps1",
"launch-dev.ps1",
"setup-react-core.ps1",
"create-linting-guide.ps1",
"composer-linting-eli5.md",
"development_diary.md",
"setup-yolorenai.ps1",
"Yolorenai.code-workspace",
".env",
"render-mermaid.ps1",
"YOLOREN.AI.Rmd",
"header.html",
"styles.css",
"yolo-db-setup.ps1",
"start-battles.ps1",
"yolo-deploy.ps1",
"yolo-monitor.ps1",
"setup-grafana.ps1",
"archive-version.ps1"
),
Type = c(
"Script", "Script", "Script", "Script", "Script",
"Documentation", "Documentation", "Script", "Config",
"Config", "Script", "Documentation", "Template",
"Styles", "Script", "Script", "Script", "Script",
"Script", "Script"
),
Path = c(
"D:/Cursor/Yolorenai/fix-react-structure.ps1",
"D:/Cursor/Yolorenai/setup-react-components.ps1",
"D:/Cursor/Yolorenai/launch-dev.ps1",
"D:/Cursor/Yolorenai/setup-react-core.ps1",
"D:/Cursor/Yolorenai/create-linting-guide.ps1",
"D:/Cursor/Yolorenai/composer-linting-eli5.md",
"D:/Cursor/Yolorenai/development_diary.md",
"D:/Cursor/Yolorenai/setup-yolorenai.ps1",
"D:/Cursor/Yolorenai/Yolorenai.code-workspace",
"D:/Cursor/Yolorenai/.env",
"D:/Cursor/Yolorenai/scripts/render-mermaid.ps1",
"D:/Cursor/Yolorenai/docs/YOLOREN.AI.Rmd",
"D:/Cursor/Yolorenai/docs/header.html",
"D:/Cursor/Yolorenai/docs/styles.css",
"D:/Cursor/Yolorenai/scripts/yolo-db-setup.ps1",
"D:/Cursor/Yolorenai/scripts/start-battles.ps1",
"D:/Cursor/Yolorenai/scripts/yolo-deploy.ps1",
"D:/Cursor/Yolorenai/scripts/yolo-monitor.ps1",
"D:/Cursor/Yolorenai/scripts/setup-grafana.ps1",
"D:/Cursor/Yolorenai/scripts/archive-version.ps1"
),
Purpose = c(
"React app structure setup",
"React component creation",
"Development server management",
"Core React files setup",
"Linting guide generation",
"Simplified linting explanation",
"Development progress tracking",
"Project initialization",
"VS Code workspace settings",
"Environment configuration",
"Mermaid diagram rendering",
"Main documentation",
"Documentation header template",
"Documentation styling",
"Database setup",
"Battle system management",
"Deployment automation",
"System monitoring",
"Grafana setup",
"Version archiving"
)
)
# Display the table
kable(files_df, format = "html", escape = FALSE) %>%
kable_styling(bootstrap_options = c("striped", "hover", "condensed"))
# Create a visualization of file type distribution
files_df %>%
count(Type) %>%
ggplot(aes(x = reorder(Type, n), y = n, fill = Type)) +
geom_bar(stat = "identity") +
coord_flip() +
theme_minimal() +
labs(
title = "Distribution of File Types",
x = "File Type",
y = "Count",
fill = "Type"
) +
scale_fill_viridis_d()
Our linting system employs a sophisticated set of directives to ensure code quality and consistency across the project.
directives_df <- data.frame(
Directive = c(
"ENFORCE",
"CHECK",
"OPTIMIZE",
"style=airbnb",
"jsx=strict",
"security=high",
"async=true",
"bundle=size",
"cache=check",
"data=sanitize",
"null=strict",
"memory=efficient",
"tensor=validate",
"docs=required",
"tests=coverage:80"
),
Context = c(
"Global", "Global", "Global",
"Frontend", "Frontend", "Backend",
"Backend", "Full Stack", "Full Stack",
"ETL", "ETL", "ML",
"ML", "Analytics", "Analytics"
),
Source = c(
"create-linting-guide.ps1",
"create-linting-guide.ps1",
"create-linting-guide.ps1",
"composer-linting-eli5.md",
"composer-linting-eli5.md",
"development_diary.md",
"development_diary.md",
"development_diary.md",
"development_diary.md",
"development_diary.md",
"development_diary.md",
"development_diary.md",
"development_diary.md",
"development_diary.md",
"development_diary.md"
),
Purpose = c(
"Strict rule enforcement",
"Validation with warnings",
"Performance improvements",
"Airbnb style guide compliance",
"Strict JSX validation",
"High security standards",
"Asynchronous operations",
"Bundle size optimization",
"Cache validation",
"Data sanitization",
"Strict null checking",
"Memory optimization",
"Tensor validation",
"Documentation requirements",
"Test coverage requirements"
)
)
kable(directives_df, format = "html", escape = FALSE) %>%
kable_styling(bootstrap_options = c("striped", "hover", "condensed"))
# Visualize directive distribution across contexts
directives_df %>%
count(Context) %>%
ggplot(aes(x = "", y = n, fill = Context)) +
geom_bar(stat = "identity", width = 1) +
coord_polar("y") +
theme_minimal() +
labs(
title = "Distribution of Directives Across Contexts",
fill = "Context"
) +
scale_fill_viridis_d()
The project uses a comprehensive set of feature toggles and settings to control various aspects of the system’s behavior.
settings_df <- data.frame(
Setting = c(
"DEBUG",
"LOG_LEVEL",
"BATTLE_MIN_AGENTS",
"BATTLE_MAX_AGENTS",
"BATTLE_TIMEOUT_SECONDS",
"MIN_BET_AMOUNT",
"MAX_BET_AMOUNT",
"HOUSE_EDGE_PERCENT",
"DEFAULT_AGENT_MEMORY_MB",
"DEFAULT_AGENT_TIMEOUT_MS",
"MAX_CONCURRENT_BATTLES"
),
Value = c(
"True",
"INFO",
"2",
"10",
"3600",
"0.001",
"100.0",
"2.5",
"512",
"30000",
"5"
),
Source = c(
".env",
".env",
".env",
".env",
".env",
".env",
".env",
".env",
".env",
".env",
".env"
),
Purpose = c(
"Debug mode toggle",
"Logging verbosity",
"Minimum agents per battle",
"Maximum agents per battle",
"Battle timeout in seconds",
"Minimum bet amount",
"Maximum bet amount",
"House edge percentage",
"Default agent memory limit",
"Default agent timeout",
"Maximum concurrent battles"
)
)
kable(settings_df, format = "html", escape = FALSE) %>%
kable_styling(bootstrap_options = c("striped", "hover", "condensed"))
# Create a treemap of settings categories
settings_df %>%
mutate(Category = case_when(
grepl("BATTLE", Setting) ~ "Battle System",
grepl("AGENT", Setting) ~ "Agent Configuration",
grepl("BET", Setting) ~ "Betting System",
TRUE ~ "System Configuration"
)) %>%
count(Category) %>%
ggplot(aes(area = n, fill = Category, label = paste(Category, "\n", n))) +
geom_treemap() +
geom_treemap_text(colour = "white", place = "centre", size = 15) +
scale_fill_viridis_d() +
labs(title = "Settings Distribution by Category")
Our development process is enriched by a diverse set of personas, each bringing unique perspectives and priorities to the project.
personas_df <- data.frame(
Persona = c(
"YOLO Developer",
"Security Auditor",
"Performance Optimizer",
"Documentation Writer",
"Code Reviewer",
"System Architect",
"DevOps Engineer",
"Database Administrator",
"Frontend Specialist",
"Backend Engineer"
),
Focus = c(
"Rapid development & innovation",
"Security & compliance",
"System optimization",
"Documentation & clarity",
"Code quality & standards",
"System design & architecture",
"Deployment & automation",
"Database management",
"UI/UX development",
"API & service development"
),
Source = c(
"development_diary.md",
"yolo-monitor.ps1",
"yolo-monitor.ps1",
"YOLOREN.AI.Rmd",
"create-linting-guide.ps1",
"setup-yolorenai.ps1",
"yolo-deploy.ps1",
"yolo-db-setup.ps1",
"setup-react-core.ps1",
"yolo-db-setup.ps1"
),
Traits = c(
"Fast, innovative, risk-tolerant",
"Thorough, cautious, detail-oriented",
"Analytical, efficiency-focused",
"Clear, organized, comprehensive",
"Meticulous, standards-focused",
"Strategic, big-picture oriented",
"Automation-focused, systematic",
"Data-centric, reliability-focused",
"User-focused, design-oriented",
"Scalability-focused, robust"
)
)
kable(personas_df, format = "html", escape = FALSE) %>%
kable_styling(bootstrap_options = c("striped", "hover", "condensed"))
# Create a network visualization of persona relationships
library(igraph)
library(networkD3)
# Create relationships between personas based on complementary skills
nodes <- data.frame(
name = personas_df$Persona,
group = match(personas_df$Focus, unique(personas_df$Focus))
)
# Create edges between complementary personas
edges <- data.frame(
source = c(1, 1, 2, 2, 3, 3, 4, 4, 5),
target = c(2, 3, 3, 4, 4, 5, 5, 6, 6)
)
# Create network
network <- forceNetwork(
Links = edges,
Nodes = nodes,
Source = "source",
Target = "target",
NodeID = "name",
Group = "group",
opacity = 0.8,
fontSize = 12,
zoom = TRUE
)
network
Strategic combinations of personas and directives can optimize development outcomes for different focus areas.
recommendations_df <- data.frame(
Focus = c(
"Development Speed",
"Code Quality",
"Security",
"Performance",
"Documentation",
"Architecture",
"DevOps",
"Database",
"Frontend",
"Backend"
),
Recommended_Personas = c(
"YOLO Developer + Performance Optimizer",
"Code Reviewer + System Architect",
"Security Auditor + DevOps Engineer",
"Performance Optimizer + Backend Engineer",
"Documentation Writer + Frontend Specialist",
"System Architect + Database Administrator",
"DevOps Engineer + YOLO Developer",
"Database Administrator + Backend Engineer",
"Frontend Specialist + Documentation Writer",
"Backend Engineer + System Architect"
),
Recommended_Directives = c(
"OPTIMIZE + async=true",
"ENFORCE + style=airbnb",
"CHECK + security=high",
"OPTIMIZE + memory=efficient",
"ENFORCE + docs=required",
"CHECK + null=strict",
"OPTIMIZE + cache=check",
"ENFORCE + data=sanitize",
"ENFORCE + jsx=strict",
"CHECK + async=true"
),
Impact = c(
"Rapid iteration with performance awareness",
"High-quality, maintainable code",
"Secure, reliable systems",
"Optimized system performance",
"Clear, comprehensive documentation",
"Robust system architecture",
"Efficient deployment pipeline",
"Reliable data management",
"Polished user experience",
"Scalable backend services"
)
)
kable(recommendations_df, format = "html", escape = FALSE) %>%
kable_styling(bootstrap_options = c("striped", "hover", "condensed"))
# Create a heatmap of focus areas and their impacts
recommendations_df %>%
mutate(
Impact_Score = sample(7:10, n(), replace = TRUE) # Simulated impact scores
) %>%
ggplot(aes(x = Focus, y = "Impact", fill = Impact_Score)) +
geom_tile() +
scale_fill_viridis() +
theme_minimal() +
theme(axis.text.x = element_text(angle = 45, hjust = 1)) +
labs(
title = "Impact Assessment Heatmap",
x = "Focus Area",
y = NULL
)
The project includes several PowerShell scripts organized by their primary functions. Below is a comprehensive inventory of these utilities:
library(knitr)
library(kableExtra)
ps_utils <- data.frame(
Category = c(
"Setup & Installation",
"Setup & Installation",
"Setup & Installation",
"Setup & Installation",
"Setup & Installation",
"Development",
"Development",
"Development",
"Documentation",
"Documentation",
"Documentation",
"Deployment",
"Deployment",
"Deployment",
"Monitoring",
"Monitoring",
"Database",
"Database",
"Version Control"
),
Script = c(
"setup-yolorenai.ps1",
"setup-react-core.ps1",
"setup-r-environment.ps1",
"install-r-packages.ps1",
"install-gh-cli.ps1",
"fix-react-structure.ps1",
"setup-react-components.ps1",
"launch-dev.ps1",
"render-in-new-session.ps1",
"render-mermaid.ps1",
"deploy-to-ghpages.ps1",
"yolo-deploy.ps1",
"setup-grafana.ps1",
"create-linting-guide.ps1",
"yolo-monitor.ps1",
"start-battles.ps1",
"yolo-db-setup.ps1",
"init-db.ps1",
"archive-version.ps1"
),
Description = c(
"Main project setup script that initializes the development environment",
"Sets up the React application core with TypeScript configuration",
"Configures R environment with required packages and settings",
"Installs required R packages for documentation generation",
"Installs GitHub CLI for repository management",
"Fixes and organizes React project structure",
"Sets up React components with proper configuration",
"Development server launcher with port conflict resolution",
"Renders documentation in a new PowerShell session",
"Generates Mermaid diagrams for documentation",
"Deploys documentation to GitHub Pages",
"Main deployment script for the YOLOREN.AI system",
"Sets up Grafana dashboards for monitoring",
"Creates linting documentation and guidelines",
"Monitors system performance and health",
"Manages battle simulation processes",
"Sets up the database schema and initial data",
"Initializes database with required tables",
"Manages version control for documentation and code"
)
)
kable(ps_utils,
format = "html",
caption = "PowerShell Utility Scripts Inventory"
) %>%
kable_styling(
bootstrap_options = c("striped", "hover", "condensed"),
full_width = TRUE
) %>%
column_spec(1, bold = TRUE) %>%
collapse_rows(columns = 1, valign = "middle")
PowerShell scripts are organized in the following directory structure:
YOLORENAI/
├── scripts/ # Core system scripts
│ ├── deployment/ # Deployment-related scripts
│ ├── monitoring/ # Monitoring and health check scripts
│ └── database/ # Database management scripts
├── docs/ # Documentation scripts
│ └── tools/ # Documentation generation tools
└── dev/ # Development utilities
├── setup/ # Setup and installation scripts
└── tools/ # Development tools and utilities
The YOLOREN.AI context sphere is managed through a PostgreSQL database with the following structure:
erDiagram
files ||--o{ context_relationships : "participates_in"
directives ||--o{ context_relationships : "participates_in"
settings ||--o{ context_relationships : "participates_in"
personas ||--o{ context_relationships : "participates_in"
powershell_utils ||--o{ context_relationships : "participates_in"
focus_areas ||--o{ context_relationships : "influences"
files {
int file_id PK
string file_name
string file_type
string file_path
string purpose
timestamp created_at
timestamp updated_at
}
directives {
int directive_id PK
string directive_name
string context
string source_file
string purpose
timestamp created_at
}
settings {
int setting_id PK
string setting_name
string setting_value
string source_file
string purpose
boolean is_toggle
timestamp created_at
timestamp updated_at
}
personas {
int persona_id PK
string persona_name
string focus_area
string source_file
string traits
timestamp created_at
}
powershell_utils {
int script_id PK
string script_name
string category
string description
string file_path
timestamp created_at
timestamp updated_at
}
context_relationships {
int relationship_id PK
string source_type
int source_id
string target_type
int target_id
string relationship_type
float strength
timestamp created_at
}
focus_areas {
int focus_id PK
string focus_name
array recommended_personas
array recommended_directives
string impact_description
int impact_score
timestamp created_at
}
The schema is designed to capture the entire context sphere of the YOLOREN.AI project, including:
The relationships between different context elements are visualized below:
graph TD
subgraph "Development Context"
F[Files] --> D[Directives]
D --> S[Settings]
S --> P[Personas]
P --> U[PowerShell Utils]
end
subgraph "Focus Areas"
FA1[Development Speed]
FA2[Code Quality]
FA3[Security]
FA4[Performance]
end
subgraph "Relationships"
R[Context Relationships]
R --> F
R --> D
R --> S
R --> P
R --> U
R --> FA1
R --> FA2
R --> FA3
R --> FA4
end
style Development fill:#f9f,stroke:#333,stroke-width:2px
style "Focus Areas" fill:#bbf,stroke:#333,stroke-width:2px
style Relationships fill:#bfb,stroke:#333,stroke-width:2px
This context inventory provides a comprehensive overview of the YOLOREN.AI project’s structure, development practices, and organizational patterns. By following these guidelines and leveraging the provided tools and personas, we can maintain high-quality development practices while ensuring efficient project progression.
I came here to post about the same issue:
I think prompt engineering for this is the wrong approach. Prompt engineering is hard enough as is and code linters/formatters have been working well for many years already.
What seems to be the issue right now is that the linting configuration Cursor uses for the “Iterate on lints” feature is not configurable. Ideally it would intelligently check the current repository for files like
and then surface those linting/formatting violations to Composer (normal and agent). This would do wonders to improve model output and drastically reduce time spent fixing errors downstream.
In addition, Cursor should probably check for any linting/formatting configuration on user/workspace/default settings level of the editor itself like some language server extensions allow.
I realize this feature is still in beta due to not being trivial to implement… but the current implementation (as of Cursor 0.44.8) is already so great I wish it were fully implemented already because it’s so ■■■■ useful.
Thanks for the more concrete suggestions. @ichoosetoaccept
I agree with it. The addition of guardrails by the existing lint tool would make the cursor agent work more reliably.
