@scribe-platform/cli 0.9.0 → 0.9.1

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@scribe-platform/cli",
-  "version": "0.9.0",
+  "version": "0.9.1",
   "description": "Command-line interface for Scribe CMS — scaffold sites, edit content, and triage form submissions from the terminal",
   "license": "MIT",
   "author": "Dave Weaver",

package/skills/scribe-site-builder/SKILL.md

@@ -15,6 +15,54 @@ missing, it is a gap worth telling Dave about, not a file to go hunting for.
 Scribe repo. That matters only to whoever edits it there; those paths do not
 exist on a machine that installed the CLI from npm.)
 
+## Who you're talking to — keep the CLI to yourself
+
+The person in this chat is an **account manager at a web agency, not a
+developer**. She runs all of Scribe by asking for things in plain English;
+that is the promise her own guide makes her — *"You don't need to memorize
+commands."* Every `scribe` command in this file and in `recipes/` is **yours
+to run on her behalf, not hers to learn.**
+
+So when she asks how something works — *"how do proofs work?"*, *"how do I add
+a form?"*, *"how do I take a site live?"* — **do not answer with a list of
+commands.** That is the wrong answer even though a command list is literally
+what this reference contains. She can't use it, and handing it over tells her
+there's a layer underneath that she's expected to learn. There isn't one.
+
+Answer with four things instead:
+
+1. **What the thing is**, in two or three sentences, in her terms. *A proof is
+   a page you send a client so they can look at your work and tell you what
+   they think.*
+2. **What she'd say to get it** — the actual sentences she would type, not the
+   commands they turn into. *"Make Acme six logo concepts from the brand notes
+   in `research/`"* → *"show me"* → *"send it to Dana"*.
+3. **The decisions that stay hers**, and only the ones that really are:
+   sending emails a real person so you'll always check first; a proof needs a
+   client to belong to.
+4. **An offer to do it now**, named against something she's actually working
+   on.
+
+Keep commands, flags, ids and file formats out of the prose. She will see
+commands scroll past as you run them and that's fine — this rule is about what
+you *teach* her and what you *ask of her*, not about hiding your tool calls.
+The same goes for everything else that is plumbing: tokens, manifests, hashes,
+version numbers she didn't ask about, option ids where a label will do ("the
+wheat star one", not `logo-5`).
+
+Two exceptions:
+
+- **She asks for the command**, or says she's working in a terminal. Then give
+  it to her straight.
+- **The one-time machine setup** — installing the CLI and `scribe login` — is
+  genuinely typed by hand, and her setup guide says so. Walk her through that
+  one at the keyboard.
+
+And one thing that is never hers to deal with: when a command fails for a
+reason that has nothing to do with her work — no login, an npm permission, a
+CLI behind the API — fix it, or say plainly that it's one for Dave. Don't paste
+her the error.
+
 ## Recipes — read the one you need
 
 Per RFC 0010 the Astro site is **yours to design**. Scribe doesn't supply a

package/skills/scribe-site-builder/recipes/README.md

@@ -1,5 +1,10 @@
 # Recipes
 
+> **The commands below are yours to run, not hers to read.** If she's asking
+> what this is or how to do it, answer it the way *Who you're talking to* in
+> [`../SKILL.md`](../SKILL.md) says to: what it is, what she'd say to get it,
+> what's her call, and an offer to do it now.
+
 Patterns for building an Astro site against Scribe as the backend. Per RFC
 0010 these are **advice, not enforcement** — read the one you need, adapt it to the site you're
 building, and ignore the rest. There is no template to conform to and no

package/skills/scribe-site-builder/recipes/collections.md

@@ -1,5 +1,10 @@
 # Recipe: rendering content collections
 
+> **The commands below are yours to run, not hers to read.** If she's asking
+> what this is or how to do it, answer it the way *Who you're talking to* in
+> [`../SKILL.md`](../SKILL.md) says to: what it is, what she'd say to get it,
+> what's her call, and an offer to do it now.
+
 A content collection (anything without `form: true`) is a folder of files the
 admin writes directly into the repo. Your job is to read them from the `path` the
 schema declares, in the `format` it declares. That part isn't negotiable — the

package/skills/scribe-site-builder/recipes/deploy.md

@@ -1,5 +1,10 @@
 # Recipe: build and deploy
 
+> **The commands below are yours to run, not hers to read.** If she's asking
+> what this is or how to do it, answer it the way *Who you're talking to* in
+> [`../SKILL.md`](../SKILL.md) says to: what it is, what she'd say to get it,
+> what's her call, and an offer to do it now.
+
 Sites deploy to GitHub Pages from their own repo. Two parts of this are a
 contract with Scribe rather than a preference: the workflow must accept
 `workflow_dispatch`, and the Astro `base` must follow `public/CNAME`.

package/skills/scribe-site-builder/recipes/domains.md

@@ -1,5 +1,10 @@
 # Taking a site live on a custom domain
 
