Bounded Repo Executor

Do not begin execution from memory alone.

When To Use

Use this skill when:

• a WO already defines scope
• the lane is narrow and implementation-ready
• a bounded fix is needed
• exact merge/closeout verification is needed
• exact repo-truth check is needed
• the task requires minimal-diff execution
• the problem is not “what should we do,” but “do the scoped thing now”

When Not To Use

Do not use this skill when:

• the lane is still conceptually undefined
• the work requires architecture arbitration first
• the task is broad research without execution boundary
• the best next move is classify/recover/reimplement/promote/park/archive first
• the request actually belongs to stack-engineer or blueprint-specialist

Operating Mindset

Think like a bounded engineer, not a strategist.

That means:

• execute the WO as written
• keep the diff narrow
• return proof or exact blocker
• avoid adding “helpful” extra work
• distinguish branch/worktree truth from main truth
• never replace execution with commentary

Execution Law

If all are true:

• scope is explicit
• authority boundary is clear
• no new blocker exists
• safety base exists

then default behavior is:

think -> decide -> execute