{"owner":"hydralauncher","repo":"hydra","hasSkills":true,"hasMcp":false,"mcpConfig":null,"found":[".cursorrules"],"skills":{".cursorrules":"# Hydra Project Rules\n\n## Logging\n\n- **Always use `logger` instead of `console` for logging** in both main and renderer processes\n- In main process: `import { logger } from \"@main/services\";`\n- In renderer process: `import { logger } from \"@renderer/logger\";`\n- Replace all instances of:\n  - `console.log()` → `logger.log()`\n  - `console.error()` → `logger.error()`\n  - `console.warn()` → `logger.warn()`\n  - `console.info()` → `logger.info()`\n  - `console.debug()` → `logger.debug()`\n- Do not use `console` for any logging purposes\n\n## Internationalization (i18n)\n\n- All user-facing strings must be translated using i18next\n- Use the `useTranslation` hook in React components: `const { t } = useTranslation(\"namespace\");`\n- Add new translation keys to `src/locales/en/translation.json`\n- Never hardcode English strings in the UI code\n- Placeholder text in form fields must also be translated\n\n## Code Style\n\n- Use ESLint and Prettier for code formatting\n- Follow TypeScript strict mode conventions\n- Use async/await instead of promises when possible\n- Prefer named exports over default exports for utilities and services\n\n## ESLint Issues\n\n- **Always try to fix ESLint errors properly before disabling rules**\n- When encountering ESLint errors, explore these solutions in order:\n  1. **Fix the code to comply with the rule** (e.g., add missing required elements, fix accessibility issues)\n  2. **Use minimal markup to satisfy the rule** (e.g., add empty `<track>` elements for videos without captions, add `role` attributes)\n  3. **Only disable the rule as a last resort** when no reasonable solution exists\n- When disabling a rule, always include a comment explaining why it's necessary\n- Examples of proper fixes:\n  - For `jsx-a11y/media-has-caption`: Add `<track kind=\"captions\" />` even if no captions are available\n  - For `jsx-a11y/alt-text`: Add meaningful alt text or `alt=\"\"` for decorative images\n  - For accessibility rules: Add appropriate ARIA attributes rather than disabling\n\n## TypeScript Array Syntax\n\n- **Always use `T[]` syntax instead of `Array<T>`** for array types\n- Prefer: `string[]`, `number[]`, `MyType[]`\n- Avoid: `Array<string>`, `Array<number>`, `Array<MyType>`\n- This applies to all type annotations, type assertions, and generic type parameters\n\n## Comments\n\n- Keep comments concise and purposeful; avoid verbose explanations.\n- Focus on the \"why\" or non-obvious context, not restating the code.\n- Prefer self-explanatory naming and structure over excessive comments.\n- Do not comment every line or obvious behavior; remove stale comments.\n- Use docblocks only where they add value (public APIs, complex logic).\n"},"files":{".cursorrules":"# Hydra Project Rules\n\n## Logging\n\n- **Always use `logger` instead of `console` for logging** in both main and renderer processes\n- In main process: `import { logger } from \"@main/services\";`\n- In renderer process: `import { logger } from \"@renderer/logger\";`\n- Replace all instances of:\n  - `console.log()` → `logger.log()`\n  - `console.error()` → `logger.error()`\n  - `console.warn()` → `logger.warn()`\n  - `console.info()` → `logger.info()`\n  - `console.debug()` → `logger.debug()`\n- Do not use `console` for any logging purposes\n\n## Internationalization (i18n)\n\n- All user-facing strings must be translated using i18next\n- Use the `useTranslation` hook in React components: `const { t } = useTranslation(\"namespace\");`\n- Add new translation keys to `src/locales/en/translation.json`\n- Never hardcode English strings in the UI code\n- Placeholder text in form fields must also be translated\n\n## Code Style\n\n- Use ESLint and Prettier for code formatting\n- Follow TypeScript strict mode conventions\n- Use async/await instead of promises when possible\n- Prefer named exports over default exports for utilities and services\n\n## ESLint Issues\n\n- **Always try to fix ESLint errors properly before disabling rules**\n- When encountering ESLint errors, explore these solutions in order:\n  1. **Fix the code to comply with the rule** (e.g., add missing required elements, fix accessibility issues)\n  2. **Use minimal markup to satisfy the rule** (e.g., add empty `<track>` elements for videos without captions, add `role` attributes)\n  3. **Only disable the rule as a last resort** when no reasonable solution exists\n- When disabling a rule, always include a comment explaining why it's necessary\n- Examples of proper fixes:\n  - For `jsx-a11y/media-has-caption`: Add `<track kind=\"captions\" />` even if no captions are available\n  - For `jsx-a11y/alt-text`: Add meaningful alt text or `alt=\"\"` for decorative images\n  - For accessibility rules: Add appropriate ARIA attributes rather than disabling\n\n## TypeScript Array Syntax\n\n- **Always use `T[]` syntax instead of `Array<T>`** for array types\n- Prefer: `string[]`, `number[]`, `MyType[]`\n- Avoid: `Array<string>`, `Array<number>`, `Array<MyType>`\n- This applies to all type annotations, type assertions, and generic type parameters\n\n## Comments\n\n- Keep comments concise and purposeful; avoid verbose explanations.\n- Focus on the \"why\" or non-obvious context, not restating the code.\n- Prefer self-explanatory naming and structure over excessive comments.\n- Do not comment every line or obvious behavior; remove stale comments.\n- Use docblocks only where they add value (public APIs, complex logic).\n"},"items":[{"name":".cursorrules","path":".cursorrules","title":".cursorrules","content":"# Hydra Project Rules\n\n## Logging\n\n- **Always use `logger` instead of `console` for logging** in both main and renderer processes\n- In main process: `import { logger } from \"@main/services\";`\n- In renderer process: `import { logger } from \"@renderer/logger\";`\n- Replace all instances of:\n  - `console.log()` → `logger.log()`\n  - `console.error()` → `logger.error()`\n  - `console.warn()` → `logger.warn()`\n  - `console.info()` → `logger.info()`\n  - `console.debug()` → `logger.debug()`\n- Do not use `console` for any logging purposes\n\n## Internationalization (i18n)\n\n- All user-facing strings must be translated using i18next\n- Use the `useTranslation` hook in React components: `const { t } = useTranslation(\"namespace\");`\n- Add new translation keys to `src/locales/en/translation.json`\n- Never hardcode English strings in the UI code\n- Placeholder text in form fields must also be translated\n\n## Code Style\n\n- Use ESLint and Prettier for code formatting\n- Follow TypeScript strict mode conventions\n- Use async/await instead of promises when possible\n- Prefer named exports over default exports for utilities and services\n\n## ESLint Issues\n\n- **Always try to fix ESLint errors properly before disabling rules**\n- When encountering ESLint errors, explore these solutions in order:\n  1. **Fix the code to comply with the rule** (e.g., add missing required elements, fix accessibility issues)\n  2. **Use minimal markup to satisfy the rule** (e.g., add empty `<track>` elements for videos without captions, add `role` attributes)\n  3. **Only disable the rule as a last resort** when no reasonable solution exists\n- When disabling a rule, always include a comment explaining why it's necessary\n- Examples of proper fixes:\n  - For `jsx-a11y/media-has-caption`: Add `<track kind=\"captions\" />` even if no captions are available\n  - For `jsx-a11y/alt-text`: Add meaningful alt text or `alt=\"\"` for decorative images\n  - For accessibility rules: Add appropriate ARIA attributes rather than disabling\n\n## TypeScript Array Syntax\n\n- **Always use `T[]` syntax instead of `Array<T>`** for array types\n- Prefer: `string[]`, `number[]`, `MyType[]`\n- Avoid: `Array<string>`, `Array<number>`, `Array<MyType>`\n- This applies to all type annotations, type assertions, and generic type parameters\n\n## Comments\n\n- Keep comments concise and purposeful; avoid verbose explanations.\n- Focus on the \"why\" or non-obvious context, not restating the code.\n- Prefer self-explanatory naming and structure over excessive comments.\n- Do not comment every line or obvious behavior; remove stale comments.\n- Use docblocks only where they add value (public APIs, complex logic).\n","category":"root","tokens":661}]}