|
| 1 | +### Maintenance checks for Learning Paths and Install Guides |
| 2 | + |
| 3 | +Please review the content in the specified content path and support my manual review by: |
| 4 | + |
| 5 | +1. **Summarizing what this guide does** |
| 6 | + - What the end goal is |
| 7 | + - What platform(s) and environments it targets |
| 8 | + - Any key assumptions the reader must meet |
| 9 | + |
| 10 | +2. **Identifying dependencies and moving parts** |
| 11 | + - OS, architecture, toolchains, frameworks, SDKs |
| 12 | + - External repositories, models, downloads, or services |
| 13 | + - Commands or workflows that are central to the guide |
| 14 | + |
| 15 | +3. **Flagging potential risk areas** |
| 16 | + - References to old OS versions, runtimes, or toolchains |
| 17 | + - Dependencies that may be stale, deprecated, or fragile |
| 18 | + - Links or resources that might require checking |
| 19 | + - Steps that rely heavily on UI flows or screenshots |
| 20 | + |
| 21 | +4. **Calling out anything that may need a closer human look** |
| 22 | + - Ambiguous or unclear instructions |
| 23 | + - Areas where “latest” or unpinned versions are used |
| 24 | + - Places where ecosystem changes could affect correctness |
| 25 | + |
| 26 | +--- |
| 27 | + |
| 28 | +### How to behave |
| 29 | + |
| 30 | +- Be conservative and transparent — if something is uncertain, say so. |
| 31 | +- Prefer **flagging** over **fixing**. |
| 32 | +- Do not invent new commands, tools, or workflows. |
| 33 | +- If suggesting changes, keep them minimal and clearly optional. |
| 34 | +- Treat this as a *conversation starter* for the reviewer, not a final verdict. |
| 35 | + |
| 36 | +--- |
| 37 | + |
| 38 | +### Output format (keep it lightweight) |
| 39 | + |
| 40 | +Please respond with: |
| 41 | +- A short summary of the guide |
| 42 | +- A bulleted list of dependencies |
| 43 | +- A bulleted list of review flags or questions to consider |
| 44 | + |
| 45 | +No code changes are required unless I explicitly ask for them. |
0 commit comments