lov-skill-pricing

Skill Pricing Card

Turn a Skill's price from a wild guess into a Pricing Card that can be explained to creators, buyers, and channels. The result focuses on deliverable value: suggested price, price band, pricing rationale, channel fit, promotion actions, risks, and evidence gaps; internal prompts, source file details, and personal background serve only as judgment context.

Triggers

Activate when

• The user says "price this Skill", "set unified pricing for all Skills", "generate a Skill Pricing Card", or "evaluate how much this Skill is worth".
• The user provides Skill source code, README, capability description, user results, or existing prices, and wants pricing, package, and promotion recommendations.
• The user asks to “price this Skill”, “create a Skill Pricing Card”, “review Skill monetization”, or “set a price ladder for these Skills”.

Do not activate when

• The user only needs to implement, fix, refactor, or publish a Skill; hand these off to the corresponding development or publishing capabilities.
• The user only needs to look up a platform's current fee rates, payment interfaces, or contract terms; first use the fact-verification capability, then bring the conclusions back to this Skill.
• The user only wants ordinary SaaS subscription or physical goods pricing, and the delivery unit is not an Agent Skill.

Product contract

• Result unit: One Skill corresponds to one card; batch requests use the same scoring criteria and retain independent evidence and assumptions for each item.
• Cost floor: Include requirements analysis, development, testing, documentation, publishing, maintenance, support, and direct costs; convert creator time using an explainable hourly rate or salary benchmark.
• Value anchor: Use time saved by users, reduced outsourcing spend, delivery quality, revenue opportunities, and risk reduction as evidence; outcome descriptions take precedence over feature lists.
• Value adjustment: Evaluate scarcity, purchase confidence, actual value, and the data/ecosystem flywheel, and record maintenance burden and replication risk.
• Display unit: LovStudio's product cards, detail pages, packages, subscriptions, and purchase entry points display only Credits; fiat amounts such as RMB, USD, and HKD are allowed only on the Credits top-up interface.
• Separation of accounting and display: The cost floor and value anchor may be accounted internally in fiat, then converted into product prices according to the currently verified Credits exchange rules; internal fiat valuations must not flow back into product displays.
• Channel boundaries: Distinguish list price, launch price, subscription price, per-use price, package price, and service quote; fiat prices mandatorily required by external marketplaces are recorded only in the corresponding channel execution information and are not used as LovStudio product price displays.
• Public expression: The external card explains "why this price is reasonable, what the buyer gets, and what the usage risks are", avoiding exposure of internal prompts, private data, or unverifiable revenue promises.

For the complete scoring table, formulas, score explanations, and card template, see Pricing Card specification。

Workflow (MANDATORY)

Follow these steps in order.

Step 0: Resolve the Skill root and reference

1. Use SKILL_DIR; when missing, infer the root directory from the current installed Skill context.
2. Check $SKILL_DIR/references/pricing-card.md and $SKILL_DIR/scripts/validate_skill.py。
3. Read the Pricing Card specification, then process the input; when resources are missing, report the relative path and pause output.

For manual verification, you can run:

export SKILL_DIR="/path/to/lov-skill-pricing"

Step 1: Establish the pricing subject

Build a fact list from the current request, Skill source code, README, manifest, historical prices, and user results:

• skill_id, version, delivery unit, and target buyer;
• inputs, outputs, typical completion time, reuse frequency, and dependency conditions;
• creator hours from requirements analysis to launch, estimated maintenance hours, support burden, and direct costs;
• results obtained by users, quantifiable benefits, alternatives, and existing quality evidence;
• target channel, Credits billing cycle, price ceiling, settlement method, internal valuation currency, current Credits conversion rules, and verification sources.

When input fields are missing, use project context and industry common sense to form "tentative assumptions," and mark each item in the card; ask one focused question only when a missing field would change the pricing model. When there is no evidence of user results, lower the purchase confidence score and do not fill the gap with imagined cases.

Step 2: Separate capability from internal context

Divide the information into four layers:

