{"owner":"SubtitleEdit","repo":"subtitleedit","hasSkills":true,"totalSkillsCount":2,"totalTokensCount":1323,"categories":["anthropic-skill","copilot-instructions"],"hasMcp":false,"mcpConfig":null,"found":[".github/skills/subtitleedit-ai-contributor-guidelines/SKILL.md",".github/copilot-instructions.md"],"skills":{".github/skills/subtitleedit-ai-contributor-guidelines/SKILL.md":"---\nname: subtitleedit-ai-contributor-guidelines\ndescription: \"Use when: using AI coding agents or LLM assistance for Subtitle Edit code changes, reviews, refactors, tests, or documentation updates. Provides project-specific safeguards against broad, overcomplicated, or unverified changes.\"\nlicense: MIT\n---\n\n# Subtitle Edit AI Contributor Guidelines\n\nAI-assisted contributions are becoming a normal part of open source development. This guidance gives AI tools, and contributors who use them, a shared quality bar for Subtitle Edit. The goal is not to ban AI use, but to reduce the avoidable damage that default LLM behavior can cause: wrong assumptions, broad edits, overbuilt abstractions, and unverified pull requests.\n\nThese instructions apply to code changes, reviews, refactors, tests, documentation, build scripts, packaging files, and translation-related work in this repository.\n\n## 1. Clarify Before Changing\n\nBefore editing, identify the requested outcome, affected area, and verification path.\n\n- If the issue can mean more than one thing, state the interpretations and ask for clarification before implementing.\n- If a requested change conflicts with existing behavior, project conventions, privacy expectations, or platform support, call that out.\n- Prefer the smallest change that fully solves the stated problem.\n- Do not infer new product behavior, UI redesigns, settings, or compatibility promises from a vague request.\n\n## 2. Keep Changes Surgical\n\nEvery changed line should be traceable to the request.\n\n- Do not reformat unrelated files, reorder unrelated code, rename existing symbols, or modernize adjacent code unless it is required for the task.\n- Match the local style of the file being edited, even when another style would also be valid.\n- Preserve existing comments, translations, resource keys, subtitle format behavior, and platform-specific code unless the task directly requires changing them.\n- If you find unrelated dead code or a possible bug, mention it in the PR notes instead of fixing it in the same change.\n- Remove only the unused imports, variables, helpers, or files made unused by your own change.\n\n## 3. Prefer Boring Code\n\nSubtitle Edit has a large feature surface and many file-format edge cases. Avoid cleverness that makes future maintenance harder.\n\n- Use existing helpers, patterns, forms, services, and test utilities before introducing new abstractions.\n- Do not add configurability, extension points, dependencies, caches, background tasks, or generic frameworks unless the issue clearly needs them.\n- Keep UI changes consistent with existing workflows. Do not redesign screens as part of a bug fix.\n- Keep parsing, conversion, timing, encoding, and localization changes narrow and explicit.\n- For subtitle format handling, protect backwards compatibility unless the issue is specifically about changing compatibility behavior.\n\n## 4. Verify The Actual Risk\n\nDefine verification before implementation, then run the most relevant check that is practical.\n\n- For bug fixes, prefer a focused regression test that fails before the fix and passes after it.\n- For shared parsing, conversion, timing, waveform, OCR, translation, or export behavior, run targeted tests and expand coverage when risk is broad.\n- For UI-only changes where automated tests are not practical, document the manual verification path.\n- If a command cannot be run locally, say so in the PR and explain the remaining risk.\n- Do not claim a change is verified unless the relevant command or manual check was actually performed.\n\n## 5. Protect User Data And Offline Expectations\n\nSubtitle Edit is an offline editor by default. Keep that trust boundary intact.\n\n- Do not introduce telemetry, analytics, remote logging, model training, or network calls unless explicitly requested and reviewed.\n- Be careful with subtitle text, media paths, and user-provided content in logs, exceptions, screenshots, or test artifacts.\n- Keep optional third-party service integrations explicit and isolated.\n\n## 6. Write Useful PR Notes\n\nAI-assisted PRs should make maintainer review easier, not harder.\n\n- Explain what changed and why.\n- List the verification performed.\n- Mention assumptions, tradeoffs, and known limitations.\n- Keep generated descriptions factual and concise.\n- Do not hide that AI assistance was used if the contribution was materially AI-assisted.\n\n## 7. Follow The AI Pull Request Gate\n\nWhen an AI agent owns a change from implementation to merge, it must use the full branch, PR, review, and merge workflow instead of committing directly to `main`.\n\n- Create a dedicated branch for the change and open a pull request into `main`.\n- Request a GitHub Copilot review and wait for it to finish before treating the PR as merge-ready.\n- Read Copilot's comments critically. Fix findings that identify a real bug, regression risk, missing test, unclear behavior, or maintainability problem, then rerun the relevant verification.\n- If a Copilot comment is not applicable, explain that decision briefly in the PR discussion instead of silently ignoring it.\n- Resolve review threads after addressing them or after documenting why no code change is needed.\n- Request another Copilot review after meaningful follow-up changes, and repeat loop \"request review --> fix --> request revie --> fix\" until Copilot has no comments about possible code issues.\n- Merge to `main` only after the PR is verified, Copilot review is complete, all useful findings are handled, and review threads are resolved.\n\n- As AI you have to be patient. Copilot review takes sometimes 5 to 10 minutes. No possible code issues found by copilot have following comment: \"Copilot reviewed x out of x changed files in this pull request and generated no new comments.\" This is a sign that merge to main might be done.\n\n## Attribution\n\nThis is an original, project-specific adaptation inspired by `forrestchang/andrej-karpathy-skills` and Andrej Karpathy's public observations about common LLM coding failure modes.\n\nSource inspiration: https://github.com/forrestchang/andrej-karpathy-skills\n\nThe source repository declares MIT licensing in its README and skill metadata. This file is not a vendored copy of the source text; keep this attribution if the guidance is moved or expanded.\n",".github/copilot-instructions.md":"# Copilot Instructions\n\nWhen using GitHub Copilot or another AI coding agent in this repository, apply the project guidance in `.github/skills/subtitleedit-ai-contributor-guidelines/SKILL.md` for code changes, reviews, refactors, and documentation updates.\n\nKeep AI-assisted changes small, verified, and tied directly to the requested issue or pull request."},"files":{".github/skills/subtitleedit-ai-contributor-guidelines/SKILL.md":"---\nname: subtitleedit-ai-contributor-guidelines\ndescription: \"Use when: using AI coding agents or LLM assistance for Subtitle Edit code changes, reviews, refactors, tests, or documentation updates. Provides project-specific safeguards against broad, overcomplicated, or unverified changes.\"\nlicense: MIT\n---\n\n# Subtitle Edit AI Contributor Guidelines\n\nAI-assisted contributions are becoming a normal part of open source development. This guidance gives AI tools, and contributors who use them, a shared quality bar for Subtitle Edit. The goal is not to ban AI use, but to reduce the avoidable damage that default LLM behavior can cause: wrong assumptions, broad edits, overbuilt abstractions, and unverified pull requests.\n\nThese instructions apply to code changes, reviews, refactors, tests, documentation, build scripts, packaging files, and translation-related work in this repository.\n\n## 1. Clarify Before Changing\n\nBefore editing, identify the requested outcome, affected area, and verification path.\n\n- If the issue can mean more than one thing, state the interpretations and ask for clarification before implementing.\n- If a requested change conflicts with existing behavior, project conventions, privacy expectations, or platform support, call that out.\n- Prefer the smallest change that fully solves the stated problem.\n- Do not infer new product behavior, UI redesigns, settings, or compatibility promises from a vague request.\n\n## 2. Keep Changes Surgical\n\nEvery changed line should be traceable to the request.\n\n- Do not reformat unrelated files, reorder unrelated code, rename existing symbols, or modernize adjacent code unless it is required for the task.\n- Match the local style of the file being edited, even when another style would also be valid.\n- Preserve existing comments, translations, resource keys, subtitle format behavior, and platform-specific code unless the task directly requires changing them.\n- If you find unrelated dead code or a possible bug, mention it in the PR notes instead of fixing it in the same change.\n- Remove only the unused imports, variables, helpers, or files made unused by your own change.\n\n## 3. Prefer Boring Code\n\nSubtitle Edit has a large feature surface and many file-format edge cases. Avoid cleverness that makes future maintenance harder.\n\n- Use existing helpers, patterns, forms, services, and test utilities before introducing new abstractions.\n- Do not add configurability, extension points, dependencies, caches, background tasks, or generic frameworks unless the issue clearly needs them.\n- Keep UI changes consistent with existing workflows. Do not redesign screens as part of a bug fix.\n- Keep parsing, conversion, timing, encoding, and localization changes narrow and explicit.\n- For subtitle format handling, protect backwards compatibility unless the issue is specifically about changing compatibility behavior.\n\n## 4. Verify The Actual Risk\n\nDefine verification before implementation, then run the most relevant check that is practical.\n\n- For bug fixes, prefer a focused regression test that fails before the fix and passes after it.\n- For shared parsing, conversion, timing, waveform, OCR, translation, or export behavior, run targeted tests and expand coverage when risk is broad.\n- For UI-only changes where automated tests are not practical, document the manual verification path.\n- If a command cannot be run locally, say so in the PR and explain the remaining risk.\n- Do not claim a change is verified unless the relevant command or manual check was actually performed.\n\n## 5. Protect User Data And Offline Expectations\n\nSubtitle Edit is an offline editor by default. Keep that trust boundary intact.\n\n- Do not introduce telemetry, analytics, remote logging, model training, or network calls unless explicitly requested and reviewed.\n- Be careful with subtitle text, media paths, and user-provided content in logs, exceptions, screenshots, or test artifacts.\n- Keep optional third-party service integrations explicit and isolated.\n\n## 6. Write Useful PR Notes\n\nAI-assisted PRs should make maintainer review easier, not harder.\n\n- Explain what changed and why.\n- List the verification performed.\n- Mention assumptions, tradeoffs, and known limitations.\n- Keep generated descriptions factual and concise.\n- Do not hide that AI assistance was used if the contribution was materially AI-assisted.\n\n## 7. Follow The AI Pull Request Gate\n\nWhen an AI agent owns a change from implementation to merge, it must use the full branch, PR, review, and merge workflow instead of committing directly to `main`.\n\n- Create a dedicated branch for the change and open a pull request into `main`.\n- Request a GitHub Copilot review and wait for it to finish before treating the PR as merge-ready.\n- Read Copilot's comments critically. Fix findings that identify a real bug, regression risk, missing test, unclear behavior, or maintainability problem, then rerun the relevant verification.\n- If a Copilot comment is not applicable, explain that decision briefly in the PR discussion instead of silently ignoring it.\n- Resolve review threads after addressing them or after documenting why no code change is needed.\n- Request another Copilot review after meaningful follow-up changes, and repeat loop \"request review --> fix --> request revie --> fix\" until Copilot has no comments about possible code issues.\n- Merge to `main` only after the PR is verified, Copilot review is complete, all useful findings are handled, and review threads are resolved.\n\n- As AI you have to be patient. Copilot review takes sometimes 5 to 10 minutes. No possible code issues found by copilot have following comment: \"Copilot reviewed x out of x changed files in this pull request and generated no new comments.\" This is a sign that merge to main might be done.\n\n## Attribution\n\nThis is an original, project-specific adaptation inspired by `forrestchang/andrej-karpathy-skills` and Andrej Karpathy's public observations about common LLM coding failure modes.\n\nSource inspiration: https://github.com/forrestchang/andrej-karpathy-skills\n\nThe source repository declares MIT licensing in its README and skill metadata. This file is not a vendored copy of the source text; keep this attribution if the guidance is moved or expanded.\n",".github/copilot-instructions.md":"# Copilot Instructions\n\nWhen using GitHub Copilot or another AI coding agent in this repository, apply the project guidance in `.github/skills/subtitleedit-ai-contributor-guidelines/SKILL.md` for code changes, reviews, refactors, and documentation updates.\n\nKeep AI-assisted changes small, verified, and tied directly to the requested issue or pull request."},"items":[{"name":"SKILL.md","path":".github/skills/subtitleedit-ai-contributor-guidelines/SKILL.md","rawUrl":"https://raw.githubusercontent.com/SubtitleEdit/subtitleedit/HEAD/.github/skills/subtitleedit-ai-contributor-guidelines/SKILL.md","title":"subtitleedit-ai-contributor-guidelines","category":"anthropic-skill","format":"markdown","content":"---\nname: subtitleedit-ai-contributor-guidelines\ndescription: \"Use when: using AI coding agents or LLM assistance for Subtitle Edit code changes, reviews, refactors, tests, or documentation updates. Provides project-specific safeguards against broad, overcomplicated, or unverified changes.\"\nlicense: MIT\n---\n\n# Subtitle Edit AI Contributor Guidelines\n\nAI-assisted contributions are becoming a normal part of open source development. This guidance gives AI tools, and contributors who use them, a shared quality bar for Subtitle Edit. The goal is not to ban AI use, but to reduce the avoidable damage that default LLM behavior can cause: wrong assumptions, broad edits, overbuilt abstractions, and unverified pull requests.\n\nThese instructions apply to code changes, reviews, refactors, tests, documentation, build scripts, packaging files, and translation-related work in this repository.\n\n## 1. Clarify Before Changing\n\nBefore editing, identify the requested outcome, affected area, and verification path.\n\n- If the issue can mean more than one thing, state the interpretations and ask for clarification before implementing.\n- If a requested change conflicts with existing behavior, project conventions, privacy expectations, or platform support, call that out.\n- Prefer the smallest change that fully solves the stated problem.\n- Do not infer new product behavior, UI redesigns, settings, or compatibility promises from a vague request.\n\n## 2. Keep Changes Surgical\n\nEvery changed line should be traceable to the request.\n\n- Do not reformat unrelated files, reorder unrelated code, rename existing symbols, or modernize adjacent code unless it is required for the task.\n- Match the local style of the file being edited, even when another style would also be valid.\n- Preserve existing comments, translations, resource keys, subtitle format behavior, and platform-specific code unless the task directly requires changing them.\n- If you find unrelated dead code or a possible bug, mention it in the PR notes instead of fixing it in the same change.\n- Remove only the unused imports, variables, helpers, or files made unused by your own change.\n\n## 3. Prefer Boring Code\n\nSubtitle Edit has a large feature surface and many file-format edge cases. Avoid cleverness that makes future maintenance harder.\n\n- Use existing helpers, patterns, forms, services, and test utilities before introducing new abstractions.\n- Do not add configurability, extension points, dependencies, caches, background tasks, or generic frameworks unless the issue clearly needs them.\n- Keep UI changes consistent with existing workflows. Do not redesign screens as part of a bug fix.\n- Keep parsing, conversion, timing, encoding, and localization changes narrow and explicit.\n- For subtitle format handling, protect backwards compatibility unless the issue is specifically about changing compatibility behavior.\n\n## 4. Verify The Actual Risk\n\nDefine verification before implementation, then run the most relevant check that is practical.\n\n- For bug fixes, prefer a focused regression test that fails before the fix and passes after it.\n- For shared parsing, conversion, timing, waveform, OCR, translation, or export behavior, run targeted tests and expand coverage when risk is broad.\n- For UI-only changes where automated tests are not practical, document the manual verification path.\n- If a command cannot be run locally, say so in the PR and explain the remaining risk.\n- Do not claim a change is verified unless the relevant command or manual check was actually performed.\n\n## 5. Protect User Data And Offline Expectations\n\nSubtitle Edit is an offline editor by default. Keep that trust boundary intact.\n\n- Do not introduce telemetry, analytics, remote logging, model training, or network calls unless explicitly requested and reviewed.\n- Be careful with subtitle text, media paths, and user-provided content in logs, exceptions, screenshots, or test artifacts.\n- Keep optional third-party service integrations explicit and isolated.\n\n## 6. Write Useful PR Notes\n\nAI-assisted PRs should make maintainer review easier, not harder.\n\n- Explain what changed and why.\n- List the verification performed.\n- Mention assumptions, tradeoffs, and known limitations.\n- Keep generated descriptions factual and concise.\n- Do not hide that AI assistance was used if the contribution was materially AI-assisted.\n\n## 7. Follow The AI Pull Request Gate\n\nWhen an AI agent owns a change from implementation to merge, it must use the full branch, PR, review, and merge workflow instead of committing directly to `main`.\n\n- Create a dedicated branch for the change and open a pull request into `main`.\n- Request a GitHub Copilot review and wait for it to finish before treating the PR as merge-ready.\n- Read Copilot's comments critically. Fix findings that identify a real bug, regression risk, missing test, unclear behavior, or maintainability problem, then rerun the relevant verification.\n- If a Copilot comment is not applicable, explain that decision briefly in the PR discussion instead of silently ignoring it.\n- Resolve review threads after addressing them or after documenting why no code change is needed.\n- Request another Copilot review after meaningful follow-up changes, and repeat loop \"request review --> fix --> request revie --> fix\" until Copilot has no comments about possible code issues.\n- Merge to `main` only after the PR is verified, Copilot review is complete, all useful findings are handled, and review threads are resolved.\n\n- As AI you have to be patient. Copilot review takes sometimes 5 to 10 minutes. No possible code issues found by copilot have following comment: \"Copilot reviewed x out of x changed files in this pull request and generated no new comments.\" This is a sign that merge to main might be done.\n\n## Attribution\n\nThis is an original, project-specific adaptation inspired by `forrestchang/andrej-karpathy-skills` and Andrej Karpathy's public observations about common LLM coding failure modes.\n\nSource inspiration: https://github.com/forrestchang/andrej-karpathy-skills\n\nThe source repository declares MIT licensing in its README and skill metadata. This file is not a vendored copy of the source text; keep this attribution if the guidance is moved or expanded.\n","frontmatter":{"name":"subtitleedit-ai-contributor-guidelines","description":"Use when: using AI coding agents or LLM assistance for Subtitle Edit code changes, reviews, refactors, tests, or documentation updates. Provides project-specific safeguards against broad, overcomplicated, or unverified changes.","license":"MIT"},"isInternal":false,"tokens":1248,"sizeBytes":6267},{"name":"copilot-instructions.md","path":".github/copilot-instructions.md","rawUrl":"https://raw.githubusercontent.com/SubtitleEdit/subtitleedit/HEAD/.github/copilot-instructions.md","title":"GitHub Copilot Instructions","category":"copilot-instructions","format":"markdown","content":"# Copilot Instructions\n\nWhen using GitHub Copilot or another AI coding agent in this repository, apply the project guidance in `.github/skills/subtitleedit-ai-contributor-guidelines/SKILL.md` for code changes, reviews, refactors, and documentation updates.\n\nKeep AI-assisted changes small, verified, and tied directly to the requested issue or pull request.","isInternal":false,"tokens":75,"sizeBytes":357}],"systemPromptSnippet":"<yakaai_skills repo=\"SubtitleEdit/subtitleedit\">\n<!-- File: .github/skills/subtitleedit-ai-contributor-guidelines/SKILL.md (Tokens: ~1248 | Category: anthropic-skill) -->\n---\nname: subtitleedit-ai-contributor-guidelines\ndescription: \"Use when: using AI coding agents or LLM assistance for Subtitle Edit code changes, reviews, refactors, tests, or documentation updates. Provides project-specific safeguards against broad, overcomplicated, or unverified changes.\"\nlicense: MIT\n---\n\n# Subtitle Edit AI Contributor Guidelines\n\nAI-assisted contributions are becoming a normal part of open source development. This guidance gives AI tools, and contributors who use them, a shared quality bar for Subtitle Edit. The goal is not to ban AI use, but to reduce the avoidable damage that default LLM behavior can cause: wrong assumptions, broad edits, overbuilt abstractions, and unverified pull requests.\n\nThese instructions apply to code changes, reviews, refactors, tests, documentation, build scripts, packaging files, and translation-related work in this repository.\n\n## 1. Clarify Before Changing\n\nBefore editing, identify the requested outcome, affected area, and verification path.\n\n- If the issue can mean more than one thing, state the interpretations and ask for clarification before implementing.\n- If a requested change conflicts with existing behavior, project conventions, privacy expectations, or platform support, call that out.\n- Prefer the smallest change that fully solves the stated problem.\n- Do not infer new product behavior, UI redesigns, settings, or compatibility promises from a vague request.\n\n## 2. Keep Changes Surgical\n\nEvery changed line should be traceable to the request.\n\n- Do not reformat unrelated files, reorder unrelated code, rename existing symbols, or modernize adjacent code unless it is required for the task.\n- Match the local style of the file being edited, even when another style would also be valid.\n- Preserve existing comments, translations, resource keys, subtitle format behavior, and platform-specific code unless the task directly requires changing them.\n- If you find unrelated dead code or a possible bug, mention it in the PR notes instead of fixing it in the same change.\n- Remove only the unused imports, variables, helpers, or files made unused by your own change.\n\n## 3. Prefer Boring Code\n\nSubtitle Edit has a large feature surface and many file-format edge cases. Avoid cleverness that makes future maintenance harder.\n\n- Use existing helpers, patterns, forms, services, and test utilities before introducing new abstractions.\n- Do not add configurability, extension points, dependencies, caches, background tasks, or generic frameworks unless the issue clearly needs them.\n- Keep UI changes consistent with existing workflows. Do not redesign screens as part of a bug fix.\n- Keep parsing, conversion, timing, encoding, and localization changes narrow and explicit.\n- For subtitle format handling, protect backwards compatibility unless the issue is specifically about changing compatibility behavior.\n\n## 4. Verify The Actual Risk\n\nDefine verification before implementation, then run the most relevant check that is practical.\n\n- For bug fixes, prefer a focused regression test that fails before the fix and passes after it.\n- For shared parsing, conversion, timing, waveform, OCR, translation, or export behavior, run targeted tests and expand coverage when risk is broad.\n- For UI-only changes where automated tests are not practical, document the manual verification path.\n- If a command cannot be run locally, say so in the PR and explain the remaining risk.\n- Do not claim a change is verified unless the relevant command or manual check was actually performed.\n\n## 5. Protect User Data And Offline Expectations\n\nSubtitle Edit is an offline editor by default. Keep that trust boundary intact.\n\n- Do not introduce telemetry, analytics, remote logging, model training, or network calls unless explicitly requested and reviewed.\n- Be careful with subtitle text, media paths, and user-provided content in logs, exceptions, screenshots, or test artifacts.\n- Keep optional third-party service integrations explicit and isolated.\n\n## 6. Write Useful PR Notes\n\nAI-assisted PRs should make maintainer review easier, not harder.\n\n- Explain what changed and why.\n- List the verification performed.\n- Mention assumptions, tradeoffs, and known limitations.\n- Keep generated descriptions factual and concise.\n- Do not hide that AI assistance was used if the contribution was materially AI-assisted.\n\n## 7. Follow The AI Pull Request Gate\n\nWhen an AI agent owns a change from implementation to merge, it must use the full branch, PR, review, and merge workflow instead of committing directly to `main`.\n\n- Create a dedicated branch for the change and open a pull request into `main`.\n- Request a GitHub Copilot review and wait for it to finish before treating the PR as merge-ready.\n- Read Copilot's comments critically. Fix findings that identify a real bug, regression risk, missing test, unclear behavior, or maintainability problem, then rerun the relevant verification.\n- If a Copilot comment is not applicable, explain that decision briefly in the PR discussion instead of silently ignoring it.\n- Resolve review threads after addressing them or after documenting why no code change is needed.\n- Request another Copilot review after meaningful follow-up changes, and repeat loop \"request review --> fix --> request revie --> fix\" until Copilot has no comments about possible code issues.\n- Merge to `main` only after the PR is verified, Copilot review is complete, all useful findings are handled, and review threads are resolved.\n\n- As AI you have to be patient. Copilot review takes sometimes 5 to 10 minutes. No possible code issues found by copilot have following comment: \"Copilot reviewed x out of x changed files in this pull request and generated no new comments.\" This is a sign that merge to main might be done.\n\n## Attribution\n\nThis is an original, project-specific adaptation inspired by `forrestchang/andrej-karpathy-skills` and Andrej Karpathy's public observations about common LLM coding failure modes.\n\nSource inspiration: https://github.com/forrestchang/andrej-karpathy-skills\n\nThe source repository declares MIT licensing in its README and skill metadata. This file is not a vendored copy of the source text; keep this attribution if the guidance is moved or expanded.\n\n<!-- File: .github/copilot-instructions.md (Tokens: ~75 | Category: copilot-instructions) -->\n# Copilot Instructions\n\nWhen using GitHub Copilot or another AI coding agent in this repository, apply the project guidance in `.github/skills/subtitleedit-ai-contributor-guidelines/SKILL.md` for code changes, reviews, refactors, and documentation updates.\n\nKeep AI-assisted changes small, verified, and tied directly to the requested issue or pull request.\n</yakaai_skills>"}