# Cige Stale Execution Repair

> Use when cige-failure-classification identifies Outdated Test Logic (repair Execution steps, Mode A) or a confirmed False Positive (add a stricter Guardrail, Mode B). Human approval required before committing either kind of repair.

- Skill: `vivekkrishna/cige-stale-execution-repair` (Agent Skill)
- Install (CLI): `npx skillmds@latest add vivekkrishna/cige-stale-execution-repair`
- Raw SKILL.md: https://api.skillmd.com/api/skills/vivekkrishna/cige-stale-execution-repair/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: vivekkrishna (https://skillmd.com/u/vivekkrishna)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/vivekkrishna/cige-stale-execution-repair

---


# CIGE: StaleExecutionAgent

Invoked by `cige-failure-classification` in two situations: **Outdated Test Logic** (Mode A — repair `Execution[]`) and a confirmed **False Positive** (Mode B — strengthen `Guardrails`). These are different repairs with different targets; do not conflate them.

## When to invoke

- **Mode A**: Execution steps fail mid-flow (element not found, endpoint 404, workflow step no longer exists), and `specRef` confirms the intended outcome is still a valid product requirement.
- **Mode B**: A run reported pass, but `cige-failure-classification` confirmed it was a false positive — the evidence backing the pass was weak or gameable, not that the steps were wrong.

If neither condition is confirmed, do not use this skill.

---

## Mode A — Repair Execution

1. Read `Intent` (the goal to preserve) and `Guardrails` (constraints that apply during repair).
2. Fetch `specRef` to confirm the intended outcome is still a stated product requirement.
3. Inspect the current system state (live UI, API schema, current workflow) to understand what changed.
4. Propose new `Execution[]` steps that achieve `Intent` within `Guardrails`.
5. Dry-run the proposed steps to verify `Intent` can still be confirmed.
6. Surface the proposed diff to a human for approval — **do not commit without sign-off**.

**Escalation rule:** If no execution path can confirm `Intent` within the existing `Guardrails`, stop — this may be a misclassified Product Defect. Escalate to `cige-product-defect-escalation` rather than forcing a repair that technically passes.

## Mode B — Strengthen Guardrails (the narrow exception)

A false positive means the steps "worked," but the pass shouldn't have counted — the test's evidence bar was too weak to catch an invalid end-state (e.g. it accepted UI success text without checking the backend record it implies). The fix targets `Guardrails`, not `Execution`.

1. Read the false-positive report from `cige-failure-classification`: what state was accepted as a pass, and why it shouldn't have been.
2. Propose an **additive** guardrail or evidence rule that would have caught this specific gap (e.g. "require backend order-service confirmation, not UI text alone").
3. **Never** remove, weaken, or relax an existing guardrail as part of this repair — this mode only adds constraints, it never loosens them.
4. Replay the test with the proposed guardrail in an isolated environment to confirm it still allows the true-positive path to pass and correctly blocks the false-positive path.
5. Surface the proposed diff (old Guardrails, new Guardrails, the false positive it addresses) to a human for approval — **do not commit without sign-off**.

## Field permissions

| Field | Permission |
|---|---|
| `Context` | Never touch |
| `Intent` | Never touch |
| `Guardrails` | **Write** — Mode B only, additive/strengthening only, never loosen or remove, human approval required |
| `Execution[]` | **Write** — Mode A only, human approval required |

This is the only skill in the CIGE self-healing set permitted to write to `Guardrails`, and even here the write is one-directional (stricter only) and always human-gated. If a proposed change would remove or weaken any existing guardrail, that is out of scope for this skill — halt and escalate for human review instead of applying it.

## Human gate

Required before committing either an updated `Execution[]` (Mode A) or a strengthened `Guardrails` entry (Mode B). This skill proposes; a human approves. This is what prevents silent intent drift disguised as execution repair, and what prevents guardrail creep disguised as test-quality improvement.