VibeCherry template spec

JSON format

The JSON format is easiest to consume programmatically. A pack describes a vibe for a certain context: product reviews, research interviews, support replies, etc.

Minimal example

{
  "name": "support_reply_drafter",
  "version": "0.1.0",
  "kind": "support_reply",

  "tone": {
    "base": "warm_and_practical",
    "avoid": ["over_apologizing", "emoji_spam"]
  },

  "style_notes": [
    "Acknowledge the issue once.",
    "Explain what is happening in plain language.",
    "Offer one clear next step, not five.",
    "Keep paragraphs short."
  ],

  "structure": {
    "sections": ["acknowledge", "explain", "next_step"],
    "max_length": "medium",
    "reading_level": "standard"
  },

  "guardrails": {
    "do_not": [
      "Offer compensation unless explicitly instructed.",
      "Invent timelines or internal processes."
    ],
    "escalate_if": [
      "The user mentions legal action.",
      "The issue involves safety or security."
    ]
  }
}

Fields

• name: Machine-friendly identifier for the pack.
• version: Semver string.
• kind: High-level category: support_reply, product_brief,ux_review, story_seed, etc.
• tone: Human descriptions of voice; can be translated into model parameters or prompts.
• style_notes: Bullets that become in-context instructions.
• structure: Hints about sections, length, and reading level.
• guardrails: Hard "no"s and escalation rules for the AI.

Optional fields

{
  "context_tags": ["product:docs", "plan:pro"],
  "compatible_tools": ["chatgpt", "cursor", "claude"],
  "prompt_snippets": {
    "system_message": "You are a support rep...",
    "user_preamble": "Help me answer this ticket...",
    "examples": [
      { "input": "Ticket text...", "output": "Suggested reply..." }
    ]
  }
}

Markdown format

For humans editing in notes apps, you can use a simple markdown format with frontmatter. Tools can parse the frontmatter and treat the body as style notes.

Example pack (markdown)

---
name: product_spec_review
version: 0.1.0
kind: product_review
tone:
  base: thoughtful_but_direct
  avoid:
    - marketing_fluff
    - sarcasm
structure:
  sections:
    - summary
    - questions
    - risks
  max_length: medium
  reading_level: expert
guardrails:
  do_not:
    - rewrite the spec
    - change scope
---

# Product Spec Review

**Goal:** stress-test a product spec without derailing it.

- Start by summarizing the spec in 3–5 bullets.
- Ask 3–7 sharp, concrete questions.
- Highlight 2–3 risks or open assumptions.
- Don't nitpick wording; focus on decisions and tradeoffs.

Any fields from the JSON format can appear in the frontmatter. The body becomes an extendedstyle_notes block.

Using packs in tools

The exact wiring depends on the tool, but the general pattern is:

1. Load the pack (JSON or MD) from disk, a repo, or an API.
2. Turn tone, style_notes, and guardrails into a system/prompt block.
3. Use structure to shape the output and post-process if needed.

Example: building a system prompt (pseudo-code)

function buildSystemPrompt(pack, context) {
  return `
You are acting in the "${pack.name}" vibe (${pack.kind}).

Tone:
- Base: ${pack.tone.base}
- Avoid: ${pack.tone.avoid.join(", ")}

Style:
${pack.style_notes.map((n) => "- " + n).join("\n")}

Structure:
- Sections: ${pack.structure.sections.join(" → ")}
- Max length: ${pack.structure.max_length}
- Reading level: ${pack.structure.reading_level}

Guardrails:
- Do not: ${pack.guardrails.do_not.join("; ")}
- Escalate if: ${pack.guardrails.escalate_if.join("; ")}

Context:
${context}`;
}

Spec status & evolution

This is a draft. The immediate goal is to keep it:

• Small enough to remember.
• Flexible enough to adapt to any builder.
• Stable enough to version and share.

Future revisions may add:

• More formal JSON schema.
• Recommended field maps for specific tools (ChatGPT, Cursor, etc.).
• Optional links into ChatCard and EarthCloud so persona and vibe stay aligned.

If you start building around this format, feedback is welcome at [your contact details].