When to fall to disk
- A round of platform initializationhas all been completed and the verification ladder has passedafterward (usually handed off here from accel-init stage 5).
- After-the-fact additions/revisions: when a rule is overturned by new facts, a version line is outdated, or a new fork compatibility conclusion is added.
- Do not prewrite when the solution has not yet been proven to work—only allowverifiedcontent; mark unverified content as
(未验证)or do not write it.
Slots and naming (skill names never change)
| Slot | skill name (fixed) | What to put in | Where it goes |
|---|---|---|---|
| System layer | accel-platform-install |
Driver/SDK/toolchain installation: compatibility set, user-space layout, download signature verification, verification ladder | Repository distribution + local rewrites |
| Python layer | accel-pytorch-python |
Dual-source discipline, version matching matrix, environment variables, installation flow, verification, common failures | Same as above |
| Code layer | accel-pytorch-code-porting |
API mapping table, device probing, AMP, distributed, third-party package compatibility, migration checklist | Same as above |
| Host layer | <host>-environment(local naming) |
Local conda/uv paths, hardware table, storage volumes, caches, factual records of installed stacks | Keep local only, never flow back |
Platform names (musa/cuda/cann/rocm) appear only in the trio'scontent; skill names and trigger words are always platform-independent. Each item in the trio has a "how to specialize" rewrite guide at the top—during initializationrewrite the body in place, do not create a new platform-name skill, and do not change the distributed version name.
Rewrite rules
- Two-layer fill-in: the trio body is filled with platform-common values (version lines/commands/pitfalls), and the artifact flows back to the repository to become the new distributed version—no unique local copy is kept; local values (paths/hostnames) go only into the host layer.
- Rewrite section by section according to each item's header guide; delete whole sections that are meaningless for this platform, do not leave empty headings.
- For the version matching matrix, write "the current line found + the query command", with source link and date; do not hardcode conclusions that will expire without giving a requery command.
- In the verification section, paste real commands and key output lines (with PIDs/job names/private data removed), and state clearly "expected no output/expected a certain line to appear".
- Failure modes include only those actually encountered, each with symptom→cause→resolution.
- description is platform-independent and rich in trigger words; the division of labor with adjacent skills is written clearly.
Repository flow-back process
- Use
platform-environment-skill-auditto audit the trio: username/path/IP/credential/verification artifact leakage, and the overreach of "treating local as common". - After correction, push
brilliantrough/agent-skills(old platform instances go into git history, not coexist). - New machines get the latest distributed version through the setup script;machines already installed do not chase the new version(installed only once); an explicit refresh is a manual action.
- Even if the host layer passes the audit, itdoes not flow back—its value is precisely that it is bound to the local machine.
Template files
- templates/host-environment.md: host-layer skeleton (hardware table / storage volume expansion / multi-Python environment anti-confusion / cache / installed platform stack factbook), reference examples: local-python-environment on the server, system-profile on the Ascend machine.