arabelatso/tlaplus-guided-code-repair
Automatically repair C/C++ code violations detected by TLA+ model checking. Takes a program, TLA+ specification, and TLC counterexample trace as input, then generates minimal code modifications to eliminate the violation. Use when: (1) TLC model checker reports an invariant violation, deadlock, or temporal property failure, (2) You have a counterexample trace and need to fix the corresponding code, (3) You need to understand how a TLA+ violation maps to program-level bugs, (4) You want to validate repairs by re-running TLC. Supports safety properties (invariants), liveness properties (temporal logic), and deadlock detection.
npx skills add https://github.com/ArabelaTso/Skills-4-SE --skill tlaplus-guided-code-repair
Automatically repair C/C++ code based on TLA+ model checking violations. This skill analyzes TLC counterexamples, identifies root causes in the implementation, and generates semantically justified repairs.
Follow this sequential process when given a TLA+ violation:
Use scripts/parse_tlc_trace.py to extract structured information from TLC output:
python scripts/parse_tlc_trace.py trace.txt
# Or for JSON output:
python scripts/parse_tlc_trace.py --json trace.txt
This extracts:
Read the reference guides to understand the violation:
references/repair_patterns.md - Common violations and repair strategiesreferences/tlaplus_to_cpp_mapping.md - How to map TLA+ to C/C++ codeKey analysis steps:
Example analysis:
Violation: Invariant BalanceNonNegative violated
Final state: balance = -50
Action: Withdraw (line 45 in spec)
Cause: withdraw() function allows amount > balance
Trace backwards from the violation to find the program-level bug:
Common root causes:
Mapping strategy:
Create a minimal, semantically justified code modification:
Repair principles:
Common repair patterns:
Pattern A: Add precondition check
// Before
void withdraw(int amount) {
balance -= amount; // Can violate balance >= 0
}
// After - enforces invariant: balance >= 0
bool withdraw(int amount) {
if (amount > balance) return false; // Guard from TLA+ spec
balance -= amount;
return true;
}
Pattern B: Add synchronization
// Before - race condition
void increment() {
counter++;
}
// After - enforces atomic action from TLA+ spec
void increment() {
std::lock_guard<std::mutex> lock(mtx);
counter++;
}
Pattern C: Fix lock ordering
// Before - potential deadlock
void transfer(Account& from, Account& to, int amount) {
std::lock_guard<std::mutex> lock1(from.mtx);
std::lock_guard<std::mutex> lock2(to.mtx);
// ...
}
// After - consistent ordering prevents deadlock
void transfer(Account& from, Account& to, int amount) {
Account* first = &from < &to ? &from : &to;
Account* second = &from < &to ? &to : &from;
std::lock_guard<std::mutex> lock1(first->mtx);
std::lock_guard<std::mutex> lock2(second->mtx);
// ...
}
Re-run TLC model checker to verify the violation is fixed:
python scripts/run_tlc.py spec.tla --config spec.cfg
Run existing tests to ensure no regressions:
# Run your test suite
make test
# or
./run_tests.sh
Validation checklist:
Provide a clear explanation of:
Example explanation:
Violation: Invariant BalanceNonNegative (balance >= 0) was violated.
Root Cause: The withdraw() function at line 45 in account.cpp did not check
if the withdrawal amount exceeds the current balance, allowing negative balances.
Repair: Added precondition check `if (amount > balance) return false;` before
the balance update. This enforces the TLA+ guard condition from the Withdraw
action in the specification.
Validation: TLC model checking now passes with no violations. All 15 existing
unit tests pass. The repair is minimal and preserves existing functionality.
When you receive:
parse_tlc_trace.py to extract violation inforepair_patterns.md section 1repair_patterns.md section 2repair_patterns.md section 3tlaplus_to_cpp_mapping.mdOutput format:
Take arabelatso/tlaplus-guided-code-repair from the repository into ~/.claude/skills for personal
use, or into .claude/skills inside a project.
The agent identifies a skill by the name field in its header. Two skills with the
same name cannot sit side by side — one of them will be ignored.