offer

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

offer: design it, price it, close it

报价方案:设计、定价与落地

Pricing is where founders bleed silently: too low out of fear, too clever out of theory, or changed weekly out of doubt. This skill runs the offer conversation like an operator: the founder's numbers first, tested mechanics second, receipts on everything.
  the offer question
        |
  [ ground ]     recall: their numbers, past pricing lessons, the vision
        |
  [ probe ]      wishful pricing dies here, before the market kills it
        |
  [ design ]     ladder -> price -> close -> launch, heuristics applied
        |
  [ receipts ]   their fact + external comparable, or PARKED
Before any step, read
${CLAUDE_SKILL_DIR}/../../CONVENTIONS.md
. This resolves from the installed skill directory to the plugin's shared contract, independent of the founder's working folder. Its receipts, filing, decision, and state rules govern this workflow.
定价是创始人默默“流血”的环节:因恐惧定得过低,因理论定得过于复杂,或是因疑虑每周调整价格。该技能以运营者的视角推进报价方案沟通:先以创始人的业务数据为基础,再应用经过验证的实操机制,所有环节都有依据支撑。
  报价相关问题
        |
  [ 基础梳理 ]     调取:用户的业务数据、过往定价经验、业务愿景
        |
  [ 排查校验 ]      不切实际的定价在此被排除,避免被市场淘汰
        |
  [ 方案设计 ]     层级设置 → 定价 → 落地 → 上线,应用启发式规则
        |
  [ 依据支撑 ]   用户的实际数据 + 外部可比案例,或标记为“暂存”
在开展任何步骤前,请阅读
${CLAUDE_SKILL_DIR}/../../CONVENTIONS.md
。该文件从已安装的技能目录解析至插件的共享协议,与创始人的工作目录无关。其中的依据留存、归档、决策及状态规则将指导整个工作流程。

Step 0: Ground in their reality

步骤0:基于用户实际业务梳理基础信息

Run the shared contract's Universal preflight. A Fresh, Partial, or Wrong-folder result routes to
/co-founder:co-founder-setup
(re-sync for Partial) and stops without designing or filing an offer. On Ready, recall first: stage and margins from the charter, every pricing-related learning and decision in the vault, what customers have actually paid before, the vision's direction. Cite by file. An offer designed against an imagined business fails in the real one.
Before sizing or creating anything, search
index.md
and every file in
wiki/initiatives/
for the same destination and price move; titles alone are not a dedupe key. Record the matching path and current state. An exact move gets one initiative for its whole lifecycle.
This is a money surface: the always-ask law applies to everything here.
Done when: their real numbers and history are on the table, or their absence is stated.
执行共享协议中的通用预检流程。若结果为“未就绪(Fresh)”“部分就绪(Partial)”或“目录错误(Wrong-folder)”,则跳转至
/co-founder:co-founder-setup
(部分就绪时重新同步),且停止设计或归档报价方案。若处于“就绪(Ready)”状态,首先调取以下信息:业务章程中的阶段与利润率、知识库(vault)中所有与定价相关的经验和决策、客户实际支付过的价格、业务愿景方向。需标注引用文件。脱离真实业务设计的报价方案在实际市场中必然失败。
在确定规模或创建任何内容前,搜索
index.md
wiki/initiatives/
下的所有文件,查找相同目标和定价变动;仅靠标题不足以判定重复。记录匹配路径和当前状态。同一变动在整个生命周期内仅对应一个项目。
这是涉及营收的环节:所有内容均需遵循“必问原则”。
完成标志:用户的真实数据和历史信息已梳理完毕,或已明确说明缺失的数据。

Step 0.5: Size the move, and stop if it is BIG

步骤0.5:评估变动规模,若为重大变动则停止当前流程

Public price changes, repricing existing customers, and anything that materially moves revenue are BIG. A truly small reversible test may size SMALL only when its bounded audience, cost, rollback, and non-impact on existing customers are recorded. A BIG move found here follows the dedupe result before any stub is created:
  • Exact
    idea
    or
    survived
    match:
    reuse that file. An
    idea
    returns to the gauntlet; a
    survived
    file proceeds only when its latest verdict is SURVIVES with no parked recommendation.
  • Exact
    planned
    or
    executing
    match:
    amend that initiative and preserve its state. If the approved Key decisions already contain this exact price move, offer may design the remaining terms against it. If the ask changes the approved move, route the change through plan's same-destination amendment checkpoint first. Never create or re-run the gauntlet on a parallel initiative.
  • Exact
    reviewed
    or
    banked
    match:
    the arc is closed; a renewed move creates one new
    idea
    with
    reopens:
    pointing to the closed file.
  • No exact match: create one new
    idea
    stub, append
    ## [date] offer | <initiative title>
    to root
    log.md
    , add the same event to the initiative's local Log, and hand it to the gauntlet. Durable state creation always has a root event even when offer design stops at the gate.
