Engineering Loop
Own the change from a verified starting point to a reviewed result. Use one
agent and this skill alone unless a specialist changes a material decision.
Establish the baseline
- Read applicable
AGENTS.md files and repository documentation.
- Record the requested behavior, constraints, and observable done conditions.
- Inspect the branch and working tree; preserve unrelated user-owned changes.
- Identify repository-native validation and run the smallest safe baseline
that separates pre-existing failures from task regressions.
For a long, cross-stack, or high-risk change, use the templates and failure
rules in references/loop-contract.md.
When a defect is intermittent, performance-related, difficult to reproduce, or
resists the first evidence-driven pass, use
references/hard-debugging.md.
Run the loop
- Reproduce the defect, or capture the current behavior for a feature.
- Choose the smallest coherent change and the evidence that will prove it.
- Add a failing regression test first when practical.
- Implement one bounded change and run the narrowest relevant check.
- Classify failures as product, test, environment, or assumption failures;
fix the cause and rerun the affected check.
- Run repository-required broader checks after focused checks pass.
- Inspect the complete diff and perform a fresh findings-first review.
- Fix consequential findings and rerun checks affected by those fixes.
Keep a compact ledger of confirmed facts, changed files, commands, outcomes,
and the next decision. Return concise diagnostics instead of full logs.
Stop conditions
- If the same command fails twice for the same reason, stop retrying and
re-check the environment, target, permissions, and underlying assumption.
- Stop and report a blocker when progress requires missing authority, secrets,
unavailable infrastructure, destructive action, or a product decision.
- Never make a failing check pass by weakening assertions, deleting coverage,
hiding errors, or silently changing acceptance criteria.
- Do not query production, deploy, migrate, merge, or publish unless the user
explicitly authorizes that action.
Finish with evidence
Report:
- behavior implemented or defect fixed;
- changed files and important design decisions;
- regression proof or acceptance evidence;
- focused and broader commands with outcomes;
- review findings fixed or explicitly unresolved;
- unrun checks, residual risks, and blockers.
1---2name: engineering-loop3description: Drive an authorized repository change through a verified local loop: baseline, reproduce, implement, test, review, and report evidence. Use for end-to-end features or fixes that should continue autonomously until observable acceptance criteria pass; do not use for explanation-only, review-only, or production operations.4---5
6# Engineering Loop
7
8Own the change from a verified starting point to a reviewed result. Use one
9agent and this skill alone unless a specialist changes a material decision.
10
11## Establish the baseline
12
131. Read applicable `AGENTS.md` files and repository documentation.
142. Record the requested behavior, constraints, and observable done conditions.
153. Inspect the branch and working tree; preserve unrelated user-owned changes.
164. Identify repository-native validation and run the smallest safe baseline
17 that separates pre-existing failures from task regressions.
18
19For a long, cross-stack, or high-risk change, use the templates and failure
20rules in [references/loop-contract.md](references/loop-contract.md).
21When a defect is intermittent, performance-related, difficult to reproduce, or
22resists the first evidence-driven pass, use
23[references/hard-debugging.md](references/hard-debugging.md).
24
25## Run the loop
26
271. Reproduce the defect, or capture the current behavior for a feature.
282. Choose the smallest coherent change and the evidence that will prove it.
293. Add a failing regression test first when practical.
304. Implement one bounded change and run the narrowest relevant check.
315. Classify failures as product, test, environment, or assumption failures;
32 fix the cause and rerun the affected check.
336. Run repository-required broader checks after focused checks pass.
347. Inspect the complete diff and perform a fresh findings-first review.
358. Fix consequential findings and rerun checks affected by those fixes.
36
37Keep a compact ledger of confirmed facts, changed files, commands, outcomes,
38and the next decision. Return concise diagnostics instead of full logs.
39
40## Stop conditions
41
42- If the same command fails twice for the same reason, stop retrying and
43 re-check the environment, target, permissions, and underlying assumption.
44- Stop and report a blocker when progress requires missing authority, secrets,
45 unavailable infrastructure, destructive action, or a product decision.
46- Never make a failing check pass by weakening assertions, deleting coverage,
47 hiding errors, or silently changing acceptance criteria.
48- Do not query production, deploy, migrate, merge, or publish unless the user
49 explicitly authorizes that action.
50
51## Finish with evidence
52
53Report:
54
551. behavior implemented or defect fixed;
562. changed files and important design decisions;
573. regression proof or acceptance evidence;
584. focused and broader commands with outcomes;
595. review findings fixed or explicitly unresolved;
606. unrun checks, residual risks, and blockers.
aiskillstore