Files
dss/.knowledge/adrs/archived/operational/SLACK_ANNOUNCEMENT_TEMPLATE.md
Digital Production Factory 276ed71f31 Initial commit: Clean DSS implementation
Migrated from design-system-swarm with fresh git history.
Old project history preserved in /home/overbits/apps/design-system-swarm

Core components:
- MCP Server (Python FastAPI with mcp 1.23.1)
- Claude Plugin (agents, commands, skills, strategies, hooks, core)
- DSS Backend (dss-mvp1 - token translation, Figma sync)
- Admin UI (Node.js/React)
- Server (Node.js/Express)
- Storybook integration (dss-mvp1/.storybook)

Self-contained configuration:
- All paths relative or use DSS_BASE_PATH=/home/overbits/dss
- PYTHONPATH configured for dss-mvp1 and dss-claude-plugin
- .env file with all configuration
- Claude plugin uses ${CLAUDE_PLUGIN_ROOT} for portability

Migration completed: $(date)
🤖 Clean migration with full functionality preserved
2025-12-09 18:45:48 -03:00

119 lines
4.7 KiB
Markdown
Raw Blame History

This file contains ambiguous Unicode characters
This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.
# Slack Announcement Template
Copy this message and post to [YOUR_TEAM_SLACK_CHANNEL] when ready to launch the pilot.
Replace [PLACEHOLDERS] with your team-specific details.
---
## Message
> 🎯 **DSS Principles Pilot: Architecture Decision Records**
>
> Hey team! We're running a 4-week pilot to strengthen our DSS principles adoption—and we want [PILOT_TEAM_MEMBER_1], [PILOT_TEAM_MEMBER_2], and [PILOT_TEAM_MEMBER_3] to be our partners in testing it.
>
> **The Experiment**
> We're using lightweight "Architecture Decision Records" (ADRs) to capture the rationale behind significant decisions we make. This helps us:
> - 📝 Capture "why" while it's fresh (not reconstruct from git history months later)
> - 🧅 Onboard new people with context, not just code
> - 💡 Make our core principles real, not just a document
>
> **The Pilot Team**
> This starts with the `dss_sync_figma` project. [PILOT_TEAM_NAMES], we're kicking off a 30-min sync on **[DAY], [DATE], [TIME]** to show how this works and get your feedback.
>
> **Why You?**
> You're building something complex right now with interesting trade-offs. Perfect for piloting this process. We want your **honest feedback**—if this feels valuable, great. If it feels like noise, tell us that too.
>
> **Learn More**
> Check out `.knowledge/adrs/README.md` for the full context and how this works.
>
> Questions? Drop them below or in the kickoff meeting.
>
> Let's go! 🚀
---
## Customization Checklist
- [ ] Replace `[YOUR_TEAM_SLACK_CHANNEL]` with actual channel name
- [ ] Replace `[PILOT_TEAM_MEMBER_1], [PILOT_TEAM_MEMBER_2], [PILOT_TEAM_MEMBER_3]` with actual names
- [ ] Replace `[DAY]` with day of week (Thursday, Friday, etc.)
- [ ] Replace `[DATE]` with date (Dec 12, etc.)
- [ ] Replace `[TIME]` with meeting time (2:00 PM, etc.)
---
## Timing
Post this message **24-48 hours before the kickoff meeting** to give team time to:
- Read the README
- Ask questions
- Mentally prepare
## Alternative (Longer Version)
If your team prefers more context, use this expanded version:
> 🎯 **DSS Principles Pilot: Let's Try Something New**
>
> We've spent the last month defining DSS's core principles—the "why" behind every decision we make. Now the real work begins: **bringing those principles to life in how we actually work.**
>
> **The Challenge**
> Principles are only as good as their adoption. And one of our biggest challenges is that decision rationale gets lost. You write code today, and six months later, a new team member asks, "Why did we do it this way?" Git history says *what* changed, but not *why*. That context is in Slack, in commit messages, or just in your head. It's lost.
>
> **The Experiment**
> We're testing a lightweight process: **Architecture Decision Records (ADRs)**. When we make a significant decision, we spend 15 minutes capturing:
> - What is the decision?
> - Why did we choose it?
> - What alternatives did we consider and reject?
> - What are the consequences?
>
> That's it. One file. Done.
>
> **The Pilot Team**
> [PILOT_TEAM_NAMES], you're building `dss_sync_figma` right now, and that project has *exactly* the kind of architectural decisions this is designed for. We're asking you to be our test pilots.
>
> **What We're NOT Asking**
> - Don't create ADRs for every decision (just the big, consequential ones)
> - Don't spend hours on documentation (15 mins, max)
> - Don't adopt new tools or learn new syntax (it's just Markdown)
>
> **What We ARE Asking**
> - Create 1-3 ADRs over the next month for the biggest decisions
> - Give us honest feedback: Does this help? Or is it just bureaucracy?
> - Help us understand what works and what doesn't
>
> **Kickoff Meeting**
> [DAY], [DATE], [TIME] 30 minutes
> We'll show you the template (it's tiny), write your first ADR together, and answer questions.
>
> **Learn More**
> - `.knowledge/adrs/README.md` Full overview
> - `.knowledge/adrs/001-...md` The meta-ADR explaining why we chose this approach
>
> Thanks for being our partners in this. Your feedback is what makes it work. 🚀
---
## Post-Kickoff Follow-up (Optional)
After the kickoff meeting, consider sending this short note:
> **ADR Kickoff Recap**
>
> Thanks everyone for the great kickoff! Here's what to do next:
>
> 📍 **Create ADRs** for your top 2-3 `dss_sync_figma` decisions over the next month
> 📝 **Template**: Copy `.knowledge/adrs/000-template.md`
> 🔗 **Link in PRs**: Add to the "DSS Principles Check" section
> 💬 **Questions**: Post in thread or grab me directly
>
> Check-ins: I'll reach out around week 2-3 to see how it's going.
> Retro: We'll do a 30-minute retrospective in Week 4 to gather your feedback.
>
> Let's see if this helps us move faster. 🎯
---
**Ready to send?** Replace the placeholders, copy, and paste to Slack!