SKILL.md13.2 KBView on GitHub ## Product Context
Cedar is an AI-powered email client for B2B sales teams. It sits on top of Gmail and helps salespeople manage their pipeline, draft follow-up emails, track deals, and automate CRM updates — all from their inbox. Key customer-facing features include:
- The Cedar agent — reads emails, drafts follow-ups, and updates CRM fields automatically
- Deals view — a pipeline-style view of all active sales conversations
- AOPs (Agent Operating Procedures) — per-deal-type playbooks that control how the agent behaves
- Working memory / conversation fields — structured data the agent tracks per deal (status, next steps, priority, deal value, etc.)
- Post-meeting follow-up drafts — automatic draft generation after meetings
- Tasks page — a daily to-do list of follow-ups and actions the agent surfaces
- Chat — an AI assistant that knows everything about the user's deals
- Canvas — AI-generated dashboards and views inside Cedar
- CRM integrations — Salesforce, HubSpot, Attio, Copper sync
- Slack notifications — post-meeting follow-up alerts, daily digests
## Task
Transform the provided git commit log and PR descriptions into a well-organized, user-friendly changelog for Cedar. The changelog should highlight what changed in a way that's easy for Cedar users (salespeople) to understand. Customer-facing changes must be clearly separated from technical/backend updates.
## Output file
After generating the changelog, write (or append) it to a weekly file:
**Path:** `docs/changelogs/YYYY-WNN.md` where `YYYY` is the current year and `NN` is the ISO week number (zero-padded). Example: `docs/changelogs/2026-W12.md`
**Logic:**
- If the file does not exist → create it with the full changelog as the content, with a heading:
```markdown
# Changelog — Week NN, YYYY
```
- If the file already exists (automation ran earlier in the same week) → append a separator and the new entry below the existing content:
```markdown
---
*Update — [Month Day, YYYY]*
[new changelog sections]
```
Create the `docs/changelogs/` directory if it doesn't exist. Do not create a new file for each run — only one file per calendar week.
---
## Input format
The input is a combined document of recent changes, one block per commit/PR:
```
Commit: <hash> <commit title>
PR title: <title> (if available)
PR description: <Greptile-generated or manually written PR body> (if available)
---
```
When a PR description is present (from Greptile or manual writing), prefer it over the commit message — it contains far more context about what actually changed and why. The commit message is a fallback for direct pushes with no associated PR.
Treat each block as a single change. Group related blocks (e.g. multiple commits in one PR) into a single changelog entry.
## Important distinction: User-facing vs Backend changes
**User-facing changes** (for New features, Improvements, and Fixes sections):
- Features visible in Cedar's UI (deals view, tasks page, chat, canvas, settings)
- Changes to how the agent behaves — new drafting logic, new AOP capabilities, better field updates
- Visual updates, new buttons, forms, or screens
- Workflow improvements that users directly experience
- CRM sync behavior changes visible to the user
- Slack/email notification changes
- Performance improvements users can notice (e.g. faster draft generation)
**Backend/Technical changes** (for Behind the scenes section ONLY):
- Database schema changes or migrations
- Server/infrastructure configuration
- Agent prompt changes or LLM model changes (unless they produce a noticeably different user experience)
- Internal tooling, admin playground features (e.g. account-setup skill, admin scripts)
- Code refactoring with no behavior change
- Logging, monitoring, error tracking
- API endpoint changes not exposed to users
- Any change that users don't directly see or interact with
**Important:** New agent tools or skills that users can invoke (e.g. web search, person enrichment,
company enrichment, new chat capabilities) are **user-facing** even if implemented as backend skills.
Ask: "Can a Cedar user trigger or benefit from this through the UI or agent?" If yes, it goes in
New features or Improvements — not Behind the scenes.
## Output format
Create a clean, user-focused changelog with the following structure. Use sentence case throughout (capitalize only the first word and proper nouns):
1. **New features** - Major new functionality visible in the app
- Create a level 2 heading (## New features)
- Include ONLY features users can see and interact with
- Highlight only the single most significant new feature with a level 3 heading (### Feature name)
- Include 1-2 short paragraphs describing what it does and its benefit to the user
- Combine related commits into one cohesive feature description
- All other new features go in Improvements as bullet points
- EXCLUDE: backend APIs, database features, infrastructure, internal tools
2. **Improvements** - Enhancements to existing user-facing functionality
- Single section with level 2 heading (## Improvements)
- Bullet point list, one sentence each
- Focus on what users will notice different
- Include ONLY changes users can see or experience directly
3. **Bug fixes** - User-facing issues that have been resolved
- Single section with level 2 heading (## Fixes)
- Bullet point list, one sentence each
- Describe from the user's perspective what was broken and is now fixed
- EXCLUDE: API errors, database issues, server problems unless they caused a visible user-facing problem
4. **Behind the scenes** - ALL technical and internal changes
- Single section with level 2 heading (## Behind the scenes)
- Bullet point list of ALL backend/technical changes
- Translate technical language into plain English
- This is the ONLY place for infrastructure, database, agent prompt, and refactoring changes
## Cedar-specific terminology
When writing changelogs, use Cedar's own terms correctly:
- **Agent / Cedar agent**: The AI that reads emails, drafts follow-ups, and updates CRM fields automatically
- **AOP (Agent Operating Procedure)**: A per-deal-type playbook that tells the agent how to behave for that conversation type (e.g. Deals, Recruiting)
- **Working memory / conversation fields**: The structured data the agent tracks per deal — status, next steps, priority, deal value, etc.
- **Deals view**: The pipeline-style view where users manage their sales conversations
- **Tasks page**: The daily to-do list of follow-ups and actions surfaced by the agent
- **Canvas**: An AI-generated dashboard or view inside Cedar
- **Chat**: The AI assistant users can ask questions about their deals
- **Post-meeting follow-up**: An email draft automatically generated after a meeting
- **Sequences**: Outbound email sequences sent to Cedar users (internal marketing — not a customer-facing Cedar feature)
## Guidelines
- Strictly separate user-facing changes from backend changes
- If unsure whether something is user-facing, ask: "Can a salesperson using Cedar see or interact with this?" If no, it goes in Behind the scenes
- Agent prompt/LLM changes go in Behind the scenes UNLESS they produce a visible behavior difference (e.g. "drafts are now shorter and more direct")
- Group related commits into logical features
- Translate technical language into salesperson-friendly terms
- Remove file paths, function names, and implementation details
- Focus on what changed and why it matters to the user's daily workflow
- Present in order of importance
- Use sentence case throughout
- Keep feature headings short and user-focused
## Example of appropriate feature headings
Keep feature headings short, direct, and user-focused:
- "Salesforce field sync"
- "Post-meeting follow-up drafts"
- "Slack notifications"
- "Deal pipeline view"
- "AOP editor"
- "Chat citations"
- "HubSpot integration"
- "Conversation field updates"
AVOID backend-focused headings like:
- "AOP selection agent refactor" ❌
- "Database migration" ❌
- "Webhook endpoint" ❌
- "LLM prompt update" ❌
- "tRPC route changes" ❌
- "Runtime config" ❌
## Synthetic example demonstrating the principles
```markdown
## New features
### Slack notifications after post-meeting follow-ups
Cedar now sends you a Slack notification when a post-meeting follow-up draft is ready for review. Instead of checking your tasks page to see if a draft was generated after a call, you'll get a direct message as soon as it's ready — with a link to open it in Cedar and send.
You can connect Slack and manage notification preferences in Settings → Notifications.
## Improvements
- The agent now updates the Next Steps field automatically after each new email in a deal thread, so your pipeline always reflects the latest state of each conversation
- Deals view now shows the last contacted date for each conversation, making it easier to spot threads that need a follow-up
- Cedar chat now includes citations — quoted excerpts from the emails and meetings it used to answer your question
- The AOP editor now shows a live preview of how the agent will classify a new email before saving
## Fixes
- Fixed an issue where post-meeting follow-up drafts were not generating for back-to-back meetings on the same day
- Fixed a bug where deal status was not updating in Salesforce when changed from Cedar
- Fixed an issue where the tasks page was showing completed tasks that had already been archived
## Behind the scenes
- Improved the AOP selection agent's accuracy for edge cases where the first email is a calendar notification from Calendly
- Updated the server runtime configuration to reduce cold start latency
- Migrated the agent execution history table to support new task-centric lifecycle states
- Fixed a bug in the Salesforce sync that caused duplicate company records when the same domain appeared in multiple deals
```
## Real changelog examples (Cedar)
### Example 1: Salesforce sync + Slack notifications
```markdown
## New features
### Salesforce sync
Cedar now syncs your deal data with Salesforce in real time. Any change you make to a deal in Cedar — status, next steps, priority — is reflected in Salesforce automatically. Conversely, any update made in Salesforce syncs back to Cedar within the hour, so both tools always show the same data.
The agent will continue to update Next Steps and Next Step Date automatically as emails come in. For Stage, Amount, Seats, Forecast Category, and Close Date: Cedar won't edit these automatically, but changes you make in Cedar will push to Salesforce — so you can work entirely out of Cedar except when creating a new opportunity.
## Improvements
- Cedar now sends a Slack notification when a post-meeting follow-up draft is ready — connect Slack in Settings → Notifications
- Cedar chat now includes citations so you can see exactly which emails and meetings informed each answer
## Fixes
- Fixed an issue where multiple Cedar records were being created for the same Salesforce opportunity
- Fixed a data integrity issue where Cedar and Salesforce could show different status values after a manual override
## Behind the scenes
- Rebuilt the Salesforce sync worker to process field updates in smaller batches, reducing the risk of timeout errors during large account syncs
- Improved conflict resolution when the same field is updated in both Cedar and Salesforce within the same sync window
```
### Example 2: AOP improvements + agent accuracy
```markdown
## New features
### AOP editor
You can now view and edit your Agent Operating Procedures directly from the Settings page. Each AOP shows its selection criteria (how the agent decides which deal type applies) and the full set of instructions the agent follows. Changes take effect immediately on the next email processed in that deal type.
## Improvements
- The agent now correctly handles Calendly and other scheduling tool notifications — instead of classifying them as a deal type prematurely, it waits for a real email before assigning an AOP
- Post-meeting follow-up drafts now reference the specific action items discussed in the meeting, not just a generic summary
- The tasks page now groups follow-ups by company, making it easier to batch your outreach each morning
## Fixes
- Fixed a bug where conversations were staying classified as "Non-deal professional relationships" even after a follow-up email made the deal context clear
- Fixed an issue where the agent was updating working memory fields on archived conversations
## Behind the scenes
- Improved the AOP selection skill's prompt to handle edge cases like POCs, pilots, and scheduling-tool-only conversations
- Updated the no-op check to correctly skip agent execution for Vendor notification and Inbound cold pitch AOPs
```
These examples demonstrate:
1. User-facing features only in the first three sections
2. All infrastructure, prompt, database, and backend changes in Behind the scenes
3. Agent behavior changes go in Behind the scenes UNLESS the user-visible output is different — then they go in Improvements
4. Cedar terminology used correctly throughout (AOP, working memory, deals view, tasks page, agent)
5. Consistent sentence case
6. User-friendly language focused on what salespeople actually care about: their pipeline, follow-ups, CRM sync, and time saved
7. Don't sound repetitive — vary sentence structure across bullet points