You do not need to know how to code or use Git. Choose the route that matches where you are now, and this guide will take you from creating a GitHub account to editing wiki content and submitting a Pull Request.
A mistake will not instantly break the site. A Pull Request is a request for review; maintainers check the change before it is merged.
One contribution, three stages
01Prepare your account
02Edit the content
03Submit a PR
Target file
When you arrive from an article, this is the real source file you will change. If it is wrong, return to the article and use “Edit source” again.
No file was selected. You can still learn here; enter from a specific article when you are ready to edit.
01 / Route
Where are you starting from?
Choose the statement that matches your situation. You can switch routes at any time, and progress is saved in this browser.
Zero-experience route · no coding required
This is the most complete and reassuring route. You only need an email account and a modern browser. Everything happens on the web—you do not need Git, a terminal, or a code editor.
Follow it in order the first time. On future contributions, the shorter web-editing route will be enough.
I do not have a GitHub account
Completed 0 / 10
01
Step 01
Prepare what you need
GitHub and contributing are free; all you need is email, a browser, the fact you want to change, and a reliable source.
Prepare a long-term email address you can access, a modern browser, the information you want to change, and a reliable source that supports it.
You do not need a payment card, GitHub Pro, Git, a terminal, a code editor, or the GitHub app. Changes are first saved in your own safe copy and then reviewed through a PR.
Keep passwords, verification codes, 2FA codes, and recovery codes private. Maintainers and AI assistants never need them.
You are ready when: You have access to your email and understand that the complete browser workflow is free.
Ask AI to help with this step
Add what you can currently see, the public error text, or what feels unclear. The guide combines it with this step's goal, target file, and repository constraints.
Describe only public interface text and errors. Never enter a password, verification code, cookie, token, email address, or private personal information.
Complete prompt to be copied
0 / 600
I am about to make my first contribution to a fan wiki and know nothing about GitHub. Explain Repository, Fork, Commit, and Pull Request in very simple English, and explain why a PR cannot instantly break the live website. Do not assume I can code, and never ask for a password or verification code.
02
Step 02
Create a free personal GitHub account
Follow GitHub's sign-up prompts, choose a public username, then verify your email. GitHub Free is enough.
Open the GitHub sign-up page below.
Sign up with email, or use a supported Google or Apple sign-in option shown by GitHub.
Choose a username you are comfortable displaying publicly beside your contributions.
Create a strong, unique password and store it safely.
Complete any verification GitHub requests.
Choose a free personal account if plans are shown. Then open GitHub’s verification email and follow the link. An unverified email prevents important actions such as creating forks and Pull Requests.
If the email does not arrive, check spam, then open avatar → Settings → Emails → Resend verification email. Request a new link if the old one has expired.
You are ready when: You can sign in, and your primary email is shown as verified under Settings → Emails.
Ask AI to help with this step
Add what you can currently see, the public error text, or what feels unclear. The guide combines it with this step's goal, target file, and repository constraints.
Describe only public interface text and errors. Never enter a password, verification code, cookie, token, email address, or private personal information.
Complete prompt to be copied
0 / 600
I am creating a free personal GitHub account. Explain the current sign-up fields one step at a time and tell me which profile information will be public. Do not generate, collect, or ask me to share a password, email verification code, 2FA code, or recovery code. If I describe an error, give only safe troubleshooting steps.
03
Step 03
Understand the four-part workflow
You do not need to learn Git; remember “repository → fork → commit → Pull Request.”
Think of contributing as submitting writing to an editorial team:
The repository is the shared project folder.
A fork is your personal working copy.
A commit saves one change with a short note.
A Pull Request submits that saved change for review.
A PR is not a direct edit to the live site. Review comments are a normal part of collaboration, not a failed contribution.
Checks / CI are automatic tests. Green means the files passed; red means there is a specific issue to inspect and fix.
You are ready when: You can explain that a commit saves the change and a PR sends it to maintainers for review.
Ask AI to help with this step
Add what you can currently see, the public error text, or what feels unclear. The guide combines it with this step's goal, target file, and repository constraints.
Describe only public interface text and errors. Never enter a password, verification code, cookie, token, email address, or private personal information.
Complete prompt to be copied
0 / 600
Explain Repository, Fork, Branch, Commit, Pull Request, and Checks/CI using an “article submitted to an editorial team” analogy for a nontechnical reader. End with a plain-text flow from editing to merge, without command-line jargon.
04
Step 04
Confirm the target file and source
Check the path, locale, and evidence before editing so you do not change the wrong article.
The target at the top should begin with src/content/, for example:
src/content/artists/vwp/kaf/en.md
zh.md is Chinese, ja.md is Japanese, and en.md is English. Common folders are artists/, songs/, albums/, projects/, logs/, and site/.
Prepare a traceable source. Prefer official websites and announcements, then official social posts, formal interviews, or reliable publications. Do not treat AI output, rumors, or unverifiable fan discussion as factual evidence.
You are ready when: The path points to the right entry and locale, and you know what reliable source supports the new information.
Ask AI to help with this step
Add what you can currently see, the public error text, or what feels unclear. The guide combines it with this step's goal, target file, and repository constraints.
Describe only public interface text and errors. Never enter a password, verification code, cookie, token, email address, or private personal information.
Complete prompt to be copied
0 / 600
I am editing KAMITSUBAKI FAN WIKI. My target is: {{TARGET_PATH}}
Explain what content type and locale this path represents, and whether my proposed change belongs in frontmatter or the Markdown body. Do not invent artist facts. If I lack a source, tell me to find an official source first. Do not suggest changing dist, .astro, node_modules, or unrelated code.
05
Step 05
Open the GitHub web editor
The final button opens the file. GitHub may ask you to sign in and automatically create a fork.
Use the edit action at the end of this route. Sign in if necessary. Without write access, GitHub may show Fork this repository or create a fork when you propose the change. This is expected and safe.
Confirm the file path again. Button labels can change slightly, but the flow stays:
You are ready when: You can see the GitHub editor, and its file path exactly matches the target shown here.
Ask AI to help with this step
Add what you can currently see, the public error text, or what feels unclear. The guide combines it with this step's goal, target file, and repository constraints.
Describe only public interface text and errors. Never enter a password, verification code, cookie, token, email address, or private personal information.
Complete prompt to be copied
0 / 600
I am editing a file in someone else's public GitHub repository. The target is: {{TARGET_PATH}}
Based on the page text I describe, tell me only the next button to use. An automatic fork is expected. Never ask for my password, verification code, cookie, token, or full account details. If a screenshot is useful, tell me to hide private information first.
06
Step 06
Edit frontmatter and body safely
Most contributions change text. Preserve the structure at the top and do not remove fields you do not understand.
A Markdown content file normally has frontmatter and body content:
---locale: entranslationKey: kafname: "KAF"image: "https://example.com/image.jpg"---## OverviewNormal article text starts here.
Keep both --- lines, existing keys, quotes, and indentation. locale must match the filename, and localized files for one entry share the same translationKey. Use spaces, not tabs, in YAML.
Make the smallest relevant change; include a source for new facts; never add placeholders, guesses, AI-invented facts, credentials, tokens, or private personal information.
You are ready when: The edit is focused, the structure is intact, facts are sourced, and no private data is present.
Ask AI to help with this step
Add what you can currently see, the public error text, or what feels unclear. The guide combines it with this step's goal, target file, and repository constraints.
Describe only public interface text and errors. Never enter a password, verification code, cookie, token, email address, or private personal information.
Complete prompt to be copied
0 / 600
Act as a careful Markdown editor. I am editing {{TARGET_PATH}}. I will provide a proposed excerpt and a reliable source. Change only facts directly supported by that source; preserve YAML fields, indentation, and both --- markers; do not invent facts or touch unrelated paragraphs. Return the complete revised excerpt and a short change list. Stop and ask for better evidence if the source is insufficient.
07
Step 07
Preview the diff and create a commit
Review Preview / Changes, then write a short message describing exactly what you changed.
In Preview or Changes, green usually means added and red means removed. Check for accidental deletion, damaged --- markers, the wrong locale, strange indentation, broken links, or incorrect dates and names.
Click Commit changes… and use a clear message such as:
docs: correct KAF debut datedocs: add KAF official linkdocs: fix a typo in KAF entry
For an external contributor, the final action may be Propose changes. A commit saves the change to your fork/branch; you still need to create the PR on the next page.
You are ready when: The diff contains only your intended edit, and the commit message accurately describes it.
Ask AI to help with this step
Add what you can currently see, the public error text, or what feels unclear. The guide combines it with this step's goal, target file, and repository constraints.
Describe only public interface text and errors. Never enter a password, verification code, cookie, token, email address, or private personal information.
Complete prompt to be copied
0 / 600
Review the GitHub diff I paste for {{TARGET_PATH}}. Check accidental deletions, YAML structure, locale consistency, unsupported facts, and private data. Then suggest three concise English commit messages. Do not assume anything outside the pasted diff.
08
Step 08
Create your first Pull Request
Confirm the original repository and main branch, write a clear title and description, then create the PR.
On the comparison page, confirm the base repository is LinkTh1rsty/kamitsubaki-wiki-site, the base branch is main, and the head/compare side is your fork and new branch.
A useful PR description includes:
## What changed- Added a 2024 activity entry## Source- Official announcement: https://...## Locale and scope- English; KAF entry only
Click Create pull request. You are done when you see a numbered PR page. A normal content fix does not need to be a draft. Allowing maintainer edits is usually helpful for small corrections.
You are ready when: A numbered Pull Request page exists and shows your title, description, commits, and changed files.
Ask AI to help with this step
Add what you can currently see, the public error text, or what feels unclear. The guide combines it with this step's goal, target file, and repository constraints.
Describe only public interface text and errors. Never enter a password, verification code, cookie, token, email address, or private personal information.
Complete prompt to be copied
0 / 600
Help me write a KAMITSUBAKI FAN WIKI Pull Request for {{TARGET_PATH}}. I will provide the real change and source. Produce a concise title, a Markdown body with “What changed / Source / Locale and scope,” and a final checklist. Never invent a change, test result, or source.
09
Step 09
Read checks, comments, and change requests
Wait for automated checks. Red is not the end—open Details, fix the specific issue, and keep the same PR.
Yellow or gray means checks are still running; green means they passed; red means a check failed. Open Details and start with the first concrete error. Common causes are YAML indentation, missing fields, an invalid locale, or broken Markdown.
Edit the same file on the same fork/branch and commit again. New commits automatically appear in the existing PR—do not open a duplicate PR.
Maintainers may comment in Conversation or on a line under Files changed. Make the requested change, then reply briefly. A review request is a normal collaboration step.
You are ready when: You understand the PR's current state and have located the exact issue if a check or review needs action.
Ask AI to help with this step
Add what you can currently see, the public error text, or what feels unclear. The guide combines it with this step's goal, target file, and repository constraints.
Describe only public interface text and errors. Never enter a password, verification code, cookie, token, email address, or private personal information.
Complete prompt to be copied
0 / 600
My GitHub PR has a failed check or review comment for {{TARGET_PATH}}. I will paste the public error or comment. Explain it in plain language, propose the smallest fix, and remind me to update the same branch and PR. Do not guess at logs I have not shown or ask for private credentials.
10
Step 10
Finish and follow the result
Your contribution is complete once the PR is submitted; follow notifications until it is merged or closed.
Open means the PR is being reviewed or waiting for changes. Merged means the change has entered the project and will appear after deployment. Closed means it was closed without merging; read the maintainer’s explanation.
Reviews may take time. Do not close a PR simply because it is waiting. If you discover a problem, update the same branch or leave a clear comment. Even a sourced date correction or typo fix is a valuable contribution.
You are ready when: Your PR is submitted, you know where to follow it, and you have completed one traceable contribution.
Ask AI to help with this step
Add what you can currently see, the public error text, or what feels unclear. The guide combines it with this step's goal, target file, and repository constraints.
Describe only public interface text and errors. Never enter a password, verification code, cookie, token, email address, or private personal information.
Complete prompt to be copied
0 / 600
Based on the GitHub PR status I describe, explain whether it is Open, Merged, or Closed and tell me the next necessary action in beginner-friendly English. Never ask for account credentials.
Pull Request
Send your contribution to the maintainers
Final check: correct file, verifiable content, clear source, no placeholders, guesses, or private information. Then follow Edit → Preview → Commit / Propose changes → Create pull request. If you get stuck, use the AI help prompt inside the matching step.
For contributors who can sign in to a verified GitHub account and want the shortest safe browser workflow. It skips account setup and focuses on the target, editor, fork, PR, checks, and follow-up edits.
I have an account and want web editing
Completed 0 / 6
01
Step 01
Confirm account, target, and scope
Sign in, confirm your verified email, and check the target path and locale.
The target must begin with src/content/ and match the intended locale. Keep one PR focused on one subject. New facts need a traceable official or reliable source; AI can check wording but is not a source.
You are ready when: The account works, the path and locale are correct, and you can state the PR's single purpose.
Ask AI to help with this step
Add what you can currently see, the public error text, or what feels unclear. The guide combines it with this step's goal, target file, and repository constraints.
Describe only public interface text and errors. Never enter a password, verification code, cookie, token, email address, or private personal information.
Complete prompt to be copied
0 / 600
Help me scope a small wiki change for {{TARGET_PATH}}. I will describe the issue and source. Tell me what belongs in this PR and what unrelated cleanup I should avoid. Do not invent facts.
02
Step 02
Edit and preview in the browser
Accept an automatic fork if required, preserve frontmatter, and review the diff.
Open the target with the final action. If GitHub requests a fork, continue. Preserve YAML markers, keys, quotes, and indentation. In Preview / Changes, make sure red and green lines show only the intended edit. Never add credentials, tokens, private contact details, placeholders, or unsupported claims.
You are ready when: The diff is focused and the YAML/Markdown structure remains valid.
Ask AI to help with this step
Add what you can currently see, the public error text, or what feels unclear. The guide combines it with this step's goal, target file, and repository constraints.
Describe only public interface text and errors. Never enter a password, verification code, cookie, token, email address, or private personal information.
Complete prompt to be copied
0 / 600
Review my proposed Markdown diff for {{TARGET_PATH}}. Check YAML, Markdown, accidental deletion, locale consistency, sourcing, and privacy. Suggest only the smallest necessary corrections.
03
Step 03
Commit and propose the change
Use a meaningful commit message; GitHub will save the change to your fork/branch.
Click Commit changes… and use a concise message such as docs: correct KAF event date. External contributors may see Propose changes and an automatic fork. Keep the generated topic branch; do not try to write directly to upstream main.
You are ready when: The commit exists in your fork/branch and GitHub has opened a comparison or PR page.
Ask AI to help with this step
Add what you can currently see, the public error text, or what feels unclear. The guide combines it with this step's goal, target file, and repository constraints.
Describe only public interface text and errors. Never enter a password, verification code, cookie, token, email address, or private personal information.
Complete prompt to be copied
0 / 600
Give me five concise `docs: ...` commit messages for the actual edit I describe in {{TARGET_PATH}}. Do not exaggerate scope.
04
Step 04
Create the Pull Request
Base is the original main branch; head is your fork. Describe the change, source, locale, and scope.
Confirm upstream LinkTh1rsty/kamitsubaki-wiki-site:main as the base. Use your fork/branch as head. Include what changed, the supporting source, and locale/scope, then click Create pull request. A numbered PR page confirms success.
You are ready when: The numbered PR page shows the expected title, description, commits, and files.
Ask AI to help with this step
Add what you can currently see, the public error text, or what feels unclear. The guide combines it with this step's goal, target file, and repository constraints.
Describe only public interface text and errors. Never enter a password, verification code, cookie, token, email address, or private personal information.
Complete prompt to be copied
0 / 600
Draft a concise PR title and Markdown body for {{TARGET_PATH}} using only the real change and source I provide. Include What changed, Source, and Locale/scope. Do not invent evidence.
05
Step 05
Handle checks and review
Open Details for red checks and push fixes to the same branch and PR.
Wait for checks. Open the first concrete error if one fails. Fix the same fork/branch; new commits update the existing PR automatically. Reply to review comments after addressing them, and do not open a replacement PR for CI fixes.
You are ready when: Checks pass, or you have located and fixed the specific issue in the same PR.
Ask AI to help with this step
Add what you can currently see, the public error text, or what feels unclear. The guide combines it with this step's goal, target file, and repository constraints.
Describe only public interface text and errors. Never enter a password, verification code, cookie, token, email address, or private personal information.
Complete prompt to be copied
0 / 600
Explain this public GitHub Actions error or review comment for {{TARGET_PATH}} and give the smallest fix. Do not guess missing logs; remind me to update the same PR.
06
Step 06
Update or close an existing PR correctly
Further commits join the original PR. Close only when you truly intend to stop.
Edit the same branch to add corrections. Leave a short reply explaining what changed. Waiting is not a reason to close a PR. Close only when you no longer intend to continue; the public history will remain.
You are ready when: You know how to update the original PR and understand Open, Merged, and Closed.
Ask AI to help with this step
Add what you can currently see, the public error text, or what feels unclear. The guide combines it with this step's goal, target file, and repository constraints.
Describe only public interface text and errors. Never enter a password, verification code, cookie, token, email address, or private personal information.
Complete prompt to be copied
0 / 600
I have an open GitHub PR. Based on the page information I describe, help me confirm the same fork and branch so my next commit updates the original PR. Do not suggest a duplicate PR.
Pull Request
Review once, then submit
Verify the path, diff, sources, and privacy, then follow Edit → Preview → Propose changes → Create pull request → Checks / review.
Use this route to add a new artist, song, album, project, or timeline record rather than changing an existing file. New entries usually add a folder and several files, so begin by finding an existing entry of the same type to use as a structural reference.
I want to add a complete new entry
Completed 0 / 8
01
Step 01
Choose the entry type and scope
Decide between artists, songs, albums, projects, and logs, and confirm that the subject needs its own entry.
artists/ contains artists, creators, groups, and musical isotopes. songs/ contains songs grouped by artist and category. albums/ contains albums, EPs, and other official releases grouped by artist. projects/ contains projects, settings, exhibitions, and labels. logs/ contains dated news, events, and observations.
A new entry needs a clear subject, stable name, and traceable public sources. If you only need to add one date or link, edit the existing entry instead.
You are ready when: You can name the collection and explain why this should be an independent entry.
Ask AI to help with this step
Add what you can currently see, the public error text, or what feels unclear. The guide combines it with this step's goal, target file, and repository constraints.
Describe only public interface text and errors. Never enter a password, verification code, cookie, token, email address, or private personal information.
Complete prompt to be copied
0 / 600
【Goal】Decide whether my new wiki content belongs in artists, songs, albums, projects, or logs and whether it needs an independent entry.
【Content root】{{REPO_CONTENT_ROOT}}
【My situation】{{USER_CONTEXT}}
【Constraints】Use only the subject, sources, and directory context I provide. Do not invent policy or facts.
【Output】Recommended collection, reasoning, existing-entry alternative, and preparation checklist.
02
Step 02
Choose a folder slug and translationKey
Use a stable lowercase slug and one shared translationKey across all locales.
Examples include src/content/artists/vwp/new-artist/, src/content/songs/kaf/originals/new-song/, src/content/albums/kaf/new-album/, src/content/projects/arg/new-project/, and src/content/logs/2026/2026-07-12-new-event/.
Use lowercase letters, numbers, and hyphens. The slug and translationKey should not change with display-language translations. Search the repository for duplicates first.
You are ready when: The slug and translationKey are stable, locale-independent, and not duplicated.
Ask AI to help with this step
Add what you can currently see, the public error text, or what feels unclear. The guide combines it with this step's goal, target file, and repository constraints.
Describe only public interface text and errors. Never enter a password, verification code, cookie, token, email address, or private personal information.
Complete prompt to be copied
0 / 600
【Goal】Design a folder slug and translationKey for a new wiki entry.
【My situation】{{USER_CONTEXT}}
【Constraints】Lowercase letters, numbers, and hyphens only; one translationKey for zh/ja/en; do not guess an official English name.
【Output】Three candidates, one recommendation, and duplicate checks to run.
03
Step 03
Create the folder and three locale files
Put zh.md, ja.md, and en.md together in the same entry directory.
<entry>/zh.md<entry>/ja.md<entry>/en.md
On GitHub, browse to the correct collection and use Add file → Create new file. A filename such as new-artist/zh.md creates the directory too. An unfinished body may remain empty, but do not add placeholder prose.
You are ready when: All three files are in the same correct directory with no accidental extra nesting.
Ask AI to help with this step
Add what you can currently see, the public error text, or what feels unclear. The guide combines it with this step's goal, target file, and repository constraints.
Describe only public interface text and errors. Never enter a password, verification code, cookie, token, email address, or private personal information.
Complete prompt to be copied
0 / 600
【Goal】Create the correct directory and zh.md / ja.md / en.md skeleton for a new entry.
【Content root】{{REPO_CONTENT_ROOT}}
【My situation】{{USER_CONTEXT}}
【Constraints】Follow the existing hierarchy, keep all locales together, and invent no placeholder facts.
【Output】Final directory tree, GitHub web steps, and the minimum structure for each file.
04
Step 04
Add collection-valid frontmatter
Follow content.config.ts and an existing entry of the same type; include only fields you understand.
Artists, songs, albums, projects, and logs have different required fields. Each file’s locale must match its filename, while translationKey must be identical across all three. Songs require artist and artistId; album tracks should include songId only when the linked song entry exists.
Do not invent theme, seo, image, or ordering values merely to make the file look complete. Use src/content.config.ts as the source of truth.
You are ready when: All locale frontmatter matches the schema, with correct locale values and one translationKey.
Ask AI to help with this step
Add what you can currently see, the public error text, or what feels unclear. The guide combines it with this step's goal, target file, and repository constraints.
Describe only public interface text and errors. Never enter a password, verification code, cookie, token, email address, or private personal information.
Complete prompt to be copied
0 / 600
【Goal】Create the minimum valid frontmatter for all three locale files using the content.config.ts and reference entry I provide.
【My situation】{{USER_CONTEXT}}
【Constraints】List missing facts as questions instead of inventing values; keep translationKey identical.
【Output】zh/ja/en frontmatter, field rationale, and unresolved items.
05
Step 05
Write and translate the body
Map facts to sources first, then translate with matching structure and natural language.
Build a source-backed fact list, complete the strongest locale, translate the others, then verify names, dates, work titles, and links. AI may help translate or edit, but it is never a source. Keep uncertain official terms in their original form.
You are ready when: Locale structures align, with no placeholders or unsupported facts.
Ask AI to help with this step
Add what you can currently see, the public error text, or what feels unclear. The guide combines it with this step's goal, target file, and repository constraints.
Describe only public interface text and errors. Never enter a password, verification code, cookie, token, email address, or private personal information.
Complete prompt to be copied
0 / 600
【Goal】Turn reliable sources into a structured three-locale wiki article.
【Sources and situation】{{USER_CONTEXT}}
【Constraints】Write only directly supported facts; AI is not a source; retain uncertain official terms in the original language.
【Output】Fact-to-source map, zh/ja/en Markdown, and unresolved content.
06
Step 06
Review sources, links, and image rights
Make key facts traceable and avoid private, paid, leaked, or unattributed media.
Prefer official pages, announcements, posts, and formal interviews. Do not add screenshots of paid content, leaked assets, private photos, personal information, or unattributed reposts. If image usage is uncertain, use a reliable official URL or ask maintainers before adding it.
You are ready when: Key facts are sourced, links work, and images have no obvious rights or privacy risk.
Ask AI to help with this step
Add what you can currently see, the public error text, or what feels unclear. The guide combines it with this step's goal, target file, and repository constraints.
Describe only public interface text and errors. Never enter a password, verification code, cookie, token, email address, or private personal information.
Complete prompt to be copied
0 / 600
【Goal】Audit sources, links, and image risk for a new entry.
【My situation】{{USER_CONTEXT}}
【Constraints】AI output is not evidence; reject paid, leaked, private, or unattributed media; flag uncertainty.
【Output】Fact-source table, weak links, image risks, and blocking fixes.
07
Step 07
Validate locales and the build
Check locale, translationKey, schema, and links; run the same commands as CI when possible.
pnpm testpnpm checkpnpm build
Browser-only contributors can use PR CI and fix failures on the same branch. Never include generated output or private data.
You are ready when: Manual review is complete and local checks pass, or you know where to read PR CI.
Ask AI to help with this step
Add what you can currently see, the public error text, or what feels unclear. The guide combines it with this step's goal, target file, and repository constraints.
Describe only public interface text and errors. Never enter a password, verification code, cookie, token, email address, or private personal information.
Complete prompt to be copied
0 / 600
【Goal】Audit a new entry's directories, locales, frontmatter, body, and sources before submission.
【My situation】{{USER_CONTEXT}}
【Constraints】Do not claim tests ran unless I provide their results.
【Output】Group findings as Blocking / Recommended / Passed and give the smallest repair order.
08
Step 08
Submit a reviewable new-entry PR
Keep the PR limited to this entry and explain paths, locales, sources, images, and validation.
Include entry type and paths, locale completeness, major sources, image source, checks actually run, and open questions. Do not mix unrelated formatting or other entries into this PR. Continue CI and review fixes on the same branch.
You are ready when: The PR contains only new-entry files and gives maintainers everything needed to review it.
Ask AI to help with this step
Add what you can currently see, the public error text, or what feels unclear. The guide combines it with this step's goal, target file, and repository constraints.
Describe only public interface text and errors. Never enter a password, verification code, cookie, token, email address, or private personal information.
Complete prompt to be copied
0 / 600
【Goal】Draft a commit message and PR description for a new wiki entry.
【My situation】{{USER_CONTEXT}}
【Constraints】Use only actual files, sources, and validation results; do not invent translation completeness, tests, or image rights.
【Output】Commit message, PR title, and Markdown with Summary / Files / Locales / Sources / Image / Validation / Open questions.
Pull Request
Start the new entry from the content directory
Open src/content/, choose the correct collection and category, then create the entry directory and all three locale files. Confirm schema, sources, images, and validation before submitting the PR.
For contributors already comfortable with forks, branches, commits, PRs, and CI. Use the web editor, GitHub Desktop, or a local Git workflow; this route focuses on this Astro repository’s content model and review expectations.
I know Git and GitHub
Completed 0 / 6
01
Step 01
Establish the content model
Content Collections are the primary source; routes and homepage sections render from the folder structure.
Do not include dist/, .astro/, node_modules/, or hard-coded article copy in components in a content PR.
You are ready when: The change is classified as content or implementation and the target matches its collection path.
Ask AI to help with this step
Add what you can currently see, the public error text, or what feels unclear. The guide combines it with this step's goal, target file, and repository constraints.
Describe only public interface text and errors. Never enter a password, verification code, cookie, token, email address, or private personal information.
Complete prompt to be copied
0 / 600
Review whether {{TARGET_PATH}} fits this repository's artists/songs/albums/projects/logs/site content model and explain its likely rendering impact. Avoid assumptions about code I have not supplied.
02
Step 02
Apply schema and localization constraints
content.config.ts validates frontmatter; localized records share translationKey and structure.
locale is zh | ja | en. Localized files share a stable translationKey. Artists, songs, albums, projects, and logs have distinct schemas. Prefer zh.md, ja.md, and en.md together for a new entry; incomplete bodies may be empty but must not use placeholder prose.
Keep theme.* color values consistent across locales, localize only palette labels, and use seo.* only for deliberate metadata overrides.
You are ready when: Frontmatter satisfies its collection schema and locale/translationKey match sibling files.
Ask AI to help with this step
Add what you can currently see, the public error text, or what feels unclear. The guide combines it with this step's goal, target file, and repository constraints.
Describe only public interface text and errors. Never enter a password, verification code, cookie, token, email address, or private personal information.
Complete prompt to be copied
0 / 600
Act as an Astro Content Collections reviewer. Against the content.config.ts schema I provide, validate frontmatter for {{TARGET_PATH}} and list type, enum, required-field, and i18n consistency issues without inventing defaults.
03
Step 03
Choose web, Desktop, or local Git
Web is fine for one file; use a topic branch for multi-file entries and structural work.
External contributors should target upstream LinkTh1rsty/kamitsubaki-wiki-site:main from a personal fork branch.
Keep generated output, local settings, and unrelated formatting out of the PR. Confirm rights and project media policy before adding images.
You are ready when: The topic branch starts from current upstream/main and the staged diff contains only relevant files.
Ask AI to help with this step
Add what you can currently see, the public error text, or what feels unclear. The guide combines it with this step's goal, target file, and repository constraints.
Describe only public interface text and errors. Never enter a password, verification code, cookie, token, email address, or private personal information.
Complete prompt to be copied
0 / 600
Review the `git status` and `git diff --stat` I provide for a content PR centered on {{TARGET_PATH}}. Flag unrelated files, but never recommend reset --hard or deleting unconfirmed user work.
04
Step 04
Run the same validation as CI
Run tests, Astro check, and build; fix the first root-cause error.
pnpm testpnpm checkpnpm build
check catches collection schema and Astro/TypeScript issues; build validates static routes and rendering. Start from the first concrete error rather than downstream cascades.
You are ready when: All commands pass, or the PR clearly records an objective reason local validation was unavailable.
Ask AI to help with this step
Add what you can currently see, the public error text, or what feels unclear. The guide combines it with this step's goal, target file, and repository constraints.
Describe only public interface text and errors. Never enter a password, verification code, cookie, token, email address, or private personal information.
Complete prompt to be copied
0 / 600
I will paste output from pnpm test, pnpm check, or pnpm build. Identify the first root cause, distinguish schema errors from implementation errors, and propose the smallest fix without inventing file contents.
05
Step 05
Write a reviewable PR
Make scope, sources, locale, validation, and risk obvious; target upstream/main.
Include a change summary, motivation, sources mapped to the facts they support, locale/file scope, validation commands actually run, and screenshots only for visible implementation changes. Keep the diff single-purpose and reviewable.
You are ready when: Base/head are correct and the description lets a reviewer understand scope and evidence before opening every file.
Ask AI to help with this step
Add what you can currently see, the public error text, or what feels unclear. The guide combines it with this step's goal, target file, and repository constraints.
Describe only public interface text and errors. Never enter a password, verification code, cookie, token, email address, or private personal information.
Complete prompt to be copied
0 / 600
Using only the real diff, sources, and validation results I provide, draft a concise PR title and Markdown body for {{TARGET_PATH}} with Summary, Sources, Locales/scope, and Validation. Do not invent tests or evidence.
06
Step 06
Complete review on the same branch
Push CI and review fixes to the head branch and preserve the conversation history.
New commits update the PR. Prefer small fixes for explicit issues. Avoid duplicate PRs or rewriting a branch under active review unless a maintainer asks. Resolve content conflicts by rechecking facts and sibling locales, not just deleting conflict markers.
You are ready when: CI passes, review comments are answered, and the final diff remains focused and free of generated output.
Ask AI to help with this step
Add what you can currently see, the public error text, or what feels unclear. The guide combines it with this step's goal, target file, and repository constraints.
Describe only public interface text and errors. Never enter a password, verification code, cookie, token, email address, or private personal information.
Complete prompt to be copied
0 / 600
Classify the PR review comments and diff I provide into required fixes, clarification questions, and optional suggestions. Give a minimal same-branch repair order and avoid destructive Git commands.
Pull Request
Submit within the repository rules
Final check: collection path and schema are valid, localization strategy is explicit, sources are traceable, the diff is focused, and pnpm test, pnpm check, and pnpm build pass.
You do not need to leave the contribution flow or memorize the whole reference. Complete only what your change needs, then jump to the relevant section when you meet a formatting, media, or frontmatter question.
01Choose a contribution route
02Confirm the file and locale
03Look up syntax while editing
04Review the diff and open a PR
Use this as a look-up reference, not a chapter you must memorize. For a first contribution, choose a route above. While editing, jump here only when you need a heading, link, image, media embed, or frontmatter field.
Before you edit
The shortest reliable workflow is:
Confirm that the target is under src/content/ and that zh.md, ja.md, or en.md matches the intended locale.
Change only what the contribution needs, and prepare a traceable source for new facts.
Preserve both --- markers, existing fields, indentation, and quotes in frontmatter.
Review Preview / Changes before opening the Pull Request.
This site uses Markdown rather than wiki text. Syntax characters must be half-width ASCII characters; full-width punctuation entered by a Chinese or Japanese input method will not work.
Beginner rule: prefer a small, correct change. Do not reorganize unrelated paragraphs, and never use AI output as a factual source.
Headings
Use # to create headings. Its count determines the level, up to six, and it must be followed by a space. Entry bodies normally begin with ##, because the page title already comes from frontmatter.
Use | to define columns and - to define the header separator:
Source:
| Artist | Song | Lyrics || :--- | :---: | ---: || KAF | 糸 | Omitted || RIM | 1999 | Omitted |
Rendered result:
Artist
Song
Lyrics
KAF
糸
Omitted
RIM
1999
Omitted
Alignment rules:
:--- means left-aligned.
:---: means centered.
---: means right-aligned.
Frontmatter
The frontmatter block at the top of a file contains the properties of the entry being edited.
A frontmatter block begins and ends with ---.
For example:
---locale: entranslationKey: example-entrytitle: Example Entry---
Rendered result: the page reads these fields to generate its title, locale relationship, and metadata; the YAML block is not displayed as article text.
Inserting images
Source:

