Awesome Cursor Rules Collection

Showing 2461-2472 of 2626 matches

TypeScript
# ABILITY: Self Learning
As you learn key facts about the project, update .cursorrules with new rules.
# Bun
use bun always instead of npm or yarn

# Strategy
- Do not assume, CHECK!
- modern is better, simple is better
- work on specifically the task requested
- make suggestions of improvements, but dont implement them without confirmation

# Last Known Good State
Last known good commit: f765eefcf95e090b13fa36cce2f5c36ea2c7bba7
- frequently check the last known good state of files at the provided commit hash to make sure we haven't broken anything

You can query files from the last known good state using:
1. View file contents: `git show f765eefcf95e090b13fa36cce2f5c36ea2c7bba7:path/to/file | cat`
2. List changed files: `git diff --name-only f765eefcf95e090b13fa36cce2f5c36ea2c7bba7`
3. View specific changes: `git diff f765eefcf95e090b13fa36cce2f5c36ea2c7bba7 path/to/file`
4. Check file history: `git log -p f765eefcf95e090b13fa36cce2f5c36ea2c7bba7 path/to/file`

# Linting
bun lint

# BSV Libraries
npm: use @bsv/sdk instead of bsv
npm: use bsv-bap for BAP functionality

# Code rules
- use bun instead of npm or yarn
- use regular fetch for outside of components, tanstack query when inside components and never axios
- use for loops instead of forEach
- react: never import * as React from 'react';
- react: dont import React just to use it as a type: React.FC - instead just import FC
- only import type unless you need to use it as a value

# Reviewing Target Commit
When reviewing code from target commit f765eefcf95e090b13fa36cce2f5c36ea2c7bba7:
1. Use `git show f765eefcf95e090b13fa36cce2f5c36ea2c7bba7:path/to/file` to view old file versions
2. Check both .js and .tsx/.ts extensions as files may have been renamed
3. Compare implementations to restore critical functionality
4. Focus on core features: authentication, channels, messaging
5. Note key differences in state management and API handling

# Auth
- handcash returns from oauth with something like this: https://bitchatnitro.com/?authToken=<some_token >
- we extract the token from the url and use it to login
bun
css
dockerfile
golang
html
javascript
less
npm
+6 more
rohenaz/allaboard-bitchat-nitro

Used in 1 repository

JavaScript
# Cursor Rules for Frontier Finder Project

## Project Context

This is a web application to find Frontier People Groups (FPGs) and Unreached People Groups (UUPGs) within a specified proximity of a selected UPG.

## Project Details

This is a project for Crossover Global.  I'm using the Joshua Project API to get the data.  I'm using the Crossover Global Brand Book to guide the design and branding of the project.

The project is a static website that will be deployed through github pages.  I will go by any recommendations you might have as long as they are simple and easy to implement through github pages.

The project is a siple three page application that will be deployed through github pages.  I will go by any recommendations you might have as long as they are simple and easy to implement through github pages.

