shape-your-agent

작성자: sanity-io

대화형 세션으로, Sanity Context MCP 서버로 구동되는 AI 에이전트의 시스템 프롬프트를 제작합니다. 사용자가 에이전트를 정의하려 할 때 이 스킬을 사용하세요.

npx skills add https://github.com/sanity-io/context --skill shape-your-agent

Shape Your Agent

An optional, conversational workflow for creating a system prompt for an AI agent that uses the Sanity Context MCP server. This is for users who control the system prompt in their agent setup.

Don't have access to the system prompt? Skip this skill entirely. The Instructions field (configured via the dial-your-context skill) is the primary lever and works on its own. A minimal system prompt like "You are a helpful agent." combined with good Instructions field content scores 80%+ in our evaluations.

Before You Start

What the system prompt is for

The system prompt defines agent behavior — who it is, how it talks, what it refuses to do. Think of it as the agent's personality and policy manual.

What the system prompt is NOT for

These are handled elsewhere — don't duplicate them:

ConcernHandled by
Content schema, field meaningsInstructions field (Dial Your Context)
Query patterns, data relationshipsInstructions field (Dial Your Context)
GROQ syntax and guidanceMCP auto-provides
Response formatting rulesMCP auto-provides

Duplicating these in the system prompt creates conflicts. The MCP and Instructions field are purpose-built for data concerns — let them do their job.

The golden rule: less is more

Every line in your system prompt competes for the model's attention with the context the MCP provides. An over-engineered prompt can actually degrade answer quality. Start minimal. Add rules only when you have a concrete scenario that needs one.


How to run this session

This is a conversation, not a form. Ask questions, listen to the answers, and adapt. Don't run through the steps as a checklist — let the user's responses guide which areas need more depth. Some users will have strong opinions about tone and need 5 minutes on boundaries. Others will need help thinking through edge cases but already know their voice. Follow the energy.


Step 1: Understand the Use Case

Start by answering these questions:

  1. Who uses this agent? (customers, internal team, developers, general public)
  2. What setting? (support chat, docs site, internal tool, sales assistant)
  3. What problem does it solve? (answer product questions, troubleshoot issues, find content)
  4. What's the user's typical state? (exploring, stuck, evaluating, frustrated)

These answers drive every decision that follows. A support agent for frustrated customers needs different rules than a docs assistant for developers.

Step 2: Define Behavior

Choose concrete positions on each axis:

Tone: Professional / Casual / Friendly / Technical

  • Bad: "Be friendly and professional"
  • Good: "Use a warm, first-name tone. No corporate jargon. Write like a knowledgeable coworker, not a press release."

Verbosity: How much detail by default?

  • Bad: "Be concise but thorough"
  • Good: "Lead with a 1-2 sentence answer. Offer to elaborate. Never open with more than 3 sentences before getting to the point."

Technical level: Match the audience.

  • Bad: "Adjust to the user's level"
  • Good: "Assume the user knows JavaScript and REST APIs. Don't explain what an API key is. Do explain Sanity-specific concepts like GROQ projections."

Step 3: Set Boundaries

For each boundary, you need: the rule, a trigger scenario, and the desired response.

What to refuse:

  • Example: "If asked to write or modify content in the dataset, explain that you're a read-only assistant and point them to the Sanity Studio."

What to redirect:

  • Example: "For billing or account questions, say: 'I can help with product questions, but for billing please contact support@example.com.'"

Guardrails:

  • Example: "Never mention competitor products by name. If asked to compare, describe our capabilities without naming alternatives."
  • Example: "Don't quote specific pricing. Say 'Check our pricing page at [url] for current plans.'"

When information isn't found:

  • Example: "If the query returns no results, say so honestly. Suggest 2-3 related topics you can help with. Never fabricate an answer."

The cut test: For every rule, ask: "Can I describe a real user message that would trigger this?" If not, cut the rule. Untriggerable rules are dead weight.

Step 4: Draft the Prompt

Assemble your answers into a prompt. Use this structure:

You are [role] for [company/product].

## Voice
[2-3 concrete tone/style rules]

## Boundaries
[Only rules that passed the cut test]

## When you don't know
[Specific fallback behavior]

That's it. Most agents need 200-400 words here, not 1500.

Example: E-commerce Support Agent

You are a customer support agent for Acme Store.

## Voice
- Warm and conversational. Use the customer's first name if provided.
- Keep answers short — lead with the answer, then explain if needed.
- No marketing language. Don't upsell or promote products unprompted.

## Boundaries
- Never process returns, refunds, or order changes. Direct customers to support@acme.com for order issues.
- Don't quote exact shipping times. Say "typically 3-5 business days" and link to the shipping policy page.
- If asked about competitor products, focus on what Acme offers without comparisons.
- Don't share internal inventory numbers. Say whether something is "in stock" or "currently unavailable."

## When you don't know
- Say "I don't have that information" directly. Don't hedge or speculate.
- Suggest related topics you can help with.
- For urgent issues, direct to live support at support@acme.com.

This is ~150 words. It covers role, voice, boundaries, and fallback behavior. Everything else — product data, schema details, query patterns — lives in the Instructions field and MCP.

Step 5: Review & Iterate