1. publishable capability: the results the buyer can obtain, the delivery scope, and the applicable conditions;
2. cost evidence: time, maintenance, support, infrastructure, and other direct costs;
3. value evidence: time saved, spending reduced, quality improvement, revenue opportunities, and risk reduction;
4. private context: source prompts, keys, internal paths, personal background, undisclosed strategies, and unverified promises.

The Pricing Card externally presents only the organized conclusions from the first 1–3 layers; layer 4 is used only for internal judgment and is summarized in the output as "evidence gaps."

Step 3: Build the cost floor and value anchor

According to the Pricing Card specification , calculate two boundaries:

• cost_floor: creator time cost + maintenance/support reserve + direct costs;
• value_anchor: a conservative estimate of the user-perceivable time value, alternative procurement cost, quality benefits, revenue opportunities, and risk reduction.

Provide baseline values and ranges separately. The cost range comes from uncertainty in time or rates; the value range comes from the strength of evidence for user results. Between the two is the discussable price space; using the cost floor directly as the sale price, or the theoretical value directly as the charged result, both require additional justification.

For the LovStudio channel, keep fiat cost and value ranges in the internal evidence layer, and give the product interface only the suggested Credits price, launch price, and price band derived from the current conversion rules. When conversion rules are missing or unverified, do not generate public prices using guessed exchange rates.

Step 4: Score the card

Record the following dimensions, weights, evidence, and notes on a 0–5 scale:

• Actual result value: 30%;
• Scarcity and difficulty of substitution: 20%;
• Quality evidence and purchase confidence: 15%;
• Value flywheel potential: 15%;
• Reverse score for maintenance, support, and delivery burden: 10%;
• Reverse score for replication risk and channel controllability: 10%.

Scores are only used to pin down the reasoning, not to replace facts. The card must also state both "positive facts" and "negative facts," and map the total score to a price positioning: validation entry, standard delivery, professional delivery, or flagship bundle. When the score is high but evidence is thin, prioritize a verifiable launch price and trial mechanism.

Step 5: Select the commercial shape

Choose based on delivery method and usage frequency:

• One-time purchase: clear results, stable boundaries, limited support burden;
• Subscription or quota: continuous maintenance, continuous generation, or significant infrastructure costs;
• Per-use/per-volume: single-use value is easy to measure, and user usage frequency varies greatly;
• Free entry + paid combination: the channel lacks payment capability, purchasing mindset is still forming, or results evidence needs to be accumulated first;
• Skill package + services: multiple stages reinforce each other, or the buyer needs implementation, migration, and customization support.

Output a single-item suggested price, launch test price, stable price band, and package relationships. All buyer-facing numbers for LovStudio channels are expressed in Credits, with period, channel, and basis attached; fiat currency is retained only as internal accounting evidence, or used in the Credits recharge interface. If an external market mandates fiat currency, record that channel's execution price separately and do not let it flow back to LovStudio product pages.

Step 6: Match the channel and promotion

Verify the target channel's current rules, then generate the corresponding actions:

• Channel supports installation only: use free entry, content distribution, result samples, and follow-up services to carry the value;
• Content-bound Skill: clearly state the immediate benefits of the article/video, the replication path, and the Skill delivery boundaries;
• LovStudio Agent self-service payment: provide machine-readable Credits pricing, installation, trial, version, and post-payment delivery information;
• External marketplace mandates fiat pricing: record and display its fiat execution price only in that external channel, while LovStudio still displays Credits;
• Supported paid creation marketplace: use launch pricing, usage examples, a clear support scope, and an upgrade path to reduce purchase hesitation.

Platform observations in the article are background material and are not equivalent to the current platform contract. For questions about fees, price floors and ceilings, settlement, or agreements, note the verification time and source; re-verify if the query result is outdated.

Step 7: Render the user-facing Pricing Card

Output according to the template, in fixed order:

