القائمة
Quickly orient the user in the project workflow, identify the most likely current phase, and recommend the single best next action with concise supporting context.
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
استنادا إلى تصنيف SOC المهني
| name | studio-help |
| description | Quickly orient the user in the project workflow, identify the most likely current phase, and recommend the single best next action with concise supporting context. |
| category | studio |
| source | chronos-adapted |
| source_path | .claude/skills/help/SKILL.md |
Use this skill when the user asks what to do next, says they are stuck, or needs a lightweight workflow orientation.
This skill is read-only. It should be fast, practical, and short.
Look for any repository-level workflow definitions, progress trackers, stage files, sprint files, or active-session notes.
If a formal workflow catalog exists, use it.
If not, infer the workflow from the repository structure and existing planning artifacts.
Scan installed skill files and collect the most relevant ones for the user's likely current phase.
If some skills are not part of the primary workflow, they can still be listed as optional tools.
Limit optional suggestions to the most relevant items.
Check for a phase-tracking file first if one exists.
If not, infer the most advanced likely phase from artifacts such as:
Prefer the most advanced artifact set that is actually present.
If the repository contains an active session or progress note, read it to identify:
Use this to personalize the answer.
Determine:
If the user's message mentions that they just finished something, use that as extra evidence when the repository signals are ambiguous.
If an important step cannot be confirmed from files alone, ask the user directly instead of guessing.
Examples:
Use a compact structure like this:
## Where You Are: [Phase]
**In progress:** [recent work, if known]
### Done
- [confirmed completed step]
### Next up (required)
**[step name]** — [why it is next]
Command or workflow: `[name]`
### Also available
- [optional step] → `[name]`
### Coming up after that
- [future step]
Formatting rules:
If the project appears close to a phase transition, mention that a formal gate or readiness check is the next milestone.
Do not mention this if the project is still clearly far from a gate.
If the user sounds confused or overwhelmed, include one or two deeper follow-up options such as:
Keep this section minimal and only show it when it is genuinely useful.
Verdict: COMPLETE when the user can see exactly what to do next.
Lazy-load for LUX Unity bridge and MCP game-development operations: status, compile, tests, logs, launch, screenshots, hierarchy, dynamic code, record/replay, and one-loop MCP workflows.
Lazy-load only when this workflow is explicitly needed. Use for durable technical choices. Output a short ADR: Context, Decision, Alternatives, Consequences, Verification, Owner. Prefer existing LUX boundaries: gateway owns CLI/server, bridge owns Unity protocol, Skills owns passive workflows. Reject duplicate state, hidden fallback, and broad rewrites without evidence.
Lazy-load only when this workflow is explicitly needed. Use to review an existing design or implementation for boundary drift. Check SSoT, responsibility split, protocol consistency, atomicity, idempotency, and observable failures. Return ranked findings with file references, risk level, and the smallest corrective action.
Lazy-load only when this workflow is explicitly needed. Use when a change risks architectural drift. Enforce: .lux is SSoT; clear subsystem ownership; consistent schemas; atomic operations; idempotent retries; no silent fallback. Report violations and concrete repair steps.
Lazy-load only when this workflow is explicitly needed. Use for high-risk product, automation, or ethical decisions. Run: clarify intent; quantify evidence; check user/data/IP/fairness risks; define stop and rollback conditions; record approval. Verdicts: PASS, REVIEW, or REJECT.
Lazy-load only when this workflow is explicitly needed. Use to turn observed failures into actionable reports. Capture summary, environment, exact steps, expected result, actual result, logs, suspected subsystem, severity, reproducibility, and minimal next diagnostic. Do not invent fallback data.