No designing or recommending happens while a required gauntlet or plan amendment is pending. The stub-creation event above is the invocation's one offer row. A genuinely small, reversible experiment proceeds only when sizing records it as small; a BIG label has no experiment-shaped bypass. Discovering mid-design that the move needed interrogation is discovering it too late.
Done when: the move is sized, and BIG moves are with the gauntlet instead of here.
公开调价、为现有客户重新定价,以及任何会显著影响营收的变动均属于重大变动。只有当明确记录了受限受众、成本、回滚方案以及对现有客户无影响时,真正微小且可逆的测试才会被判定为小规模变动。若此处判定为重大变动,需先遵循重复项处理规则,再创建任何草稿:
  • 完全匹配“创意(idea)”或“已通过(survived)”状态的项目: 复用该文件。“创意”状态的项目需返回至审核流程(gauntlet);“已通过”状态的项目仅当最新结论为“通过(SURVIVES)”且无暂存建议时,才可继续推进。
  • 完全匹配“计划中(planned)”或“执行中(executing)”状态的项目: 修改该项目并保留其状态。若已获批的核心决策中已包含该定价变动,则可针对剩余条款进行设计。若用户需求改变了已获批的变动,需先通过计划的同目标修改审核节点。切勿创建并行项目或重新启动审核流程。
  • 完全匹配“已审核(reviewed)”或“已归档(banked)”状态的项目: 该项目周期已结束;重启变动需创建一个新的“创意”状态项目,并在其中添加
    reopens:
    指向已归档文件。
  • 无完全匹配项: 创建一个新的“创意”状态草稿,在根目录
    log.md
    中追加
    ## [日期] offer | <项目标题>
    ,在项目本地日志中添加相同事件,然后提交至审核流程(gauntlet)。即使报价设计在入口处停止,持久化状态的创建也必须有一个根事件记录。
在必要的审核流程或计划修改完成前,不得进行任何设计或建议。上述草稿创建事件是本次调用的唯一报价记录项。只有当规模评估记录为小规模时,真正微小且可逆的实验才可继续推进;重大变动无实验性绕过途径。若在设计中途发现变动需要审核,则为时已晚。
完成标志:已评估变动规模,重大变动已移交至审核流程处理。

Step 1: Probe the wishful thinking

步骤1:排查不切实际的想法

Inventory every parameter the design would need: delivery input, capacity, cap, spot count, guarantee window, buyer behavior, and launch audience. Run each through the shared parameter gate before applying a heuristic. A missing value gets one question or a parked/unverified label and is excluded from current terms and customer-facing close.
Ask before you assert: never present a quantity, duration, sample size, date, or causal motive in prose before asking the founder for it or citing a receipt for it.
Before designing anything, the pricing-specific gap probes, each only where a real gap shows:
  • What has anyone actually paid? The strongest pricing fact is a payment that already happened. Interest, compliments, and survey answers are not payments.
  • What is the price of the current alternative? What the customer spends today (money or hours) bounds what the offer can charge.
  • Does the math survive their real volume? Revenue fantasies use fantasy volume. Run the unit economics at the volume the vault supports.
  • Can they operationally honor what the price implies? A cap, a guarantee, a service-heavy tier: each is a promise with an operating cost.
Done when: the design brief rests on facts, with the wishes named as wishes.
梳理设计所需的所有参数:交付输入、产能、上限、名额、担保周期、买家行为、上线受众。在应用启发式规则前,先通过共享参数审核。缺失的值需提出一次问题,或标记为“暂存/未验证”,并排除在当前条款和面向客户的落地内容之外。
先询问再断言: 在向创始人询问或引用依据之前,切勿在文案中提及任何数量、时长、样本量、日期或因果动机。
在开始设计前,针对定价相关的信息缺口进行排查,仅在存在真实缺口时进行:
  • 实际支付过的价格是多少? 最有力的定价依据是已发生的支付行为。兴趣、赞美和调查反馈都不属于支付行为。
  • 当前替代方案的价格是多少?客户当前的支出(金钱或时间)决定了报价的收费上限。
  • 该定价在真实业务量下是否可行? 营收幻想基于虚构的业务量。需根据知识库支持的业务量计算单位经济效益。
  • 他们能否在运营层面兑现定价隐含的承诺? 上限规则、担保条款、服务密集型层级:每一项都是带有运营成本的承诺。
