Design Control Loop

Design a control loop

Treat the request text that activated this skill as the desired outcome. Read grilling for the shared questioning method and native planning boundaries. Use its settled answers and open questions to design this contract; do not restart the interview. Ground options in inspected commands, patterns, CI, and permissions. In native Plan, use permitted reading/search and keep the contract in conversation; defer shell, MCP, writes, prototypes, and validation. Apply the shared approved-plan capture checkpoint when writes become permitted.

Required control vocabulary

Use these definitions in the contract; they are included here so native skill loading supplies the complete method. references/taxonomy.md is a separate copy for reference.

• Set point: the invariant, threshold, or direction to maintain.
• Sensor: a repeatable measurement of the repository and its gap from the set point.
• Controller: the rule choosing what to do now and what to defer.
• Actuator: Kiro plus a skill applying one bounded change.
• Disturbance: an external change such as upstream drift or concurrent development.
• Dampener: an independent gate that prevents regression or stale proof.
• Feedback: durable human steering that changes future selection or behavior.
• Flow control: attempt, batch, time, and open-candidate bounds.

Components may be fused. Each must remain locally runnable, observable, and replaceable.

This method defines reusable automation. For completing the current task, use pkstack-verified-goal. Use architect for an unresolved component boundary or arena for a distinct contested artifact, passing the agreed control contract forward. Do not repeat a completed alternatives comparison. Keep any native Kiro Spec as the planning authority.

Design phases

1. Define a measurable set point and the directories the loop may write or only inspect.
2. Choose a repeatable local sensor and describe its false-positive, cost, and disablement risks.
3. Define a controller that selects the next small, reviewable increment. Start deterministic when the measurement already supplies enough structure.
4. Choose a Kiro actuator and repo-local skill. Establish golden patterns and exact validation.
5. Name disturbances and add a dampener when it can prevent regression or stale proof.
6. Define terminal states, attempt and work-in-progress bounds, and durable human feedback. Name who enforces the attempt count before actuation and how separately invoked commands or promised restarts retain it. Invalid input is a failure even when nothing is eligible. Bind each increment to its pre-actuation selection and baseline; distinguish a verified increment from the global set point, which may require further increments.
7. Specify how sensor, controller, and actuator will run and be proved independently locally before adding CI; a design-only request does not run or build them.
8. Record the agreed contract in conversation or an authorized native design artifact, then implement only if the user requested implementation and execution is permitted.

Do not manufacture separate components where they are genuinely fused. Do not introduce external model API keys, broad write access, floating dependencies, or an unbounded PR/comment loop. When implementation is requested, pass the agreed contract to build-iterated-agentic-loop, including when GitHub Actions is selected. A design request does not authorize wiring or enabling automation.

Completion criterion: the design identifies every authority, transition, proof, failure state, and local command well enough to test the loop without CI.

Label proposed commands and hypothetical transitions as unexecuted. Call a result observed only when an actual run supplies evidence; a worked example is not a run.