1. One-sentence result and suggested Credits price;
2. Price range, billing form, channel, and launch test plan;
3. Cost floor and value anchor;
4. Six-dimension scoring table with evidence for each item;
5. The results the buyer gets, applicable boundaries, and usage risks;
6. Promotion strategy, package relationships, and triggers for the next re-evaluation;
7. Assumptions, evidence gaps, sources, and confidence.

In batch mode, attach a horizontal comparison table at the end, and explain the unified criteria and individual differences. Use capability and benefit descriptions for buyer-facing copy; put internal labels, personal information, and implementation sources in evidence notes rather than the main copy.

The suggested price, price band, launch price, and bundle price in LovStudio product cards, detail pages, packages, and purchase entries must all use Credits, and must not include ¥、$、HKD、CNY and other fiat amounts. Fiat recharge amounts belong only to the Credits recharge interface and do not enter the buyer-facing main copy of the Pricing Card.

Step 8: Validate the deliverable

Check item by item before delivery:

• The suggested price is between the cost floor and the value range, or the reason for exceeding the boundary is clearly stated;
• Every key number has an input, assumption, or source;
• LovStudio's public product prices, packages, and purchase entries display only Credits, and fiat currency appears only in the Credits recharge interface;
• Internal fiat valuations, external channel execution prices, and LovStudio Credits prices are not mixed together;
• Risks, maintenance scope, versions, and support boundaries can be understood by buyers;
• Article observations and current platform facts have been layered separately;
• Feature count, source code length, or author effort is not treated as user value on its own;
• Gaps, confidence, and re-evaluation conditions are clearly visible.

When a causal contradiction is found, return to Steps 1–3 and recalculate, and retain the adjustment rationale in the final card. The validation script only checks the Skill source structure; factual acceptance of the Pricing Card is still based on the input evidence and the current channel read-back.

Output contract

By default, output a Markdown Pricing Card; when the user specifies, a JSON summary can also be output. The LovStudio JSON fields must include at least:skill_id、version、display_unit: "credits"、billing_model、recommended_price_credits、price_range_credits、cost_floor、value_anchor、valuation_currency、weighted_score、channel、assumptions、evidence_gaps、confidence、review_trigger。valuation_currency It is only used for internal accounting; only the top-up interface or external market execution records may additionally include fiat currency display fields.

Dependencies

None. If current platform rates or rules are needed, use the fact-verification capability available at runtime, and write the source and time into the card.

Runtime context

Before running, read the skill.yamlin the same directory, injected by the host's skill-runtime in the order of "current request, project context, personal configuration, brand Profile, safe defaults", using only the fields declared in the manifest.

• When the required: true field is missing, ask the user one focused question according to questions ; the answer is used only for this run unless the user explicitly requests to save it.
• Profile is only used for public brand facts; personal configuration is only used for decision-making and is not automatically written into artifacts or source code.
• Debug errors provide a copyable context_id, field path, and source, without outputting secrets, full private paths, or raw content.

Runtime context (shared)

Before running, read this Skill package's skill.yaml, with skill-runtime/v1 context provided by the host. The field parsing order is: current request, project context, personal Preferences, brand Profile, general defaults.

• Use only the fields declared in the Manifest; Profile stores public brand facts, and Preferences stores personal work preferences.
• required: true When a field is missing, ask the user one focused question according to the Manifest's question configuration; save the answer only after the user explicitly agrees.
• Errors provide a copyable context_id, field path, and source, and the diagnostic content avoids secrets, full private paths, and raw configuration.

General feedback loop

When the user raises modification feedback during a Skill-driven task, the following must be executed before continuing the current artifact:

1. First determine whether the feedback is task-specific(this time only) or reusable(reusable across tasks).
2. task-specific Only modify the current task, do not change the Skill.
3. reusable First determine the scope: for domain rules, first update the corresponding canonical Skill; for rules applicable to all Skills, first update the shared specification.
4. After completing rule updates, versioning, lint, and distribution verification, then apply the modifications to the current task.
5. reusable The modification invalidates previous "confirm", "continue", and "send it"; after completing the current artifact modification and read-back, you must stop and wait for the user's next instruction, without automatically proceeding to publishing, submission, or other external writes.