Add dynamo-content-designer as first shared organization custom agent

[Copilot]

• Inspect existing repo structure and upstream skill directory
• Fetch all skill files from DynamoDS/Dynamo
• Create .agents/skills/dynamo-content-designer/SKILL.md
• Create .agents/skills/dynamo-content-designer/assets/ (7 asset files: blog-posts, feature-documentation, node-descriptions, node-errors-warnings, release-notes, tutorials-user-guides, ui-content)
• Update agent wrapper canonical-source reference to local path
• Validate (CodeQL clean; one upstream phrasing note in node-descriptions.md left as-is — verbatim from upstream)

Original prompt

I want to use this repo as collection of shared custom agents for the organization. docs https://docs.github.com/en/copilot/how-tos/administer-copilot/manage-for-organization/prepare-for-custom-agents

Can you bring in dynamo-content-designer agent to begin with ?https://github.com/DynamoDS/Dynamo/blob/master/.github/agents/dynamo-content-designer.agent.md

[Copilot]

Pull request overview

Adds the first shared organization custom agent, dynamo-content-designer, along with its canonical skill definition and supporting writing guideline assets.

Changes:

• Added a GitHub custom agent wrapper at .github/agents/dynamo-content-designer.agent.md.
• Added canonical skill definition at .agents/skills/dynamo-content-designer/SKILL.md with references to content-type assets.
• Added 7 supporting asset documents (UI content, release notes, node docs/errors, feature docs, blog posts, tutorials/user guides).

Reviewed changes

Copilot reviewed 9 out of 9 changed files in this pull request and generated 4 comments.

Show a summary per file

File	Description
.github/agents/dynamo-content-designer.agent.md	Adds the organization agent entrypoint wrapper referencing the canonical skill.
.agents/skills/dynamo-content-designer/SKILL.md	Defines the Dynamo Content Designer skill and links to content-type reference assets.
.agents/skills/dynamo-content-designer/assets/ui-content.md	UI content writing guidelines.
.agents/skills/dynamo-content-designer/assets/tutorials-user-guides.md	Templates for tutorials and user guides.
.agents/skills/dynamo-content-designer/assets/release-notes.md	Release note guidelines (plus embedded node description guidance).
.agents/skills/dynamo-content-designer/assets/node-errors-warnings.md	Guidance for node warning/error message writing.
.agents/skills/dynamo-content-designer/assets/node-descriptions.md	Guidance for node descriptions and extended node help.
.agents/skills/dynamo-content-designer/assets/feature-documentation.md	Feature documentation style/tone guidance.
.agents/skills/dynamo-content-designer/assets/blog-posts.md	Blog post structure and tone guidance.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Copilot]

This instruction uses apostrophes in the example ('like this') while referring to backticks. For correctness and clarity, show the example using real backticks (like this) (escaped appropriately) so readers don’t copy the wrong character.

[avidit]

@copilot apply changes based on this feedback

[Copilot]

Done in 271fce5 — replaced all apostrophe-as-backtick proxies with real backticks throughout the Do's and Don'ts sections (lines 97–123), including the inline `like this` example and all node name examples.

[Copilot]

release-notes.md includes a full "Node descriptions" guideline section, but the same guidance also exists (and is expanded) in assets/node-descriptions.md. Having two sources for the same rules increases drift risk; consider removing the duplicated section here and linking to the dedicated node-descriptions reference instead.

Suggested change

	Node descriptions briefly describe a node's function and output. In Dynamo, they appear in two places:
	- In the node tooltip
	- In the documentation browser
	Follow these guidelines to ensure consistency and help save time when writing or updating node descriptions.
	#### Overview
	Descriptions should be one to two sentences. If more info is needed, it can be included under In Depth in the Documentation Browser.
	Sentence case (capitalize the first word of a sentence and any proper nouns). No period at the end if the description is one sentence. Use a period at the end if the description is two or more sentences.
	Language should be as clear and simple as possible. Define acronyms at first mention unless they are known even to non-expert users.
	Always prioritize clarity, even if that means deviating from these guidelines.
	#### Guidelines
	| Do's | Don'ts |
	|------|--------|
	| Start the description with a third-person verb. Example: "Determines if one geometry object intersects with another" | Don't start with a second-person verb or with any noun. Bad example: "Determine if one geometry object intersects with another" |
	| Use "Returns," "Creates," or another descriptive verb instead of "Gets." Example: "Returns a Nurbs representation of a surface" | Don't use "Get" or "Gets." It's less specific and has several possible translations. Bad example: "Gets a Nurbs representation of the surface" |
	| When referring to inputs, use "given" or "input" instead of "specified." Example: "Deletes the given file." You may use "specified" when not directly referring to an input. Example: "Writes text content to a file specified by the given path" | Don't use "specified" when directly referring to inputs. Bad example: "Deletes the specified file" |
	| Use "a" or "an" when first referring to an input. Use "the given" or "the input" for clarity. Example: "Sweeps a curve along the path curve" | Don't use "this" when first referring to an input. Bad example: "Sweeps this curve along the path curve" |
	| Use "a" or "an" when first referring to an output. Use "the" only with "input" or "given." Example: "Copies a file. Copies the given file" | Don't use "the" on its own for outputs. Bad example: "Copies the file" |
	| Capitalize the first word of a sentence and proper nouns. Example: "Returns the intersection of two BoundingBoxes" | Don't capitalize common geometry objects. Bad example: "Scales non-uniformly around the given Plane" |
	| Capitalize Boolean, True, and False for output. Example: "Returns True if the two values are different" | Don't lowercase Boolean, True, or False. Bad example: "Returns true if the two values are different" |
	For node description guidance, refer to the dedicated reference in `assets/node-descriptions.md`.

[avidit]

@copilot remove the Node descriptions section from release-notes.md

[Copilot]

Done in e44d19f — removed the full "Node descriptions" section from release-notes.md and replaced it with a single line pointing to assets/node-descriptions.md.

[Copilot]

This sentence is grammatically broken ("immediately behind the nodes operational or graph") and is hard to understand. Please rewrite it (e.g., clarify that most users don’t need advanced details unless they’re relevant to uncommon scenarios or the node’s operational context).

Suggested change

	However, most users have no need for the advanced technical details applicable to using the node in any other uncommon or immediately behind the nodes operational or graph. Unless there's a compelling reason to include information at this expert level, omit it.
	However, most users do not need advanced technical details unless they are relevant to uncommon scenarios or to the node's operational context in a graph. Unless there's a compelling reason to include information at this expert level, omit it.

[Copilot]

This section says to use Markdown backticks but shows an apostrophe (') instead. That’s ambiguous and may lead to authors using the wrong character. Please update the text and examples to use actual backticks (`) (escaping them in Markdown if needed).

[avidit]

@copilot apply changes based on this feedback

[Copilot]

This was already addressed in 271fce5 — all apostrophe-as-backtick proxies in the Do's and Don'ts sections were replaced with real backticks, including the `like this` example and all node name examples.