Awesome Cursor Rules Collection

Showing 1033-1044 of 2626 matches

TypeScript
# .cursorrules

# General
1. Use Cursor AI to write code.
2. Use Cursor AI to write documentation.
3. Every time you write code, write a prompt for Cursor AI to help it understand your intentions.
4. Provide reasoning and defense supported by reference documentation for every change you make.
5. Provide thorough explanations of your code changes or new components.


# Core Rules
1. The landing page must be optimized for speed and responsiveness.
2. All forms must auto-save user inputs (address and phone number) even if the user does not complete the form.
3. Use Google Places API for address autofill functionality.
4. Integrate Zapier and Webhook API to send form data to Go High Level CRM.
5. Ensure the landing page is built with SEO-optimized content, including meta tags and keywords.
6. Use a mobile-first design approach.

# Folder Structure
- Follow the predefined folder structure:
  - All React components must be placed in the `src/components/` directory.
  - Pages must be placed in the `src/pages/` directory.
  - Static assets like images and styles go into `src/assets/`.
  - Utility scripts for APIs and analytics belong in `src/utils/`.
  - Backend integrations (webhooks, API handlers) go into `src/backend/`.

# Styling
1. Use TailwindCSS for consistent styling across components.
2. Adhere to the following color palette:
   - Primary: #5b5a99
   - Accent: #65bee4
   - Background: White
   - Text: Dark grey (#333)
3. All buttons must be styled with the primary color unless otherwise specified.

# Form Components
1. The form must consist of multiple steps:
   - Step 1: Address (with autofill) and Phone Number.
   - Step 2: Additional property details (e.g., condition, reason for selling).
2. The "Next" button on each step must submit and save user data.
3. Display a loading indicator for API calls, especially for address autofill.
4. Include validation for required fields (address and phone number).

# Analytics and Tracking
1. Integrate Google Analytics to track:
   - Page visits
   - Clicks
   - Form completions
2. Add a Facebook Pixel for PPC campaign tracking.
3. Implement Hotjar for heatmaps and user behavior tracking.

# Performance
1. Ensure Lighthouse scores for performance, accessibility, best practices, and SEO are above 90.
2. Optimize images and assets for web performance.
3. Use lazy-loading for images and asynchronous loading for third-party scripts.

# Deployment
1. The project must be deployable via Vercel with CI/CD enabled.
2. Ensure that the deployed landing page URL is accessible and works on mobile, tablet, and desktop devices.

# Developer Prompts
1. When working on a new feature:
   - "How will this feature improve the user experience or lead capture rate?"
2. When optimizing:
   - "Does this change improve performance or simplicity?"
3. When debugging:
   - "What are the possible points of failure? Are there fallback mechanisms in place?"
4. When writing SEO content:
   - "Does this content include relevant keywords? Is it concise and user-focused?"

# Error Handling
1. All API calls must include proper error handling with clear error messages displayed to the user.
2. Log errors in the backend for debugging.
3. Redirect users to a "Thank You" page or error page if there is an issue during submission.

# Automation
1. Use Zapier for automation, including:
   - Sending form data to CRM.
   - Triggering email notifications on new leads.
2. Implement webhooks to ensure real-time lead submission.

# React Components
1. All components must be reusable and modular.
2. Use props for dynamic content where applicable.
3. Separate UI logic from business logic within components.

# SEO Rules
1. Include meta tags:
   - Title: "Sell Your House Fast | Get a Cash Offer Today"
   - Description: "We buy houses in any condition. Submit your address for a fast, no-obligation cash offer."
2. Use H1 tags for main headlines and H2 for secondary content.
3. Include alt attributes for all images.

# Testing
1. Run unit tests on React components for functionality.
2. Perform integration testing for form submission and CRM integration.
3. Test on multiple browsers and devices to ensure compatibility.

# Prompts for Cursor Assistance
- "Generate a form component with Google Places API integration."
- "Create a reusable button component styled with TailwindCSS."
- "Set up a webhook to send form data to Go High Level CRM via Zapier."
- "Implement analytics tracking for user interactions using Google Tag Manager."
- "Optimize the landing page for a Lighthouse performance score above 90."
- "Build a responsive header component with the brand logo and navigation links."
- "Add validation rules for required form fields."
- "Create a Thank You page that acknowledges successful form submissions."
- "Ensure form data is saved at every step, even if the user doesn't complete the process."

# Notes
1. Keep code modular and maintainable.
2. Regularly commit progress to GitHub with clear commit messages.
3. Prioritize simplicity and user experience in all components.

# Google Sheets Integration
1. Use googleapis library for direct sheet interaction
2. Follow JWT authentication pattern
3. Maintain consistent column structure:
   - timestamp (A) - ISO string format
   - leadId (B) - Unique identifier with timestamp
   - address (C) - Full property address
   - streetAddress (D) - Street component
   - city (E) - City component
   - state (F) - State component
   - postalCode (G) - Postal code
   - phone (H) - Contact phone
   - placeId (I) - Google Places ID
   - firstName (J) - First name
   - lastName (K) - Last name
   - email (L) - Email address
   - isPropertyListed (M) - Yes/No format
   - propertyCondition (N) - Property condition
   - timeframe (O) - Selling timeframe
   - price (P) - Asking price
   - lastUpdated (Q) - ISO string format

# Lead Capture Rules
1. Capture leads immediately after "Get Cash Offer" click
2. Generate unique leadId using timestamp and random string
3. Record submission timestamp and lastUpdated for every entry
4. Handle missing fields gracefully with empty strings
5. Convert boolean values to Yes/No format

# Sheet Operations
1. Use A1 notation for all range references
2. Quote sheet names that contain spaces
3. Use USER_ENTERED for value input option
4. Use INSERT_ROWS for data insertion
5. Validate response status (200 for success)

# Error Handling
1. Validate all required environment variables
2. Check for missing credentials
3. Provide detailed error messages
4. Log errors for debugging
5. Return standardized error responses

# Security
1. Use JWT authentication with service account
2. Store credentials in environment variables
3. Validate all input data
4. Implement rate limiting
5. Use HTTPS for all API calls

# Data Formatting
1. Use ISO strings for all dates
2. Clean and standardize inputs
3. Handle missing fields with empty strings
4. Convert booleans to Yes/No
5. Maintain consistent data types

# Performance
1. Single API call per submission
2. Efficient error handling
3. Proper credential caching
4. Minimal data transformation

# Lead Capture Flow
1. Initial Lead Capture (First Step):
   - Triggered by "Get Cash Offer" button click
   - Submits to /api/submit-partial endpoint
   - Generates unique leadId
   - Creates new row in Google Sheets
   - Stores leadId in form state
   - Required fields: address, phone, consent

2. Complete Lead Submission (Contact Page):
   - Uses stored leadId from initial capture
   - Submits to /api/submit-form endpoint
   - Updates existing row in Google Sheets
   - Required fields: firstName, lastName, email, propertyCondition, timeframe, price
   - No duplicate rows created

3. Google Sheets Integration:
   - Uses A1 notation for ranges
   - Maintains consistent column structure
   - Updates existing rows based on leadId
   - Records timestamps for all changes
   - Handles partial and complete submissions

4. Data Flow:
   - PropertyForm.tsx -> submit-partial -> googleSheets.ts (new row)
   - Contact/page.tsx -> submit-form -> googleSheets.ts (update row)
   - Consistent leadId tracking throughout process
   - Error handling at each step
   - Validation of required fields
analytics
batchfile
css
golang
javascript
jwt
less
powershell
+5 more
wilsonaustin10/landingpage

Used in 1 repository

Go
## **Commit Message Format**

```
type(scope): subject

[optional body]

[optional footer(s)]
```

### **Types**

- `feat`: A new feature (minor version)
  - New functionality in reusable modules
  - New integrations with Dagger
  - Enhancements to CI/CD logic in `.dagger/`
- `fix`: A bug fix (patch version)
  - Fixes in module logic
  - Corrections in auto-generated configurations
  - Workflow or script fixes
- `perf`: A code change that improves performance (patch version)
  - Optimizations in reusable modules
  - Workflow performance improvements
  - Build efficiency updates
- `docs`: Documentation-only changes (patch version)
  - Updates to README or module-specific documentation
  - Comments explaining module behaviors
  - Changes in documentation for `.dagger/` workflows
- `style`: Non-functional changes to code style
  - Formatting adjustments
  - Linting fixes
  - Naming conventions
- `refactor`: Code changes without feature addition or bug fix
  - Module structure reorganization
  - Internal logic improvements
  - Redundant code removal
- `test`: Adding or fixing tests
  - Unit tests for modules
  - Workflow tests
  - Integration tests for Dagger pipelines
- `build`: Changes in build configuration or dependencies
  - Updates to `go.mod` or `go.sum`
  - Adjustments in Dagger development setup
  - Build script modifications
- `ci`: Updates to CI/CD configuration
  - Workflow improvements in `.dagger/`
  - GitHub Actions configurations
  - Release process updates
- `chore`: Repository maintenance or minor updates
  - Cleanup tasks
  - Administrative changes
  - Dependency updates without code modifications

### **Scopes**

#### Language-Specific Scopes
- `python`: Changes related to Python modules and functionality
- `nodejs`: Changes related to Node.js modules and functionality
- `ruby`: Changes related to Ruby modules and functionality

#### Module-Specific Scopes
- `<language>-<module_name>`: Changes related to specific modules (e.g., `python-pipeline`, `nodejs-scheduler`)
- Any new module name must follow the pattern `<language>-<module_name>`.

#### General Scopes
- `global`: Repository-wide changes or changes affecting multiple modules

---

## **Commit Message Rules**

1. **Subject Line:**
   - Format: `type(scope): subject`
   - Use present tense (e.g., "Add feature", not "Added feature").
   - Keep it concise (72 characters or fewer).
   - Avoid ending with a period.
   - Example: `feat(python): add new testing pipeline`.

2. **Body:**
   - Must be separated from the subject by a blank line.
   - Explain _what_ and _why_, not _how_.
   - Use bullet points for multiple items.
   - Example:
     ```
     feat(python): add new testing pipeline

     - Added comprehensive tests with coverage reporting
     - Integrated with popular testing frameworks
     - Enhanced reporting for detailed metrics
     ```

3. **Breaking Changes:**
   - Add `!` after the type/scope: `feat(python)!: change API structure`.
   - Include a `BREAKING CHANGE:` section in the footer.
   - Example:
     ```
     feat(python)!: update testing API structure

     BREAKING CHANGE: The test runner now requires explicit configuration.
     ```

---

## **Module Naming and Structure**

1. **Module Import Path**
   - Modules must follow this structure:  
     ```
     github.com/felipepimentel/daggerverse/<pasta>/<module_name>/internal/dagger
     ```

2. **Directory Responsibilities**
   - **`internal/`**: Contains auto-generated files. **Do not manually modify files here**.
   - **`dagger.gen.go`**: An auto-generated file. Any updates must be done using:
     ```bash
     dagger develop
     ```

3. **Protected Components**
   - Changes to `dagger.gen.go` or files in `/internal` are prohibited.
   - Validate generated content with the `dagger develop` command.

4. **Example Module Structure**
   ```
   daggerverse/
   ├── python/
   │   ├── pipeline/
   │   │   ├── go.mod
   │   │   ├── main.go
   │   │   └── internal/
   │   │       └── dagger/
   │   │           ├── dagger.gen.go
   │   │           └── (other auto-generated files)
   ├── nodejs/
   │   ├── scheduler/
   └── global/
   ```

---

## **Reusing Internal Modules**

### **1. Declaring Module Dependencies**

To reuse an internal module, declare it as a dependency in your module’s `dagger.json` file. This ensures the dependency is linked during the development process.

Example `dagger.json`:
```json
{
  "name": "wolfi",
  "engineVersion": "v0.15.2",
  "sdk": "go",
  "dependencies": [
    {
      "name": "apko",
      "source": "../apko"
    }
  ],
  "source": "."
}
```

### **2. Using Internal Modules**

After declaring the dependency in `dagger.json`, you can access the module’s exported structures or methods by importing it into your Go code. For example:

```go
package main

import (
	"github.com/felipepimentel/daggerverse/essentials/wolfi/internal/dagger"
)

// A Dagger Module to integrate with Wolfi Linux
type Wolfi struct{}

// Build a Wolfi Linux container
func (w *Wolfi) Container(
	// APK packages to install
	// +optional
	packages []string,
	// Overlay images to merge on top of the base.
	// +optional
	overlays []*dagger.Container,
) *dagger.Container {
	ctr := dag.Apko().Wolfi(packages)
	for _, overlay := range overlays {
		ctr = ctr.WithDirectory("/", overlay.Rootfs())
	}
	return ctr
}
```

In this example:
- The `dag.Apko()` function refers to the `apko` dependency declared in `dagger.json`.
- Dependencies are structured to encourage code reuse and modularity.

### **3. Guidelines for Reusing Modules**

- **Always declare dependencies** in `dagger.json` to make them explicit and trackable.
- **Avoid duplicating logic**; reuse existing modules when functionality overlaps.
- **Leverage internal APIs**: Use exported functions or methods provided by the dependent module.
- **Document dependencies** in the README or inline comments to clarify module relationships.

---

## **Code Quality Rules**

1. **General**
   - Adhere to idiomatic Go practices.
   - Ensure all changes pass linting and formatting checks.
   - Write unit tests for all new or modified functionality.

2. **Dagger Workflow-Specific Rules**
   - Always use `dagger/<module>/internal/dagger` for imports.
   - Validate Dagger and Go versions:
     - Dagger version: `0.15.2`.
     - Go version: `1.23.2`.

3. **Testing**
   - Mock external dependencies where possible.
   - Ensure CI/CD workflows test all critical paths.

4. **Documentation**
   - Clearly describe module purpose and usage.
   - Highlight any requirements for Dagger or Go versions.

---

## **Breaking Changes**

1. **Commit Header:**
   - Use `!` after `type(scope)` (e.g., `feat(python)!:`).

2. **Commit Footer:**
   - Include a `BREAKING CHANGE:` section explaining the impact and migration steps.
cue
dockerfile
go
golang
javascript
makefile
python
ruby
+1 more
felipepimentel/daggerverse

Used in 1 repository

Jupyter Notebook
You are an expert in Solana program development, focusing on building and deploying smart contracts using Rust and Anchor, and integrating on-chain data with Web3.js. You are also proficient in developing full-stack applications using Next.js for the frontend and FastAPI (Python) for the backend, with Qdrant for vector database management and LiteLLM for AI model access.

Prime Directives:

1. Before responding with an uncertain solution, ask clarifying questions, request additional files, or suggest reading specific documentation or searching the web for more information.

2. Conclude your responses with a rating from 1-10, indicating how likely the solution is to work, with 1 being highly uncertain and 10 being extremely confident.

3. Always perform hierarchal chain-of-thought reasoning, starting with aim, goals, resources, and inputs, and flowing into a list of instructions to perform in sequence.

4. Context limitations and prompt cacheing means that sometimes you don't have every file you need. ALWAYS ask for missing files, they will be provided. DO NOT respond with changes when you are missing context.

General Guidelines:

- Prioritize writing secure, efficient, and maintainable code, following best practices for Solana program development and full-stack web applications.
- Ensure all smart contracts are rigorously tested and audited before deployment, with a strong focus on security and performance.

Solana Program Development with Rust and Anchor:

- Write Rust code with a focus on safety and performance, adhering to the principles of low-level systems programming.
- Use Anchor to streamline Solana program development, taking advantage of its features for simplifying account management, error handling, and program interactions.
- Structure your smart contract code to be modular and reusable, with clear separation of concerns.
- Ensure that all accounts, instructions, and data structures are well-defined and documented.

Security and Best Practices:

- Implement strict access controls and validate all inputs to prevent unauthorized transactions and data corruption.
- Use Solana's native security features, such as signing and transaction verification, to ensure the integrity of on-chain data.
- Regularly audit your code for potential vulnerabilities, including reentrancy attacks, overflow errors, and unauthorized access.
- Follow Solana's guidelines for secure development, including the use of verified libraries and up-to-date dependencies.

On-Chain Data Handling with Solana Web3.js:

- Use Solana Web3.js to interact with on-chain data efficiently, ensuring all API calls are optimized for performance and reliability.
- Implement robust error handling when fetching and processing on-chain data to ensure the reliability of your application.

Performance and Optimization:

- Optimize smart contracts for low transaction costs and high execution speed, minimizing resource usage on the Solana blockchain.
- Use Rust's concurrency features where appropriate to improve the performance of your smart contracts.
- Profile and benchmark your programs regularly to identify bottlenecks and optimize critical paths in your code.

Testing and Deployment:

- Develop comprehensive unit and integration tests for all smart contracts, covering edge cases and potential attack vectors.
- Use Anchor's testing framework to simulate on-chain environments and validate the behavior of your programs.
- Perform thorough end-to-end testing on a testnet environment before deploying your contracts to the mainnet.
- Implement continuous integration and deployment pipelines to automate the testing and deployment of your Solana programs.

Documentation and Maintenance:

- Document all aspects of your Solana programs, including the architecture, data structures, and public interfaces.
- Maintain a clear and concise README for each program, providing usage instructions and examples for developers.
- Regularly update your programs to incorporate new features, performance improvements, and security patches as the Solana ecosystem evolves.

Full-Stack Development:

- Use Next.js for building a responsive and performant frontend, leveraging its server-side rendering capabilities for improved SEO and user experience.
- Implement FastAPI (Python) for creating efficient and scalable backend services, utilizing its asynchronous capabilities for handling concurrent requests.
- Integrate Qdrant for vector database management, optimizing similarity search and efficient data retrieval for AI-related tasks.
- Utilize LiteLLM for seamless access to AI models, ensuring proper integration with your backend services for content generation and analysis.

Data Management and AI Integration:

- Design efficient data schemas and indexing strategies in Qdrant to support fast similarity searches and data retrieval.
- Implement proper error handling and fallback mechanisms when interacting with AI models through LiteLLM.
- Optimize API calls to AI services to minimize latency and manage costs effectively.

Frontend-Backend Integration:

- Develop RESTful APIs using FastAPI that efficiently serve data to your Next.js frontend.
- Implement proper state management in your Next.js application for handling complex UI interactions and data flow.
- Ensure secure communication between frontend and backend, implementing proper authentication and authorization mechanisms.

Deployment and Scaling:

- Set up efficient deployment pipelines for both frontend and backend components.
- Implement proper logging and monitoring solutions to track application performance and user behavior.
- Design your architecture to be scalable, considering potential increases in user base and data volume.
css
dockerfile
fastapi
golang
javascript
jupyter notebook
less
next.js
+4 more

First seen in:

yusefmosiah/choir-scales

Used in 1 repository

Shell
// Cursor AI用の.cursorrulesファイルガイドライン

// 基本的な説明
.cursorrulesファイルは、Cursor AIの動作をプロジェクトごとにカスタマイズするための設定ファイルです。このファイルをリポジトリのルートに配置することで、Cursor AIがプロジェクトの文脈をより良く理解し、適切な提案やコード生成を行うことができます。

// README.mdの構造
README.mdファイルは以下の構造を維持してください:
1. タイトルとAwesomeバッジ: プロジェクトのタイトルとバッジを表示します。
2. ロゴ: プロジェクトのロゴを表示します。
3. 簡単な説明: プロジェクトの概要を簡潔に説明します。
4. 「なぜ.cursorrules?」セクション: .cursorrulesファイルの重要性を説明します。
5. 目次: 各セクションへのリンクを含む目次を提供します。
6. ルールセクション: 以下のカテゴリに分けてルールを記載します。
- フロントエンドフレームワークとライブラリ
- バックエンドとフルスタック
- モバイル開発
- CSSとスタイリング
- 状態管理
- データベースとAPI
- テスト
- ビルドツールと開発
- 言語固有
- その他
7. 使用方法セクション: .cursorrulesファイルの使用方法を説明します。
貢献方法セクション: プロジェクトへの貢献方法を説明します。
9. ライセンスセクション: プロジェクトのライセンス情報を提供します。

// ルールの組織化
.cursorrulesファイルは、rulesディレクトリ内の以下の主要カテゴリに整理します:
- フロントエンドフレームワークとライブラリ
- バックエンドとフルスタック
- モバイル開発
- CSSとスタイリング
- 状態管理
- データベースとAPI
- テスト
- ビルドツールと開発
- 言語固有
- その他
各.cursorrulesファイルはrulesフォルダに直接配置します。
フォルダ名はファイルのカテゴリと内容を説明するものにします。
各フォルダのREADMEを参照して命名規則と説明を確認します。

// 命名とフォーマット
.cursorrulesファイルとそのフォルダには、`technology`-`focus`-`cursorrules`-`prompt`-`file` のパターンに従った説明的な名前を付けます。
README.mdファイル内の各カテゴリはアルファベット順に整理します。
リスト項目のフォーマットは一貫性を保ちます。

// コンテンツガイドライン
.cursorrulesファイルを作成または編集する際は、プロジェクト固有の指示とベストプラクティスに焦点を当てます。
複雑なルールには説明コメントを付けてコンテキストを提供します。
すべてのドキュメントと.cursorrulesファイルには明確で簡潔な言語を使用します。
プロジェクトの構築、スタイルガイドライン、または一般的に使用されるメソッドに関するコンテキストを提供します。

// メンテナンスと更新
新しい.cursorrulesファイルを追加する際は、README.mdファイルを更新し、正しいカテゴリに配置します。
README.mdファイル内のすべてのリンクが相対的で正しいことを確認します。
README.mdを更新する際は、目次が正確であることを確認します。
新しいカテゴリを追加する際は、README.mdの「目次」と「ルール」セクションの両方を更新します。
リポジトリが成長するにつれて、カテゴリの整理を定期的に見直し、更新します。

// ベストプラクティス
リポジトリ全体で大文字小文字と句読点の一貫性を保ちます。
Cursor AIを参照する際は、常に正しい大文字小文字とスペースを使用します。
例や説明を追加する際は、Cursor AIユーザーの実践的なユースケースに焦点を当てます。
.cursorrulesファイルが複数のカテゴリに適合する場合は、最も関連性の高いカテゴリに配置し、必要に応じて他のカテゴリで参照します。
「その他」カテゴリは、主要カテゴリにうまく収まらない.cursorrulesファイル用に保持します。

// ドキュメントの読み込み設定
README.mdの参考文献から以下の順序でドキュメントを読み込みます:
- 「参考文献」セクションに従う
- 記載順にURLを読み込む
- これらのドキュメントをAIアシスタンスの参考として使用
// 例:
```markdown:README.md
## 参考文献
- [Document](url)
```

// 参考文献の優先順位
ドキュメントの優先順位:
1. プロジェクト固有のドキュメント(README.mdから)
2. フレームワークとライブラリのドキュメント
3. 一般的な仕様と標準

// ドキュメントの使用方法
アシスタンス提供時:
- 読み込まれたドキュメントを正確な情報源として参照
- 参照ドキュメントから最新の仕様に従う
- プロジェクト固有のガイドラインを優先

// 追加の洞察
.cursorrulesファイルはリポジトリ固有の「AIのためのルール」です。
.cursorrulesファイルはリポジトリのルートに配置します。
.cursorrulesファイルの内容は、Cursorのグローバル「AIのためのルール」設定に追加されます。
一般的なコーディングプラクティスではなく、リポジトリレベルのコンテキストとガイドラインを提供することに焦点を当てます。
.cursorrulesには、プロジェクト構造、アーキテクチャの決定事項、一般的に使用されるライブラリやメソッドに関する情報を含めることができます。
プロジェクト固有のファイルタイプやコーディングパターンの扱い方に関するルールを含めることを検討します。
ルールは、Cursor AIのコード生成とコード理解の両方の側面をカバーできます。
このガイドラインに従うことで、Cursor AIがプロジェクトの文脈をより良く理解し、より適切な提案やコード生成を行うことができるようになります。
css
dockerfile
makefile
ruby
shell
vim script

First seen in:

budybye/dotfiles

Used in 1 repository

Vue
You are a senior .NET developer with expertise in C#, Avalonia, and cross-platform desktop application development. Your task is to translate and adapt the provided .NET Development Rules for C# Avalonia development, optimizing them for Japanese developers.
Here are the original .NET Development Rules:
<dotnet_rules>
{{DOTNET_RULES}}
</dotnet_rules>
Please translate and adapt these rules to create a set of guidelines for C# Avalonia development, tailored for Japanese developers. Follow these steps:
1. Translate the content into Japanese, ensuring that technical terms are accurately conveyed.
2. Adapt the rules to focus on Avalonia-specific concepts and best practices for desktop application development.
3. Remove or modify any sections that are not applicable to Avalonia development (e.g., ASP.NET Core, Entity Framework Core, API design).
4. Add new sections or guidelines that are particularly relevant to Avalonia development.
5. Ensure that the language used is clear, concise, and easily understood by Japanese developers.
Pay special attention to the following areas during translation and adaptation:
- XAML usage and best practices in Avalonia
- Avalonia-specific controls and layouts
- Cross-platform considerations for desktop applications
- MVVM pattern implementation in Avalonia
- Reactive programming concepts used in Avalonia
- Styling and theming in Avalonia applications
Present your translated and adapted rules in a structured format, using appropriate Japanese formatting and punctuation. Use markdown-style headers (##) for main sections and bullet points (-) for individual rules or guidelines.
Begin your response with the title "# Avalonia開発のためのC#ガイドライン" and organize the content into logical sections. Ensure that the final output is a comprehensive set of guidelines that will help Japanese developers create high-quality Avalonia applications using C#.
c#
css
html
python
react
rust
shell
typescript
+1 more

First seen in:

ishidafuu/isdf_bmeditor

Used in 1 repository