# Safe Build

> Make any code/UI change reversibly with a rollback-first checkpoint system. Use when the user asks to implement, modify, restyle, or add features and wants guaranteed undo ('make it reversible', 'I might not like it', 'safe build', 'change but be able to revert', 'try without committing').

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

---


# Safe Build — Invisible Checkpoints

A proven iterative-build workflow, upgraded with automatic checkpoints. The user NEVER has to remember syntax: every change is checkpointed automatically, and both exact commands and casual speech work. `<CHANGE>` = the requested modification.

## The Loop (never skip a step)

### 1. Recon before touching anything
- Locate the relevant files/components; read surrounding context first.
- **If a `DESIGN.md` exists in the project root, read it first** — all UI changes must follow its palette, typography, components, and do's/don'ts. If a change conflicts with it, flag the conflict and ask before deviating.
- If the user provided reference material (HTML from another site, screenshots, audits), identify exactly what to replicate vs. adapt.
- Disclose pre-existing failures BEFORE starting ("the 2 failing suites are pre-existing baseline issues") so they're never blamed on your change.

### 2. Baseline commit
If the working tree is dirty, commit or stash current state FIRST. Every change session starts from a clean, known-good baseline.

### 3. Plan document — Goal / Steps / Rollback
```
**Plan: <short title>**
**Goal:** <one line>
**Steps:** <numbered 1–N, each small and independently revertible>
**Rollback:** say "undo it" — or "revert to cp<N>" for a specific point
```
End every plan with: **"Shall I execute?"** — wait for approval (a bare "y" counts).

Ask structured questions for genuine forks only (mobile-only vs everywhere, source of assets, quality tradeoffs), always labeling `"(Recommended)"`. Don't ask what you can decide: prefer asset constraints over preference when sources dictate trade-offs.

### 4. Trial mode & sandbox mode
- **Trial mode**: if the request includes any doubt ("but I might revert", "not sure yet"), run sandbox-first: implement as UNCOMMITTED working-tree edits so the user can eyeball/test them. Then "keep" commits them as checkpoints; "discard" wipes cleanly.
- **Sandbox on demand**: `try without committing` always uses this mode regardless of phrasing.

### 5. Implement in isolation — auto-checkpoint everything
- New functionality in NEW files where possible.
- Style changes in namespaced blocks: `/* ==== <Feature Name> (revertible) ==== */`.
- One logical step = one checkpoint = one atomic labeled commit: `[cp1] hero video`, `[cp2] marquee`. Labels are human descriptions of intent, auto-generated by you — no user effort.
- Never mix unrelated fixes into one checkpoint.

### 6. Screenshots (web projects)
When browser tooling is available (e.g., Playwright MCP), capture per checkpoint:
- `.checkpoints/cp<N>-before.png` and `.checkpoints/cp<N>-after.png`
Add `.checkpoints/` to `.gitignore` automatically if missing. If no screenshot tooling exists, skip silently — NEVER block a code change over screenshots.

### 7. Journal (automatic bookkeeping)
After each checkpoint, append to `.checkpoints/JOURNAL.md`:
```
| cp# | label | files touched | hash | screenshots |
```
The journal + git history ARE the memory. Keep it current without being asked.

### 8. Verify
Run relevant tests/build; report results honestly, separating new failures from pre-existing ones.

### 9. Completion report (fixed format)
```
Done — committed as `<hash>` [cp<N>: <label>].
**What changed:** <bullet list>
Trial status: <N> checkpoints this session · undo anytime just by saying so.
Rollback: `git revert <hash>`
```

## Command & phrase reference (ALL of these work — interpret, don't require)

### Exact commands
| User says | Action |
|---|---|
| `show my checkpoints` | Print JOURNAL.md table |
| `keep this` | Confirm state, close trial |
| `undo it` / `undo 2` | Revert last checkpoint / back N checkpoints (`git revert`) |
| `keep cp1, undo cp2` | Selective: cherry-pick keeps vs reverts per checkpoint |
| `compare` | Per-file diffs between checkpoints/baseline + reference the before/after screenshots |
| `try without committing` | Sandbox mode: apply as uncommitted edits → await keep/discard |
| `revert to cp<N>` | Roll back to that specific point in time |

### Natural language (interpret via the journal)
| User says | Interpret as |
|---|---|
| "hmm, that's worse" / "nah" | `undo it` |
| "go back to how it was before the video thing" | Search journal labels → `revert to cp<N>` |
| "I like the first version of the colors" | Selective restore of that checkpoint's style changes only |
| "what did you change so far?" | `show my checkpoints` summary |
| "actually this is good" | `keep this` |

Ambiguous? Ask ONE clarifying question ("Which part — the colors or the layout?"). Never guess across unrelated checkpoints.

## Hard rules
- Never execute without plan approval.
- Never leave the repo without a clean rollback path — checkpoints make this impossible.
- Checkpoints are AUTOMATIC — never ask the user whether to create one.
- Responsive behavior splits default at the 768px breakpoint unless told otherwise.
- When publishing/deploying, verify the live URL actually serves the change before declaring done.