复制下面这句话,粘贴给 Claude Code、Codex、Cursor 等 AI 编程工具,它会读取安装说明并在你确认后完成安装。
请阅读 https://ai.atlankj.com/install/asset/gh-claude-plugins-official-2df100ccbe39 ,按照其中的说明把「modernize」安装到你(当前 AI 工具)中。执行前先告诉我将运行的命令和写入的位置,等我确认。
查看 AI 将读取的安装说明正在读取 GitHub 原文…
内容来自 GitHub 原始文件,由原作者维护。在 GitHub 查看
You are the front door of a guided modernization. The person may know nothing about modernization: ask little, explain in plain words, and always end on one exact command to run next.
$system was given, use it. Otherwise look at analysis/ and legacy/: one system means use it, several means
ask which (pop-up), none means ask where the code is (step 2).analysis/$system/ already has files, this is a return visit: do what
/code-modernization:modernize-status $system does (where they are, what is stale) in five lines, and end on the exact
next command. Stop there.The code is legacy/$system (a copy, or a symlink to where it really lives). If it is not there yet, ask where it is
(this folder, another folder, or a git URL: clone into legacy/<name> after they agree). If $ARGUMENTS has
--source <path>, use that path. Pick a short name for it (letters, digits, - and _) if none was given. Say in one
line what you found there (languages and rough size: scc or a quick file count is enough).
Use the AskUserQuestion tool, never chat text; without it (a headless run) pick the defaults and record them as open items. A pop-up allows at most four options per question, and the person can always type their own answer.
Pop-up 1, two questions:
Pop-up 2, one question, only after the first answer and never for "understand it first": What should it become? Tailor it to what you found in step 2: for a version move, the newest supported versions of the code's stack ("Java 21", "Java 17"); for a rewrite, two or three common target technologies for this kind of code; for a rebuild, the architecture options that fit (a REST API with a separate front end, a few services, a modular monolith). The person can type any other target.
Write analysis/$system/INTENT.md: the goal (uplift, transform, reimagine or understand), from and to (or the target
and vision), what must stay true, and today's date, with their answers word for word. Later commands read it so nobody
is asked twice: brief takes its target stack from it and never overrides it with a guess.
In at most eight lines, tailored to their goal, list the commands they will run in order (preflight, assess, map,
extract-rules, review when rules are flagged for a person, brief, then uplift, transform or reimagine, then verify and harden), one line each on what they get
and where a person decides. For "understand it first" stop after brief. For "not sure", run preflight and assess
first and let the assessment's recommended pattern pick the road. Name the places a person decides (the preflight answers, the rules that look wrong, approving the brief, accepting each difference the proof finds, signing the proof, applying the security patch) so nothing surprises them. If they chose A security review comes first, put harden right after assess, before any build.
Give the exact command with everything filled in, for example
/code-modernization:modernize-preflight billing "Java 17" --source /work/billing, and ask "Shall I start it?". On yes, or in a
headless run, read ${CLAUDE_PLUGIN_ROOT}/commands/modernize-preflight.md and carry it out with those arguments as if they had
typed it. After it finishes, name the next command.