{"owner":"vrtmrz","repo":"obsidian-livesync","hasSkills":true,"hasMcp":false,"mcpConfig":null,"found":["AGENTS.md"],"skills":{"AGENTS.md":"# AI Coding Assistant Instructions (AGENTS.md)\n\nWhen working on this repository (writing code, comments, documentation, or commits), you MUST follow these guidelines to maintain consistency.\n\n## Required Reference Files\n\nBefore making changes to documentation, user-facing text, or settings:\n1. Read [docs/terms.md](docs/terms.md) for terminology, vocabulary conventions, and technical definitions.\n2. Read [docs/settings.md](docs/settings.md) (and [docs/settings_ja.md](docs/settings_ja.md)) for UI settings and setting key mappings.\n3. Read [docs/troubleshooting.md](docs/troubleshooting.md) for troubleshooting guidelines and common recovery steps (such as flag files and SCRAM state).\n4. Read [devs.md](devs.md) for development workflows, module architecture, and testing infrastructure.\n\n---\n\n## Documentation and User-Facing Text Rules\n\nAlways adhere to the following stylistic and spelling rules:\n\n1. **British English Spelling**:\n   - Write all documentation and user-facing messages in British English. If in doubt, the BBC News Styleguide may be useful as a reference.\n   - **Traditional Spelling (Trad-spelling)**: Use `-ise` and `-isation` suffixes instead of `-ize` and `-ization` (for example: 'initialisation', 'synchronisation', and 'organisation').\n   - **Oxford Comma**: Use the serial (Oxford) comma to separate items in lists of three or more (for example: 'settings, snippets, and themes' instead of 'settings, snippets and themes').\n   - **Logical Punctuation**: Place punctuation marks (such as commas and full stops) outside quotation marks unless they are part of the quoted text itself (for example: write 'dialogue', not 'dialogue,').\n\n2. **No Contractions**:\n   - Do not use contractions in general text or documentation (for example: write \"do not\" instead of \"don't\", \"cannot\" instead of \"can't\", and \"is not\" instead of \"isn't\").\n\n3. **Quotation Style**:\n   - Prefer single quotation marks (`'`) over double quotation marks (`\"`) in general documentation text, unless the context requires double quotes (for example, inside JSON code blocks).\n\n4. **Specific Terminology and Spelling**:\n   - Use **'dialogue'** in documentation, user-facing messages, and general text. Use **'dialog'** only inside source code (e.g. class names, methods).\n   - Use the hyphenated form **'plug-in'** in user-facing text. Use **'plugin'** only in codebase files, configuration settings, or technical contexts.\n\n5. **User Communication Language**:\n   - Always reply to the user in the language in which they asked the question.\n\n---\n\n## Technical & Architecture Rules\n\n1. **Database Structure**:\n   - Remember that Self-hosted LiveSync splits files into **Metadata** (file properties, size, paths) and **Chunks** (actual content). Do not store raw content in the metadata document directly.\n2. **Setup and Recovery**:\n   - **Fast Setup (Simple Fetch)** is the preferred flow for initial replication on secondary devices. It utilises stream-based replication for high speed and delays local file reflection to suppress temporary synchronisation warnings.\n   - **Flag files** (such as `redflag.md`, `redflag2.md`, and `redflag3.md`) at the root of the vault control the boot-up sequence and trigger automated fetch/rebuild tasks.\n3. **Subrepositories**:\n   - Treat `@vrtmrz/livesync-commonlib` as an external, authoritative package. Make Commonlib changes in its repository, validate the packed artefact and downstream LiveSync consumer, and update the exact dependency here. Do not recreate a `src/lib` source mirror or generated `_types` fallback.\n4. **Application Directories**:\n   - The directory [src/apps](src/apps) contains independent application modules:\n     - `cli`: A Command Line Interface application. Tests specifically for the CLI (both unit and End-to-End tests) are located and executed within [src/apps/cli](src/apps/cli) using its local `package.json` scripts.\n     - `webapp`: A Web-based application.\n     - `webpeer`: A Web-based peer utility.\n\n---\n\n## Development & Verification Commands\n\nBefore submitting code, you should run verification scripts locally to ensure correct syntax and function.\n\n1. **Lint and Type Checking**:\n   - Run `npm run check` to perform code verification. This runs type-checking (`tsc-check`), ESLint (`lint`), and Svelte checks (`svelte-check`).\n2. **Unit Tests**:\n   - Run `npm run test:unit` to execute fast local unit tests.\n   - Run `npm run test:unit:coverage` when unit-test coverage is required.\n   - Run focused integration, CLI E2E, or real Obsidian E2E commands for the boundary being changed. Start only the Docker services required by that command.\n3. **Build**:\n   - Run `npm run build` to compile the production bundle (`main.js`).\n   - Run `npm run dev` for the development watch/build task.\n"},"files":{"AGENTS.md":"# AI Coding Assistant Instructions (AGENTS.md)\n\nWhen working on this repository (writing code, comments, documentation, or commits), you MUST follow these guidelines to maintain consistency.\n\n## Required Reference Files\n\nBefore making changes to documentation, user-facing text, or settings:\n1. Read [docs/terms.md](docs/terms.md) for terminology, vocabulary conventions, and technical definitions.\n2. Read [docs/settings.md](docs/settings.md) (and [docs/settings_ja.md](docs/settings_ja.md)) for UI settings and setting key mappings.\n3. Read [docs/troubleshooting.md](docs/troubleshooting.md) for troubleshooting guidelines and common recovery steps (such as flag files and SCRAM state).\n4. Read [devs.md](devs.md) for development workflows, module architecture, and testing infrastructure.\n\n---\n\n## Documentation and User-Facing Text Rules\n\nAlways adhere to the following stylistic and spelling rules:\n\n1. **British English Spelling**:\n   - Write all documentation and user-facing messages in British English. If in doubt, the BBC News Styleguide may be useful as a reference.\n   - **Traditional Spelling (Trad-spelling)**: Use `-ise` and `-isation` suffixes instead of `-ize` and `-ization` (for example: 'initialisation', 'synchronisation', and 'organisation').\n   - **Oxford Comma**: Use the serial (Oxford) comma to separate items in lists of three or more (for example: 'settings, snippets, and themes' instead of 'settings, snippets and themes').\n   - **Logical Punctuation**: Place punctuation marks (such as commas and full stops) outside quotation marks unless they are part of the quoted text itself (for example: write 'dialogue', not 'dialogue,').\n\n2. **No Contractions**:\n   - Do not use contractions in general text or documentation (for example: write \"do not\" instead of \"don't\", \"cannot\" instead of \"can't\", and \"is not\" instead of \"isn't\").\n\n3. **Quotation Style**:\n   - Prefer single quotation marks (`'`) over double quotation marks (`\"`) in general documentation text, unless the context requires double quotes (for example, inside JSON code blocks).\n\n4. **Specific Terminology and Spelling**:\n   - Use **'dialogue'** in documentation, user-facing messages, and general text. Use **'dialog'** only inside source code (e.g. class names, methods).\n   - Use the hyphenated form **'plug-in'** in user-facing text. Use **'plugin'** only in codebase files, configuration settings, or technical contexts.\n\n5. **User Communication Language**:\n   - Always reply to the user in the language in which they asked the question.\n\n---\n\n## Technical & Architecture Rules\n\n1. **Database Structure**:\n   - Remember that Self-hosted LiveSync splits files into **Metadata** (file properties, size, paths) and **Chunks** (actual content). Do not store raw content in the metadata document directly.\n2. **Setup and Recovery**:\n   - **Fast Setup (Simple Fetch)** is the preferred flow for initial replication on secondary devices. It utilises stream-based replication for high speed and delays local file reflection to suppress temporary synchronisation warnings.\n   - **Flag files** (such as `redflag.md`, `redflag2.md`, and `redflag3.md`) at the root of the vault control the boot-up sequence and trigger automated fetch/rebuild tasks.\n3. **Subrepositories**:\n   - Treat `@vrtmrz/livesync-commonlib` as an external, authoritative package. Make Commonlib changes in its repository, validate the packed artefact and downstream LiveSync consumer, and update the exact dependency here. Do not recreate a `src/lib` source mirror or generated `_types` fallback.\n4. **Application Directories**:\n   - The directory [src/apps](src/apps) contains independent application modules:\n     - `cli`: A Command Line Interface application. Tests specifically for the CLI (both unit and End-to-End tests) are located and executed within [src/apps/cli](src/apps/cli) using its local `package.json` scripts.\n     - `webapp`: A Web-based application.\n     - `webpeer`: A Web-based peer utility.\n\n---\n\n## Development & Verification Commands\n\nBefore submitting code, you should run verification scripts locally to ensure correct syntax and function.\n\n1. **Lint and Type Checking**:\n   - Run `npm run check` to perform code verification. This runs type-checking (`tsc-check`), ESLint (`lint`), and Svelte checks (`svelte-check`).\n2. **Unit Tests**:\n   - Run `npm run test:unit` to execute fast local unit tests.\n   - Run `npm run test:unit:coverage` when unit-test coverage is required.\n   - Run focused integration, CLI E2E, or real Obsidian E2E commands for the boundary being changed. Start only the Docker services required by that command.\n3. **Build**:\n   - Run `npm run build` to compile the production bundle (`main.js`).\n   - Run `npm run dev` for the development watch/build task.\n"},"items":[{"name":"AGENTS.md","path":"AGENTS.md","title":"AGENTS.md","content":"# AI Coding Assistant Instructions (AGENTS.md)\n\nWhen working on this repository (writing code, comments, documentation, or commits), you MUST follow these guidelines to maintain consistency.\n\n## Required Reference Files\n\nBefore making changes to documentation, user-facing text, or settings:\n1. Read [docs/terms.md](docs/terms.md) for terminology, vocabulary conventions, and technical definitions.\n2. Read [docs/settings.md](docs/settings.md) (and [docs/settings_ja.md](docs/settings_ja.md)) for UI settings and setting key mappings.\n3. Read [docs/troubleshooting.md](docs/troubleshooting.md) for troubleshooting guidelines and common recovery steps (such as flag files and SCRAM state).\n4. Read [devs.md](devs.md) for development workflows, module architecture, and testing infrastructure.\n\n---\n\n## Documentation and User-Facing Text Rules\n\nAlways adhere to the following stylistic and spelling rules:\n\n1. **British English Spelling**:\n   - Write all documentation and user-facing messages in British English. If in doubt, the BBC News Styleguide may be useful as a reference.\n   - **Traditional Spelling (Trad-spelling)**: Use `-ise` and `-isation` suffixes instead of `-ize` and `-ization` (for example: 'initialisation', 'synchronisation', and 'organisation').\n   - **Oxford Comma**: Use the serial (Oxford) comma to separate items in lists of three or more (for example: 'settings, snippets, and themes' instead of 'settings, snippets and themes').\n   - **Logical Punctuation**: Place punctuation marks (such as commas and full stops) outside quotation marks unless they are part of the quoted text itself (for example: write 'dialogue', not 'dialogue,').\n\n2. **No Contractions**:\n   - Do not use contractions in general text or documentation (for example: write \"do not\" instead of \"don't\", \"cannot\" instead of \"can't\", and \"is not\" instead of \"isn't\").\n\n3. **Quotation Style**:\n   - Prefer single quotation marks (`'`) over double quotation marks (`\"`) in general documentation text, unless the context requires double quotes (for example, inside JSON code blocks).\n\n4. **Specific Terminology and Spelling**:\n   - Use **'dialogue'** in documentation, user-facing messages, and general text. Use **'dialog'** only inside source code (e.g. class names, methods).\n   - Use the hyphenated form **'plug-in'** in user-facing text. Use **'plugin'** only in codebase files, configuration settings, or technical contexts.\n\n5. **User Communication Language**:\n   - Always reply to the user in the language in which they asked the question.\n\n---\n\n## Technical & Architecture Rules\n\n1. **Database Structure**:\n   - Remember that Self-hosted LiveSync splits files into **Metadata** (file properties, size, paths) and **Chunks** (actual content). Do not store raw content in the metadata document directly.\n2. **Setup and Recovery**:\n   - **Fast Setup (Simple Fetch)** is the preferred flow for initial replication on secondary devices. It utilises stream-based replication for high speed and delays local file reflection to suppress temporary synchronisation warnings.\n   - **Flag files** (such as `redflag.md`, `redflag2.md`, and `redflag3.md`) at the root of the vault control the boot-up sequence and trigger automated fetch/rebuild tasks.\n3. **Subrepositories**:\n   - Treat `@vrtmrz/livesync-commonlib` as an external, authoritative package. Make Commonlib changes in its repository, validate the packed artefact and downstream LiveSync consumer, and update the exact dependency here. Do not recreate a `src/lib` source mirror or generated `_types` fallback.\n4. **Application Directories**:\n   - The directory [src/apps](src/apps) contains independent application modules:\n     - `cli`: A Command Line Interface application. Tests specifically for the CLI (both unit and End-to-End tests) are located and executed within [src/apps/cli](src/apps/cli) using its local `package.json` scripts.\n     - `webapp`: A Web-based application.\n     - `webpeer`: A Web-based peer utility.\n\n---\n\n## Development & Verification Commands\n\nBefore submitting code, you should run verification scripts locally to ensure correct syntax and function.\n\n1. **Lint and Type Checking**:\n   - Run `npm run check` to perform code verification. This runs type-checking (`tsc-check`), ESLint (`lint`), and Svelte checks (`svelte-check`).\n2. **Unit Tests**:\n   - Run `npm run test:unit` to execute fast local unit tests.\n   - Run `npm run test:unit:coverage` when unit-test coverage is required.\n   - Run focused integration, CLI E2E, or real Obsidian E2E commands for the boundary being changed. Start only the Docker services required by that command.\n3. **Build**:\n   - Run `npm run build` to compile the production bundle (`main.js`).\n   - Run `npm run dev` for the development watch/build task.\n","category":"root","tokens":1192}]}