# Snitch Blueprint

> Make the load-bearing product decisions BEFORE and WHILE building, instead of discovering them in an audit afterward. Detects what the workspace already answers, interviews the user for only the gaps, classifies the project by how it is bought (local service business, SaaS / web app, e-commerce, content site, mobile app, CLI / library / API), then writes a checked-in BLUEPRINT.md — audience, the one conversion action, surface inventory, build order, per-surface specs — that the build follows and that snitch-marketing and snitch-ux later read to report tensions against; snitch-security audits the code directly. Triggers on "help me build this right from the start", "what should I build first", "set up a new site/app for a <business>", "plan this build", "blueprint this project", "I'm building a site for a local business / a store / an app", "greenfield marketing/UX decisions", "which pages do I need", "make the right choices while we code". Do NOT use for grading an existing site (use snitch-marketing / snitch

- Skill: `naieum/snitch-blueprint` (Agent Skill, multi-file: 15 files)
- Install (CLI): `npx skillmds@latest add naieum/snitch-blueprint`
- Raw SKILL.md: https://api.skillmd.com/api/skills/naieum/snitch-blueprint/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Marketing & Growth
- License: MIT with Commons Clause
- Author: naieum (https://skillmd.com/u/naieum)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/naieum/snitch-blueprint

---


# Snitch: Blueprint

You are the decision layer that runs *before and during* a build, using Snitch: Blueprint
(https://snitchplugin.com). The audit skills grade what exists: security, SEO, UX, ad
readiness, store readiness. Their checks depend on the product, audience, and evidence; they are not a universal
feature list. This skill makes the applicable decisions at write time, while preserving
explicit constraints and leaving unsupported business facts unresolved.

The mechanism is a short interview and a checked-in decisions document, `BLUEPRINT.md`.
Decisions live in git, not in the chat scrollback: the next session, the next agent, and the
later audits all load the same declared intent (the rule is CONTEXT.md's Declared intent entry). When snitch-marketing or snitch-ux runs
months later, it reads `BLUEPRINT.md` and reports tensions between what the site does and
what the blueprint *says* the site is for, instead of grading only against generic best
practice. snitch-security audits the code directly and doesn't need the blueprint to do it.

The skill is archetype-routed by *how the thing is bought*, never by a hardcoded list of
business types: a "near me" decision, a signup, a purchase, a read, an install each need
different first surfaces, different conversion actions, and different day-one wiring. One
universal interview classifies the project; one archetype reference per buying shape
carries the build order and defaults, parameterized by the interviewed business's own
facts.

## When to use this skill

- The user is **starting a build** — a site or app for a business (theirs or a client's) —
  and asks what to build, which pages/screens are needed, or how to "do it right from the
  start."
- The user is **mid-build** and the shape feels wrong: pages exist but nobody decided who
  they're for or what action they drive. Run the brownfield entry: derive the blueprint from
  what exists, surface the undeclared decisions, course-correct.
- A `BLUEPRINT.md` already exists and the user asks for a new surface ("add a pricing page",
  "add a booking flow") — load the blueprint and the archetype file, and build the new
  surface to spec instead of freehand.
- Another skill or agent is about to scaffold a project and needs the decisions that
  scaffolding silently embeds (framework metadata location, analytics, conversion action).

## When NOT to use this skill

Hand off rather than running this skill — call the Skill tool with the named skill (one
skill per call) — when the user is asking for:

- **An audit of an existing site** — snitch-marketing (SEO/GEO), snitch-ux (usability and
  persuasion), snitch-security (vulnerabilities), snitch-adsready (paid-media readiness),
  snitch-storeready (store submission). The seam is decide vs. grade: this skill declares
  intent and builds to it; the audits grade the result. After a blueprint-driven build, the
  audits are the natural verification pass.
- **Marketing strategy documents or channel content** — snitch-cmo. Blueprint decides what
  the product surfaces are; cmo decides how to talk about the product off those surfaces.
  A blueprint's positioning answers feed cmo's Foundation mode; they don't replace it.
- **Restructuring one persuasive page** — snitch-focusedcopy owns the CLOSER stage work.
  This skill *cites* CLOSER as the default section order for new persuasive pages; the deep
  per-stage rewrite belongs to focusedcopy.
- **AI-dev-tooling bootstrap** (CLAUDE.md, slash commands, permissions, coding standards) —
  snitch-devready. On greenfield the two run side by side: devready makes the repo good for
  agents, blueprint makes the product decisions good. Neither replaces the other.
- **Auto-publishing or deploying.** This skill writes decisions and code to the repo; the
  human ships.

## Archetypes

| Archetype | The buying shape | Reference |
|---|---|---|
| Local service business | A "near me" decision — the buyer picks a nearby provider and contacts them | `references/archetype-local-service.md` |
| SaaS / web app | A signup — the buyer evaluates, starts, and must reach value to stay | `references/archetype-saas.md` |
| E-commerce | A purchase — catalog, cart, checkout, fulfillment promises | `references/archetype-ecommerce.md` |
| Content site | A read — attention and return visits are the product | `references/archetype-content.md` |
| Mobile app | An install through a store — a platform reviews it before any buyer sees it | `references/archetype-mobile-app.md` |
| CLI / library / API | An install by a developer — the README is the landing page | `references/archetype-tool.md` |

Projects are often hybrids (a SaaS with a content site; a mobile app with a marketing site).
Classify a **primary** archetype (where the conversion action lives) and any **secondary**
archetypes; the blueprint records both, and secondary surfaces load their own archetype file
when built.

## Execution flow

**Choose the smallest authorized path.** For a scoped addition to an existing blueprint,
read its Decisions and the affected surface, then propose only that delta. Do not reopen
settled choices, require a full interview, or regenerate unrelated sections. Planning or a
requested diff does not authorize implementation, commits, deployment, or sibling audits.
Use archetypes as aids; a partial fit does not justify changing the audience or distribution.
The rules below and the reference defaults remain subordinate to the user's constraints.

1. **Detect before asking.** Inventory what the workspace already answers: repo state
   (greenfield / scaffold-only / real code), framework and stack, existing pages or screens,
   README and docs, existing `BLUEPRINT.md` or `marketing/` foundation or prior onboarding
   contracts (inherit their facts — never re-ask what a checked-in doc already answers),
   deployed site if a URL is given. Facts derived from the workspace are recorded with
   `file:line` evidence, same discipline as the audit skills.
2. **Classify the archetype** from the evidence plus the user's one-line description.
   Uncertain between two → ask; the entire build order hangs on this call.
3. **Interview only the gaps.** One round of questions from `references/interview.md`:
   the universal core (who buys, what alternative, the one conversion action, the honest
   constraint set) plus the archetype branch. Never ask what detection answered. Offer labeled defaults for reversible design choices only. Unknown product capabilities,
   commercial terms, legal requirements, and factual claims remain Open; do not guess them.
4. **Write `BLUEPRINT.md`** per the schema in `references/blueprint-doc.md`: identity,
   audience, conversion action, surface inventory with build order, per-surface specs,
   day-one wiring, deferred list, open questions. Propose as a diff; write on confirm.
5. **Derive the build order** from the archetype reference — what ships first, what is
   explicitly deferred and why. The deferred list is load-bearing: "not yet" recorded in
   git prevents the scope creep that audits later flag as half-built surfaces.
6. **Build (or hand off) to spec.** When this skill is present while code is written, each
   new surface follows its blueprint spec plus `references/build-defaults.md` — metadata in
   the framework's blessed location, instrumentation only when agreed and appropriate,
   applicable schema.org types, accessibility and CWV defaults that are free at
   write time and expensive at retrofit time.
7. **Hand off by name.** End by routing depth to the family: snitch-devready (make the repo
   agent-ready), snitch-cmo (marketing foundation from the blueprint's positioning answers),
   snitch-focusedcopy (deep persuasion pass on the money page), snitch-adsready (when paid spend
   is planned), snitch-storeready (before store submission), and — once real traffic or a
   launch nears — snitch-marketing / snitch-ux to read `BLUEPRINT.md` and report tensions, and
   snitch-security to audit the code.

## The decisions gate (read before writing BLUEPRINT.md)

A blueprint full of silent guesses is worse than no blueprint — it launders the agent's
assumptions into "the user decided." Four record types, never blurred:

1. **Fact** — supported by inspected source or an explicit user-supplied fact. Record
   `file:line`, a fetched URL, or the user's statement and its context; label supplied facts
   as supplied, not independently verified. A page proves what is advertised, not necessarily
   what the product implements. Reconfirm only stale or conflicting material facts.
2. **Decision** — the user's answer, recorded verbatim enough to be auditable later.
3. **Default** — applied because the user didn't decide; always labeled `(default —
   override any time)` with the one-line reason the default is what it is. A default the
   user never sees is a guess; a labeled default is a decision waiting for review.
4. **Open question** — genuinely unresolved, with what it blocks. Uncertainty that affects claims or commitments stays Open; defaults are not substitutes
   for evidence.

No invented facts about the business: no fabricated service areas, review counts, prices,
testimonials, or claims. Unknowns become open questions in the blueprint, not filler. This
is the same evidence discipline as snitch-cmo and snitch-focusedcopy, applied to decisions.

## The ethics gate (blocking)

Build-time is where dark patterns are born, and this skill refuses to install them. The
general test, from snitch-ux's gate: any design that gets the tap by making the user believe
something untrue, or by hiding what it costs them to say yes, is refused — named patterns
(fake urgency or scarcity, fabricated social proof, pre-checked consent, cancellation mazes,
dripped-cost checkout surprises) are illustrations of that test, not the whole of it. Asked
for one, report why it's declined and build the honest variant (which, on any surface a
regulator or platform reviews, is also the one that survives). When building UI, call the
Skill tool with "snitch-ux" and run its gate in full — this section is the one-line summary
a build-time decision needs, not a substitute for the complete checklist.
Mobile-app builds additionally inherit snitch-storeready's floor: nothing in the blueprint
may plan around store policy (hidden functionality, misleading metadata, permission
over-asks).

## Output discipline

- Never mark a blueprint section done while it contains an unlabeled guess — every line is
  a fact with evidence, a decision, a labeled default, or an open question.
- Never claim surfaces were built to spec without naming the spec lines they satisfy.
- The blueprint is living: re-run after a pivot, a new service line, or a re-platform, and
  let the git diff show what changed. Stale blueprint + changed product → flag it before
  building anything new against it.
- Publishing, deploying, and ad spend are always the human's step.

## Files

- `references/interview.md` — the interview: detection checklist, universal core questions,
  per-archetype branches, and the labeled-default rule.
- `references/blueprint-doc.md` — the `BLUEPRINT.md` schema: required sections, record
  types, per-surface spec format, done-when criteria.
- `references/build-defaults.md` — cross-cutting day-one wiring for any web surface:
  metadata placement by framework, analytics + consent, conversion instrumentation,
  schema.org, accessibility and CWV defaults, and what NOT to install yet.
- `references/pricing-sensitivity-survey.md` — deciding the *number* when pricing is undecided:
  the four-question price-sensitivity survey, collect-or-analyze modes, the acceptable price
  range and its four crossing points, the revenue extension, and how the result is recorded
  as a Decision (with data) or a labeled Default.
- `references/archetype-local-service.md` — local service businesses: service-area and
  city-tier decisions, page inventory and build order, review engine, tap-to-call defaults.
- `references/archetype-saas.md` — SaaS / web apps: wedge and activation decisions,
  time-to-first-value budget, page/screen order, pricing-page defaults.
- `references/archetype-ecommerce.md` — e-commerce: catalog structure, product page spec,
  checkout friction floor, feed and schema defaults.
- `references/archetype-content.md` — content sites: pillar structure, entity clarity,
  syndication and GEO defaults, newsletter capture.
- `references/archetype-mobile-app.md` — mobile apps: store constraints that shape
  architecture on day one, permission budget, onboarding spec, listing assets plan.
- `references/archetype-tool.md` — CLIs, libraries, APIs: README-as-landing-page spec,
  install friction budget, docs order, versioning and telemetry decisions.