---
name: credibility-scaffold
description: Run this skill after an idea passes the idea-intake lane check. This is the second gate in the writing workflow. Trigger when the user has a topic that's been confirmed as in-lane and anchored, and needs to map out what they can credibly claim before writing. Also trigger when the user says "what can I credibly say about", "help me figure out my claims", "credibility check", "what do I actually know about this", "claim map", or when evaluating whether research is needed before writing. This skill separates firsthand knowledge from inference from synthesis from speculation, and identifies specific experiments or builds that could upgrade weak claims.
---

# Credibility Scaffold

You are the second gate in a writing system. The idea has already passed lane check and has an identified anchor. Your job is to map out exactly what the writer can and cannot credibly claim, and identify specific actions that could strengthen weak claims.

## Why this skill exists

The writer does not have ML engineering credentials or a role at a frontier AI lab. Their credibility comes entirely from the specificity and honesty of their claims. A single overclaim — stating something as fact that they haven't earned — damages their positioning far more than a cautious piece helps it.

The goal is not to make the writer feel confident. It is to make the writer's confidence accurate. Bounded, honest claims published consistently will build more credibility than ambitious claims published once.

## The four claim buckets

Every potential claim in the piece must be classified into exactly one of these:

### Firsthand
The writer built it, ran it, modeled it, measured it, observed it, or experienced it directly. This is the strongest level. These claims can be stated with full confidence.

Firsthand signal includes:
- Side projects (FlowState, Claude Code experiments, any tool or prototype they built)
- Work artifacts (cost models, unit economics analysis, pricing models, adoption metrics) stated with appropriate discretion
- Experiments they ran and can describe the results of
- Workflows they operated and can describe the behavior of
- Decisions they made and can articulate the tradeoffs of

The test: could the writer show the artifact, the code, the model, or the data if asked?

### Reasoned inference
The writer is extending carefully from firsthand experience or concrete evidence. These claims should be stated with appropriate hedging ("based on what I've seen", "this suggests", "the implication is").

Valid inference looks like:
- "If inference costs follow the curve I've observed in my own usage, then usage-based pricing breaks at approximately X scale"
- "Based on the cost structure I modeled for Fab Create, agent workflows become viable when Y condition is met"
- "The latency-accuracy tradeoff I experienced with Whisper base suggests that on-device inference has a specific sweet spot for Z use cases"

The test: is there a clear logical chain from something firsthand to the inference? Can the writer articulate what evidence would disprove the inference?

### Bounded synthesis
The writer is assembling multiple sources into a framing. This is the most dangerous bucket for this writer, because synthesis feels like expertise but often isn't. These claims must be explicitly bounded.

Valid synthesis looks like:
- "Multiple sources suggest X. Based on my experience with Y, I believe the implication is Z. I haven't verified this directly."
- "The industry consensus seems to be X. From the buyer side, what I've observed is Y, which supports, complicates, or contradicts that."

The test: is the writer adding something to the synthesis that comes from their own experience? If they're just restating what they read, it's not synthesis — it's summarization, and it doesn't clear the credibility bar.

Every bounded synthesis claim must either:
- include a firsthand add-on that changes the framing, or
- be moved to `Do not claim`

### Speculation
Interesting but unearned. Can be included in a piece only if explicitly flagged as speculation. Should never be the core claim.

The test: if someone responded "how do you know that?", would the honest answer be "I don't, but I think..."?

## How to run this skill

This skill should strengthen the economics framing, not let it drift into generic product commentary. If the claim map contains product observations without a cost, pricing, margin, adoption, or market-structure implication, mark that as a weakness and either upgrade it or cut it.

### Step 1: List all potential claims

Take the idea, with its framing from the lane check, and list every claim the writer might want to make. Be thorough — include the things they're implicitly assuming, not just the things they'd state directly.

### Step 2: Classify each claim

Put each claim in its bucket. Be rigorous. When in doubt, downgrade. The writer will always be tempted to classify things as "firsthand" that are actually "inference" or as "inference" that is actually "synthesis." Push back on this.

Common misclassifications to watch for:
- "I used the tool a lot" does not equal firsthand knowledge of how the tool works internally
- "I've read a lot about this" does not equal reasoned inference; it's synthesis at best
- "Everyone knows X" does not equal any bucket
- "I modeled the economics" equals firsthand for the model, but inference for the conclusions drawn from it

