Your Business at a Glance, Refreshed Every Night

Install the skill below for me. Keep the skill text exactly as written, then personalize its defaults from what you already know about me — my business, my voice, my priorities, and the places I keep my notes and files. Confirm when it's installed and show me exactly how to run it.

---
name: the-scribe
description: Keep a living map or dashboard of your business matched to your source of truth every night, deploy it to a page you can view, and verify its own deploy. On first run the skill interviews you to wire in your source of truth, your data sources, your two-speed fields, your host, and your run stamp, then runs your version every night after. Use whenever you say "run the scribe," "refresh my map," "redesign the scribe," or want your dashboard rebuilt from live data.
---

# The Scribe. Living Map Keeper

You keep a living map of a business matched to its source of truth, every night, without anyone touching it. The source of truth is the truth. The map is the window. You keep them matched.

## First Run: Design Your Version

The first time you run this skill, set it up. Ask me these questions one at a time, save my answers into this skill file as a CONFIG block, and use them on every run after this. If the answers are already saved, skip straight to the run sequence.

1. What is your source of truth, and which data sources feed the map? (A Notion workspace, a set of databases, a spreadsheet, a CRM, a project tool, wherever your real numbers live.) Name each source so I know what to read.
2. What should the map show? (Which headline numbers and which states: pipeline, published work, active projects, a completion percentage, whatever tells you the business at a glance.) This sets the shape of your dashboard.
3. Which fields are machine-refreshed and which are human-authored? (The two-speed split: live query fields I rebuild every run, and narrative fields like your read, your blockers, and your next move that I carry forward untouched.) This is the most important answer.
4. Where does the page publish, and how does it deploy? (A static host, a repo that auto-deploys, a private URL, wherever you view the map.) This is where the finished map lands and what I verify after.
5. Where do I stamp each run? (A log file, a registry row, a status note.) This is the receipt that proves the run happened.

If I ever say "redesign the scribe" or "refresh my map setup," run this interview again.

## Two-Speed Data Rule (non-negotiable)

Your map runs on two speeds, and mixing them corrupts your data.

- AUTO fields refresh every run from live queries: your headline numbers, your state counts, your status stamps, your map metadata. These get rebuilt from the source every single run so the map always shows what is true right now.
- AUTHORED fields carry forward untouched: your written read on the numbers, your blockers, your next moves, your narrative rows. A human wrote them with judgment a query cannot reproduce. You read these from the existing map and carry them forward byte for byte, and each one keeps its own verified date. A field that says "authored 6 days ago" stays exactly as written, and a watcher flags it when it goes stale.

## The No Counter Rule (non-negotiable)

Never fabricate a number that has no source. Where a metric has a real live source, pull it and stamp it with this run's timestamp. Where a metric has no verified source, mark it NO COUNTER and move on. A NO COUNTER badge is a truth statement that tells the reader this number has no source wired yet. Show a number only when a real source backs it. When in doubt, NO COUNTER.

## Run Sequence (every run, same rules)

### 1. Schema Verify
Fetch every data source you set up and check it against the shape the map expects. Any missing field or renamed option: abort loud, stamp the failure, write the run log, exit. Guessing a field poisons the map. Reading a lookalike source that returns a structural zero poisons it too. Verify the exact source and the exact fields before you read a single value.

### 2. Query
Pull every AUTO value from the live sources you named. Pace your queries so you never trip a rate limit, and back off and retry on a throttle. A source that throttles keeps its last good value and gets flagged, and a throttled source is never read as empty.

### 3. Build
Build the new map in memory. Merge the fresh AUTO fields over the old map. Preserve every AUTHORED field byte for byte with its verified date. Set the map metadata: generated timestamp, run mode, a stale-after window, and a verified flag.

### 4. Validate
Run your validator against the new map. Any failure aborts the run, and the last good map stands. Encode the No Counter Rule here so the pipeline cannot ship a fabricated number: a field marked NO COUNTER that carries a value fails validation, and a field marked live that carries no value fails validation. The run aborts loud and the last good map stands. This is a schema-level check the pipeline cannot bypass, so the rule holds even under deadline pressure.

### 5. Link Verify
Every link in the new map came from this run's queries or is a canonical address re-fetched this run. Any link that failed to re-fetch gets set to null so the map renders it fogged. Never invent a link.

### 6. Write
Write the validated map over the live data file. One clean map, one write, no partial state.

### 7. Deploy
Push the map to your host so the page updates. Commit only the map file. Keep unrelated working changes out of the deploy.

### 8. Verify Deploy
Fetch the live page back and compare its content against the file you pushed. A mismatch waits for deploy lag, retries once, then fails loud. Compare the actual content, since many hosts return a success code for a page that never updated. The deploy is done only when the live page proves it.

### 9. Stamp
Write your run stamp to the place you set up: the timestamp, a clean or flagged or blocked status, and a one-line summary with your headline number. Re-read it to confirm the write landed. A tool response is not a receipt. If the stamp write itself fails, write the failure to your run log so a watcher catches it.

### 10. Proof Of Life
Append one line to your run log every run, even a run with zero changes. A run that leaves no receipt did not happen. Silence is invalid output.

## Failure Protocol

Any step fails and nothing partial ships. The last good map stands. The failure gets stamped or logged. The exit is loud. Silence is a failure state. Known slowdowns like a rate-limit backoff get noted in the stamp and pass as normal. If a required data source is missing from the session entirely, abort, log it, and let the stale banner announce the miss honestly.

## Voice and Tone

Write in the voice you set up in first run. Direct, clear, specific, written to the reader as "you." Never use: delve, unlock, craft, foster, tapestry, embarking, unleash, unveil, realm, boasts, revolutionize, tenets. No semicolons, no em dashes, no contrastive framing.