autonomous-multi-action-software-engineering-orchestration

# Skill: autonomous-multi-action-software-engineering-orchestration ## 1. Capability Definition & Real Case * **Professional Definition**: The ability to autonomously orchestrate diverse engineering work units into a dynamic, goal-oriented workflow across highly divergent paradigms (e.g., Finite Element Method simulations, partial-observable World Model synthesis, Hardware RTL, Formal Verification, Social Robotics). This involves parsing highly specialized domain rules or framework API documents, decomposing tasks into specialized components, executing in domain-specific simulation engines (e.g., MOOSE, CocoTB, Theorem Provers), and iteratively refining implementations via residual logs or state observation checks. * **Dimension Hierarchy**: Repository Maintenance and Repair->Complex Software Feature Engineering->autonomous-multi-action-software-engineering-orchestration ### Real Case **[Case 1]** * **Initial Environment**: A cloud-based engineering environment with a MOOSE multiphysics solver binary, a target 16-sided prismatic fuel assembly mesh file (assembly.e), and a knowledge base of simulation components. * **Real Question**: Solve for the thermal and mechanical performance of the prismatic fuel element. Set the heat flux on the inner boundary to 5e5 W/m^2, and fix the displacement at the bottom nodeset. * **Real Trajectory**: The agent searches the knowledge base to identify requisite HeatConduction and SolidMechanics kernels. It drafts the MOOSE input card (.i file), explicitly mapping the [Mesh] boundaries to Dirichlet/Neumann conditions. Execution yields a parameter syntax error; the agent consults documentation, surgical edits the block, and re-executes. It verifies physical correctness by monitoring the L2-norm residual decay in the terminal logs. * **Real Answer**: An iteratively verified multiphysics MOOSE input file that successfully models thermal expansion without solver or convergence errors. * **Why this demonstrates the capability**: Shows translation of high-level physics requirements into specialized Domain Specific Language (DSL) execution logic, utilizing a solver's residual feedback to iteratively resolve nonlinear convergence states. --- **[Case 2]** * **Initial Environment**: A hardware repository containing a skeleton 'sorting_engine.v' (Verilog) and a CocoTB-based Python simulation harness. The target is cycle-accurate Register-Transfer Level (RTL) code. * **Real Question**: Implement a sequential brick sort module in Verilog that handles N 8-bit elements. The system must meet strict cycle latency constraints. * **Real Trajectory**: The agent inspects port constraints and implements a Finite State Machine (FSM) utilizing non-blocking datapath assignments. It executes the CocoTB testbench and encounters a 'Timing Violation' log. Identifying a critical path in the swap logic, it updates the clock-edge registers and re-runs the simulation, validating the logic against the functional golden model. * **Real Answer**: A functional, synthesized Verilog module where the FSM correctly manages data phases within cycle-accurate precision, natively verified by the hardware simulator. * **Why this demonstrates the capability**: Illustrates domain-specific orchestration where the agent must adapt to low-level hardware constraints and iteratively debug based on timing verification traces. --- **[Case 3]** * **Initial Environment**: A repository with rules defining an incomplete-information card game, alongside empirical trajectory logs displaying player 'action-observation' pairs. * **Real Question**: Develop a grounded executable world model (Python simulator) for this game that encapsulates transition dynamics and includes an inference function mapping observed state sequences to hidden representations. * **Real Trajectory**: The agent analyzes the text rules to formulate transition logic and cross-references trajectory variables to ensure state fidelity. It implements a stochastic inference function, then utilizes an inference-to-observation replicator check, determining if its inferred hidden deck state actually produces the observation found in the log. It iterates until the simulation models match empirical logs perfectly. * **Real Answer**: An integrated simulation engine containing both environment transition rules and a latent state inference sampler aligned perfectly with trajectory records. * **Why this demonstrates the capability**: Tests the ability to synthesize executable 'world models' bridging English rule-sets and empirical trace data, requiring heavy constraint alignment and domain feature abstraction. ## Pipeline Execution Instructions To synthesize data for this capability, you must strictly follow a 3-phase pipeline. **Do not hallucinate steps.** Read the corresponding reference file for each phase sequentially: 1. **Phase 1: Environment Exploration** Read the exploration guidelines to discover raw knowledge seeds: `references/EXPLORATION.md` 2. **Phase 2: Trajectory Selection** Once Phase 1 is complete, read the selection criteria to evaluate the trajectory: `references/SELECTION.md` 3. **Phase 3: Data Synthesis** Once a trajectory passes Phase 2, read the synthesis instructions to generate the final data: `references/SYNTHESIS.md`