Run any Skill in Manus with one click

dev-loop

Stars0

Forks0

UpdatedJuly 11, 2026 at 10:37

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.

Installation

Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.

Run Skill in Manus

Source

flying-dice

flying-dice/ee-dcs

View GitHub Repository View Creator Repositories

Download

Run Skill in Manus

Related occupationsSOC

Based on SOC occupation classification

Software DevelopersComputer and Mathematical Occupations·SOC 15-1252

SKILL.md

readonly

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.

Dev loop: edit → build → check → inject → observe

The one true cycle for changing this port. Every change goes through it. Do not skip build or check — they are gates, not suggestions.

0. Prerequisite: DCS Studio must be running

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.

Detect absence: if the build / check / dcs_eval / DB-query MCP tools are not present in your tool list, the app is not running (or the session predates its launch).
What to tell the user: "Start the DCS Studio desktop app, then restart or reconnect this Claude session so the MCP tools register." Do not try to fake it.
Never run dcs-studio from the shell to get help/output — that launches the full desktop app, it does not give you the tools.

1. Edit

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).

2. Build (mandatory gate)

Run the DCS Studio build tool. It transpiles/bundles the 22 modules into dist/ee-dcs.lua.

Healthy output: 22 modules, 0 warnings.
Any warning is a stop-the-line failure. Fix it before proceeding — do not inject a warning build.

3. Check (mandatory gate)

Run the DCS Studio check (static analysis) tool over all files.

Healthy output: all files scanned, NO findings.
Any finding is a stop-the-line failure. Fix it (or, if it is a documented deliberate proxy, that belongs in 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.

4. Inject into the live mission

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).

5. Observe (dcs.log)

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.

Guardrails baked into this loop

Verified type names only — query the live DB, never guess

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.

Spawners must refund the reserve pool on every failure branch

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.

More from this repository

same repository

eech-fidelity

flying-dice/ee-dcs

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.

2026-07-110

live-validation

flying-dice/ee-dcs

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.

2026-07-110

fable-method

flying-dice/ee-dcs

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.

2026-07-110

goal-backlog

flying-dice/ee-dcs

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.

2026-07-110

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.

Dev loop: edit → build → check → inject → observe

The one true cycle for changing this port. Every change goes through it. Do not skip build or check — they are gates, not suggestions.

0. Prerequisite: DCS Studio must be running

Detect absence: if the build / check / dcs_eval / DB-query MCP tools are not present in your tool list, the app is not running (or the session predates its launch).
What to tell the user: "Start the DCS Studio desktop app, then restart or reconnect this Claude session so the MCP tools register." Do not try to fake it.
Never run dcs-studio from the shell to get help/output — that launches the full desktop app, it does not give you the tools.

1. Edit

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).

2. Build (mandatory gate)

Run the DCS Studio build tool. It transpiles/bundles the 22 modules into dist/ee-dcs.lua.

Healthy output: 22 modules, 0 warnings.
Any warning is a stop-the-line failure. Fix it before proceeding — do not inject a warning build.

3. Check (mandatory gate)

Run the DCS Studio check (static analysis) tool over all files.

Healthy output: all files scanned, NO findings.
Any finding is a stop-the-line failure. Fix it (or, if it is a documented deliberate proxy, that belongs in 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.

4. Inject into the live mission

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")')

5. Observe (dcs.log)

Mission-script logging goes through env.info() and lands in:

Saved Games/DCS/Logs/dcs.log