Files
interview-demo-code/.cursor/prompts/changelog.md
Nikita Kiselev 393bbb286b
Some checks failed
Telegram Mini App Shop Builder / Compute version metadata (push) Has been cancelled
Telegram Mini App Shop Builder / Run Frontend tests (push) Has been cancelled
Telegram Mini App Shop Builder / Run Backend tests (push) Has been cancelled
Telegram Mini App Shop Builder / Run PHP_CodeSniffer (push) Has been cancelled
Telegram Mini App Shop Builder / Build module. (push) Has been cancelled
Telegram Mini App Shop Builder / release (push) Has been cancelled
Squashed commit message
2026-03-11 23:00:59 +03:00

102 lines
3.2 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.
# Changelog Documentation Rules
## General requirements
- **Format**: Markdown
- **Structure**: One version = one page
- **Style**: Professional, concise, without marketing slogans
- **Language**: English
- **Target audience**: Developers and store owners
- **Content**: Only key changes, without unnecessary technical details
## Page structure
### Intro paragraph
- Short release description (12 sentences)
- Add 12 sentences about key changes
- Mention the main features and improvements
### Sections (strictly in this order)
1. **🚀 Added** new features and capabilities
2. **✨ Improved** improvements to existing features
3. **🐞 Fixed** bug fixes
4. **⚠️ Breaking changes** nonbackward compatible changes
5. **🔧 Technical changes** technical changes (separate section)
### Section rules
- **Do NOT** add a section if it has no items
- Use markdown bullet lists, no numbering
- Do not add links unless they are explicitly specified
- Do not add extra explanations, conclusions, or summaries
- Output only the content of the Markdown file, without comments
## Separating changes
### Business logic and processes
Sections "Added", "Improved", "Fixed", "Breaking changes" contain only changes related to:
- Store business processes
- User experience
- Functionality for store owners
- Selling / valuedriven features
### Technical changes
All technical changes go into a separate **🔧 Technical changes** section:
- No subsections, everything in a single list
- Only the most important technical changes
- Do not describe details that are not interesting to end users
## Writing style
### Terminology
- Use English terms (e.g. "navbar", not a localized variant)
- Avoid lowlevel technical terms in business sections (e.g. "customer_id" → "automatic customer linking")
### Descriptions
**For key selling features:**
- Provide detailed descriptions
- Highlight capabilities and advantages
- Emphasize value for the user
**For technical changes:**
- Be brief and to the point
- Avoid unnecessary details
**For regular features:**
- Be concise but informative
- Focus on user benefit
## Ordering
### In the "Added" section
Place key selling features **first**:
1. Main page configuration system based on blocks
2. Form builder based on FormKit
3. Yandex.Metrica integration
4. Privacy policy
5. Support for coupons and gift certificates
6. Other features
## Examples of good wording
### ✅ Good
- "Automatic linking of Telegram customers with ECommerce customers: the system automatically finds and links customers from the Telegram shop with existing customers in ECommerce by email or phone number, creating a unified customer base"
### ❌ Bad
- "Saving customer_id with the order to link with ECommerce customers: automatic linking of orders from Telegram with customers in ECommerce, unified customer base"
### ✅ Good
- "Navbar with logo and application name"
### ❌ Bad
- "Navigation bar with logo and application name" (too verbose, no added value)
## What not to include
- Internal development details (tests, static analysis, obfuscation)
- Technical details not interesting to users
- Excessively detailed technical descriptions
- Marketing slogans and calls to action