AI makes building easy.
Without structure, you ship noise.

What job is the customer hiring us to do — and is the gap big enough to bet on?

Write job statements using the template: (action verb) + (object) + (context). Separate functional task from emotional need and social context. Score outcomes using importance × satisfaction gap to find the most underserved jobs — the ones where current solutions fail and customers feel the pain most acutely. If no gap is large enough, kill the bet before writing a spec.

• Interview customers about their struggling moments, not feature wishes
• Write job statements with all three dimensions: functional, emotional, social
• Score outcomes: high importance + low satisfaction = underserved opportunity
• Rank the backlog by opportunity score, not stakeholder loudness

Plan the full hook cycle before you build any of it. Identify which internal triggers (negative emotions — boredom, anxiety, FOMO) your product will attach to. Define the simplest possible action, choose the variable reward type (Tribe, Hunt, or Self), and plan what stored value users will create that makes the product better with each visit. Estimate the target cycle frequency — how often must users repeat the loop to form a habit?

• Map the full cycle: trigger → action → variable reward → investment
• Identify internal triggers (emotions) and the external triggers that bridge to them
• Choose the reward type: Tribe (social), Hunt (discovery), or Self (mastery)
• Define the stored value users invest and the target cycle frequency for habit formation

Working Backwards: write the press release as if the bet already shipped — if it’s boring, the bet is boring. Probe Cagan’s four risks (Value, Usability, Feasibility, Viability) with specific evidence; “we’ll figure it out” is not an answer. Set a falsification signal upfront so you can’t move the goalposts later. Set the Shape Up appetite — fixed time, variable scope — before any spec is written.

• Draft a one-paragraph press release; if it’s embarrassing to publish, the bet isn’t sharp enough
• Force a specific answer to each Cagan risk — evidence, not vibes
• Define the falsification: cheapest signal that would tell us we’re wrong
• Set a fixed appetite (1 week / 2 weeks / 6 weeks); cut scope to fit, never extend time

/vibeslop.pitch front-loads research before asking the user anything — prior artifacts, git state, available trackers and CRM signals. The skill drafts a PR-FAQ + Cagan’s four risks + falsification + appetite, names its own weak spots inline, and offers deepen passes with concrete costs. Soft spots the user passes on land in the artifact under “Open soft spots” — visible to /speckit.specify, not silenced.

• Agent pulls inputs: prior artifacts, git history, support themes, deal-stage data when reachable
• Three proposal rounds: the bet, Cagan’s four risks, the shape (confidence + falsification + appetite + scope)
• Skill writes pitch.md with “Open soft spots” preserving anything the user passed on
• Close hands off to /vibeslop.sketch, /speckit.specify, or kill-the-bet — not a linear waterfall

What does progress look like — and what’s the shortest path to it?

Define the “before” state (struggling moment) and the “after” state (desired outcome), then design the shortest path between them. Tag every screen with the job dimension it serves: functional, emotional, or social. If a screen doesn’t advance any dimension, cut it. The sketch isn’t a UI — it’s a behavioral path.

• Map the struggling moment → desired outcome journey for each job
• Tag every screen: which job dimension does it serve (functional, emotional, social)?
• Define progress metrics at sketch time — how will you know the user succeeded?
• Cut screens that don’t advance any job dimension

Apply Fogg’s Behavior Model: B = MAT (Behavior happens when Motivation, Ability, and Trigger converge). Audit the core action against the six simplicity factors: time, money, physical effort, brain cycles, social deviance, non-routine. Then design the variable reward: what’s different every time? Variability — not magnitude — is what keeps users engaged. Sketch the investment step that loads the next trigger.

• Identify the single core action — reduce it to the minimum steps
• Score the six simplicity factors and design out the biggest friction
• Design reward variability — what’s different every time the user completes the action?
• Sketch the investment step: what do users put back that loads the next trigger?

Use breadboarding to map flow logic — places, affordances, connections — with no visual design. Use fat-marker sketches drawn at a level where you physically can’t add detail. Cagan’s value + usability risks are not resolved by talking; spin up a 30-minute HTML prototype and put it in front of someone before you lock the design. The agent can build that prototype itself if you don’t.