完成标志:设计大纲基于事实,不切实际的想法已被明确指出。

Step 2: Design with the heuristics

步骤2:应用启发式规则进行设计

STOP. Read
references/offer-heuristics.md
now: it holds the distilled operator mechanics for ladders, caps, grandfathering, anchors, close sequence, guarantees, annual-versus- monthly, urgency legality, and launch timing, each with its trap. Advising on an offer without them is recalling generic frameworks, which is the thing this skill exists to replace.
Apply them to THIS business, one decision at a time, recommended answer attached: the ladder (what is free, what is gated, why), the price and its cap logic, the close (anchor, sequence, guarantee window), the launch (timing signal, warm slice). Where a heuristic and the founder's vault evidence disagree, the vault wins and the disagreement gets said.
Done when: each element of the offer has a recommendation with its mechanism and its trap named.
暂停操作。立即阅读
references/offer-heuristics.md
:其中包含了针对层级设置、上限规则、老用户 grandfathering、定价锚点、落地流程、担保条款、年付vs月付、紧急性合法性、上线时机等环节的提炼运营实操机制,以及每个环节的陷阱。不参考这些内容就提供报价建议,就是在调用通用框架,而这正是该技能想要替代的做法。
将这些机制应用于当前业务,逐一做出决策并附上建议:层级设置(免费内容、 gated内容及原因)、定价及其上限逻辑、落地环节(锚点、流程、担保周期)、上线环节(时机信号、预热受众)。若启发式规则与创始人知识库中的证据存在冲突,以知识库内容为准,并说明冲突点。
完成标志:报价方案的每个元素都有对应的建议,且明确标注了所采用的机制及潜在陷阱。

Step 3: Receipts before the recommendation ships

步骤3:提供建议前先准备依据支撑

Every element of the final recommendation carries both legs: at least one fact about THEIR business (a vault file: past payment, margin, churn, audience number) and at least one checked external comparable (run research; category pricing, a real benchmark). A leg missing moves that element to
Parked recommendations
in the shared canonical shape and names recall or research as the next action. "Needs your call" is only for a judgment fork after the evidence is present. No confident-sounding heuristic bypasses this: the heuristics choose the QUESTIONS, the receipts justify the answers.
Done when: the founder can click through to why, on every number.
Run the shared durable claim admission gate on every proposed cap, duration, capacity, price, buyer behavior, and urgency statement. Reopen each cited source and quote the exact supporting passage; recompute capacities from recorded inputs. Anything supplied only by the founder is
Founder-stated: unverified
. A heuristic supplies a question, never an invented input.
最终建议的每个元素都需具备两个支撑:至少一个关于用户业务的事实(知识库文件:过往支付记录、利润率、客户流失率、受众数据),以及至少一个经过核实的外部可比案例(开展调研;品类定价、真实基准)。若缺少任一支撑,则将该元素移至共享标准格式中的“暂存建议”部分,并说明下一步需调取信息或开展调研。只有在证据齐全后的判断分歧点,才可使用“需您决策”的表述。任何听起来自信的启发式规则都不能绕过这一步:启发式规则用于提出问题,依据用于支撑答案。
完成标志:创始人可点击查看每个数字背后的依据。
对每个提议的上限、时长、产能、价格、买家行为及紧急性声明,执行共享的持久化主张审核流程。重新打开每个引用来源并引用确切的支持段落;根据记录的输入重新计算产能。仅由创始人提供的信息标记为
Founder-stated: unverified
。启发式规则仅用于提出问题,绝不提供虚构输入。

Step 4: Bank it

步骤4:归档方案

