Workflow
Three projects work together to make vimcolorschemes possible:
Pick a development path
Section titled “Pick a development path”Use the environment that can validate your change.
| Change Type | Recommended Path |
|---|---|
| UI, CSS, copy, navigation | Frontend Path |
| App behavior using existing data | Frontend Path |
| Database shape or generated fields | Full Stack Path |
| Repository discovery or eligibility | The Worker |
| Highlight extraction behavior | extractor.nvim |
| Preview rendering and generated data | Code Previews |
Development loop
Section titled “Development loop”- Read the relevant architecture page.
- Reproduce the current behavior locally.
- Make the change.
- Run the relevant tests, build, or manual checks.
- Update docs when setup, data shape, or contributor workflow changes.
- Open a pull request with the problem, solution, and validation steps.
Validation commands
Section titled “Validation commands”| Repository | Full check | Focused commands |
|---|---|---|
| App | pnpm check | pnpm test, pnpm tc, pnpm lint.check, pnpm format.check |
| Worker | bin/test | bin/lint, bin/format, bin/start <job> --repo owner/name |
| Docs | pnpm build | pnpm dev |
For UI changes, include screenshots or a short manual test note. For data changes, include the job commands you ran and which database you used.
Code maps
Section titled “Code maps”Use these pages when you know the behavior but not the file:
- App UI and data reads: The App
- Worker jobs and database writes: The Worker
- Preview generation and rendering: Code Previews
- Database contract: Data Flow
Pull request notes
Section titled “Pull request notes”Pull requests include:
- What behavior changed.
- Which repository or part of the system changed.
- Whether the database contract changed.
- How the change was validated.
- Follow-up work, if any.