• Breadboard the flow: places + affordances + connections, no visual design
• Fat-marker sketch the UI: intentionally rough so detail can’t creep in
• Build a 30-minute prototype that exercises the core action — the agent can do this
• Put it in front of a representative user; record what they struggled with that you didn’t expect

/vibeslop.sketch reads pitch.md and any existing spec-kit artifacts, then drafts B=MAT + the simplicity audit + topology + a prototype offer. The agent will build a 30-minute HTML prototype itself if no prototype was tested. Open soft spots ride forward into /speckit.specify so the spec embodies the behavioral discipline rather than the data shape.

• Agent reads pitch.md + existing component library + available accessibility tooling
• Three proposal rounds: the change (B=MAT), the shape (simplicity + topology), the bounded prototype
• Skill writes sketch.md and optionally a working HTML prototype to specs/<feature>/contracts/
• Close hands off to /speckit.specify with the behavioral constraints already locked

Does the spec embody the bet, and does the implementation match the spec?

Spec-kit’s spec.md template enforces Given/When/Then acceptance scenarios and FR-XXX functional requirements that trace back to the bet. The spec is the source of truth for what gets built. Vibeslop hands the bet off here — pitch.md and sketch.md become the inputs spec-kit uses to write the spec, plan the architecture, break down the tasks, and implement.

• /speckit.specify reads pitch.md + sketch.md and writes spec.md with Given/When/Then scenarios
• /speckit.clarify asks up to 3 targeted questions to resolve the riskiest ambiguities
• /speckit.plan produces the technical plan: data models, contracts, quickstart
• /speckit.tasks breaks the plan into actionable units; /speckit.implement builds them

Build the infrastructure that makes the entire hook cycle work. For Action: optimize the critical path for minimum latency, prefetch the likely next step. For Variable Reward: build the systems that generate variability (recommendations, social feeds, personalization). For Investment: build the data layer that stores user contributions — each investment must visibly improve the next session.

• Optimize the critical path: the one action users do most should be fastest
• Build the systems that generate reward variability — not static content
• Build persistence for user investments: content, connections, preferences, history
• Ensure investments are visible on return — the product should feel “mine”

Spec-kit’s pipeline: constitution (project principles, written once) → specify (requirements + acceptance scenarios) → optional clarify (max 3 questions) → plan (data model, contracts, quickstart) → tasks (actionable units) → implement (code + tests). Each step writes to specs/&lt;NNN-feature&gt;/. Vibeslop’s pitch.md and sketch.md cohabit there.

• Run /speckit.specify to write the spec; clarify only if needed (max 3 questions)
• Run /speckit.plan to produce the technical plan with contracts and quickstart
• Run /speckit.tasks to break the plan into actionable units
• Run /speckit.implement to build the feature with tests — stops at “code generated”

Spec-kit handles the engineering substrate (constitution, specify, plan, tasks, implement). Vibeslop intentionally does not duplicate this work. After /speckit.implement produces shipped code, /vibeslop.ship picks up the launch ceremony.

• Vibeslop hands the bet (pitch.md + sketch.md) off to /speckit.specify
• Spec-kit’s artifacts (spec.md, plan.md, tasks.md) live in specs/<feature>/ alongside vibeslop’s
• Engineering disciplines (Daily Standup, Pair Programming, Code Review, Secure Coding) live with spec-kit
• /vibeslop.ship reads everything in specs/<feature>/ before drafting the launch plan

How do we position this around the job, not the feature?

Launch messaging speaks to the job the customer is hiring for. “We added dark mode” is a feature. “Work comfortably at night” is a job. Lead with the struggling moment (“Tired of squinting at bright screens?”), present the product as progress on their job, and use social proof from users who got the job done. Feature lists go in the changelog, not the announcement.

• Lead with the struggling moment: “Tired of [old way]?”
• Present the product as progress on the job, not a feature list
• Use social proof from users who completed the job successfully
• Write launch copy using job statement language: verb + object + context

Launch is where you activate the first full hook cycle. Fire external triggers — announcements, emails, in-app prompts — that create a mental association between the user’s internal trigger and your product. Don’t send a “new feature” email; send a “struggling with X?” email. Design the first-use experience to deliver an immediate variable reward and prompt an investment, so the user completes the entire cycle on day one.

