Name: dspace-dev-rules
Author: democratizedspace

Instruction file imported from democratizedspace/dspace (.cursor/rules/dspace-dev-rules.mdc). Copyright stays with the author.

this project uses Astro SSR + hydration of Svelte components on the client side. Thus, interactivity must happen after onMount, and this is especially important when writing tests.
after every change, run all tests (unit, playwright, linter) to ensure nothing regressed and help guide development of new features.
whenever possible, create unit tests, integration tests, playwright tests, and anything else that may be relevant to make the codebase more robust and less prone to unexpected regressions.
you may commit to git locally to make sure your changes also pass precommit hooks. Make sure you don't git push to the origin yourself. Ask me to do it, just to be safe! I want to review all code to make sure we're headed in the right direction and not breaking our tests.
look for user journeys based on certain obvious interactions with pages via playwright, and write unique tests for those. This should be a fairly fluid idle game that feels natural and fun to use.
When building UIs, check the available Svelte components that have been created already, and try to reuse components when possible. In particular, anything that functions as a button should use the Chip.svelte component. This component's CSS should match that of Chip.astro, which shouldn't be touched for the most part.
when possible, update both README.md and frontend/README.md and find a better split between those two files whenever possible. In particular, make the root README more high-level and additional READMEs more detailed for their particular domain.

{ "ocm": "1", "id": "democratizedspace-dspace-dspace-dev-rules-rule", "kind": "skill", "name": "dspace-dev-rules", "description": "this project uses Astro SSR + hydration of Svelte components on the client side. Thus, interactivity must happen after onMount, and this is especially important when writing tests. - after every change, run all tests (unit, playwright, linter) to ensure nothing regressed and help guide development of new features. - whenever possible, create unit tests, integration tests, playwright tests, and anything else that may be relevant to make the codebase more robust and less prone to unexpected regressions. - you may commit to git locally to make sure your changes also pass precommit hooks. Make sure you don't git push to the origin yourself. Ask me to do it, just to be safe! I want to review all code to make sure we're headed in the right direction and not breaking our tests. - look for user journeys based on certain obvious interactions with pages via playwright, and write unique tests for those. This should be a fairly fluid idle game that feels natural and fun to use. - When building UIs, check the available Sv", "publisher": "democratizedspace", "version": "1.0.0", "capabilities": { "domains": [ "coding" ], "tags": [ "skill-md", "github-cursor-rules" ], "languages": [ "en" ] }, "quality_prior": 0.6, "examples": [ "this project uses Astro SSR + hydration of Svelte components on the client side. Thus, interactivity must happen after onMount, and this is especially important when writing tests. - after every change, run all tests (unit, playwright, linter) to ensure nothing regressed and help guide development of new features. - whenever possible, create unit tests, integration tests, playwright tests, and anything else that may be relevant to make the codebase more robust and less prone to unexpected regressions. - you may commit to git locally to make sure your changes also pass precommit hooks. Make sure you don't git push to the origin yourself. Ask me to do it, just to be safe! I want to review all code to make sure we're headed in the right direction and not breaking our tests. - look for user journeys based on certain obvious interactions with pages via playwright, and write unique tests for those. This should be a fairly fluid idle game that feels natural and fun to use. - When building UIs, check the available Sv" ], "primary": false, "metadata": { "source": { "provider": "github-cursor-rules", "repository": "https://github.com/democratizedspace/dspace", "path": ".cursor/rules/dspace-dev-rules.mdc", "ref": "97ab09f13fb098de928a878bf1fe9b8d13032cb5", "url": "https://github.com/democratizedspace/dspace/blob/97ab09f13fb098de928a878bf1fe9b8d13032cb5/.cursor/rules/dspace-dev-rules.mdc", "key": "democratizedspace/dspace/.cursor/rules/dspace-dev-rules.mdc" } }, "instructions": "- this project uses Astro SSR + hydration of Svelte components on the client side. Thus, interactivity must happen after onMount, and this is especially important when writing tests.\n- after every change, run all tests (unit, playwright, linter) to ensure nothing regressed and help guide development of new features.\n- whenever possible, create unit tests, integration tests, playwright tests, and anything else that may be relevant to make the codebase more robust and less prone to unexpected regressions.\n- you may commit to git locally to make sure your changes also pass precommit hooks. Make s", "cost": { "context_tokens": 388 } }

dspace-dev-rules

About

Use it

Manifest

Reviews