菜单
Use whenever you change any Lua module under Scripts/ee-dcs/ — the mandatory edit→build→check→inject→observe cycle for this EECH→DCS port, including the 0-warnings/no-findings gates, live re-injection, reading dcs.log, the verified-type-name DB guardrail, and the reserve-refund rule for spawner code.
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
| name | dev-loop |
| description | Use whenever you change any Lua module under Scripts/ee-dcs/ — the mandatory edit→build→check→inject→observe cycle for this EECH→DCS port, including the 0-warnings/no-findings gates, live re-injection, reading dcs.log, the verified-type-name DB guardrail, and the reserve-refund rule for spawner code. |
The one true cycle for changing this port. Every change goes through it. Do not skip build or check — they are gates, not suggestions.
Build, static analysis (check), live eval/injection (dcs_eval), and live DB queries are not
shell commands — they are tools exposed by the DCS Studio MCP server at
http://127.0.0.1:25570/mcp (registered in .mcp.json). The DCS Studio desktop app must be
running for these tools to appear in a Claude session.
dcs_eval / DB-query MCP tools are not present in your
tool list, the app is not running (or the session predates its launch).dcs-studio from the shell to get help/output — that launches the full desktop app,
it does not give you the tools.Edit the modules under Scripts/ee-dcs/. One system per module; each module header
names its EECH source file(s) — keep that header accurate (see the eech-fidelity skill).
Run the DCS Studio build tool. It transpiles/bundles the 22 modules into
dist/ee-dcs.lua.
Run the DCS Studio check (static analysis) tool over all files.
eech-fidelity — check does not normally flag those). Do not inject with findings open.The 0-warnings / no-findings discipline is absolute: both gates green after every change, no exceptions, before you inject.
With a mission running (see the live-validation skill for what that mission must be), inject via
the dcs_eval MCP tool:
net.dostring_in('server', 'dofile("C:/Users/jonat/DCSStudio/my-test-mod/dist/ee-dcs.lua")')
Re-injection is safe mid-session. campaign_state.lua bumps a global _DMT_GEN (generation
counter) on every load; every scheduled closure captures my_gen = cs.GENERATION and self-cancels
(return nil) when cs.GENERATION ~= my_gen. So a hot re-inject supersedes the old timers instead
of double-running them. Caveat: this is per-process only — a DCS_server.exe restart resets all
in-memory state to OOB (there is no persistence yet).
Mission-script logging goes through env.info() and lands in:
Saved Games/DCS/Logs/dcs.log
Read that file (or the log-reading MCP tool the DCS Studio server exposes, if present) to confirm
your change fired: init lines, scheduler ticks, reserve/strength/phase logs. What each system
should print and roughly when is the live-validation skill's observation checklist.
Before you use any new unit type name or weapon CLSID in code, query the live DCS DB through
the DCS Studio bridge/MCP and confirm the exact string. The DB is reachable even at the main menu.
Guessing a type name silently produces coalition.addGroup failures or wrong loadouts. This is how
the verified statics (.Ammunition depot, Fuel tank, Comms tower M, .Command Center) and all
pylon CLSIDs were established — follow the same path for anything new.
Every spawn passes through the finite per-side reserve (supply.consume_side on spawn,
supply.recycle_side on RTB/failure). If a spawn consumes reserve and then bails — most commonly
coalition.addGroup returning nil, or a "no friendly base" early return — you must
recycle_side the exact amount back before returning. A missed refund silently drains a pool
forever (this class of bug produced 3 HIGH findings in the Cluster A review). Audit every new
early-return and error branch in any spawner code path for the matching refund. Wrap addGroup in
pcall where a throw is possible and refund in the failure arm.
Use whenever you add or change campaign behaviour, constants, or modules in this EECH→DCS port — how to stay faithful to the EECH C source. Covers where the EECH source lives, the file:line citation rule for every constant, the one-system-per-module convention, the documented structural limits you must NOT "fix", the never-replace run_* export list, and the per-feature adversarial Agent review pattern.
Use when running end-to-end validation of the EECH campaign port in a live mission (ideally an MP dedicated server) — the current P0. Covers prerequisites (empty Caucasus mission, DCS Studio up), the inject command, a per-system observation checklist with expected env.info lines and timings, what "healthy" looks like, common failure signatures, multi-hour soak guidance, MP player-slot checks, and what cannot yet be validated.
A disciplined operating method for agents solving non-trivial tasks. Use this skill whenever a task is multi-step, ambiguous, open-ended, high-stakes, or agentic (coding, research, file manipulation, workflow automation, anything where "done" could be faked or approximated). Also use it when a task seems simple but failure would be costly, when the user's request is vague, or when the agent is about to operate autonomously for many steps without user feedback. It governs how to interpret goals, calibrate thinking vs. execution, handle ambiguity, avoid drift, and prove — not approximate — that the goal was met.
Maintain a goals backlog in the repo under goals/ where each goal has a GOAL.md definition and per-day append-only journal files, so any agent can pick up work with zero verbal handover. Use this skill whenever the user asks to define, start, resume, continue, check on, hand over, or close out a goal; whenever they mention the goals/ directory, a goals backlog, journaling work, or working towards something autonomously across sessions; and whenever you begin a work session in a repo that contains a goals/ directory — read the relevant journal before doing anything else.