{"owner":"we-promise","repo":"sure","hasSkills":true,"totalSkillsCount":10,"totalTokensCount":1471,"categories":["cursor-rule","copilot-instructions","root-instruction","claude-rule"],"hasMcp":false,"mcpConfig":null,"found":[".cursor/rules/api-endpoint-consistency.mdc",".cursor/rules/general-rules.mdc",".cursor/rules/project-design.mdc",".cursor/rules/stimulus_conventions.mdc",".cursor/rules/testing.mdc",".cursor/rules/ui-ux-design-guidelines.mdc",".cursor/rules/view_conventions.mdc",".github/copilot-instructions.md","AGENTS.md","CLAUDE.md"],"skills":{".cursor/rules/api-endpoint-consistency.mdc":"---\ndescription: API endpoint consistency — checklist to run after every API endpoint commit (Minitest behavior, rswag docs-only, API key auth).\nglobs: app/controllers/api/v1/**/*.rb, spec/requests/api/v1/**/*.rb, test/controllers/api/v1/**/*.rb\nalwaysApply: false\n---\n\n@docs/llm-guides/api-endpoint-consistency.md\n",".cursor/rules/general-rules.mdc":"---\ndescription: Miscellaneous rules to get the AI to behave\nglobs: *\nalwaysApply: true\n---\n\n@AGENTS.md\n",".cursor/rules/project-design.mdc":"---\ndescription: This rule explains the system architecture and data flow of the Rails app\nglobs: *\nalwaysApply: true\n---\n\n@docs/llm-guides/architecture.md\n",".cursor/rules/stimulus_conventions.mdc":"---\ndescription: \nglobs: \nalwaysApply: false\n---\n\n@docs/llm-guides/ui.md\n",".cursor/rules/testing.mdc":"---\ndescription: \nglobs: test/**\nalwaysApply: false\n---\n\n@docs/llm-guides/testing.md\n",".cursor/rules/ui-ux-design-guidelines.mdc":"---\ndescription: This file describes Sure's design system and how views should be styled\nglobs: app/views/**,app/helpers/**,app/javascript/controllers/**\nalwaysApply: true\n---\n\n@docs/llm-guides/design-system.md\n",".cursor/rules/view_conventions.mdc":"---\ndescription: \nglobs: app/views/**,app/javascript/**,app/components/**/*.js\nalwaysApply: false\n---\n\n@docs/llm-guides/ui.md\n",".github/copilot-instructions.md":"Read and follow [AGENTS.md](../AGENTS.md) before working in this repository.\nFollow the shared guides linked there when their subjects apply to the task,\nincluding the development checks, architecture, testing, UI, API and provider guides.\n","AGENTS.md":"# Repository guidance\n\n## Working in the repository\n\n- Read [architecture and conventions](docs/llm-guides/architecture.md) before changing code, and the relevant [task guides](docs/llm-guides/README.md).\n- Rails code lives in `app/`; keep business logic in models, concerns and POROs, with thin controllers. JavaScript is in `app/javascript/`, components in `app/components/`, assets in `app/assets/`, and configuration in `config/`.\n- Minitest tests mirror `app/` under `test/`; fixtures are in `test/fixtures/`. Migrations and schema are in `db/`, scripts in `bin/`, shared libraries in `lib/`.\n- Use `Current.user` and `Current.family`, never `current_user` or `current_family`. Preserve family tenancy and existing authorization boundaries.\n- Prefer built-in Rails patterns and established dependencies. New dependencies need a strong technical or business reason. Keep changes focused, readable and consistent with nearby code.\n- Keep comments focused on non-obvious intent, constraints, and current behavior—not implementation diaries or issue/PR history. Put that history in commits and PR descriptions. Update or remove stale comments when changing code.\n- Ruby uses two-space indentation, `snake_case` methods/variables and `CamelCase` classes. JavaScript uses `lowerCamelCase` variables/functions and `PascalCase` classes; follow Biome. Keep domain logic out of ERB.\n- Never commit secrets; use environment variables and `.env.local` for local configuration.\n- Do not start `rails server`, touch `tmp/restart.txt`, run `rails credentials`, or automatically run migrations. Setup and database commands in the [development guide](docs/llm-guides/development.md) are for explicitly requested environment work.\n- New migrations use the current Rails migration version; leave historical migration versions intact.\n\n## Tests and pull requests\n\n- Use Minitest and fixtures for behavioral tests, with Mocha and VCR where needed. RSpec/rswag is for OpenAPI documentation only. Follow the [testing guide](docs/llm-guides/testing.md).\n- Run `bin/rails test` and ensure it is green before pushing. Before opening a PR, run **all** checks in the [pre-PR checklist](docs/llm-guides/development.md#before-opening-a-pull-request): full Rails tests, applicable system tests, Ruby and ERB lint, Biome and Brakeman. Only create the PR when all required checks pass.\n- Commits use imperative subjects of at most 72 characters, with rationale and issue references where relevant. Target `main` with small, cohesive changes.\n- PRs explain the problem, resulting behavior and validation; link issues and include screenshots for UI changes and migration notes when applicable. Ensure CI passes and the branch is up to date before requesting review; see [CONTRIBUTING.md](CONTRIBUTING.md).\n\n## UI changes\n\nWhen touching ERB, view components or CSS, follow the [design system guide](docs/llm-guides/design-system.md):\n\n- Use functional tokens from `app/assets/tailwind/sure-design-system.css`, such as `bg-container`, `text-primary`, `border-primary`, `bg-warning/10` and `text-destructive`. No raw Tailwind palette classes or hex literals.\n- Check `app/components/DS/` first for alerts, badges, buttons, disclosures, dialogs and inputs. Use existing `DS::*` primitives.\n- If the same hand-built shape appears at least twice in a diff with no DS equivalent, propose a new `DS::*` primitive before the second copy lands.\n- Use the `icon` helper, never `lucide_icon` directly; no raw SVG outside DS primitives. Use `t()` for user-facing strings and scale tokens instead of arbitrary pixel values when a scale token fits.\n- Adding styles to `app/assets/tailwind/sure-design-system.css` or `app/assets/tailwind/application.css` requires explicit permission.\n- Reviewers escalate DS reuse and repeated-shape violations to close/rewrite; token and icon/SVG/localization/scale violations are request-changes.\n\n## API changes\n\nAdding or modifying `app/controllers/api/v1/` endpoints requires Minitest behavioral coverage and corresponding **documentation-only** rswag specs in `spec/requests/api/v1/`. Reusable schemas belong in `spec/swagger_helper.rb`; regenerate `docs/api/openapi.yaml` with `RAILS_ENV=test bundle exec rake rswag:specs:swaggerize` after changes.\n\n**Post-commit API consistency:** after every API endpoint commit, follow the [API checklist](docs/llm-guides/api-endpoint-consistency.md): Minitest coverage, no behavioral assertions in rswag, and the shared `X-Api-Key` authentication pattern in those tests/specs.\n\n## Provider and feature work\n\n- Read [provider sync guidance](docs/llm-guides/providers.md) when changing imports, pending transactions, FX metadata or diagnostics. Use `DebugLogEntry.capture(...)` for support-relevant failures and partial responses, with provider/source metadata and family/account-provider context where available.\n- For securities providers, follow [adding a securities provider](docs/llm-guides/adding-a-securities-provider.md).\n- For feature rollout, follow [preview-feature gating](docs/llm-guides/gating-a-preview-feature.md); for goals, read the [Goals guide](docs/llm-guides/goals.md).\n","CLAUDE.md":"@AGENTS.md\n"},"files":{".cursor/rules/api-endpoint-consistency.mdc":"---\ndescription: API endpoint consistency — checklist to run after every API endpoint commit (Minitest behavior, rswag docs-only, API key auth).\nglobs: app/controllers/api/v1/**/*.rb, spec/requests/api/v1/**/*.rb, test/controllers/api/v1/**/*.rb\nalwaysApply: false\n---\n\n@docs/llm-guides/api-endpoint-consistency.md\n",".cursor/rules/general-rules.mdc":"---\ndescription: Miscellaneous rules to get the AI to behave\nglobs: *\nalwaysApply: true\n---\n\n@AGENTS.md\n",".cursor/rules/project-design.mdc":"---\ndescription: This rule explains the system architecture and data flow of the Rails app\nglobs: *\nalwaysApply: true\n---\n\n@docs/llm-guides/architecture.md\n",".cursor/rules/stimulus_conventions.mdc":"---\ndescription: \nglobs: \nalwaysApply: false\n---\n\n@docs/llm-guides/ui.md\n",".cursor/rules/testing.mdc":"---\ndescription: \nglobs: test/**\nalwaysApply: false\n---\n\n@docs/llm-guides/testing.md\n",".cursor/rules/ui-ux-design-guidelines.mdc":"---\ndescription: This file describes Sure's design system and how views should be styled\nglobs: app/views/**,app/helpers/**,app/javascript/controllers/**\nalwaysApply: true\n---\n\n@docs/llm-guides/design-system.md\n",".cursor/rules/view_conventions.mdc":"---\ndescription: \nglobs: app/views/**,app/javascript/**,app/components/**/*.js\nalwaysApply: false\n---\n\n@docs/llm-guides/ui.md\n",".github/copilot-instructions.md":"Read and follow [AGENTS.md](../AGENTS.md) before working in this repository.\nFollow the shared guides linked there when their subjects apply to the task,\nincluding the development checks, architecture, testing, UI, API and provider guides.\n","AGENTS.md":"# Repository guidance\n\n## Working in the repository\n\n- Read [architecture and conventions](docs/llm-guides/architecture.md) before changing code, and the relevant [task guides](docs/llm-guides/README.md).\n- Rails code lives in `app/`; keep business logic in models, concerns and POROs, with thin controllers. JavaScript is in `app/javascript/`, components in `app/components/`, assets in `app/assets/`, and configuration in `config/`.\n- Minitest tests mirror `app/` under `test/`; fixtures are in `test/fixtures/`. Migrations and schema are in `db/`, scripts in `bin/`, shared libraries in `lib/`.\n- Use `Current.user` and `Current.family`, never `current_user` or `current_family`. Preserve family tenancy and existing authorization boundaries.\n- Prefer built-in Rails patterns and established dependencies. New dependencies need a strong technical or business reason. Keep changes focused, readable and consistent with nearby code.\n- Keep comments focused on non-obvious intent, constraints, and current behavior—not implementation diaries or issue/PR history. Put that history in commits and PR descriptions. Update or remove stale comments when changing code.\n- Ruby uses two-space indentation, `snake_case` methods/variables and `CamelCase` classes. JavaScript uses `lowerCamelCase` variables/functions and `PascalCase` classes; follow Biome. Keep domain logic out of ERB.\n- Never commit secrets; use environment variables and `.env.local` for local configuration.\n- Do not start `rails server`, touch `tmp/restart.txt`, run `rails credentials`, or automatically run migrations. Setup and database commands in the [development guide](docs/llm-guides/development.md) are for explicitly requested environment work.\n- New migrations use the current Rails migration version; leave historical migration versions intact.\n\n## Tests and pull requests\n\n- Use Minitest and fixtures for behavioral tests, with Mocha and VCR where needed. RSpec/rswag is for OpenAPI documentation only. Follow the [testing guide](docs/llm-guides/testing.md).\n- Run `bin/rails test` and ensure it is green before pushing. Before opening a PR, run **all** checks in the [pre-PR checklist](docs/llm-guides/development.md#before-opening-a-pull-request): full Rails tests, applicable system tests, Ruby and ERB lint, Biome and Brakeman. Only create the PR when all required checks pass.\n- Commits use imperative subjects of at most 72 characters, with rationale and issue references where relevant. Target `main` with small, cohesive changes.\n- PRs explain the problem, resulting behavior and validation; link issues and include screenshots for UI changes and migration notes when applicable. Ensure CI passes and the branch is up to date before requesting review; see [CONTRIBUTING.md](CONTRIBUTING.md).\n\n## UI changes\n\nWhen touching ERB, view components or CSS, follow the [design system guide](docs/llm-guides/design-system.md):\n\n- Use functional tokens from `app/assets/tailwind/sure-design-system.css`, such as `bg-container`, `text-primary`, `border-primary`, `bg-warning/10` and `text-destructive`. No raw Tailwind palette classes or hex literals.\n- Check `app/components/DS/` first for alerts, badges, buttons, disclosures, dialogs and inputs. Use existing `DS::*` primitives.\n- If the same hand-built shape appears at least twice in a diff with no DS equivalent, propose a new `DS::*` primitive before the second copy lands.\n- Use the `icon` helper, never `lucide_icon` directly; no raw SVG outside DS primitives. Use `t()` for user-facing strings and scale tokens instead of arbitrary pixel values when a scale token fits.\n- Adding styles to `app/assets/tailwind/sure-design-system.css` or `app/assets/tailwind/application.css` requires explicit permission.\n- Reviewers escalate DS reuse and repeated-shape violations to close/rewrite; token and icon/SVG/localization/scale violations are request-changes.\n\n## API changes\n\nAdding or modifying `app/controllers/api/v1/` endpoints requires Minitest behavioral coverage and corresponding **documentation-only** rswag specs in `spec/requests/api/v1/`. Reusable schemas belong in `spec/swagger_helper.rb`; regenerate `docs/api/openapi.yaml` with `RAILS_ENV=test bundle exec rake rswag:specs:swaggerize` after changes.\n\n**Post-commit API consistency:** after every API endpoint commit, follow the [API checklist](docs/llm-guides/api-endpoint-consistency.md): Minitest coverage, no behavioral assertions in rswag, and the shared `X-Api-Key` authentication pattern in those tests/specs.\n\n## Provider and feature work\n\n- Read [provider sync guidance](docs/llm-guides/providers.md) when changing imports, pending transactions, FX metadata or diagnostics. Use `DebugLogEntry.capture(...)` for support-relevant failures and partial responses, with provider/source metadata and family/account-provider context where available.\n- For securities providers, follow [adding a securities provider](docs/llm-guides/adding-a-securities-provider.md).\n- For feature rollout, follow [preview-feature gating](docs/llm-guides/gating-a-preview-feature.md); for goals, read the [Goals guide](docs/llm-guides/goals.md).\n","CLAUDE.md":"@AGENTS.md\n"},"items":[{"name":"AGENTS.md","path":"AGENTS.md","rawUrl":"https://raw.githubusercontent.com/we-promise/sure/HEAD/AGENTS.md","title":"AI Agent Protocol & Instructions","category":"root-instruction","format":"markdown","content":"# Repository guidance\n\n## Working in the repository\n\n- Read [architecture and conventions](docs/llm-guides/architecture.md) before changing code, and the relevant [task guides](docs/llm-guides/README.md).\n- Rails code lives in `app/`; keep business logic in models, concerns and POROs, with thin controllers. JavaScript is in `app/javascript/`, components in `app/components/`, assets in `app/assets/`, and configuration in `config/`.\n- Minitest tests mirror `app/` under `test/`; fixtures are in `test/fixtures/`. Migrations and schema are in `db/`, scripts in `bin/`, shared libraries in `lib/`.\n- Use `Current.user` and `Current.family`, never `current_user` or `current_family`. Preserve family tenancy and existing authorization boundaries.\n- Prefer built-in Rails patterns and established dependencies. New dependencies need a strong technical or business reason. Keep changes focused, readable and consistent with nearby code.\n- Keep comments focused on non-obvious intent, constraints, and current behavior—not implementation diaries or issue/PR history. Put that history in commits and PR descriptions. Update or remove stale comments when changing code.\n- Ruby uses two-space indentation, `snake_case` methods/variables and `CamelCase` classes. JavaScript uses `lowerCamelCase` variables/functions and `PascalCase` classes; follow Biome. Keep domain logic out of ERB.\n- Never commit secrets; use environment variables and `.env.local` for local configuration.\n- Do not start `rails server`, touch `tmp/restart.txt`, run `rails credentials`, or automatically run migrations. Setup and database commands in the [development guide](docs/llm-guides/development.md) are for explicitly requested environment work.\n- New migrations use the current Rails migration version; leave historical migration versions intact.\n\n## Tests and pull requests\n\n- Use Minitest and fixtures for behavioral tests, with Mocha and VCR where needed. RSpec/rswag is for OpenAPI documentation only. Follow the [testing guide](docs/llm-guides/testing.md).\n- Run `bin/rails test` and ensure it is green before pushing. Before opening a PR, run **all** checks in the [pre-PR checklist](docs/llm-guides/development.md#before-opening-a-pull-request): full Rails tests, applicable system tests, Ruby and ERB lint, Biome and Brakeman. Only create the PR when all required checks pass.\n- Commits use imperative subjects of at most 72 characters, with rationale and issue references where relevant. Target `main` with small, cohesive changes.\n- PRs explain the problem, resulting behavior and validation; link issues and include screenshots for UI changes and migration notes when applicable. Ensure CI passes and the branch is up to date before requesting review; see [CONTRIBUTING.md](CONTRIBUTING.md).\n\n## UI changes\n\nWhen touching ERB, view components or CSS, follow the [design system guide](docs/llm-guides/design-system.md):\n\n- Use functional tokens from `app/assets/tailwind/sure-design-system.css`, such as `bg-container`, `text-primary`, `border-primary`, `bg-warning/10` and `text-destructive`. No raw Tailwind palette classes or hex literals.\n- Check `app/components/DS/` first for alerts, badges, buttons, disclosures, dialogs and inputs. Use existing `DS::*` primitives.\n- If the same hand-built shape appears at least twice in a diff with no DS equivalent, propose a new `DS::*` primitive before the second copy lands.\n- Use the `icon` helper, never `lucide_icon` directly; no raw SVG outside DS primitives. Use `t()` for user-facing strings and scale tokens instead of arbitrary pixel values when a scale token fits.\n- Adding styles to `app/assets/tailwind/sure-design-system.css` or `app/assets/tailwind/application.css` requires explicit permission.\n- Reviewers escalate DS reuse and repeated-shape violations to close/rewrite; token and icon/SVG/localization/scale violations are request-changes.\n\n## API changes\n\nAdding or modifying `app/controllers/api/v1/` endpoints requires Minitest behavioral coverage and corresponding **documentation-only** rswag specs in `spec/requests/api/v1/`. Reusable schemas belong in `spec/swagger_helper.rb`; regenerate `docs/api/openapi.yaml` with `RAILS_ENV=test bundle exec rake rswag:specs:swaggerize` after changes.\n\n**Post-commit API consistency:** after every API endpoint commit, follow the [API checklist](docs/llm-guides/api-endpoint-consistency.md): Minitest coverage, no behavioral assertions in rswag, and the shared `X-Api-Key` authentication pattern in those tests/specs.\n\n## Provider and feature work\n\n- Read [provider sync guidance](docs/llm-guides/providers.md) when changing imports, pending transactions, FX metadata or diagnostics. Use `DebugLogEntry.capture(...)` for support-relevant failures and partial responses, with provider/source metadata and family/account-provider context where available.\n- For securities providers, follow [adding a securities provider](docs/llm-guides/adding-a-securities-provider.md).\n- For feature rollout, follow [preview-feature gating](docs/llm-guides/gating-a-preview-feature.md); for goals, read the [Goals guide](docs/llm-guides/goals.md).\n","isInternal":false,"tokens":1139,"sizeBytes":5125},{"name":"CLAUDE.md","path":"CLAUDE.md","rawUrl":"https://raw.githubusercontent.com/we-promise/sure/HEAD/CLAUDE.md","title":"Claude Agent Guidelines & System Prompt","category":"claude-rule","format":"markdown","content":"@AGENTS.md\n","isInternal":false,"tokens":5,"sizeBytes":11},{"name":"copilot-instructions.md","path":".github/copilot-instructions.md","rawUrl":"https://raw.githubusercontent.com/we-promise/sure/HEAD/.github/copilot-instructions.md","title":"GitHub Copilot Instructions","category":"copilot-instructions","format":"markdown","content":"Read and follow [AGENTS.md](../AGENTS.md) before working in this repository.\nFollow the shared guides linked there when their subjects apply to the task,\nincluding the development checks, architecture, testing, UI, API and provider guides.\n","isInternal":false,"tokens":49,"sizeBytes":240},{"name":"api-endpoint-consistency.mdc","path":".cursor/rules/api-endpoint-consistency.mdc","rawUrl":"https://raw.githubusercontent.com/we-promise/sure/HEAD/.cursor/rules/api-endpoint-consistency.mdc","title":"Cursor Rule: api-endpoint-consistency","category":"cursor-rule","format":"mdc","content":"---\ndescription: API endpoint consistency — checklist to run after every API endpoint commit (Minitest behavior, rswag docs-only, API key auth).\nglobs: app/controllers/api/v1/**/*.rb, spec/requests/api/v1/**/*.rb, test/controllers/api/v1/**/*.rb\nalwaysApply: false\n---\n\n@docs/llm-guides/api-endpoint-consistency.md\n","frontmatter":{"description":"API endpoint consistency — checklist to run after every API endpoint commit (Minitest behavior, rswag docs-only, API key auth).","globs":"app/controllers/api/v1/**/*.rb, spec/requests/api/v1/**/*.rb, test/controllers/api/v1/**/*.rb","alwaysApply":false},"isInternal":false,"tokens":79,"sizeBytes":317},{"name":"general-rules.mdc","path":".cursor/rules/general-rules.mdc","rawUrl":"https://raw.githubusercontent.com/we-promise/sure/HEAD/.cursor/rules/general-rules.mdc","title":"Cursor Rule: general-rules","category":"cursor-rule","format":"mdc","content":"---\ndescription: Miscellaneous rules to get the AI to behave\nglobs: *\nalwaysApply: true\n---\n\n@AGENTS.md\n","isInternal":false,"tokens":27,"sizeBytes":104},{"name":"project-design.mdc","path":".cursor/rules/project-design.mdc","rawUrl":"https://raw.githubusercontent.com/we-promise/sure/HEAD/.cursor/rules/project-design.mdc","title":"Cursor Rule: project-design","category":"cursor-rule","format":"mdc","content":"---\ndescription: This rule explains the system architecture and data flow of the Rails app\nglobs: *\nalwaysApply: true\n---\n\n@docs/llm-guides/architecture.md\n","isInternal":false,"tokens":38,"sizeBytes":156},{"name":"stimulus_conventions.mdc","path":".cursor/rules/stimulus_conventions.mdc","rawUrl":"https://raw.githubusercontent.com/we-promise/sure/HEAD/.cursor/rules/stimulus_conventions.mdc","title":"Cursor Rule: stimulus_conventions","category":"cursor-rule","format":"mdc","content":"---\ndescription: \nglobs: \nalwaysApply: false\n---\n\n@docs/llm-guides/ui.md\n","frontmatter":{"description":null,"globs":null,"alwaysApply":false},"isInternal":false,"tokens":24,"sizeBytes":73},{"name":"testing.mdc","path":".cursor/rules/testing.mdc","rawUrl":"https://raw.githubusercontent.com/we-promise/sure/HEAD/.cursor/rules/testing.mdc","title":"Cursor Rule: testing","category":"cursor-rule","format":"mdc","content":"---\ndescription: \nglobs: test/**\nalwaysApply: false\n---\n\n@docs/llm-guides/testing.md\n","frontmatter":{"description":null,"globs":"test/**","alwaysApply":false},"isInternal":false,"tokens":25,"sizeBytes":85},{"name":"ui-ux-design-guidelines.mdc","path":".cursor/rules/ui-ux-design-guidelines.mdc","rawUrl":"https://raw.githubusercontent.com/we-promise/sure/HEAD/.cursor/rules/ui-ux-design-guidelines.mdc","title":"Cursor Rule: ui-ux-design-guidelines","category":"cursor-rule","format":"mdc","content":"---\ndescription: This file describes Sure's design system and how views should be styled\nglobs: app/views/**,app/helpers/**,app/javascript/controllers/**\nalwaysApply: true\n---\n\n@docs/llm-guides/design-system.md\n","frontmatter":{"description":"This file describes Sure's design system and how views should be styled","globs":"app/views/**,app/helpers/**,app/javascript/controllers/**","alwaysApply":true},"isInternal":false,"tokens":49,"sizeBytes":211},{"name":"view_conventions.mdc","path":".cursor/rules/view_conventions.mdc","rawUrl":"https://raw.githubusercontent.com/we-promise/sure/HEAD/.cursor/rules/view_conventions.mdc","title":"Cursor Rule: view_conventions","category":"cursor-rule","format":"mdc","content":"---\ndescription: \nglobs: app/views/**,app/javascript/**,app/components/**/*.js\nalwaysApply: false\n---\n\n@docs/llm-guides/ui.md\n","frontmatter":{"description":null,"globs":"app/views/**,app/javascript/**,app/components/**/*.js","alwaysApply":false},"isInternal":false,"tokens":36,"sizeBytes":126}],"systemPromptSnippet":"<yakaai_skills repo=\"we-promise/sure\">\n<!-- File: AGENTS.md (Tokens: ~1139 | Category: root-instruction) -->\n# Repository guidance\n\n## Working in the repository\n\n- Read [architecture and conventions](docs/llm-guides/architecture.md) before changing code, and the relevant [task guides](docs/llm-guides/README.md).\n- Rails code lives in `app/`; keep business logic in models, concerns and POROs, with thin controllers. JavaScript is in `app/javascript/`, components in `app/components/`, assets in `app/assets/`, and configuration in `config/`.\n- Minitest tests mirror `app/` under `test/`; fixtures are in `test/fixtures/`. Migrations and schema are in `db/`, scripts in `bin/`, shared libraries in `lib/`.\n- Use `Current.user` and `Current.family`, never `current_user` or `current_family`. Preserve family tenancy and existing authorization boundaries.\n- Prefer built-in Rails patterns and established dependencies. New dependencies need a strong technical or business reason. Keep changes focused, readable and consistent with nearby code.\n- Keep comments focused on non-obvious intent, constraints, and current behavior—not implementation diaries or issue/PR history. Put that history in commits and PR descriptions. Update or remove stale comments when changing code.\n- Ruby uses two-space indentation, `snake_case` methods/variables and `CamelCase` classes. JavaScript uses `lowerCamelCase` variables/functions and `PascalCase` classes; follow Biome. Keep domain logic out of ERB.\n- Never commit secrets; use environment variables and `.env.local` for local configuration.\n- Do not start `rails server`, touch `tmp/restart.txt`, run `rails credentials`, or automatically run migrations. Setup and database commands in the [development guide](docs/llm-guides/development.md) are for explicitly requested environment work.\n- New migrations use the current Rails migration version; leave historical migration versions intact.\n\n## Tests and pull requests\n\n- Use Minitest and fixtures for behavioral tests, with Mocha and VCR where needed. RSpec/rswag is for OpenAPI documentation only. Follow the [testing guide](docs/llm-guides/testing.md).\n- Run `bin/rails test` and ensure it is green before pushing. Before opening a PR, run **all** checks in the [pre-PR checklist](docs/llm-guides/development.md#before-opening-a-pull-request): full Rails tests, applicable system tests, Ruby and ERB lint, Biome and Brakeman. Only create the PR when all required checks pass.\n- Commits use imperative subjects of at most 72 characters, with rationale and issue references where relevant. Target `main` with small, cohesive changes.\n- PRs explain the problem, resulting behavior and validation; link issues and include screenshots for UI changes and migration notes when applicable. Ensure CI passes and the branch is up to date before requesting review; see [CONTRIBUTING.md](CONTRIBUTING.md).\n\n## UI changes\n\nWhen touching ERB, view components or CSS, follow the [design system guide](docs/llm-guides/design-system.md):\n\n- Use functional tokens from `app/assets/tailwind/sure-design-system.css`, such as `bg-container`, `text-primary`, `border-primary`, `bg-warning/10` and `text-destructive`. No raw Tailwind palette classes or hex literals.\n- Check `app/components/DS/` first for alerts, badges, buttons, disclosures, dialogs and inputs. Use existing `DS::*` primitives.\n- If the same hand-built shape appears at least twice in a diff with no DS equivalent, propose a new `DS::*` primitive before the second copy lands.\n- Use the `icon` helper, never `lucide_icon` directly; no raw SVG outside DS primitives. Use `t()` for user-facing strings and scale tokens instead of arbitrary pixel values when a scale token fits.\n- Adding styles to `app/assets/tailwind/sure-design-system.css` or `app/assets/tailwind/application.css` requires explicit permission.\n- Reviewers escalate DS reuse and repeated-shape violations to close/rewrite; token and icon/SVG/localization/scale violations are request-changes.\n\n## API changes\n\nAdding or modifying `app/controllers/api/v1/` endpoints requires Minitest behavioral coverage and corresponding **documentation-only** rswag specs in `spec/requests/api/v1/`. Reusable schemas belong in `spec/swagger_helper.rb`; regenerate `docs/api/openapi.yaml` with `RAILS_ENV=test bundle exec rake rswag:specs:swaggerize` after changes.\n\n**Post-commit API consistency:** after every API endpoint commit, follow the [API checklist](docs/llm-guides/api-endpoint-consistency.md): Minitest coverage, no behavioral assertions in rswag, and the shared `X-Api-Key` authentication pattern in those tests/specs.\n\n## Provider and feature work\n\n- Read [provider sync guidance](docs/llm-guides/providers.md) when changing imports, pending transactions, FX metadata or diagnostics. Use `DebugLogEntry.capture(...)` for support-relevant failures and partial responses, with provider/source metadata and family/account-provider context where available.\n- For securities providers, follow [adding a securities provider](docs/llm-guides/adding-a-securities-provider.md).\n- For feature rollout, follow [preview-feature gating](docs/llm-guides/gating-a-preview-feature.md); for goals, read the [Goals guide](docs/llm-guides/goals.md).\n\n<!-- File: CLAUDE.md (Tokens: ~5 | Category: claude-rule) -->\n@AGENTS.md\n\n<!-- File: .github/copilot-instructions.md (Tokens: ~49 | Category: copilot-instructions) -->\nRead and follow [AGENTS.md](../AGENTS.md) before working in this repository.\nFollow the shared guides linked there when their subjects apply to the task,\nincluding the development checks, architecture, testing, UI, API and provider guides.\n\n<!-- File: .cursor/rules/api-endpoint-consistency.mdc (Tokens: ~79 | Category: cursor-rule) -->\n---\ndescription: API endpoint consistency — checklist to run after every API endpoint commit (Minitest behavior, rswag docs-only, API key auth).\nglobs: app/controllers/api/v1/**/*.rb, spec/requests/api/v1/**/*.rb, test/controllers/api/v1/**/*.rb\nalwaysApply: false\n---\n\n@docs/llm-guides/api-endpoint-consistency.md\n\n<!-- File: .cursor/rules/general-rules.mdc (Tokens: ~27 | Category: cursor-rule) -->\n---\ndescription: Miscellaneous rules to get the AI to behave\nglobs: *\nalwaysApply: true\n---\n\n@AGENTS.md\n\n<!-- File: .cursor/rules/project-design.mdc (Tokens: ~38 | Category: cursor-rule) -->\n---\ndescription: This rule explains the system architecture and data flow of the Rails app\nglobs: *\nalwaysApply: true\n---\n\n@docs/llm-guides/architecture.md\n\n<!-- File: .cursor/rules/stimulus_conventions.mdc (Tokens: ~24 | Category: cursor-rule) -->\n---\ndescription: \nglobs: \nalwaysApply: false\n---\n\n@docs/llm-guides/ui.md\n\n<!-- File: .cursor/rules/testing.mdc (Tokens: ~25 | Category: cursor-rule) -->\n---\ndescription: \nglobs: test/**\nalwaysApply: false\n---\n\n@docs/llm-guides/testing.md\n\n<!-- File: .cursor/rules/ui-ux-design-guidelines.mdc (Tokens: ~49 | Category: cursor-rule) -->\n---\ndescription: This file describes Sure's design system and how views should be styled\nglobs: app/views/**,app/helpers/**,app/javascript/controllers/**\nalwaysApply: true\n---\n\n@docs/llm-guides/design-system.md\n\n<!-- File: .cursor/rules/view_conventions.mdc (Tokens: ~36 | Category: cursor-rule) -->\n---\ndescription: \nglobs: app/views/**,app/javascript/**,app/components/**/*.js\nalwaysApply: false\n---\n\n@docs/llm-guides/ui.md\n</yakaai_skills>"}