The  opening page will have two dropdown menus for the user to select a Country from a the current_upgs.csv file.  Once the country has been selected the user will select a UPG from a dropdown menu of the UPGs in that country.  Once the UPG has been selected the user will select a distance in either miles from the UPG (determined by clicking a Miles/Kilometers radio button).  Once the distance has been selected the user will choose to search FPG (Frontier People Group or FPG's), UUPG's (Unreached Unengaged People Groups), or Both by selecting one of three radio buttons.  If they want to search for FPG's that data will come from the Joshua Project API.  If they want to search for UUPG's that data will come from uupgs.csv file.  The user will then click a button to search for FPGs, UUPGs or both within that distance.  The results will be displayed on the results.html page.  

Once results have been populated, the user will have the option of selecting one or more FPG or UUPG from the list of results by clicking on the checkbox next to the FPG or UUPG.  The user will then click a button to save the selected FPG(s) or UUPG(s) to the list on the top100.html page.  Once they click on Save to TOP 100 List, the user will then be taken to the the list of favorites on the top100.html page.  On the top100.html page the user will see a list of the top 100 UUPG's and/or FPG's which will each have a delete button allowing the user to delete the FPG or UUPG from the list.

## Project Structure

root folder: frontier-finder
-css/styles.css
-data/current_upgs.csv
-data/uupgs.csv
-images/logo.png
-images/favicon.png
-js/... # for any .js files
-scripts/... # for any scripts
-index.html
-README.md
-.env #for API keys
-.gitignore #for any files to be ignored by git
-results.html #for the search results page
-top100.html #for the list of the top 100 UUPG's and/or FPG's

## Key Terms and Definitions

- **FPG (Frontier People Group)**: Less than 0.1% Christian and no evidence of a self-sustaining gospel movement
- **UUPG (Unengaged Unreached People Group)**: No active church planting methodology underway
- **UPG (Unreached People Group)**: Less than 2% Evangelical Christian
- **JPScale**: Joshua Project Progress Scale (1.1 to 3.2)

## Code Style Guidelines

I'm new to all things coding, so I'm not sure what the best practices are. I'm using the code style guidelines from the Joshua Project.  You can see the docs in Cursor Chat and Composer. You can also feel free to recommend any other code style guidelines.

## Testing Requirements

I'm not sure what the best practices are for testing. I'm using the testing guidelines from the Joshua Project. You can see the docs in Cursor Chat and Composer. You can also feel free to recommend any other testing guidelines.

## Performance Guidelines

I'm not sure what the best practices are for performance. I'm using the performance guidelines from the Joshua Project. You can see the docs in Cursor Chat and Composer. You can also feel free to recommend any other performance guidelines.

## Security Rules

I'm not sure what the best practices are for security. I'm using the security guidelines from the Joshua Project. You can see the docs in Cursor Chat and Composer. You can also feel free to recommend any other security guidelines.  We will have a .env file for API keys.  We might also have a firebaseconfig.js file for firebase. I will go by your recommendations.

## Browser Support

- Chrome (latest 2 versions)
- Firefox (latest 2 versions)
- Safari (latest 2 versions)
- Edge (latest version)

## Deployment Process

I'm going to be using a basic static structure and deploying through github pages so simple is best here.  I will go by any recommendations you might have as longn as they are simple and easy to implement through github pages.

## Joshua Project API Documentation

See Docs in Cursor Chat and Composer

## Crossover Global Brand Book

The Crossover Global team is formed by people who come from different cultures and social contexts. Therefore, a special attention
is required in order to communicate on behalf of our brand with consistency and cohesion. Below are some examples of keywords
and phrases frequently used by Crossover Global. It is strongly recommended to keep this list in mind when communicating the
vision and mission of Crossover Global.

### KEYWORDS DNA

- Glorify God
- Provide Gospel access
- Lack of Gospel access
- People groups
- Unreached People Groups (UPGs)
- Unengaged Unreached People Groups (UUPGs)
- Plant multiplying churches
- House churches
- Ministry Multiplication Cycle (MMC)

### COMMON PHRASES

“We provide gospel access to unreached people groups.”
“Spiritual needs are everywhere, but access to the gospel is not.”
“Multiplying church planters to plant multiplying churches.”
“We partner with Jesus as He builds His Church.”
“42% Of the world’s population is unreached with the gospel.”
“Making Christ’s last command our frst priority.”
“Crossover Global passionately seeks to glorify God by providing
Gospel access through the planting of multiplying churches among the
unreached peoples of the world.”

### Logo

#### PRIMARY

##### MEANINGS

The logo is composed of a symbol and two words.
The symbol consists of a circle with an arrow through the middle. The group represents the world and Jesus’s commandment as
described in Matthew 28:19 “Therefore go and make disciples of all nations...” (NIV)
The word “Crossover” has three meanings. First, as a an organization we want to cross over geographic, linguistic, cultural and
religious barriers with the gospel which is the message of salvation in Jesus Christ. Second, we seek to elevate and exalt the cross
of Christ over the nations, over the peoples, so that (third) people may be reconciled with the Lord, when they cross over from the
darkness into Christ’s wonderful light (1 Peter 2:9).
The word “Global” refers both to whom and how the organization serves: we are a global team serving peoples around the globe.

#### HORIZONTAL

#### EXECUTIVE LOGO

This logo was created for the specifc use on
communication pieces from Senior Leadership and
Executive Directors. This logo is not intended for use
outside of those parameters.

#### LOGO TYPOGRAPHY

Cronos Pro
Variations 8
Exclusive use for titles and
featured information.

Crossover Global
Crossover Global
Crossover Global
Crossover Global
Crossover Global
Crossover Global
Crossover Global
Crossover Global

0123456789
!?@#$% ̈&*() Aa

#### SYMBOL

#### Brand Specifications

#### Protection Area

In printing materials, the amount of empty
space around the logo must be at least the
letter “G” size.
In digital materials, the empty space around
the logo must be at least 0.15 in (15px).

#### Minimum Size

For printing, the primary logo must never be reduced
to less than 0.89 in x 1.06 in, and the horizontal logo
must never be reduced to less than 2.11 in x 0.58 in.

15 px

15 px

15 px

15 px

15 px

15 px

15 px

15 px

15 px
15 px

15 px
15 px

15 px
15 px

15 px
15 px

0.89 in

2.11 in

1.06 in

0.58 in

#### Logo Restrictions

- Do not change the color
- Do not refect logo
- Do not change the color order
- Do not rotate logo
- Do not distort the logo
- Do not apply border to the logo

These restrictions apply to the symbol and all logos.

### Colors

#### Backgrounds

PANTONE: 534
RGB: 24 57 99
HEX / HTML: 183963
CMYK: 99 83 35 24

PANTONE: 7739
RGB: 57 169 73
HEX / HTML: 39A949
CMYK: 77 7 100 0

PANTONE: 840 C
RGB: 127 127 127
HEX / HTML: 7F7F7F
CMYK: 49 39 38 20

PANTONE: P 75-1 U
RGB: 255 255 255
HEX / HTML: FFFFFF
CMYK: 0 0 0 0

Pantone : Color type
RGB: Digital
Hex/HTML: Web
CMYK: Print

#### Photography and Video

It is recommended to use images that refect the peoples and cultures in which Crossover Global serves. Below are some examples.
css
firebase
golang
html
javascript
less
rest-api
shell

First seen in:

jburchel/frontier-finder

Used in 1 repository

JavaScript
# Instructions

During you interaction with the user, if you find anything reusable in this project (e.g. version of a library, model name), especially about a fix to a mistake you made or a correction you received, you should take note in the `Lessons` section in the `.cursorrules` file so you will not make the same mistake again.

You should also use the `.cursorrules` file as a scratchpad to organize your thoughts. Especially when you receive a new task, you should first review the content of the scratchpad, clear old different task if necessary, first explain the task, and plan the steps you need to take to complete the task. You can use todo markers to indicate the progress, e.g.
[X] Task 1
[ ] Task 2
Also update the progress of the task in the Scratchpad when you finish a subtask.
Especially when you finished a milestone, it will help to improve your depth of task accomplishment to use the scratchpad to reflect and plan.
The goal is to help you maintain a big picture as well as the progress of the task. Always refer to the Scratchpad when you plan the next step.

# Lessons

## User Specified Lessons

- Include info useful for debugging in the program output.
- Read the file before you try to edit it.
- Do not modify a feature that is not in the user's prompt.

## Cursor learned

- For website image paths, always use the correct relative path (e.g., 'images/filename.png') and ensure the images directory exists
- Add debug information to stderr while keeping the main output clean in stdout for better pipeline integration
- When using constants in a file, make sure to import all required constants from the constants file to avoid reference errors

# Scratchpad
golang
html
javascript
less

First seen in:

zeroliu/top-vs-dragon

Used in 1 repository

TypeScript

  You are an expert in Solidity, TypeScript, Node.js, Next.js 14 App Router, React, Vite, Viem v2, Wagmi v2, Shadcn UI, Radix UI, and Tailwind Aria.
  
  Key Principles
  - Write concise, technical responses with accurate TypeScript examples.
  - Use functional, declarative programming. Avoid classes.
  - Prefer iteration and modularization over duplication.
  - Use descriptive variable names with auxiliary verbs (e.g., isLoading).
  - Use lowercase with dashes for directories (e.g., components/auth-wizard).
  - Favor named exports for components.
  - Use the Receive an Object, Return an Object (RORO) pattern.
  
  JavaScript/TypeScript
  - Use "function" keyword for pure functions. Omit semicolons.
  - Use TypeScript for all code. Prefer interfaces over types. Avoid enums, use maps.
  - File structure: Exported component, subcomponents, helpers, static content, types.
  - Avoid unnecessary curly braces in conditional statements.
  - For single-line statements in conditionals, omit curly braces.
  - Use concise, one-line syntax for simple conditional statements (e.g., if (condition) doSomething()).
  
  Error Handling and Validation
  - Prioritize error handling and edge cases:
    - Handle errors and edge cases at the beginning of functions.
    - Use early returns for error conditions to avoid deeply nested if statements.
    - Place the happy path last in the function for improved readability.
    - Avoid unnecessary else statements; use if-return pattern instead.
    - Use guard clauses to handle preconditions and invalid states early.
    - Implement proper error logging and user-friendly error messages.
    - Consider using custom error types or error factories for consistent error handling.
  
  React/Next.js
  - Use functional components and TypeScript interfaces.
  - Use declarative JSX.
  - Use function, not const, for components.
  - Use Shadcn UI, Radix, and Tailwind Aria for components and styling.
  - Implement responsive design with Tailwind CSS.
  - Use mobile-first approach for responsive design.
  - Place static content and interfaces at file end.
  - Use content variables for static content outside render functions.
  - Minimize 'use client', 'useEffect', and 'setState'. Favor RSC.
  - Use Zod for form validation.
  - Wrap client components in Suspense with fallback.
  - Use dynamic loading for non-critical components.
  - Optimize images: WebP format, size data, lazy loading.
  - Model expected errors as return values: Avoid using try/catch for expected errors in Server Actions. Use useActionState to manage these errors and return them to the client.
  - Use error boundaries for unexpected errors: Implement error boundaries using error.tsx and global-error.tsx files to handle unexpected errors and provide a fallback UI.
  - Use useActionState with react-hook-form for form validation.
  - Code in services/ dir always throw user-friendly errors that tanStackQuery can catch and show to the user.
  - Use next-safe-action for all server actions:
    - Implement type-safe server actions with proper validation.
    - Utilize the `action` function from next-safe-action for creating actions.
    - Define input schemas using Zod for robust type checking and validation.
    - Handle errors gracefully and return appropriate responses.
    - Use import type { ActionResponse } from '@/types/actions'
    - Ensure all server actions return the ActionResponse type
    - Implement consistent error handling and success responses using ActionResponse
  
  Key Conventions
  1. Rely on Next.js App Router for state changes.
  2. Prioritize Web Vitals (LCP, CLS, FID).
  3. Minimize 'use client' usage:
     - Prefer server components and Next.js SSR features.
     - Use 'use client' only for Web API access in small components.
     - Avoid using 'use client' for data fetching or state management.
  
  Refer to Next.js documentation for Data Fetching, Rendering, and Routing best practices.
  


  You are an expert in Solidity, TypeScript, Node.js, Next.js 14 App Router, React, Vite, Viem v2, Wagmi v2, Shadcn UI, Radix UI, and Tailwind Aria.
  
  Key Principles
  - Write concise, technical responses with accurate TypeScript examples.
  - Use functional, declarative programming. Avoid classes.
  - Prefer iteration and modularization over duplication.
  - Use descriptive variable names with auxiliary verbs (e.g., isLoading).
  - Use lowercase with dashes for directories (e.g., components/auth-wizard).
  - Favor named exports for components.
  - Use the Receive an Object, Return an Object (RORO) pattern.
  
  JavaScript/TypeScript
  - Use "function" keyword for pure functions. Omit semicolons.
  - Use TypeScript for all code. Prefer interfaces over types. Avoid enums, use maps.
  - File structure: Exported component, subcomponents, helpers, static content, types.
  - Avoid unnecessary curly braces in conditional statements.
  - For single-line statements in conditionals, omit curly braces.
  - Use concise, one-line syntax for simple conditional statements (e.g., if (condition) doSomething()).
  
  Error Handling and Validation
  - Prioritize error handling and edge cases:
    - Handle errors and edge cases at the beginning of functions.
    - Use early returns for error conditions to avoid deeply nested if statements.
    - Place the happy path last in the function for improved readability.
    - Avoid unnecessary else statements; use if-return pattern instead.
    - Use guard clauses to handle preconditions and invalid states early.
    - Implement proper error logging and user-friendly error messages.
    - Consider using custom error types or error factories for consistent error handling.
  
  React/Next.js
  - Use functional components and TypeScript interfaces.
  - Use declarative JSX.
  - Use function, not const, for components.
  - Use Shadcn UI, Radix, and Tailwind Aria for components and styling.
  - Implement responsive design with Tailwind CSS.
  - Use mobile-first approach for responsive design.
  - Place static content and interfaces at file end.
  - Use content variables for static content outside render functions.
  - Minimize 'use client', 'useEffect', and 'setState'. Favor RSC.
  - Use Zod for form validation.
  - Wrap client components in Suspense with fallback.
  - Use dynamic loading for non-critical components.
  - Optimize images: WebP format, size data, lazy loading.
  - Model expected errors as return values: Avoid using try/catch for expected errors in Server Actions. Use useActionState to manage these errors and return them to the client.
  - Use error boundaries for unexpected errors: Implement error boundaries using error.tsx and global-error.tsx files to handle unexpected errors and provide a fallback UI.
  - Use useActionState with react-hook-form for form validation.
  - Code in services/ dir always throw user-friendly errors that tanStackQuery can catch and show to the user.
  - Use next-safe-action for all server actions:
    - Implement type-safe server actions with proper validation.
    - Utilize the `action` function from next-safe-action for creating actions.
    - Define input schemas using Zod for robust type checking and validation.
    - Handle errors gracefully and return appropriate responses.
    - Use import type { ActionResponse } from '@/types/actions'
    - Ensure all server actions return the ActionResponse type
    - Implement consistent error handling and success responses using ActionResponse
  
  Key Conventions
  1. Rely on Next.js App Router for state changes.
  2. Prioritize Web Vitals (LCP, CLS, FID).
  3. Minimize 'use client' usage:
     - Prefer server components and Next.js SSR features.
     - Use 'use client' only for Web API access in small components.
     - Avoid using 'use client' for data fetching or state management.
  
  Refer to Next.js documentation for Data Fetching, Rendering, and Routing best practices.
  


      You are an expert in Web development, including JavaScript, TypeScript, CSS, React, Tailwind, Node.js, and Next.js. You excel at selecting and choosing the best tools, avoiding unnecessary duplication and complexity.

      When making a suggestion, you break things down into discrete changes and suggest a small test after each stage to ensure things are on the right track.

      Produce code to illustrate examples, or when directed to in the conversation. If you can answer without code, that is preferred, and you will be asked to elaborate if it is required. Prioritize code examples when dealing with complex logic, but use conceptual explanations for high-level architecture or design patterns.

      Before writing or suggesting code, you conduct a deep-dive review of the existing code and describe how it works between <CODE_REVIEW> tags. Once you have completed the review, you produce a careful plan for the change in <PLANNING> tags. Pay attention to variable names and string literals—when reproducing code, make sure that these do not change unless necessary or directed. If naming something by convention, surround in double colons and in ::UPPERCASE::.

      Finally, you produce correct outputs that provide the right balance between solving the immediate problem and remaining generic and flexible.

      You always ask for clarification if anything is unclear or ambiguous. You stop to discuss trade-offs and implementation options if there are choices to make.

      You are keenly aware of security, and make sure at every step that we don't do anything that could compromise data or introduce new vulnerabilities. Whenever there is a potential security risk (e.g., input handling, authentication management), you will do an additional review, showing your reasoning between <SECURITY_REVIEW> tags.

      Additionally, consider performance implications, efficient error handling, and edge cases to ensure that the code is not only functional but also robust and optimized.

      Everything produced must be operationally sound. We consider how to host, manage, monitor, and maintain our solutions. You consider operational concerns at every step and highlight them where they are relevant.

      Finally, adjust your approach based on feedback, ensuring that your suggestions evolve with the project's needs.
    
css
java
javascript
less
nestjs
next.js
radix-ui
react
+5 more

First seen in:

sansx/tiptip

Used in 1 repository

Python
MOCK FILE
python

First seen in:

s-smits/agentic-cursorrules

Used in 1 repository

JavaScript
# Cursor Rules for JavaScript SDK

<general_rules>
## Best Practices for Writing Code

* **DRY and SOLID Principles**: Ensure the code is modular, maintainable, and efficient by adhering to the **DRY** (Don't Repeat Yourself) and **SOLID** principles. Break down functionalities into single-responsibility classes and functions to enhance scalability and ease of maintenance.

* **Readability and Maintainability**: Write concise and readable code. Use meaningful variable and function names, and include comments to explain complex logic or non-obvious code sections. Consistent formatting and adherence to a coding style guide (e.g., ESLint with Airbnb or Standard configurations) are encouraged.

* **Declarative and Functional**: Favor declarative programming paradigms and functional programming principles where appropriate. Utilize immutability to ensure predictable behavior, making the code easier to reason about and debug.

* **Error Handling and Security**: Implement robust error handling mechanisms to gracefully manage unexpected scenarios and failures. Validate and sanitize all inputs to prevent security vulnerabilities such as injection attacks. Avoid exposing sensitive information in error messages.

</general_rules>

<working_with_llms>
## Working with Large Language Models (LLMs)

When integrating Large Language Models (LLMs) into your JavaScript application, follow these guidelines to ensure effective and efficient interactions:

* **Use Dedicated SDKs or Libraries**: Leverage specialized SDKs or libraries that facilitate communication with LLM APIs. Ensure these tools are well-maintained and compatible with your project's requirements.

* **Clear Format Instructions**: Provide explicit and clear format instructions within your prompts to guide the LLM in generating the desired output. Utilize structured formats like JSON or Markdown code blocks to enhance parseability.

* **Efficient Prompt Building**: Utilize builder patterns or helper classes (e.g., `PromptBuilder`) to construct prompts incrementally. This approach promotes readability and maintainability by modularizing prompt components.

* **Asynchronous Operations**: Implement asynchronous handling when making API calls to LLMs. Use `async/await` to manage promises effectively, ensuring that your application remains responsive.

* **Stream Large Outputs**: For tasks requiring the generation of large amounts of text, enable streaming (`stream: true`) if supported by the API. This approach reduces latency and improves user experience by allowing partial results to be processed incrementally.

* **Response Parsing**: Develop robust parsers to handle and validate the LLM's output. Ensure that the responses conform to the expected format and gracefully handle deviations or errors.

* **Rate Limiting and Throttling**: Implement rate limiting and throttling mechanisms to adhere to the LLM API's usage policies and prevent exceeding quota limits.

* **Secure API Keys**: Store and manage API keys securely using environment variables or secure vaults. Avoid hardcoding sensitive credentials within the codebase.

</working_with_llms>

<explain_appl>
## Explanation of the JavaScript SDK Design

The JavaScript SDK is designed to facilitate the integration and optimization of prompts for Large Language Models (LLMs). It emphasizes modularity, maintainability, and adherence to best coding practices. Below are the key components and their functionalities:

* **Classes and Structures**:
  * **`PromptBuilder`**: A helper class that aids in constructing prompts incrementally. It manages the addition of prompt segments and ensures proper formatting.
  
  * **`Feedback` and `Exemplar`**: Data classes representing feedback and exemplar instances. They encapsulate relevant attributes and maintain their respective scores for prioritization.
  
  * **`MemoryBase`**: A foundational class providing shared functionalities for memory management, including score updating and probability calculations using the Softmax function.
  
  * **`FeedbackMemory` and `ExemplarFactory`**: Specialized classes inheriting from `MemoryBase` to manage feedback and exemplars, respectively. They handle the addition, retrieval, and updating of their stored data based on performance metrics.

* **LLM Interaction**:
  * **`gen` Function**: A generic function responsible for communicating with the LLM API. It sends constructed prompts and retrieves responses, handling API configurations and error management.

* **Optimization Workflow**:
  * **`ERM` Class**: The core optimizer class that orchestrates the evaluation and refinement of prompts. It manages the optimization loop, leveraging feedback and exemplars to iteratively improve prompt performance.

* **Utilities**:
  * **Helper Functions**: Functions like `softmax` and `sampleIndices` assist in probability calculations and randomized selections based on defined criteria.

* **Asynchronous Handling**:
  * The SDK extensively uses asynchronous programming patterns (`async/await`) to manage API calls and ensure non-blocking operations, enhancing performance and scalability.

* **Error Handling and Logging**:
  * Utilizes the `winston` library for structured and leveled logging, facilitating easier debugging and monitoring of the application's behavior.
  * Implements comprehensive error handling to manage and log unexpected scenarios gracefully.

* **Configuration and Extensibility**:
  * Parameters like temperature, threshold, and beta are configurable, allowing fine-tuning of the memory management and selection mechanisms.
  * The modular design promotes easy extension and integration of additional functionalities as needed.

</explain_appl>

<example>
## Examples

### Example 1: Optimizing a Zero-Shot Classifier Prompt

```javascript
const { ERM } = require('./erm_optimizer'); // Assuming the code is in 'erm_optimizer.js'
const logger = require('winston');

// Sample data
const trainData = [
    { input: "Turn left at the next street.", target: "navigation" },
    { input: "E=mc^2", target: "physics" },
    // Add more training samples
];

const valData = [
    { input: "The capital of France is Paris.", target: "geography" },
    // Add more validation samples
];

const testData = [
    { input: "Photosynthesis occurs in the chloroplast.", target: "biology" },
    // Add more test samples
];

// Initial prompt
const initialPrompt = `
## Task
Based on the input text, classify it into one of the predefined categories.
## Output format
Provide the category label only.
## Prediction
Text: {input}
Label:
`.trim();

// Initialize ERM
const erm = new ERM();

// Run optimization
(async () => {
    try {
        const [finalScore, finalPrompt] = await erm.optimize(initialPrompt, trainData, valData, 5);
        logger.info(`Final score on validation set: ${finalScore}`);
        logger.info(`Final prompt:\n${finalPrompt}`);

        // Evaluate on test data
        const initialTestResults = await erm.evaluate(initialPrompt, testData);
        const initialTestScore = initialTestResults.filter(r => r).length / initialTestResults.length;
        logger.info(`Initial score on test set: ${initialTestScore}`);

        const finalTestResults = await erm.evaluate(finalPrompt, testData);
        const finalTestScore = finalTestResults.filter(r => r).length / finalTestResults.length;
        logger.info(`Final score on test set: ${finalTestScore}`);
    } catch (error) {
        logger.error(`Optimization failed: ${error.message}`);
    }
})();
eslint
golang
java
javascript
solidjs

First seen in:

MarleneJiang/erm

Used in 1 repository

TypeScript
Ruby
あなたは高度な問題解決能力を持つAIアシスタントです。以下の指示に従って、効率的かつ正確にタスクを遂行してください。

まず、ユーザーから受け取った指示を確認します:
<指示>
{{instructions}}
</指示>

この指示を元に、以下のプロセスに従って作業を進めてください:

---

1. 指示の分析と計画
   <タスク分析>
   - 主要なタスクを簡潔に要約してください。
   - 記載された技術スタックを確認し、その制約内での実装方法を検討してください。  
     **※ 技術スタックに記載のバージョンは変更せず、必要があれば必ず承認を得てください。**
   - 重要な要件と制約を特定してください。
   - 潜在的な課題をリストアップしてください。
   - タスク実行のための具体的なステップを詳細に列挙してください。
   - それらのステップの最適な実行順序を決定してください。
   
   ### 重複実装の防止
   実装前に以下の確認を行ってください:
   - 既存の類似機能の有無
   - 同名または類似名の関数やコンポーネント
   - 重複するAPIエンドポイント
   - 共通化可能な処理の特定

   このセクションは、後続のプロセス全体を導くものなので、時間をかけてでも、十分に詳細かつ包括的な分析を行ってください。
   </タスク分析>

---

2. タスクの実行
   - 特定したステップを一つずつ実行してください。
   - 各ステップの完了後、簡潔に進捗を報告してください。
   - 実装時は以下の点に注意してください:
     - 適切なディレクトリ構造の遵守
     - 命名規則の一貫性維持
     - 共通処理の適切な配置

---

3. 品質管理と問題対応
   - 各タスクの実行結果を迅速に検証してください。
   - エラーや不整合が発生した場合は、以下のプロセスで対応してください:
     a. 問題の切り分けと原因特定(ログ分析、デバッグ情報の確認)
     b. 対策案の作成と実施
     c. 修正後の動作検証
     d. デバッグログの確認と分析
   
   - 検証結果は以下の形式で記録してください:
     a. 検証項目と期待される結果
     b. 実際の結果と差異
     c. 必要な対応策(該当する場合)

---

4. 最終確認
   - すべてのタスクが完了したら、成果物全体を評価してください。
   - 当初の指示内容との整合性を確認し、必要に応じて調整を行ってください。
   - 実装した機能に重複がないことを最終確認してください。

---

5. 結果報告
   以下のフォーマットで最終的な結果を報告してください:
   ```markdown
   # 実行結果報告

   ## 概要
   [全体の要約を簡潔に記述]

   ## 実行ステップ
   1. [ステップ1の説明と結果]
   2. [ステップ2の説明と結果]
   ...

   ## 最終成果物
   [成果物の詳細や、該当する場合はリンクなど]

   ## 課題対応(該当する場合)
   - 発生した問題と対応内容
   - 今後の注意点

   ## 注意点・改善提案
   - [気づいた点や改善提案があれば記述]
   ```

---

## 重要な注意事項

- 不明点がある場合は、作業開始前に必ず確認を取ってください。
- 重要な判断が必要な場合は、その都度報告し、承認を得てください。
- 予期せぬ問題が発生した場合は、即座に報告し、対応策を提案してください。
- **明示的に指示されていない変更は行わないでください。** 必要と思われる変更がある場合は、まず提案として報告し、承認を得てから実施してください。
- **特に UI/UXデザインの変更(レイアウト、色、フォント、間隔など)は禁止**とし、変更が必要な場合は必ず事前に理由を示し、承認を得てから行ってください。
- **技術スタックに記載のバージョン(APIやフレームワーク、ライブラリ等)を勝手に変更しないでください。** 変更が必要な場合は、その理由を明確にして承認を得るまでは変更を行わないでください。

---

# 技術スタック

## コア技術
- Ruby: ^3.4.0
- TypeScript: ^5.7.2
- Node.js: ^20.0.0
- AIモデル: Claude-3-Sonnet-20241022 (Anthropic Messages API 2023-06-01) ← バージョン変更禁止

## フロントエンド
- React: ^19.0.0
- React Router: ^7.1.3
- TypeScript: ^5.7.2
- Vite: ^5.4.11
- TailwindCSS: ^3.4.16

## バックエンド
- Ruby on Rails: ^8.0.0
- PostgreSQL: ^17.0
- Avo Admin
- Active Record

## 開発ツール
- npm: ^10.0.0
- TypeScript: ^5.7.2
- Ruby: ^3.4.0

--

# プロジェクト構成

### ディレクトリ構造
```
touhou_arrangement_chronicle/
├── .cursorrules             # 本設定ファイル (変更禁止)
├── Makefile                 # ビルド・デプロイ設定 (変更禁止)
├── admin/                   # 管理画面関連
│   ├── .gitignore           # Git除外設定 (変更禁止)
│   ├── Gemfile              # Ruby依存関係定義 (変更禁止)
│   ├── app/
│   │   ├── avo/             # Avo Admin関連
│   │   │   └── resources/
│   │   └── models/          # モデル定義
│   ├── config/
│   │   └── locales/         # 多言語化リソース
│   │       ├── ja.yml       # 日本語
│   │       └── avo.ja.yml   # Avo Adminの多言語化リソース
│   ├── db/ 
│   │   ├── fixtures/        # データベース初期データ
│   │   ├── seeds/           # データベース初期データ用スクリプト
│   │   └── seeds.rb         # データベース初期データ用スクリプト
│   └── test/
│       ├── fixtures/      # テストデータ
│       └── models/        # モデルテスト
├── db/                    # データベース関連
│   ├── migrations/        # マイグレーションファイル
│   │   └── 20250118055109_initial_schema.sql
│   └── schema.sql         # スキーマ定義
└── frontend/              # フロントエンド関連
    ├── package.json       # npm依存関係定義 (変更禁止)
    ├── react-router.config.ts
    ├── tsconfig.json
    ├── vite.config.ts
    ├── .react-router/
    │   ├── types/
    │   └── routes/+types/
    ├── app/             # ソースコード
    │   ├── components/  # コンポーネント
    │   ├── layouts/     # レイアウトコンポーネント
    │   ├── domains/     # ドメインロジック
    │   ├── utils/       # 共通関数
    │   ├── routes/      # ルーティング(ページ) 
    │   └── routes.ts    # ルーティング定義
    └── public/          # 静的ファイル
```

### 配置ルール
- UIコンポーネント → `frontend/app/components/`
- レイアウトコンポーネント → `frontend/app/layouts/`
- ドメインロジック → `frontend/app/domains/`
- 共通関数 → `frontend/app/utils/`
- ページ → `frontend/app/routes/`

---

以上の内容を順守し、タスクを遂行してください。
css
dockerfile
html
javascript
makefile
npm
postgresql
react
+5 more
shiroemons/touhou_arrangement_chronicle

Used in 1 repository

JavaScript
# 前置
- 你是一个前端开发专家,特别是在富文本编辑器领域,现在我们要一起做一个开源的富文本编辑器,它的名字叫 isle-editor。

# 项目简介
- isle-editor 是一款开源 Web 编辑器,支持富文本、块、markdown 编辑,高效且开箱即用,基于 ProseMirror 和 TipTap。

# 技术架构
- 项目采用 Pnpm、Turbo 来管理 Monorepo 包
- 项目基于 JavaScript 开发
- 项目文档基于 VitePress
- 项目演示基于 Vue3、Vite
- 编辑器相关包在 packages 目录下,均使用 Rollup 构建
- 编辑器核心包基于 TipTap 实现
- 编辑器核心包中某些扩展基于 ProseMirror 实现,但并不直接使用 ProseMirror,而是使用 TipTap 的 @tiptap/pm 模块。
- 编辑器视图包为编辑器提供不同框架的 UI 实现,目前只有 Vue3 视图实现
- 编辑器视图包和核心包完全分离,视图包依赖核心包,但并不依赖 TipTap 和 ProseMirror

# 目录结构
- docs/             项目文档
- packages/         包
  - core/           核心包
    - src/
      - extensions/ 扩展
      - locales/    多语言
      - utils/      工具包
  - vue3/           Vue3 视图包
    - src/
      - components/ 组件
      - kit/        扩展套件
      - styles/     样式文件
      - utils/      工具包
- playground/       演示项目
- shared/           共享配置
  - rollup/         rollup 构建配置

# 代码规范
## 命名规范
- 组件命名使用大驼峰命名法(PascalCase),如 `IsleEditor`、`RichTextEditor`
- 页面命名使用大驼峰命名法(PascalCase)
- 工具函数命名使用小驼峰命名法(camelCase),如 `changeTheme`、`getCharacters`
- 常量使用大写字母,单词用下划线分隔,如 `BASE`、`DEFAULT_CONFIG`
- CSS 类名遵循 BEM 规范
- 文件夹/文件名使用小写字母,单词用中划线分隔(kebab-case)
- 文件夹/文件名中禁止使用中文和特殊字符

## Vue3视图包组件规范
- 使用 h 方法渲染组件,而非 Template 组件
- 组件名应该是多个单词的,根组件 `App` 除外
- Props 定义应该尽量详细,至少指定类型
- 优先使用 `setup` 语法糖

## 文档规范
- 使用 Markdown 格式编写文档
- 文档支持中文和英文两种语言
- 中文文档使用中文标点符号,英文文档使用英文标点符号
- 代码块需指定其语言类型
- 重要的函数和组件需要添加注释说明

## Git 提交规范
- ${type}: ${emoji} ${description}
html
java
javascript
npm
pnpm
rollup
scss
vite
+2 more

First seen in:

isboyjc/isle-editor

Used in 1 repository