Open or update a pull request on the Lyrion Dashboard. Use this whenever a task writes a PR title or description, or readies a branch for review. Covers the Conventional Commits title form, the PR template, the 200-word body budget, and re-checking the body against the final diff.
日本語の概要は準備中です。原文の説明を表示しています。
実行スコア 未検証
インストール方法を見るインストールする前に、エージェントに与えられる指示の中身を確認できます。
When opening a PR, follow .github/pull_request_template.md: fill in the problem, the solution and how it was tested, and work through its checklist (it mirrors the CI gates in CLAUDE.md plus the comment rules, FR/EN string parity, README and skill lockstep, and no-auth-by-design rules). PR titles and descriptions are written in English, like commit messages — only the user-facing UI and the READMEs are bilingual.
A PR title is a commit subject, so it follows Conventional Commits: type(scope): summary. The squash merge turns it into the commit title on master, where it has to sit alongside fix(lyrics): prefer a synced LRCLIB record over a plain one without standing out. Types in use: feat, fix, refactor, docs, chore. The scope is the area touched (lyrics, lyrion, nowplaying, stats, logs, android, release, deps), dropped when the change is repo-wide. Lowercase after the colon, imperative, no trailing period, short enough to read in git log --oneline. The Pull request workflow fails a title that breaks this form, and labels the PR with its type and with the areas its files touch (.github/labeler.yml); the release notes are grouped by those labels (.github/release.yml). Commit subjects on the branch follow the same form.
Keep a PR body short — a few sentences per section, not an essay. "Problem" is the state of things without the PR — what is broken, missing or needed, in a paragraph, never the investigation that found it. "Solution" is what the branch does about it, no re-derivation of the analysis. They stay apart because a reviewer reads them for different questions: whether the change is worth making, then whether it is the right one. "How it was tested" covers only what the checklist doesn't — the verification specific to this change, and anything that stayed unverified — never a restatement of the CI gates, which the checklist already ticks. Detail that a reviewer can get from the diff, the commit message or the code comments does not belong in the body; measurements, tables and alternatives considered belong in the commit message. The three sections together stay under 200 words — count them, because "short" left to judgement drifts into an essay one honest sentence at a time, and a body that needs scrolling to reach the checklist is already too long. The same restraint applies to review and issue comments.
A PR describes the branch as it now stands, not how it got there. Before calling a PR ready — every time, not just when opening it — re-read the title and body against the actual diff (git diff origin/master...HEAD, with the origin/: a fresh clone's local master can lag and fold other people's commits into the comparison). Iteration routinely leaves them describing a first attempt whose constants, mechanism, even approach no longer exist; a stale body is worse than none, because a reviewer trusts it. The title is the squash-merge commit subject, so it has to name what finally landed.
The rules that hold on every PR — English only, no hard-wrapped Markdown, assign to the author, no progress comments, never watch, never merge — live in CLAUDE.md.
まだレビューはありません。使ってみた感想をお寄せください。
ログインなしで書き込めます。使ってみた感想、質問、動かなかった環境などを気軽にどうぞ。
まだコメントはありません。最初のコメントを書いてみませんか。
Add or modify a Flask endpoint in the Lyrion Dashboard. Use this whenever a task adds a new URL/route, a JSON API endpoint, or a page — anything that registers a handler in `routes/`. Covers the repo's route → service → test layering, input validation, caching headers, security headers, i18n wiring, and the exact test pattern, so a new endpoint matches how `routes/` already works instead of reinventing the structure.
日本語の概要は準備中です。原文の説明を表示しています。
Work on the Android app — the thin WebView wrapper in `android/`. Use this whenever a task touches the Kotlin sources, the Gradle build, the WebView shell, the native settings screen, LMS server auto-discovery, the JS↔native bridge, app strings/i18n, or the Android CI/lint. Covers the "shell only, UI lives on the web" principle, the debug/release signing split, the static versioning F-Droid needs, and the min/target SDKs, so changes fit the wrapper.
日本語の概要は準備中です。原文の説明を表示しています。
Work on album artwork — reading an image's dimensions, and embedding a folder's cover file into the tags of its tracks. Use this whenever a task touches `services/artwork.py`, the cover half of `services/tags.py`, or `scripts/embed_covers.py` / `embed_covers_cron.sh`. Covers why Lyrion shows the embedded artwork and never the folder file, how covers are compared, why images are never re-encoded, and what embedding costs in rewritten files.
日本語の概要は準備中です。原文の説明を表示しています。
Read data from Lyrion's SQLite databases — library stats, stored lyrics, album covers, recent plays. Use this whenever a task queries `library.db` or `persist.db`, adds or changes a statistic, or touches `services/database.py`. Covers the read-only connection model (RO open + `ATTACH persist.db`), the key tables, the `play_counts` view over the Alternative Play Count plugin, the single-flight stats cache, and why the app must never write to these DBs. Reach for it before writing any SQL against the Lyrion databases.
日本語の概要は準備中です。原文の説明を表示しています。
Work on the dashboard's frontend — the vanilla JS/CSS page with no framework or bundler. Use this whenever a task touches `static/nowplaying.js`, `static/style.css`, the Jinja templates (`templates/nowplaying.html`, `_icons.html`), the accent-color tinting, the karaoke lyrics sync, the now-playing poll, or the empty-state mosaic / recent-plays pile. Covers how the page is wired, how it reads i18n and data from the server, the ESLint gate, and the Android bridge, so changes match the existing patterns.
日本語の概要は準備中です。原文の説明を表示しています。
Add, change, or translate user-facing text in the Lyrion Dashboard, which ships bilingual FR/EN. Use this whenever a task introduces a new visible string (a label, tooltip, aria-label, empty state, stat name), changes wording, or touches the README or a `docs/` page — so every string lands in both languages and the EN/FR documentation pairs stay in sync. Covers `i18n.py`, how templates and JS consume translations, and the parity rule.
日本語の概要は準備中です。原文の説明を表示しています。