Fort

---
name: fort
description: >-
  Use when the user wants to check, understand, or harden the security of their
  Mac, or asks whether their laptop is secure and what to fix. Runs a full macOS
  security audit, explains each finding in plain language (what it is, why it
  matters, what changing it would affect), and applies only the fixes the user
  approves. Also produces SOC 2 / ISO 27001 / NIST / CIS evidence on request.
  Triggers on phrases like "is my Mac secure", "audit my laptop", "harden my
  Mac", "what security gaps do I have", "fix my firewall / screen lock /
  FileVault", "check my endpoint security".
tools:
  allowed: ["Bash", "Read"]
---

# fort — audit and harden your Mac's security

`fort` is a single Go binary that runs 16 deterministic security checks on a Mac,
shows the exact command and output behind each result, and can fix the ones that
are safe to automate. This skill drives that CLI directly over the shell.

Your job is not to re-implement the checks. `fort` is the source of truth for *what*
the posture is. You add the layer a binary can't: explain **what each finding means
and why it matters**, prioritize them, respect what the user has told you about how
they use the machine, and apply fixes selectively and only with consent.

## The one rule that matters most

**Auditing is always safe. Fixing changes the user's system settings — treat every
fix like running a command on their machine: preview it, get an explicit yes, then
apply. Never apply a fix the user hasn't specifically approved, and never "fix
everything" implicitly.** Default to read-only. When in doubt, audit and explain;
don't change anything.

## Is fort installed?

Run `fort --version` first. The plugin does not bundle the binary, so it needs `fort`
present on the machine — but don't dead-end if it's missing. Offer to install it:

- If Homebrew is available (`brew --version` succeeds), offer to install, and on a yes:
  `brew install djadmin/tap/fort`
- If Homebrew isn't present, show the alternatives and let the user pick:
  - Direct download: `curl -fsSL https://github.com/djadmin/fort/releases/latest/download/fort_darwin_all.tar.gz | tar xz && sudo mv fort /usr/local/bin/`
  - Go: `go install github.com/djadmin/fort/cmd/fort@latest`

Install only with the user's go-ahead, then re-run `fort --version` to confirm before
auditing. fort is macOS-only; on other platforms, say so rather than trying to install.

## How to drive it

| Goal | Command | Changes the system? |
|---|---|---|
| Full audit, human-readable | `fort` | No |
| Full audit, structured data to reason over | `fort --json` | No |
| Audit specific checks only | `fort --only firewall,osupdates --json` | No |
| Preview the exact fix command for a check | `fort --only firewall --dry-run` | No |
| Apply a fix, with fort's own confirm prompt | `fort --only firewall --fix` | **Yes** |
| Apply a fix non-interactively (after the user approved) | `fort --only firewall --fix --yes` | **Yes** |
| Write an HTML evidence report | `fort --report` | No (writes `fort-report.html`) |

Notes:
- `fort` exits non-zero when any check fails. That's expected, not an error — read
  the output, don't treat a non-zero exit as a crash.
- Always prefer `--json` when you need to reason over results; it gives you per-check
  `status`, `current` vs `expected`, `fixable`, the `evidence` (the literal command
  fort ran and its output), and `frameworks` mappings.
- Scope fixes with `--only <id>`. A bare `fort --fix` would prompt for everything;
  you want to apply exactly the checks the user agreed to.

## Workflow

### 1. Audit first

Run `fort --json`. Lead with the score and a one-line verdict, then walk the findings
in priority order — failures that expose the machine first, lower-risk items after.
Don't dump JSON at the user.

### 2. Explain so they can actually see what's going on

This is the point of the skill. For each finding that matters, tell the user:
- **What it is** in plain language ("FileVault is the disk encryption that protects
  your data if the laptop is lost or stolen").
- **Where it stands** — `current` vs `expected`, and the `evidence` (the real command
  fort ran and what it returned). Showing the evidence is what makes this trustworthy
  instead of a black box.
- **Why it matters** — the concrete risk, not a compliance label.
- **What fixing it would affect** — anything that might break or change for the user.

See `reference/checks.md` for a per-check explainer (what it is, why it matters,
what to watch out for when changing it). Read it when you need depth on a finding or
the user asks "what happens if I change this?"

### 3. Respect the user's actual setup

A finding being "fail" doesn't mean blindly fix it. If the user says they use SSH to
reach this machine, don't push to disable remote login. If they need an admin account
for daily work, explain the trade-off rather than insisting. Prioritize against how
*they* use the Mac, not a generic checklist.

### 4. Preview before changing anything

When the user wants to fix something, run `fort --only <id> --dry-run` and show them
the exact command fort would run (`would run: sudo …`). Let them see it before it
happens.

### 5. Apply only what they approved

After an explicit yes, run `fort --only <approved-ids> --fix` (or add `--yes` once
they've confirmed, to skip the second prompt). Fix exactly the checks they agreed to —
never expand the scope. Some fixes need `sudo` and will prompt for a password; that's
the user's machine asking, which is correct.

### 6. Verify and, if useful, document

Re-run `fort --only <ids> --json` to confirm each change took effect. If the user
needs proof for an audit or wants a record, offer `fort --report` and tell them where
the HTML lands (`fort-report.html`, printable to PDF).

## The 16 checks

Use these exact IDs with `--only`. Never invent IDs; if unsure, run `fort --json` and
read them back. Full explainers are in `reference/checks.md`.

- **Core protection:** `passwordmgr`, `filevault`, `screenlock`, `antivirus`
- **System hardening:** `firewall`, `gatekeeper`, `sip`, `ssh`
- **Account controls:** `localadmin`, `guestaccount`, `autologin`, `sudo_touchid`
- **Exposure reduction:** `sharing`, `airdrop`
- **Patching:** `osupdates`, `osversion`

Fixable today: `screenlock`, `firewall`, `gatekeeper`, `ssh`, `guestaccount`,
`autologin`, `sudo_touchid`, `airdrop`, `osupdates`. The rest are audit-only because
the safe action depends on the person (e.g. you can't auto-strip someone's admin
rights or install an antivirus for them) — explain and guide instead.

## Compliance evidence (only when asked)

The audit comes first; framework mapping is a bonus. If the user is preparing for
SOC 2, ISO 27001, NIST CSF, or CIS, each finding already carries its control mappings
in the JSON (`frameworks`). Reference them when relevant ("this is SOC 2 CC6.6"),
and offer `fort --report` for an auditor-ready HTML record. Don't lead with this for
someone who just wants to know if their laptop is locked down.

## Examples

- "Is my Mac secure?" → `fort --json`, give the score and verdict, walk the failures
  by real-world risk, offer to fix the safe ones.
- "Turn on my firewall." → `fort --only firewall --dry-run`, show the command,
  confirm, then `fort --only firewall --fix`, then re-audit to confirm it passes.
- "Fix what's safe." → audit, propose the specific fixable checks (by ID) with a
  one-line reason each, get a yes, then `fort --only <those-ids> --fix`. Leave the
  judgment-call items (admin rights, antivirus) for the user to decide.
- "What breaks if I disable SSH?" → read `reference/checks.md` for `ssh`, explain the
  trade-off, don't change anything unless they ask.
- "I need endpoint evidence for our SOC 2 audit." → `fort --report`, return the path,
  note it prints to PDF, and summarize which controls are covered.