// Create or refresh a corp-web-japan GitHub wiki migration-plan dashboard that shows what is already local, what still depends on querypie.com/ja, and what should be migrated next in priority order.
[HINT] Download the complete skill directory including SKILL.md and all related files
| name | corp-web-japan-website-migration-plan-wiki |
| description | Create or refresh a corp-web-japan GitHub wiki migration-plan dashboard that shows what is already local, what still depends on querypie.com/ja, and what should be migrated next in priority order. |
| version | 1.0.0 |
| author | Hermes Agent |
| license | MIT |
| metadata | {"hermes":{"tags":["corp-web-japan","wiki","migration","dashboard","replacement-readiness"],"related_skills":["github-wiki-editing","github-wiki-update-from-main"]}} |
Use this when the user asks for a GitHub wiki page that explains how far corp-web-japan has progressed toward replacing https://www.querypie.com/ja, especially as a readable migration dashboard rather than a prose-only plan.
Produce a wiki page that answers, at a glance:
corp-web-japanquerypie.com/jaThe most useful output is a replacement-readiness dashboard, not a generic architecture memo.
For this repo, the most important distinction is usually not just content existence but public-entrypoint ownership.
A family may have:
/t/* list/page implementations already availablequerypie.com/jaIn that case, treat the family as only partially migrated and usually prioritize it highly.
In the product repo:
pwd
git rev-parse --show-toplevel
git branch --show-current
git remote -v
git fetch origin --prune
If the user specifies a historical baseline date such as "latest main on 2026-05-05", do not document current origin/main blindly.
Resolve the exact commit first:
git rev-list -n 1 --before='2026-05-05 23:59:59' origin/main
Record that SHA in the wiki page.
If the user truly wants the current latest main, then use origin/main after fetch.
If the user/repo setup already has a stable local wiki clone such as ../corp-web-japan.wiki, prefer reusing it.
A clean pattern is:
This avoids mixing wiki edits into an existing local wiki checkout while still respecting the user's established local clone.
Use these files as the main sources of truth:
README.mdsrc/app/**src/app/sitemap.tssrc/lib/publications/**Sitemap.md, Blog.md, WhitePapers.md, Events.md only as supporting referencesFor this task, classify routes into four buckets:
/t/* entrypointsThis classification is usually more valuable than a flat route list.
Useful counts to collect:
/t/* entrypointsUseful family roots include:
src/content/blogsrc/content/whitepaperssrc/content/newssrc/content/use-casessrc/content/demo/aipsrc/content/demo/acpsrc/content/eventssrc/content/documentation/manualssrc/content/documentation/introduction-decksrc/content/documentation/glossaryIf the baseline is a historical main snapshot, count from that exact git revision rather than the live working tree. A reliable pattern is either:
git ls-tree -r --name-only <sha> <path>
git show <sha>:path/to/file
or archive that commit to a temp directory and inspect the extracted snapshot.
Use these audit rules consistently:
/blog, /whitepapers, /news, /contact-us, /, /solutions/ai-crew, and /solutions/ai-dashi can count as public-local when implemented as actual pages on the baseline snapshot./demo/use-cases, /demo/aip, /demo/acp should be treated as partial if the public routes still redirect even when local detail routes already exist./events should be treated as partial if the page exists but is launch-gated or returns notFound() without an unblock condition./about-us, /certifications, /services/*, and resource hubs like /resources, /manuals, /glossary, /introduction-deck should be treated as partial when public routes still redirect but /t/* preview pages exist./cookie-preference, /terms-of-service, /privacy-policy, and /eula should usually be shown as redirect-only / scope-decision items unless local pages have actually been implemented.redirectUrl, label that family as partially local or mixed, not fully local.A clear migration dashboard page usually works best with this structure:
Recommended dashboard columns:
Use:
P0 = replacement blockers at the public-entrypoint layerP1 = deepen local ownership inside already-local familiesP2 = optional or explicit-scope decisionsTypical P0 candidates:
Typical P1 candidates:
Typical P2 candidates:
If the user asks for "May 5 latest main" or a similar date-specific snapshot, the correct basis is not today's origin/main.
Resolve the historical main commit with git rev-list --before and use that SHA consistently in both counts and conclusions.
When a stable local wiki clone already exists, a wiki worktree is a good compromise between a fresh temp clone and editing the base wiki checkout directly. It keeps the edit isolated, makes review/diff clearer, and still lets you fast-forward the main local wiki clone before pushing.
The most useful conclusion for corp-web-japan replacement audits is usually:
Spell this out clearly instead of only listing migrated MDX counts.
Do not frame hidden redirect records or shadow records as cleanup candidates by default. In this repo, they often exist intentionally to preserve legacy entrypoints, avoid 404s, and route old links toward the correct current canonical content.
Important audit rule:
When documenting migration status, describe these records as legacy-preservation or canonicalization support, not as blockers or cleanup debt unless you have concrete evidence.
Useful wording patterns:
Before finalizing summary counts like preview entrypoints, verify them from actual route files.
It is easy to overcount /t/* surfaces by memory.
Use a small script or exact file listing and correct the page before publish if needed.
When the user explicitly says one wiki language page is the latest source of truth (for example Website-Migration-Plan-ko) and asks you to update sibling pages from it, do not re-derive JA/EN content from origin/main unless the user also asks for a fresh audit.
Preferred approach:
origin/main has advanced since that page was writtenWhy this matters:
origin/main, JA/EN can diverge from KO again instead of being synchronizedWhen classifying public redirect-backed entrypoints on latest main, do not check only for page.tsx.
In corp-web-japan, many redirect-backed public entrypoints are implemented as route.ts redirect handlers instead of pages.
For migration dashboards, audit each candidate route directory for at least:
page.tsxroute.tsThis matters especially for:
/services/*/demo/* list entrypoints/resources, /glossary, /manuals, /introduction-deck/about-us, /certifications/privacy-policyIf you check only for page.tsx, you can incorrectly report zero redirect-backed public entrypoints even though the redirect routes are present on latest main.
For resource preview/publication migration summaries in corp-web-japan, do not assume the local content roots are already flattened to top-level src/content/<family> paths.
On the current mainline snapshot, introduction deck / glossary / manuals content may still live under:
src/content/documentation/introduction-decksrc/content/documentation/glossarysrc/content/documentation/manualsAudit the actual latest-main tree before writing corpus counts or source-root notes into the wiki page.
redirectUrl