Rendered result: the image appears at this position. If the asset is temporarily unavailable, its alternative text still explains the intended content.
Place the file in public/images/, but use a public URL beginning with /images/; do not include public in the URL. Describe informative images clearly. Decorative images may use an empty description: .
About Markdown editors
Markdown does not require a specialized editor. You can even create a Markdown file using a basic text editor such as Notepad, as long as you save the file with the .md extension.
For users who are unfamiliar with Markdown, an editor with real-time preview may provide a more convenient workflow.
Obsidian is recommended because it offers a comprehensive feature set and is available on multiple platforms.
Wiki shortcodes and controlled media
After learning the Markdown basics, you may use a small, supported subset of HTML for ruby text, disclosure panels, and semantic markup. Article HTML is sanitized during the build; not every element supported by a browser is permitted here.
Security boundary
Article bodies allow only these groups of elements:
Structure: p, h1–h6, blockquote, hr, br, div, and span.
Text semantics: a, abbr, b, strong, i, em, u, s, del, mark, small, code, pre, kbd, samp, var, sub, sup, cite, q, and time.
Lists and data: ul, ol, li, dl, dt, dd, table, thead, tbody, tfoot, tr, th, and td.
Wiki layout: ruby, rt, rp, details, summary, figure, figcaption, picture, img, and source.
Attributes are allowlisted too. Normal link, image-alt, and table-span attributes are retained; class is limited to the few patterns implemented by the site. The following are removed:
Executable or arbitrary third-party containers such as script, style, iframe, object, embed, and form.
Every on* event attribute, including onclick, onmouseover, and onerror, plus inline style.
Dangerous URL schemes such as javascript:. Authored id and name values receive a safe prefix so article content cannot shadow page objects.
Contributors normally do not need to write this HTML directly. Prefer the Wiki shortcodes below: site code creates the matching elements and the result still passes through the same allowlist. Propose a reusable shortcode in the PR when a new interaction is needed; do not paste scripts or third-party player snippets into an article.
Wiki shortcode reference
Shortcodes use a function-like {{name::argument}} form. Every name and argument count is fixed:
Purpose
Syntax
Ruby reading
{{ruby::text::reading}}
Reading plus romaji
{{ruby::text::kana::romaji}}
Spoiler / redaction
{{spoiler::hidden text}}
Highlight
{{mark::important}}
Abbreviation
{{abbr::V.W.P::Virtual Witch Phenomenon}}
Keyboard input
{{kbd::Ctrl+K}}
Machine-readable date
{{time::display text::2026-07-19}}
Small, superscript, subscript
{{small::text}}, {{sup::2}}, {{sub::2}}
Lyric toggle buttons
{{lyrics-controls::en}} (use zh / ja for those files)
Inline arguments are plain text: do not nest Markdown or HTML inside them. A double colon :: separates arguments and remains safe inside Markdown tables. A misspelled name or incorrect argument count remains visible as source text so the mistake can be found in Preview.
Source:
{{mark::Important}}{{abbr::V.W.P::Virtual Witch Phenomenon}}Press {{kbd::Ctrl+K}}{{time::July 19, 2026::2026-07-19}}H{{sub::2}}O and x{{sup::2}}{{small::Additional note}}
Rendered result:
Important, V.W.P, press Ctrl+K, , H2O and x2, additional note
On a song page, place {{lyrics-controls::en}} in its own paragraph immediately before the .my-lyric-box lyric container. The site generates the localized kana, translation, romaji, and synchronized-lyric controls; Japanese automatically omits the translation control. The argument must match the file’s locale.
Complete lyric-page authoring
A lyric page has three parts: localized controls, the lyric container, and repeated lyric lines. The controls must occupy their own paragraph immediately before the container. Each lyric-line contains one source line and its translation.
Replace locale with the current file’s zh, ja, or en.
furi is the kana track controlled by “Show kana”; roma is the romanization track.
Chinese uses cn-lyric, English uses trans-lyric, and Japanese omits the translation <div>.
If kana needs no furigana, provide only romaji: <ruby>なら<rt class="roma">nara</rt></ruby>.
Copy the complete lyric-line group for every additional line. Do not put {{ruby::...}} shortcodes inside this raw HTML block; Markdown shortcodes are not parsed again inside an HTML block.
Authoring
This is a complete single-line example that can be copied into an English song file:
{{lyrics-controls::en}}<div class="my-lyric-box"><div class="lyric-line"><div class="jp-lyric"><ruby>間違<rt class="furi">まちが</rt><rt class="roma">machiga</rt></ruby><ruby>い<rt class="roma">i</rt></ruby></div><div class="trans-lyric">If it is a mistake</div></div></div>
Example
The code above renders as an interactive lyric-practice component:
間違い
If it is a mistake
Synchronized lyric timeline
For karaoke-style word animation, write a [mm:ss.xx] or [mm:ss.xxx] timestamp immediately before each lyric unit. A timestamp is the unit’s start time relative to the lyric timer, and the lyric fills continuously from left to right between adjacent timestamps. “Play” starts at 00:00.00, selecting a timed lyric line seeks to that line and continues playback, and “Reset” returns to the beginning.
mm and ss must each contain two digits; the fractional part may contain two or three digits. Valid examples include [00:03.50] and [01:02.345].
Put the timestamp directly against its <ruby> element or plain text, with no intervening space. Every unit that should highlight independently needs its own start time.
The first timestamp in each .jp-lyric also becomes that line’s seek time. If a translation line is present, give it the same line-start timestamp at the beginning.
Each unit fills until the next timestamp. The final unit in a line continues to the next line, while the final line receives a short automatic tail.
Keep timestamps increasing in playback order. Partial timing is allowed; lines without timestamps remain normally displayed.
Author only the bracketed timestamps. Do not write the generated lrc-tag, lrc-word, or any script. Calibrate times by listening to the track and never ask AI to estimate them.
The lyric timer is currently independent and does not automatically read the playback position of the YouTube, bilibili, or other media player above it.
Authoring
{{lyrics-controls::en}}<div class="my-lyric-box"><div class="lyric-line"><div class="jp-lyric">[00:00.00]<ruby>間違<rt class="furi">まちが</rt><rt class="roma">machiga</rt></ruby>[00:00.80]<ruby>い<rt class="roma">i</rt></ruby></div><div class="trans-lyric">[00:00.00]If it is a mistake</div></div></div>
Example
After synchronized lyrics are enabled, the two Japanese units below begin filling from left to right at 0 and 0.8 seconds:
間違い
If it is a mistake
AI prompt for generating lyric HTML
For long lyrics, an AI assistant can mechanically format source text, readings, romaji, and translations that you already have. AI is not a source for lyrics, translations, or readings: verify every line before pasting and make sure the material’s source permits this contribution.
Prompt syntax
Copy the complete prompt below and replace its five input sections:
You are a lyric HTML formatter for the KAMITSUBAKI Wiki. Convert only the lyric tracks I provide into the site's format.Requirements:1. Only transform the input. Do not add lyrics, translate, rewrite, or guess missing readings.2. Output only content that can be pasted directly into Markdown. Do not explain and do not use a code fence.3. Begin with {{lyrics-controls::file locale}}, followed by exactly one <div class="my-lyric-box"> container.4. Use one <div class="lyric-line"> per input line and put Japanese source text inside <div class="jp-lyric">.5. With kana and romaji, use <ruby>source<rt class="furi">kana</rt><rt class="roma">romaji</rt></ruby>.6. With romaji only, use <ruby>source<rt class="roma">romaji</rt></ruby>. With no reliable reading, keep plain source text.7. Use cn-lyric for Chinese translations and trans-lyric for English translations. Omit the translation div for Japanese files or missing translations.8. Preserve line count, order, punctuation, and text exactly. If word-level alignment is uncertain, use one ruby for the whole line with the supplied whole-line reading; do not invent segmentation.9. Escape <, >, and & in text. Never output style, any on* attribute, script, iframe, id, or unrequested elements.10. Check that every div, ruby, and rt is closed correctly. Leave exactly one blank line between the controls and lyric container.[FILE LOCALE]zh / ja / en[JAPANESE SOURCE — one lyric line per line]Paste here[KANA — optional; line count must match source]Paste here[ROMAJI — optional; line count must match source]Paste here[TRANSLATION — optional; line count must match source]Paste here
Authoring
Replace only the input sections, for example:
[FILE LOCALE]en[JAPANESE SOURCE]間違い[KANA]まちがい[ROMAJI]machigai[TRANSLATION]If it is a mistake
Output example
A valid AI response should resemble this and be ready to paste into the song body:
{{lyrics-controls::en}}<div class="my-lyric-box"><div class="lyric-line"><div class="jp-lyric"><ruby>間違い<rt class="furi">まちがい</rt><rt class="roma">machigai</rt></ruby></div><div class="trans-lyric">If it is a mistake</div></div></div>
Ruby readings
Provide only the displayed text and its reading:
{{ruby::局部坏死::zheng ge hao huo}}
For precise character-by-character alignment, place calls next to each other:
{{ruby::清::hun}}{{ruby::楚::dun}}
The result is:
清楚
Content hidden by default
Use the spoiler shortcode for short inline content and the block form below for longer optional content. Neither form requires article-level JavaScript.
The spoiler argument is plain text. Do not put **bold text**, Markdown links, or HTML inside {{spoiler::...}}, because the shortcode will remain visible as source text. To bold the complete spoiler, write **{{spoiler::hidden text}}**. Use the details block in the next section when hidden content needs headings, lists, links, or other mixed formatting.
Source:
The ending is: {{spoiler::hidden by default}}
Rendered result:
The ending is: hidden by default
Collapsible content
Use paired details markers. Each marker must occupy its own paragraph with a blank line around it; normal Markdown remains available between them:
{{details::Show the complete track list}}1. First song2. **Second song**{{/details}}
The result is:
Show the complete track list
First song
Second song
For ordinary paragraphs, insert a blank line. Use the allowlisted <br> only in special locations such as a table cell.
Embedding audio and video
This site provides one media shortcode. Put it on a line by itself and the build will generate a responsive, restricted, lazy-loaded iframe:
@[provider](media ID or share URL "optional title")
Supported provider names are youtube, bilibili, apple-music, spotify, netease, and qq-music. YouTube, bilibili, NetEase Cloud Music, and QQ Music accept a video or song ID directly; all providers accept their common share URLs.
When the same work has official media on several platforms, wrap the existing media shortcodes in one aggregate block. The page shows one selected source with platform buttons; the original standalone @[provider](...) syntax remains unchanged.
A localized title is required, such as the work title or “Official media.”
Every item keeps the original media syntax and the same provider and URL validation rules.
Lines may be consecutive without blank lines. A single-line block also parses, but one platform per line is recommended for review and maintenance.
A switcher accepts 2–6 distinct platforms. Do not repeat a provider, nest switchers, or mix ordinary paragraphs into the block.
Every source must validate. One unknown provider, hostile URL, or malformed ID prevents the entire block from creating an iframe and leaves visible source text for correction.
Without JavaScript, validated players appear in source order. With JavaScript, use the buttons, arrow keys, Home, or End to switch sources.
Multiple shortcodes may be placed in the same Markdown table cell. Players are stacked vertically in source order. The cell must contain only shortcodes and whitespace, without explanatory text:
An unrecognized provider or target remains a normal link and never becomes an arbitrary third-party iframe. New content should use the shortcode so provider scope, privacy attributes, sizing, and styling stay consistent; do not paste raw third-party <iframe> snippets.
Branded external-link cards on artist pages
Artist pages can show official links in two places. Both use the same platform detection and brand styling, but their source syntax is different.
Official links in the infobox
The infobox reads officialLinks from frontmatter. Every item must provide both a display label and a complete href:
Use the exact standalone level-two heading ## External Links, followed immediately by an ordinary Markdown unordered list. Put the platform or page name inside each link:
Do not write - YouTube: <https://...>, - <https://...>, or a list item containing only descriptive text. Those forms cannot produce a complete card.
Do not combine the section with sources under a heading such as “Sources and External Links.” Put evidence in a separate ## Sources section and reader-facing official pages or social accounts under ## External Links.
Chinese, Japanese, and English artist articles use 外部链接, 外部リンク, and External Links, respectively. The heading must be exact so the site can recognize it.
With JavaScript, the artist page enhances the list into responsive link cards with platform logos, brand colors, and an external-link arrow. They remain navigation links rather than form buttons. Without JavaScript, the source remains a readable, clickable list.
Recognized platforms include Bilibili, YouTube, X/Twitter, TikTok, Instagram, Weibo, Niconico, Spotify, Apple Music, NetEase Cloud Music, pixiv, piapro, Steam, Wikipedia, and official KAMITSUBAKI sites. Other URLs receive the generic website style.
Do not paste platform SVG or remote logo images into the article; the site supplies the icons centrally.
Pre-PR checklist
The path matches locale, and localized siblings share one translationKey.
Both --- markers, YAML indentation, and field types are intact.
Dates use YYYY-MM-DD; durations use MM:SS or HH:MM:SS.
New facts have reliable sources, links open, and informative images have useful alternative text.
Artist-body links use a standalone ## External Links heading and - [Label](URL) list items, with no bare URLs or combined heading.
Media uses @[provider](...); the body contains no scripts, event handlers, credentials, tokens, or private information.
Preview / Changes contains only the intended edit and no accidental deletion of another locale.
Property block guide
If you do not understand the properties in an entry’s frontmatter block, refer to the explanations below.
Common properties
The following properties are shared by every entry category:
locale: Identifies the language version of the document. The available values are zh for Chinese, en for English, and ja for Japanese. Enter the value corresponding to the language of the entry you are editing.
translationKey: A shared identifier connecting different language versions of the same entry. The Chinese, Japanese, and English files for the same entry must use the same value.
Source example:
locale: entranslationKey: kaf-originals-shi
Result: the file joins the English collection and links to the Japanese and Chinese files that share this translationKey.
Result: the artist page uses “KAF” as its heading and displays the status and profile image.
Property
Type
Required
Purpose and content
locale
zh / ja / en
Yes
Language of the current entry
translationKey
String
Yes
Shared identifier used by all language versions of the same person
code
String
No
Artist number, archive number, or internal identifier
name
String
Yes
Person’s name as displayed in the current language
romanizedName
String
Yes
Romanized, Latin-alphabet, or international display name
categoryTitle
String
No
Main title of the category to which the artist belongs
categorySubtitle
String
No
Subtitle or English description of the category
categoryOrder
Number
No
Sorting value between categories; smaller values are usually displayed first
itemOrder
Number
No
Sorting value of the current artist within the category
meta
String
No
Short metadata shown on a list card, such as a role, affiliation, or brief summary
debutDate
String
No
Debut date. The recommended format is YYYY-MM-DD, although the schema does not enforce it
profileTagline
String
No
Introductory tagline displayed on the artist detail page
designCredits
String array
No
List of character designers, visual designers, modelers, and other production staff
affiliations
String array
No
Labels, groups, projects, or organizations with which the artist is affiliated
officialLinks
Object array
No
Official website and official social-media links
officialLinks[].label
String
Yes
Link name, such as Official Site or YouTube
officialLinks[].href
String
Yes
Official link URL
featuredEntries
Object array
No
Other entries prominently associated with the artist
featuredEntries[].label
String
Yes
Display name of the associated content
featuredEntries[].href
String
Yes
Path to the associated entry
featuredEntries[].kind
Fixed enum
Yes
Type of associated content. Must be artist, project, album, or song
theme
Shared theme object
No
Customized color theme for the artist detail page
statusLabel
String
Yes
Heading of the status field, such as Activity Status
status
String
Yes
Actual status, such as Active or Inactive
inactive
Boolean
No
Whether the artist is inactive. true normally indicates that activities have ended or the entry has been archived
image
String
Yes
Path to the main image, avatar, or character illustration
seo
Shared SEO object
No
Search-engine and social-sharing information for the entry
Project properties
Minimal example:
kind: projecttitle: Kamitsubaki City Under Constructiondescription: A Kamitsubaki world-building projectorder: 10
Result: the project is sorted by order and its title and description form the listing card.
Property
Type
Required
Purpose and content
locale
zh / ja / en
Yes
Language of the current project entry
translationKey
String
Yes
Shared identifier used by all language versions of the same project
kind
String
Yes
Project type, such as project, game, or virtual-world. The schema does not restrict this field to predefined values
title
String
Yes
Project title
description
String
Yes
Short description of the project, normally used on list cards or as a page summary
order
Number
Yes
Sorting value in the project list
seo
Shared SEO object
No
Search-engine and social-sharing information
Log properties
Minimal example:
date: "2026-07-19"type: updatetitle: Site content updateorder: 10
Result: the log page displays its date, type, and title and sorts it by order.
Property
Type
Required
Purpose and content
locale
zh / ja / en
Yes
Language of the current log entry
translationKey
String
Yes
Shared identifier used by all language versions of the same log
date
String
Yes
Date of the log. The recommended format is YYYY-MM-DD, although the schema does not validate it
type
String
Yes
Log type, such as update, notice, or maintenance
title
String
Yes
Log title
summary
String
No
Short summary of the log
order
Number
Yes
Sorting value of the log
seo
Shared SEO object
No
Search-engine and social-sharing information
Song properties
Store song files as artist ID / category / song ID / locale.md, for example songs/kaf/originals/shi/en.md. The first artist folder is the entry’s canonical storage location, while its category folder is reused in every associated artist catalog. Recommended folders are originals, covers, genealogy, suites, collaborations, and projects; any additional folder automatically becomes a new category.
Sharing one entry between artists: create only one song folder for the same recording. Choose one primary artist as the canonical location, keep artistId equal to the first path folder, and put every artist catalog that should include the recording in artistIds. For example, keep “古傷” only at songs/harusaruhi/collaborations/古傷-furukizu/:
You now maintain only zh.md, ja.md, and en.md in that folder. The same entry appears under Collaborations for both Harusaruhi and KOKO, and both catalog items link to the same canonical page. Do not copy the body, translationKey, or artwork metadata into songs/koko/. artistIds must include artistId and must not contain duplicates; putting artistId first is recommended. When present, code must identify one unique recording and must not be reused by another song folder.
Result: the song page displays its title, artist, release date, and duration and appears in every artist list named by artistIds. If artistIds is omitted, it appears only under artistId.
Property
Type
Required
Purpose and content
locale
zh / ja / en
Yes
Language of the current song entry
translationKey
String
Yes
Shared identifier used by all language versions of the same song
title
String
Yes
Song title
artist
String
Yes
Main performer or artist name
artistId
Lowercase slug
Yes
Canonical storage artist, such as kaf; it must match the first folder in the song path
artistIds
List of lowercase slugs
No
Every artist catalog that should include this same entry; required for multi-artist songs, must include artistId, and must not contain duplicates
composer
String
No
Composer
lyricist
String
No
Lyricist
album
String
No
Album containing the song
duration
String
No
Song duration. The recommended format is 03:45, although the schema does not validate it
releaseDate
String
No
Release date. The recommended format is YYYY-MM-DD
code
String
No
Unique recording, archive, or internal identifier; it must not be repeated in another song folder
categoryTitle
String
No
Title of the category to which the song belongs
categorySubtitle
String
No
Subtitle of the category
categoryOrder
Number
No
Sorting value between categories
itemOrder
Number
No
Sorting value of the song within its category
image
String
No
Path to the song artwork, single cover, or album cover
Result: the album page builds its metadata and track list; a track with songId links to the corresponding song page.
Property
Type
Required
Purpose and content
locale
zh / ja / en
Yes
Language of the current album entry
translationKey
String
Yes
Shared identifier used by all language versions of the same album
title
String
Yes
Album title
romanizedTitle
String
No
Romanized, Latin-script, or international display title
artist
String
Yes
Main album artist
type
String
No
Release type, such as Album, EP, or Mini Album
description
String
No
Short description shown near the detail-page heading
releaseDate
String
No
Release date. The recommended format is YYYY-MM-DD
label
String
No
Releasing label
catalogNumber
String
No
Catalog or product number
trackCount
Number
No
Total number of tracks
duration
String
No
Total album duration
code
String
No
List number, archive number, or internal identifier
categoryTitle
String
No
Title of the album category
categorySubtitle
String
No
Subtitle of the album category
categoryOrder
Number
No
Sorting value between categories
itemOrder
Number
No
Sorting value of the album within its category
image
String
No
Path or URL for the album cover
officialLinks
Object array
No
Official, purchase, or streaming links; each item uses label and href
tracks
Object array
No
Track list. Each item requires title and may include disc, number, artist, duration, and songId
tracks[].songId
String
No
Path of a related song entry on this site, such as kaf/originals/shi
theme
Shared theme object
No
Custom color theme for the album detail page
seo
Shared SEO object
No
Search-engine and social-sharing information
Song and album backfill standard
Backfill work has two independently reviewable levels:
Catalog-ready: paths, required metadata, official sources, local high-resolution artwork, official links, and a minimal body are reliable. Track links, lyrics, or long-form text may still be incomplete if the missing scope is stated clearly.
Complete entry: adds verified tracks, internal song links, body copy, usable lyric material, and all three locales. Completeness never means filling uncertain fields.
Group songs by artist and then song category. Group albums only by artist and album ID; do not reproduce the artist-category UI as album folders. Use stable lowercase slugs for artistId, songId, and albumId, and share one translationKey across locales.
The path’s artistId, category, and songId agree with the metadata. Reuse originals, covers, genealogy, suites, collaborations, or projects when applicable.
Titles, dates, and credits are supported by official sites, official upload descriptions, legitimate release pages, or reliable interviews. AI output is not a source.
categoryOrder and itemOrder do not conflict with existing entries and preserve a stable public or site order.
image resolves to a real repository asset, not an expiring URL, search thumbnail, placeholder, or unnecessary duplicate.
Use controlled media syntax such as @[bilibili](BV...); do not add raw <iframe> markup, autoplay, or unofficial reuploads.
The body identifies the work and cites traceable sources. Lyrics are optional. If added, distinguish original, translation, and romanization, reuse the lyric controls, and verify provenance and copyright boundaries.
Prefer zh.md, ja.md, and en.md together. List missing translations or facts in the PR instead of inventing text or adding placeholder prose.
Album acceptance criteria
Catalog-ready minimum: title, artist, type, verified release information, official artwork, at least one official or licensed streaming link, a shared three-locale translationKey, and a short source-backed body.
Prefer the highest-quality artwork available from Apple Music or another licensed service or official product page. Use a square image of at least 1500 × 1500 when available; reject search thumbnails, screenshots, placeholders, and artificial upscales.
Store artwork at public/images/albums/<artistId>/<albumId>.jpg and reference /images/albums/<artistId>/<albumId>.jpg in frontmatter rather than relying on a third-party image URL.
trackCount matches the verified total. When tracks is present, check disc number, sequence, title, artist, and duration against the official track list.
Add tracks[].songId only when the target song entry exists. A track without a page keeps its title and must not create a broken link.
Separate standard, reissue, remix, and live editions only when they are officially distinct releases; never mix dates or track lists from different editions.
If tracks or body copy are incomplete, state the scope in both the entry and PR. Do not fabricate data or imply that coverage is complete.
Structural metadata, sequence, artwork, and links remain aligned across locales; localize display text and prose only.
Body code syntax
## About the releaseDescribe the work, release context, and verified production information.## Official media@[bilibili](BVxxxxxxxxxx)## Backfill statusCore metadata and official links are complete; track links will be added as song entries become available.## Sources- [Official release page](https://example.com/official)- [Apple Music](https://music.apple.com/example)
Authoring
Make only claims supported by sources. The status note should tell reviewers and future editors what is complete and what remains, without presenting plans or guesses as encyclopedia facts.
Example
Use src/content/songs/kaf/, src/content/albums/kaf/, and public/images/albums/kaf/ as current references. Before submitting, run:
pnpm checkpnpm testpnpm build
Passing checks is the minimum technical bar; it does not replace source, track-order, link, or artwork-quality review.
Advanced: supported raw HTML
Shortcodes are the easiest option, but the original safe HTML forms remain supported for maintaining older entries or controlling markup precisely. HTML must stay within the allowlist described above. The sanitizer removes style, onmouseover, onclick, script, and raw iframe content.
HTML ruby readings
Source:
<ruby>局部坏死<rt>zheng ge hao huo</rt></ruby><ruby>清<rt>hun</rt>楚<rt>dun</rt></ruby>
Rendered result:
局部坏死; 清楚
HTML spoiler text
The old version based on inline styles and mouse event attributes is no longer accepted. Safe raw HTML uses the site-defined wiki-spoiler class.
Source:
<span class="wiki-spoiler" tabindex="0">Hidden by default</span>
Rendered result:
Hidden by default
HTML disclosure panel
Source:
<details> <summary>Show the complete track list</summary> <p>This supplementary content is collapsed by default.</p></details>
Rendered result:
Show the complete track list
This supplementary content is collapsed by default.
HTML semantic elements and line breaks
Source:
<mark>Important</mark><abbr title="Virtual Witch Phenomenon">V.W.P</abbr>Press <kbd>Ctrl+K</kbd><br>H<sub>2</sub>O and x<sup>2</sup>
Rendered result:
Important, V.W.P, press Ctrl+K
H2O and x2
Raw HTML is only for static allowlisted markup. Continue to use @[provider](...) for media and {{lyrics-controls::en}} for lyric controls so site code owns all interaction behavior.
DATABASE_QUERY // EN
Search observations
Enter a keyword to search every observation on this site.