6DuckLearn Skills

detailed canvas builder

Build a detailed, conversion-ready canvas spec from a rough idea. Use when the task is to turn a campaign, storefront, event, product, or community concept into a structured bilingual canvas with clear sections, states, CTA logic, and trust/policy blocks.

canvas Tags: canvas, bilingual, conversion, campaign, event, storefront, zh-HK, community

Detailed Canvas Builder

Turn rough ideas into a usable canvas spec, not a loose moodboard.

Use this skill when the user wants a detailed canvas, landing page, event page, campaign page, storefront page, or HTML canvas plan. Default to en + zh-HK when the request is bilingual or Hong Kong-facing.

Core Rules

  • Start with one page goal and one primary action. If the action is unclear, ask for it or label the assumption.
  • Build a journey, not a poster: discovery, understanding, decision, commitment, and after-action states must be visible.
  • Prefer explicit mechanics over vague slogans. The user should understand how the page works before the CTA.
  • Include trust, policy, and fallback behavior by default for any threshold, redemption, priority, inventory, or time-bound mechanic.
  • Treat en and zh-HK as parallel outputs. Do not write one language fully and loosely paraphrase the other.
  • Do not invent legal terms, partner claims, metrics, availability, or social proof.

Input Checklist

Collect or infer only what is necessary:

  • canvas_type: event, campaign, storefront, product, community, lead-gen, other
  • business_goal: one primary conversion action
  • fallback_goal: optional secondary action if the main goal cannot complete
  • target_audience: primary audience and optional secondary audience
  • locale: default to en + zh-HK for bilingual output
  • brand_tone: campaign-led, commerce-led, editorial, community-led, premium, playful, etc.
  • reference_pattern: Broadway, SHOPLINE, both, or neither
  • operational_constraints: capacity, timing, threshold, eligibility, redemption, inventory, approval, price
  • trust_inputs: organizer, proof points, policies, refund/exchange logic, claims that must not be invented
  • platform_constraints: HTML canvas, content-only spec, or design brief
  • success_definition: what success looks like for this page

If the request spans multiple unrelated goals, split it into separate canvases instead of overloading one page.

Reference Selection

Use references intentionally:

  • Use Broadway-style references for threshold activation, private-show voting, community demand unlock, or event confirmation mechanics.
  • Use SHOPLINE-style references for conversion hierarchy, storefront sequencing, trust-building, FAQ placement, and mobile-first CTA rhythm.
  • When both fit, use Broadway for the mechanic and SHOPLINE for the page structure.

Reference decision rules:

  • Use Broadway-style references for threshold activation, private-show voting, community demand unlock, or event confirmation mechanics.
  • Use SHOPLINE-style references for conversion hierarchy, storefront sequencing, trust-building, FAQ placement, and mobile-first CTA rhythm.
  • When both fit, use Broadway for the mechanic and SHOPLINE for the page structure.
  • Do not overfit an event mechanic onto a normal storefront.
  • Do not overfit storefront structure onto a page that needs more editorial or community framing.

Workflow

  1. Define the page goal, primary CTA, audience, and operating constraints.
  2. Select the reference mode: Broadway, SHOPLINE, both, or generic.
  3. Draft the section order in conversion sequence.
  4. Define the page states and transition logic.
  5. Write bilingual core copy for hero, mechanism, CTA, trust/policy, and FAQ.
  6. Flag unsupported assumptions and anything that needs legal, PM, or business approval.
  7. Output a structured canvas spec.

Required Sections

Every canvas spec should include:

  • page brief
  • audience
  • primary CTA and optional fallback CTA
  • section-by-section structure
  • state model
  • trust/policy block
  • bilingual content blocks
  • implementation notes
  • open assumptions and approval items

Use this output structure:

page_brief:
  canvas_type: ""
  goal: ""
  audience:
    primary: ""
    secondary: ""
  primary_cta:
    id: ""
    label:
      en: ""
      zh-HK: ""
  fallback_cta:
    id: ""
    label:
      en: ""
      zh-HK: ""
  references_used: []
  assumptions: []

sections:
  - id: hero
    purpose: ""
    content:
      en:
        headline: ""
        subheadline: ""
        supporting_points: []
      zh-HK:
        headline: ""
        subheadline: ""
        supporting_points: []
    notes: []

states:
  - id: open
    trigger: ""
    user_message:
      en: ""
      zh-HK: ""
    CTA:
      en: ""
      zh-HK: ""