Test your prompt against real scenarios:

  1. Write 5-10 questions your users would actually ask. Include at least 2 edge cases (something off-topic, something you want refused).
  2. For each boundary rule, write the question that triggers it. Verify the agent handles it correctly.
  3. Try removing rules one at a time. If the agent still behaves correctly without a rule, that rule was unnecessary. Cut it.
  4. Check for conflicts with the Instructions field. If both the system prompt and Instructions field address the same concern, remove it from the system prompt. The Instructions field wins for data concerns.

Signs your prompt is too long

  • The agent ignores some rules (attention dilution)
  • Answers feel generic or templated (over-constrained)
  • The agent repeats phrasing from the prompt verbatim (parroting)

Signs your prompt is too short

  • The agent's tone is inconsistent across conversations
  • Users get answers to questions that should be refused
  • The agent speculates when it should say "I don't know"

Quick Reference

System prompt checklist

  • Role is defined in one sentence
  • Tone rules are concrete (not "be professional")
  • Every boundary has a trigger scenario
  • Fallback behavior is specified
  • No overlap with Instructions field content
  • Under 500 words (aim for 200-400)
  • Tested against 5+ real user questions

The separation principle

LayerControlsExample
System promptAgent behavior"Never quote exact pricing"
Instructions fieldData guidance"Products are in the 'product' type with a 'price' field"
MCPQuery mechanicsGROQ syntax, response formatting
System promptCommunicating uncertainty"Say 'I don't have that information' and suggest alternatives"
Instructions fieldRecovery tactics"If product search returns empty, try support-article type"

Each layer has its job. Don't cross the streams.

sanity-io의 다른 스킬

tdd
sanity-io
레드-그린-리팩터 루프를 사용한 테스트 주도 개발. 사용자가 TDD로 기능을 구축하거나 버그를 수정하려 할 때, "레드-그린-리팩터"를 언급하거나, 원할 때 사용합니다...
performance-optimization
sanity-io
애플리케이션 성능을 최적화합니다. 성능 요구사항이 있거나, 성능 회귀가 의심되거나, Core Web Vitals 또는 로드 시간이…
content-experimentation-best-practices
sanity-io
콘텐츠 실험을 설계, 실행, 분석하여 전환율과 참여도를 개선하기 위한 체계적인 가이드입니다. 가설 프레임워크, 지표 선택, 표본 크기 계산, A/B 및 다변량 실험의 통계적 유의성 검정을 다룹니다. p-값, 신뢰 구간, 검정력 분석, 결과 해석을 위한 베이지안 방법에 대한 상세 자료를 포함합니다. 필드 수준에서 변형을 관리하고 외부 시스템과 연결하기 위한 CMS 통합 패턴을 제공합니다.
content-modeling-best-practices
sanity-io
구조화된 콘텐츠 모델링 가이드로, 스키마 설계, 재사용성, 멀티채널 전달을 다룹니다. 콘텐츠를 페이지가 아닌 데이터로 취급하고, 단일 진실 공급원을 유지하며, 미래 채널을 고려한 설계와 편집자 워크플로우 최적화를 위한 핵심 원칙을 포함합니다. 참조와 임베디드 객체 간의 결정 프레임워크, 관심사 분리, 콘텐츠 재사용 패턴을 제공하며, 플랫, 계층적, 패싯 접근 방식에 대한 분류 및 분류 체계 가이드를 포함합니다. 다음에 적용됩니다...
portable-text-conversion
sanity-io
HTML 및 Markdown 콘텐츠를 Sanity용 Portable Text 블록으로 변환합니다. 레거시 CMS에서 콘텐츠를 마이그레이션하거나 HTML 또는 Markdown을 Sanity로 가져올 때 사용합니다.
portable-text-serialization
sanity-io
Portable Text를 React, Svelte, Vue, Astro, HTML, Markdown 및 일반 텍스트로 렌더링하고 직렬화합니다. 모든 프론트엔드에서 Portable Text 렌더링을 구현할 때 사용합니다…
sanity-best-practices
sanity-io
Sanity CMS 개발을 위한 포괄적인 모범 사례 및 통합 가이드로, 다양한 프레임워크와 주제를 다룹니다. Next.js, Nuxt, Astro, Remix, SvelteKit, Angular 등 10개 이상의 프레임워크 통합을 프레임워크별 패턴 및 설정 가이드와 함께 포함합니다. 스키마 디자인, GROQ 쿼리 최적화, Visual Editing, Portable Text, 이미지, TypeGen, 현지화, 콘텐츠 마이그레이션을 위한 주제 가이드를 제공합니다. 작업 유형에 따라 관련 가이드만 로드할 수 있는 빠른 참조 구조를 제공합니다.
sanity-migration
sanity-io
다른 CMS 및 콘텐츠 시스템에서 Sanity로의 마이그레이션을 계획, 구현 및 검토합니다. AEM, Adobe Experience Manager, Contentful, Strapi, Webflow, WordPress, Payload, Drupal, Markdown/MDX/frontmatter 파일, WXR/XML 내보내기, CMS API, 데이터베이스 덤프, 정적 HTML에서 Sanity로 마이그레이션하거나 리플랫폼할 때, 또는 추출, 변환, Portable Text 변환, 에셋 마이그레이션, 리디렉션, 검증 및 전환 워크플로를 설계할 때 사용합니다.
data-analysisdatabasedevelopment