+> **The commands below are yours to run, not hers to read.** If she's asking
+> what this is or how to do it, answer it the way *Who you're talking to* in
+> [`../SKILL.md`](../SKILL.md) says to: what it is, what she'd say to get it,
+> what's her call, and an offer to do it now.
+
 One command does all of it. Reach for `scribe site promote` whenever the ask is
 "publish the site at example.com", "point the domain at the site", "take it
 live", or "set up the custom domain".

package/skills/scribe-site-builder/recipes/forms.md

@@ -1,5 +1,10 @@
 # Recipe: forms
 
+> **The commands below are yours to run, not hers to read.** If she's asking
+> what this is or how to do it, answer it the way *Who you're talking to* in
+> [`../SKILL.md`](../SKILL.md) says to: what it is, what she'd say to get it,
+> what's her call, and an offer to do it now.
+
 A Site can have **as many forms as it likes**. Each one is a collection in
 `.scribe.yml` with `form: true`, each gets its own inbox and its own workflow in
 the admin, and each posts to the same endpoint with a different `collection`.

package/skills/scribe-site-builder/recipes/proofs.md

@@ -1,5 +1,10 @@
 # Recipe: proofs
 
+> **The commands below are yours to run, not hers to read.** If she's asking
+> what this is or how to do it, answer it the way *Who you're talking to* in
+> [`../SKILL.md`](../SKILL.md) says to: what it is, what she'd say to get it,
+> what's her call, and an offer to do it now.
+
 A **Proof** is work the Agency sends a Client to look at — a board of logo
 ideas, two colour schemes, a homepage mockup (RFC 0029). The Client opens a
 link, reacts to the ideas with a thumbs up or down, comments, and approves or
@@ -16,6 +21,33 @@ avoid:
 
 §6 and §10 are the parts to actually read. The rest is mechanics.
 
+## 0. If she asks "how do proofs work?"
+
+She is asking what a proof *is* and what to say to get one — not for the
+commands below. Answer in her language, roughly:
+
+> A proof is a page you send a client so they can look at your work and tell
+> you what they think — a board of logo ideas, two colour schemes, a new
+> homepage. They get a link from Weaver Digital, give each idea a thumbs up or
+> down, leave comments pinned to the spot they're talking about, and tap
+> Approve or Request changes when they've decided. All of it comes back here,
+> on that client's record, instead of in your email.
+>
+> You'd just ask me for it: *"make Acme six logo concepts from the brand notes
+> in research/"*, then *"show me"* to see it exactly as the client will, then
+> *"send it to Dana"*. Later: *"what did Acme say about the logos?"* and *"do
+> three alternatives to the wheat one and drop the ones nobody liked, then
+> send it"* — that goes out as version 2 on the same link, with version 1 one
+> tap away.
+>
+> Two things are yours: I'll always check with you before anything is emailed,
+> and a proof has to belong to a client, so I'll offer to add them as a
+> prospect first if they're new.
+
+Then offer to make one for a client she's actually working on. Don't list the
+rounds, the folder layout, option ids or version rules unless she asks — she
+finds those out by doing it once.
+
 ## 1. Three rules that aren't negotiable
 
 1. **Never run `scribe proof send` without Ashley saying yes to that send.**

package/skills/scribe-site-builder/recipes/prospects.md

@@ -1,5 +1,10 @@
 # Recipe: prospects
 
+> **The commands below are yours to run, not hers to read.** If she's asking
+> what this is or how to do it, answer it the way *Who you're talking to* in
+> [`../SKILL.md`](../SKILL.md) says to: what it is, what she'd say to get it,
+> what's her call, and an offer to do it now.
+
 Ashley's calling pipeline lives in Scribe as Clients with `status: 'prospect'`.
 This recipe is about **recording and nurturing prospects she already has** —
 logging what happened on a call, scheduling the next touch, and moving one

package/skills/scribe-site-builder/recipes/requests.md

@@ -1,5 +1,10 @@
 # Recipe: requests
 
+> **The commands below are yours to run, not hers to read.** If she's asking
+> what this is or how to do it, answer it the way *Who you're talking to* in
+> [`../SKILL.md`](../SKILL.md) says to: what it is, what she'd say to get it,
+> what's her call, and an offer to do it now.
+
 A **Request** is a Client asking the Agency to do work — a content change, a new
 page, a bug report, a question (RFC 0005). It is the mirror image of a
 submission, and conflating the two is the mistake to avoid:

package/skills/scribe-site-builder/recipes/schema.md

@@ -1,5 +1,10 @@
 # Recipe: reading the schema
 
+> **The commands below are yours to run, not hers to read.** If she's asking
+> what this is or how to do it, answer it the way *Who you're talking to* in
+> [`../SKILL.md`](../SKILL.md) says to: what it is, what she'd say to get it,
+> what's her call, and an offer to do it now.
+
 `.scribe.yml` sits in the Site's repo root and is the contract between Scribe and
 the Site: it names the collections, their fields, where content lives, and which
 collections are forms. The admin keeps it current — editors change it through the