dingxingdi Skill: state-verified-task-completion
1. Capability Definition & Real Case
- Professional Definition: The capability to complete GUI tasks in a way that produces a durable, verifiable change in the underlying application or system state, rather than only transient visual evidence. The agent must perform actions that survive beyond the immediate screen and can be checked via persistent state or reliable internal execution signals.
- Dimension Hierarchy: Goal-Directed GUI Workflow Execution->Verified Task Completion->state-verified-task-completion
Real Case
[Case 1]
- Initial Environment: A mobile calendar application is open on a device where the benchmark can inspect the app’s stored event records after execution. The task parameters specify a date, time, title, description, and duration that must be committed to the underlying calendar state.
- Real Question: In Simple Calendar Pro, create a calendar event on 2014-03-16 at 14h with the title 'Project Review' and the description 'Bring the quarterly report'. The event should last for 45 mins.
- Real Trajectory: Open the event-creation flow, fill the date, time, title, description, and duration fields, save the entry, and verify that the event exists in the app state rather than relying only on the post-save screen.
- Real Answer: A calendar event with the specified fields exists in the calendar state.
- Why this demonstrates the capability: A transient success toast or a partially filled form is not enough here, because the benchmark checks whether the event was actually created. The agent must carry the interaction through to a committed state change that survives inspection. That is exactly what durable, state-verified completion measures.
[Case 2]
- Initial Environment: A desktop code editor is open on a project containing a function named
functionA. The benchmark environment can internally observe debugging events and inspect in-memory execution data at the exact moment a breakpoint is hit. - Real Question: Debug in VSCode by setting a breakpoint in
functionA. - Real Trajectory: Open the relevant source file, place a breakpoint on the intended line, launch the program in debug mode, wait for execution to reach the breakpoint, and confirm success from the actual breakpoint event and associated runtime state rather than from a guessed screenshot.
- Real Answer: The program halts at the breakpoint in
functionA, and the debugger’s internal event confirms the hit. - Why this demonstrates the capability: The visible editor alone cannot guarantee that the breakpoint actually fired at runtime. The true success condition is an internal execution event coupled with the correct paused state, which makes this case an example of state-grounded completion rather than superficial UI matching. It tests whether the agent produces a real backend-consistent result.
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:
Phase 1: Environment Exploration Read the exploration guidelines to discover raw knowledge seeds:
references/EXPLORATION.mdPhase 2: Trajectory Selection Once Phase 1 is complete, read the selection criteria to evaluate the trajectory:
references/SELECTION.mdPhase 3: Data Synthesis Once a trajectory passes Phase 2, read the synthesis instructions to generate the final data:
references/SYNTHESIS.md