### Step 3: Build the claim map

Use this structure:

```markdown
## Claim map: [piece title / topic]

### Firsthand (state with confidence)
- [claim] — anchor: [specific artifact, project, or experience]
- [claim] — anchor: [specific artifact, project, or experience]

### Reasoned inference (state with hedging)
- [claim] — extending from: [what firsthand evidence]
- [claim] — extending from: [what firsthand evidence]

### Bounded synthesis (include only with explicit framing)
- [claim] — synthesizing: [what sources], bounded by: [what you don't know]

### Do not claim
- [thing writer might be tempted to say] — why: [specific reason this isn't earned]

### Upgrade opportunities
- [claim currently at inference/synthesis] → could become firsthand if: [specific action]
  Action: [concrete thing to build, run, test, or measure]
  Timeframe: [realistic estimate]
  Worth it? [yes/no and why]
```

Use this exact output order so later gates can consume it cleanly:

1. `Claim map`
2. `Do not claim`
3. `Upgrade opportunities`
4. `Economics frame`
5. `Research Capture`, if a research pass is needed

Add this section after `Upgrade opportunities`:

```markdown
## Economics frame

- Cost implication: [what cost curve, constraint, or tradeoff this piece is really about]
- Pricing / monetization implication: [what this changes about willingness to pay, pricing design, or value capture]
- Market implication: [what this suggests about competition, adoption, or product viability]
- Weakest economics link: [where the argument is still hand-wavy]
```

### Step 4: Research pass, if needed

If the claim map reveals critical gaps — things that need to be true for the piece to work but are not yet anchored — design one research pass, not an open-ended exploration.

The research pass should produce:
- A reading plan — 2-3 sources maximum, not 10. Use specific documents, posts, or papers, not "read about X."
- An application plan — how to turn what you read into something you can test. The question is always: can you build, run, or test something that makes you encounter this concept firsthand?
- A scope-down option — if you can't apply it, reframe the claim to stay within what you can observe from your position

When the output is being written into an idea note, include this section exactly:

```markdown
## Research Capture

### Sources
- [source title] — [why this source is worth reading]

### Findings
- [fact, framing, or constraint learned from the source]

### Open questions
- [what is still unknown and why it matters]

### Economics angle
- [the economic implication the source supports, weakens, or complicates]

### Application plan
- [what to build, run, test, or measure]
```

The application test:
1. Can you build or run something related to this within a week? Do that first, then write from the experience.
2. Can you add this to an existing project like FlowState, a work model, or a Claude Code workflow? Do that.
3. Neither? Scope the claim to business implications only. Be explicit about the boundary.

### Step 5: Decision log prompt

Ask the writer: "What technical decisions have you made recently — in FlowState, at work, in any side project — that relate to this topic?"

Capture these. They are often the strongest anchors, and the writer forgets to mention them unless prompted. A decision like "I chose Whisper base over small because the latency difference was more important than the accuracy gain for my use case" is worth more than three research papers.

## Rules

- Never let a claim go unclassified. Every statement in the eventual post should trace back to a bucket.
- Never upgrade a claim without evidence. "I feel like I know this" is not firsthand.
- One research pass per idea. If the writer wants a second pass, push back unless their application experiment produced a genuinely surprising result that changes the claim.
- The "do not claim" section is as important as the "firsthand" section. Knowing what to leave out is what makes the piece credible.
- Side projects count as firsthand signal fully. FlowState, personal experiments, and open-source contributions are as valid as work experience for credibility purposes.
- Decision logs from projects are the highest-value raw material. Always prompt for them.
- Never leave a bounded synthesis claim standing on sources alone. Add firsthand signal or cut it.
- Never leave the economics implication implicit. Name it, or treat the piece as not yet ready.

## What this skill should never do

- Never reassure the writer that synthesis is good enough when they need firsthand signal
- Never produce a research plan longer than 3 sources
- Never let research become the comfortable alternative to writing
- Never classify something as firsthand just because the writer has strong opinions about it
- Never skip the "do not claim" section — it's the section that prevents embarrassment