You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
feat: Text Management Tool with style fixes and duplicate removal (v0.29.0)
- Add manage_text tool for text operations and style management
- Remove text creation from create_node tool to eliminate duplication
- Fix style deletion trailing comma issues in Figma API operations
- Fix font loading in all text operations to prevent "unloaded font" errors
- Remove convert_to_vectors operation from manage_text (use boolean_operations instead)
- Add version tracking to all get_plugin_status responses
Designed with ❤️ by oO. Coded with ✨ by Claude Sonnet 4
Co-authored-by: Claude.AI <[email protected]>
// ❌ INCORRECT: Using style ID with trailing comma will fail silently
96
+
// await text.setTextStyleIdAsync(params.textStyleId); // Will clear textStyleId to empty string
97
+
```
98
+
99
+
**Key Principles:**
100
+
-**ALWAYS** remove trailing commas from style IDs before any operations
101
+
- Style operations require searching through local style collections, not direct API calls
102
+
- Text style application must use cleaned style IDs to work properly
103
+
- Handle style not found errors properly in try/catch blocks
104
+
61
105
### Implementation Pattern Guidelines
62
106
**CRITICAL**: Before implementing any new feature, always examine existing implementations first to match established patterns.
63
107
108
+
#### MCP Tool Parameter Design Pattern
109
+
**ALWAYS use flat parameter structures** - never nest objects for tool parameters:
110
+
111
+
**✅ CORRECT (Flat):**
112
+
```json
113
+
{
114
+
"operation": "create_text_style",
115
+
"nodeId": "123:456",
116
+
"styleName": "Heading Large",
117
+
"styleDescription": "Main heading style"
118
+
}
119
+
```
120
+
121
+
**❌ INCORRECT (Nested):**
122
+
```json
123
+
{
124
+
"operation": "create_text_style",
125
+
"nodeId": "123:456",
126
+
"createTextStyle": {
127
+
"name": "Heading Large",
128
+
"description": "Main heading style"
129
+
}
130
+
}
131
+
```
132
+
133
+
**Design Principles:**
134
+
- All tool parameters must be at the root level of the parameter object
135
+
- Use descriptive flat parameter names (e.g., `styleName`, `styleDescription`)
136
+
- Never create nested configuration objects in tool interfaces
137
+
- This ensures consistency across all MCP tools and simplifies parameter handling
138
+
- Follow the pattern established by `manage_styles`, `manage_components`, and all existing tools
139
+
64
140
#### Handler Implementation Pattern
65
141
When adding new handlers to the Figma plugin:
66
142
1.**First**: Read existing handlers (e.g., `style-handler.ts`, `node-handler.ts`) to understand the pattern
@@ -86,29 +162,59 @@ export class NewHandler extends BaseHandler {
86
162
```
87
163
3.**Do NOT use**: `async handle(type: string, payload: any)` patterns
88
164
4.**Always match**: The exact interface contracts used by existing handlers
165
+
5.**Always use flat parameters**: Convert flat parameters to internal objects if needed for helper functions
89
166
90
167
### Documentation Guidelines
91
168
92
-
**IMPORTANT**: During the pre-release phase, documentation should be factual and concise about the current state of the tool, not changes or future plans.
169
+
**CRITICAL PRE-RELEASE RULE**: During pre-release phase (major version < 1.0.0), ALL documentation must reflect the current state only. Do NOT document changes, history, or what was added/removed - that's only for CHANGELOG.md.
170
+
171
+
#### Pre-Release Documentation Rules
172
+
-**Current State Only**: All documentation (README, DEVELOPMENT, EXAMPLES) describes what the tool does NOW
173
+
-**No Change Documentation**: Never mention "new", "added", "updated", "removed", "replaced" in documentation files
174
+
-**No Version History**: Don't reference previous versions or what changed between versions
175
+
-**No Migration Notes**: Don't include upgrade instructions or breaking change notices
176
+
-**Exception**: CHANGELOG.md is the ONLY file that documents changes commit-to-commit
93
177
94
178
#### Writing Style
95
179
-**Avoid superlatives**: Do not use words like "comprehensive", "complete", "robust", "extensive", "advanced", "cutting-edge", "powerful", "seamless", etc.
96
180
-**No test counting**: Do not mention specific test numbers in documentation as they change frequently and add no value to users
97
181
-**Be direct**: Use simple, clear language without marketing fluff
98
182
-**Focus on functionality**: Describe what tools do, not how amazing they are
183
+
-**Present tense only**: Use present tense to describe current capabilities
99
184
100
-
#### Documentation Files
101
-
-**README.md**: Main project documentation - should reflect current capabilities and setup instructions
102
-
-**DEVELOPMENT.md**: Technical documentation for contributors - architecture, development workflow, testing
103
-
-**EXAMPLES.md**: Usage examples and workflows - should demonstrate actual current functionality
104
-
-**CHANGELOG.md**: Exception to the rule - tracks changes from one commit to the next, documents incremental changes within sessions
185
+
#### Documentation Files (Pre-Release < 1.0.0)
186
+
-**README.md**: Current project state - capabilities and setup instructions as they exist now
187
+
-**DEVELOPMENT.md**: Current technical architecture - how the system works now for contributors
188
+
-**EXAMPLES.md**: Current usage patterns - how to use the tools that exist now
189
+
-**CHANGELOG.md**: ONLY exception - tracks changes from one commit to the next
105
190
106
191
#### Documentation Principles
107
192
- Stay factual and concise about current state
108
193
- Avoid hardcoded numbers that require frequent maintenance updates
109
-
- Focus on "what it does now" not "what it will do"
110
-
-Only CHANGELOG.md should document changes and progression
194
+
- Focus on "what it does now" not "what it will do" or "what it used to do"
195
+
-ONLY CHANGELOG.md documents changes and progression
111
196
- Use clear, direct language without superlatives
197
+
- Write as if this is the first version anyone has ever seen
198
+
199
+
#### Documentation Scope for Commits
200
+
**CRITICAL**: Documentation should only cover changes since the last commit, not intermediate development steps.
201
+
202
+
**Process for documenting changes:**
203
+
1.**Check actual changes**: Use `git status --porcelain` and `git diff --name-status HEAD` to see what files were modified, added, or deleted since the last commit
204
+
2.**Document only commit-level changes**: Do not document intermediate development steps or work-in-progress changes
205
+
3.**Use git diff to understand scope**: Review actual code changes to understand what functionality was added, removed, or modified
206
+
4.**Examples of what to document**:
207
+
- New tools added (complete functionality, not development iterations)
208
+
- Tools removed or deprecated
209
+
- Breaking changes to existing tool interfaces
210
+
- New major features or architectural changes
211
+
5.**Examples of what NOT to document**:
212
+
- Intermediate refactoring steps during development
213
+
- Temporary fixes that were later replaced
214
+
- Development debugging or testing iterations
215
+
- Changes that were made and then reverted in the same session
216
+
217
+
**For this project**: Compare the current state against the last git commit to determine what actually changed, then document only those changes in CHANGELOG.md.
0 commit comments