trust_and_policy:
  organizer: ""
  proof_points: []
  rules:
    en: []
    zh-HK: []
  non_inventable_claims: []

implementation_notes:
  design_direction: []
  mobile_priority: []
  analytics:
    primary_metric: ""
    guardrails: []
  do_not_invent: []

review:
  strengths: []
  approval_required: []
  failure_conditions: []

Minimum requirements:

  • page_brief.goal must be explicit.
  • primary_cta must exist.
  • sections must include hero, mechanism, trust/policy, FAQ, and CTA.
  • states must include a fallback state if the page has thresholds, inventory, timing, approval, or eligibility constraints.
  • trust_and_policy.non_inventable_claims must list any information that requires human confirmation.

Section Order

Default order:

  1. Hero
  2. Why it matters
  3. How it works
  4. Progress, threshold, or availability state
  5. Benefits, rewards, or value
  6. Trust, policy, and organizer credibility
  7. FAQ and edge cases
  8. Primary CTA
  9. Secondary CTA or fallback state

Reorder only when the use case strongly requires it.

State Model

Always define visible states when the page logic changes over time:

  • draft
  • open
  • in_progress
  • threshold_met
  • priority_claim_open
  • closed
  • fallback

Rename the labels to fit the use case, but preserve the logic.

State requirements:

  • Every state must say what happened, what the user can do now, and what happens next.
  • Every state must have bilingual messaging when bilingual output is enabled.
  • If the page includes priority benefits, define who qualifies and when.
  • If the page includes thresholds, define what counts toward the threshold and what happens if it is not met.
  • If the page includes time windows, define start and end behavior.

Bilingual Rules

  • Use the same information architecture in both languages.
  • Keep key terms stable across languages.
  • Shorten supporting copy before shortening trust, policy, or CTA text.
  • If one language needs a more natural rewrite, preserve intent and action parity.
  • Use zh-HK phrasing for Hong Kong-facing work.

Output

Return:

  1. A short brief summarizing the page goal and references used.
  2. A complete canvas spec in the schema from canvas-schema.md.
  3. A short review section:
    • what is strong
    • what needs human approval
    • what would make the canvas fail

Quality Gate

Before finishing, check:

  • Is the primary action obvious within the first screen?
  • Is the mechanism explained before commitment?
  • Are states, fallback behavior, and trust constraints explicit?
  • Do en and zh-HK say the same thing?
  • Is anything invented that should have been flagged instead?

Related skills

  • shopline storefront widget builder — Build interactive SHOPLINE Shop Builder widgets that improve conversion, drive upsells, and grow your customer base. Covers game mechanics (spin wheel, scratch card, lottery), urgency tools (countdown timer, shipping bar), and marketing widgets (email popup, coupon banner, referral). Always runs intention analysis before generating code.
  • ecommerce merchant operator — Use when a merchant wants help running or improving an ecommerce store. Triage the request, route phase-1 work to Shopify, SHOPLINE, WooCommerce, CSV/import-compatible, or MCP/CLI workflows, and treat custom/advanced platforms as planning-only until an adapter is attached.
  • ahr999 btc hodl — The BTC smart investment assistant based on the Nine Gods Index (AHR999) spans bull and bear markets. It automatically retrieves on-chain valuation data, investing when undervalued and pausing when overvalued, using objective indicators to replace subjective emotions. It supports two strategies: fixed amount and AHR999 tiered variable amounts, which are executed fully automatically once set.
  • ai ma trend v2 — This strategy is based on moving average trends and multi-period resonance, combining funding rates, volatility, trading volume, and market sentiment to comprehensively assess market setup indicators. It employs dynamic position sizing and a tiered risk control approach, adapting to both trending and ranging markets to achieve robust automated trading.
  • alpha vantage — Cross-asset analysis is its unique advantage—it can simultaneously pull macro data such as the S&P 500, gold, the dollar index, Federal Reserve interest rates, CPI, GDP, etc., allowing one to see at a glance whether "BTC is moving with risk assets today or pricing independently." In conjunction with the OKX Trade Kit, Alpha Vantage is responsible for in-depth historical and macroeconomic context, while OKX provides real-time prices, funding rates, and order book data, with both complementing each other to form a complete analysis chain.
  • apex crypto intelligence — AI-driven multi-exchange cryptocurrency market analysis, arbitrage detection, and hedge fund-level trading reports using real-time data from major exchanges.