Actions & checks
Actions are discrete tasks within a focus area. Checks are verification steps that confirm a focus area's results have been met.
Actions and checks are the fine-grained layer within a focus area. They don't replace the four-part spec — they live inside it, as a way to track execution and verification at a level of detail the spec doesn't carry.
Actions
An action is a discrete task that needs to happen to help implement a focus area. Actions are always created during the planning phase as the coding agent and team members identify the specific work.
Actions are lightweight: a title, a description, and a status (open / in progress / done).
An action is the granular implementation detail of a focus area. There will likely be several actions (tasks) associated with a focus area, and all must be implemented and verified as successful in order for the parent focus area to be considered complete.
Who creates actions
Actions can be created by team members or by your coding agent. When an agent encounters a focus area, it will often decompose it into a set of actions as it works. These are visible in Penling so the team can see what the agent is doing.
As a human reviewer of the plan you can add additional actions at any time to account for work the planning agent missed, didn't consider or ignored. Remember it's your plan, the agent is there for guidance only.
Checks (Acceptance Criteria)
A check is a verification step that confirms whether an action has been implemented correctly. Your coding agent (LLM) will be instructed by Penling to implement tests of it work and validate that the acceptance criteria has been met. The action cannot be marked as complete until it does.
When all checks for an action are passing, the action can be marked done. This creates a clear, auditable path from the spec (what "done" means) to the verification (proof that it's met).
Automated checks
Because Penling requires LLM code to be verified, and report that the verification was successful to Penling we create an auditable round-trip between the specification that was originally created, the plan that was genrated, the work that was done and the output that will result in a successful Pull Request merge to your repository.
Actions vs checks
| Actions | Checks | |
|---|---|---|
| Purpose | Track tasks | Verify results |
| Created by | Team or agent | Team or spec |
| Linked to | Focus area | Specific result statement |
| Done when | Completed | Passing |