• Match external triggers to internal emotions — not “new feature” but “struggling with X?”
• Design first-use to complete the full cycle: trigger → action → reward → invest on day one
• Plan trigger frequency: enough to build the association, not enough to annoy
• Track which trigger channels produce the highest first-cycle completion rate

Stage the rollout: internal dogfood → beta cohort → general availability. Feature flags control exposure. Canary releases route a small % of real traffic to compare error rate and latency to the baseline. Define rollback tripwires before launch — concrete thresholds, not “we’ll watch it.” Train sales to position around the job statement, not walk through features.

• Stage rollout: internal → beta → GA with feature flags controlling exposure
• Define rollback tripwires upfront: error rate, latency, satisfaction thresholds with real Sentry baselines
• Train sales to position around the job: “this helps customers [job]” not “this does [feature]”
• Monitor support ticket volume and first-session completion rate post-launch

/vibeslop.ship has a hard precondition: implementation must be done (tasks.md mostly checked or recent commits matching scope). Override allowed, silent bypass not. In solo mode, the skill commits, pushes, tags, and flag-flips — with explicit yes for each action. Never deploys without one.

• Agent reads pitch.md + sketch.md + spec-kit artifacts; checks implementation evidence
• Three proposal rounds: messaging (JTBD), first experience (Hook Model), safe rollout (canary + tripwires)
• Solo mode: agent commits, pushes, tags, enables flag at N% — yes-each-time
• Close points to /vibeslop.score in 24-72 hours; rollback path is explicit

Did we help the customer make progress — and which outcomes are still underserved?

Re-score every targeted outcome using importance × satisfaction; compare pre-launch and post-launch. Identify outcomes where the gap narrowed (your bet paid off), remained (your bet missed), or new gaps emerged. Check switching behavior: did customers stop using their old workaround? If they’re using both, the job isn’t done. These findings feed directly into the next /vibeslop.pitch.

• Re-score importance × satisfaction for every outcome you targeted
• Compare pre/post: gaps that narrowed = success, gaps that remained = miss
• Watch for new underserved outcomes that emerged as unintended consequences
• Produce an evidence-ranked bet list for the next pitch — close the loop

Diagnose where the cycle is breaking. Define your habit threshold (e.g., 3+ sessions per week) and track what percentage of each cohort reaches it. Measure drop-off at each transition: trigger → action, action → reward, reward → investment. Compare trigger channels by first-cycle conversion rate. A decreasing inter-session interval means habits are forming; an increasing one means you’re losing the battle for attention.

• Define the habit threshold: how many sessions per week indicates a habit?
• Track cohort retention curves — where do users fall off the cycle?
• Measure drop-off at each transition: trigger→action, action→reward, reward→invest
• Compare trigger channels: which produce the highest cycle completion rate?

Score is honest accounting. Walk the demo end-to-end — not features in isolation. Produce a shipped/cut/carried-forward list with outcome data. Run a blameless post-mortem for any incidents or rollbacks. Run churn analysis as job-switching: which job did churned users hire something else for? They didn’t leave; they switched. Naming what they hired tells you what to build.

• Walk the demo end-to-end with real data — dead ends are evidence
• Produce shipped/cut/carried-forward; distinguish cut by appetite from cut by drift
• Run Start/Stop/Continue + blameless post-mortem RCA for incidents
• Run churn analysis as “what did they hire instead” — the most useful churn signal

/vibeslop.score reads everything in specs/<feature>/ and pulls real numbers from analytics / observability / CRM when reachable. Crucial property: the skill never invents metrics when data sources are unreachable — it records the gap honestly. The closing artifact is an evidence-ranked bet list for the next pitch (H/M/L confidence; High requires ≥2 independent sources).

• Agent pulls inputs: retention curves, error budgets, deal velocity, churn signals, session replays
• Three proposal rounds: did the bet pay off, where are people dropping off, what now
• Skill writes score.md with bet list table for next /vibeslop.pitch
• Loop closes: pitch.md inherits the bet list automatically; the next cycle starts warm