safe-experiment
npx machina-cli add skill speson/not-my-reforge/safe-experiment --openclawYou have the safe-experiment skill. When invoked, create an isolated worktree for experimental code changes.
Usage
/not-my-reforge:safe-experiment <description of experiment>
Protocol
Phase 1 — Setup Isolation
- Ensure the current working tree is clean (commit or stash pending changes)
- Create a new worktree:
git worktree add -b experiment/<timestamp> .claude/worktrees/experiment-<timestamp> HEAD - Switch to the worktree directory for all subsequent operations
Phase 2 — Experiment
- Implement the requested changes in the worktree
- Run build/test/lint to verify the changes work
- Document what was changed and why
Phase 3 — Review
Present results to the user:
## Experiment Results
### Changes Made
- file1.ts: description of change
- file2.ts: description of change
### Verification
- Build: PASS/FAIL
- Tests: PASS/FAIL (N tests)
- Lint: PASS/FAIL
### Diff Summary
(show `git diff --stat` from the worktree)
Phase 4 — Decision
Ask the user:
- Merge: Cherry-pick or merge changes back to the main branch
- Discard: Remove the worktree and branch cleanly
Merge Commands (if approved)
cd <original-cwd>
git merge experiment/<timestamp>
git worktree remove .claude/worktrees/experiment-<timestamp>
git branch -d experiment/<timestamp>
Discard Commands
git worktree remove .claude/worktrees/experiment-<timestamp> --force
git branch -D experiment/<timestamp>
Rules
- NEVER modify files in the main working tree
- ALL changes happen in the worktree
- Always verify with build/test before presenting results
- Clean up worktree after merge or discard
- If the experiment fails, explain why and suggest alternatives
Source
git clone https://github.com/speson/not-my-reforge/blob/main/skills/safe-experiment/SKILL.mdView on GitHub Overview
Safe-experiment creates an isolated Git worktree to test code changes without touching the main working tree. It follows a structured flow: setup isolation, run the experiment, review results, and decide to merge or discard. This makes risky changes reviewable and discardable with minimal friction.
How This Skill Works
When invoked, it creates a new worktree using a timestamped branch (experiment/<timestamp>) in .claude/worktrees and switches you into that worktree. You implement changes, then build, test, and lint to verify them. You document what changed and why so reviewers can evaluate before deciding to merge or discard.
When to Use It
- You want to test risky refactors without touching the main branch
- You need to evaluate performance optimizations in isolation
- You're considering a large dependency upgrade or API change
- You're prototyping a new feature or experimental API
- You want to validate a speculative bugfix with a clean discard path
Quick Start
- Step 1: Ensure your current working tree is clean (commit or stash pending changes)
- Step 2: Start the experiment: /not-my-reforge:safe-experiment <description of experiment>, which creates a timestamped worktree at .claude/worktrees/experiment-<timestamp>
- Step 3: Implement changes in the worktree, run build/test/lint, document results, then decide to merge or discard
Best Practices
- Always start with a clean main working tree (commit or stash any changes)
- Use a timestamped branch name like experiment/<timestamp> for each run
- Document changes and rationale inside the worktree during Phase 2
- Verify with build, tests, and lint inside the worktree before presenting results
- Clean up by merging or discarding the worktree and associated branch
Example Use Cases
- Refactoring a module while preserving main branch integrity
- Experimenting with a new caching strategy in a service without affecting production code
- Prototyping a feature-flag controlled rollout in isolation
- Benchmarking a micro-optimization within a dedicated worktree
- Validating a speculative bugfix with a clear discard path if it fails