Attributes have always been the answer to “where do I put context that doesn’t fit in a comment?”, release notes on a branch, decision records on a changeset, hand-off parameters. But until this release, that context had to be plain text. No headings, no lists, no code snippets, no formatting at all. And a hard 1,000-character cap that most real release notes hit long before they were done.
This release changes that. Attributes now carry Markdown, and the dialog you use to apply them understands the difference between a one-line value and a formatted document.
Markdown in the value
When you open the Apply Attribute or Edit Attribute dialog on a value that reads as Markdown, the dialog opens wider and splits into two panes: a monospace editor on the left, a live preview on the right. Type in the editor, watch the preview update as you go.
Plain values still get the compact dropdown flow you already know. The dialog picks the layout that fits the content. Nothing to configure, nothing to enable.
Paste is a shortcut
Preparing a release note in a Markdown editor somewhere else and pasting it in? The dialog notices. It peeks at the clipboard as you paste, and if the incoming text is Markdown, it flips into the split preview on the spot, with your text preserved. The old compact dropdown would have stripped your newlines silently, we don’t want that.
For plain-text pastes, nothing changes. The value stays a single line.
Room to actually write
The 1,000-character cap is now 5,000. Gives us, and you, headroom to spare. Because yes, we use it internally for our release notes.
Admins: seed a template
If you know an attribute is always going to be a Markdown document (say, a “Release Notes” attribute you apply to every task branch), you can seed the format with a default template. It lives in the attribute’s own comment field, using an extension of the `default:` marker you may already know from comma-separated defaults:
default: "# What changed
## Motivation
## What we did
-
## Screenshots
"
Now anyone applying that attribute lands in the split editor with the skeleton already filled in, cursor at the end, ready to write. No copy-pasting from a wiki, no “wait, what sections do we want again?”.
The classic form still works. default: v1, "value two", v3 populates the dropdown with three choices, the same way it always did. Only a *quoted, multi-line* value is treated as a template, so single-line lists keep behaving exactly as before.
Opt out of past-value suggestions
The Apply Attribute dropdown normally suggests values other people have used for the same attribute. Useful for status = Ready, less useful for something like Release Notes where every value is unique.
Set the attribute’s comment to just `default:` (marker only, nothing after the colon) and the dropdown stays empty. A lightweight opt-out you can toggle per attribute.
A confirmation before delete
Every attribute pill in the details panel has an X button next to it. Until this release, that X deleted the attribute value silently. One accidental click and you lost the release notes you had just written 
Now you get a Yes / No confirmation with a preview of the value you are about to remove. Same interaction pattern as changeset delete: nothing to learn, harder to shoot yourself in the foot.
Where should Markdown go next?
Attributes were the first place we brought Markdown, but they will not be the last. We are already looking at extending the same editor + live preview to other pieces of the product where the text you write today has to live as one flat line:
- Changeset comments
- Branch comments
- Code review comments
- And more places you tell us about
Which of these would help your team the most? Or is there a spot we have not thought of? Drop us a note here on the forum or through your usual support channel, the “how do you actually use this?” answers we collect from you drive most of what ships in each release.
Thanks for reading. See you in the next build.