The canonical home is always
wiki/business/offer.md
. Update it through the shared dedupe rule with Audience · Promise · Ladder and price · Terms · Receipts · Parked recommendations · History. Its base-five frontmatter carries
offer_state
:
draft
while any recommendation is parked,
approved
after explicit founder confirmation with every receipt present,
active
only after the founder confirms it is live, and
retired
when a successor takes over. Preserve superseded terms in History with dates; one file carries current truth.
Every price or term row is a T1 consent surface (shared contract, Immutable consent receipts): each carries
[receipt: raw/inbox/<file>#<exact words>]
pointing at the founder's actual words, captured into an immutable
raw/inbox/session-receipt-<date>-<slug>.md
when the yes is given. Offer may not move
offer_state
to
approved
or write a priced/term row as current truth without that receipt. Absent the founder's yes, the price stays a parked recommendation and
offer_state
stays
draft
; a system-generated date is never a founder-stated one. Keep
index.md
and
hub/business.md
pointed at the canonical offer. Before close, run the linked-state transaction across the offer's current constraints, its customer-facing close, index summary, linked initiative decisions, and metrics. A known-wrong or parked cap cannot remain in active close copy.
Then route without duplicating the design:
  • Execution work is needed (a launch, a tier build): append a pending
    queue.md
    entry from offer to plan whose
    source_paths
    contains
    wiki/business/offer.md
    . Plan owns the initiative and marks the entry done after the initiative reaches
    planned
    .
  • An initiative already exists: add the offer path plus the relevant rationale to Key decisions. The initiative points to the canonical terms instead of copying them.
  • The call passes the 3-test bar: write the short dated decision page for history and link it from offer.md. It is part of this offer event, not a second event. A
    wiki/decisions/**
    page is a T1 consent surface: it may be created only with the founder's
    [receipt: raw/inbox/<file>#<exact words>]
    for the exact call. Without that yes, write no decision page and leave the term parked.
Append exactly one row:
## [date] offer | <what was designed>
.
Close in chat: the offer in three lines, the strongest receipt, the ONE next move.
标准存储位置始终为
wiki/business/offer.md
。根据共享的重复项处理规则更新该文件,内容包含受众 · 承诺 · 层级与定价 · 条款 · 依据 · 暂存建议 · 历史记录。其基础五行前置元数据包含
offer_state
:若有任何建议处于暂存状态则为
draft
,经创始人明确确认且所有依据齐全后为
approved
,仅在创始人确认已上线后为
active
,当有替代方案推出时为
retired
。需在历史记录中保留已取代的条款及日期;一个文件承载当前的真实信息。
每条定价或条款记录都是一级(T1)同意依据(共享协议,不可变同意依据):每条记录都需包含
[receipt: raw/inbox/<file>#<exact words>]
,指向创始人的真实表述,该表述在获得同意时会被捕获到不可变的
raw/inbox/session-receipt-<date>-<slug>.md
文件中。若没有该依据,报价方案不得将
offer_state
改为
approved
,也不得将定价/条款记录写入当前真实信息中。若未获得创始人同意,价格需保持为暂存建议,
offer_state
保持为
draft
;系统生成的日期绝不视为创始人确认的日期。 保持
index.md
hub/business.md
指向标准报价方案文件。 结束操作前,针对报价方案当前的约束条件、面向客户的落地内容、索引摘要、关联项目决策及指标,执行关联状态事务。已知错误或暂存的上限规则不得保留在生效的落地文案中。
然后根据情况跳转,不重复设计:
  • 需要执行工作(上线、搭建层级):从报价方案向计划的
    queue.md
    添加一个待处理条目,其
    source_paths
    包含
    wiki/business/offer.md
    。计划模块负责该项目,当项目进入“计划中”状态后标记该条目为已完成。
  • 已存在相关项目: 将报价方案路径及相关理由添加至核心决策中。项目需指向标准条款,而非复制内容。
  • 决策通过三项测试标准: 撰写简短的带日期决策页面用于留存历史,并从offer.md链接至该页面。该页面属于本次报价事件的一部分,而非单独事件。
    wiki/decisions/**
    页面是一级(T1)同意依据:仅当获得创始人的
    [receipt: raw/inbox/<file>#<exact words>]
    明确同意时,才可创建该页面。若未获得同意,则不得撰写决策页面,且需将条款保留为暂存状态。
追加恰好一行记录:
## [日期] offer | <设计内容>
在聊天中收尾:用三句话概括报价方案、最有力的依据、下一步唯一行动。

Mandatory filing gate

强制归档审核

  1. Run
    scripts/graph-audit
    on every touched durable file, including any initiative stub created while gating the offer.
  2. Fix every violation and rerun it. Offer state, initiative creation, root event row, and queue writes remain incomplete until it exits zero.
Done when: offer.md holds the current design, exactly one log row records the event, and any execution queue item has a durable queue ID.
  1. 对所有涉及的持久化文件(包括在报价审核期间创建的任何项目草稿)运行
    scripts/graph-audit
  2. 修复所有违规项并重新运行。直到脚本返回零值,报价状态、项目创建、根事件记录及队列写入才视为完成。
完成标志:offer.md承载当前设计,恰好一行日志记录该事件,任何执行队列条目都有持久化队列ID。