| name | dynamo-jira-ticket |
| description | Create structured Jira tickets for DynamoDS projects from bug reports, failing tests, or feature requests. Use this skill whenever writing a Jira ticket, triaging a bug, turning a vague issue into an actionable ticket, or writing acceptance criteria. Also use when the user mentions "file a ticket", "write a bug report", or "create a Jira issue" for a DynamoDS project. |
Dynamo Jira Ticket
When to use
- Creating a new Jira ticket from a bug report, failing test, or code investigation.
- Refining a vague issue description into a structured, actionable ticket.
- Writing acceptance criteria from a feature request or design discussion.
When not to use
- PR descriptions -- use the
dynamo-pr-description skill instead.
- Architecture questions -- use a repo-specific onboarding skill instead.
Inputs expected
A bug description, error log, failing test output, feature request, or code investigation findings.
Output format
A complete Jira ticket body ready to paste, following the canonical template in assets/template.md.
Workflow
- Gather evidence first. Before writing, identify supporting details from the issue description or code context.
- Write the ticket using the template at
./assets/template.md.
- Review -- ensure every section has concrete, verifiable content. No vague language.
Writing Rules
- Title: short, concrete, behavior-focused. Bad: "Dynamo crash". Good: "DynamoSandbox crashes on startup when
global.json specifies missing SDK version".
- Prefer behavior over implementation: describe what the user sees, not internal class names.
- Include evidence: paste error messages, stack traces, screenshots. Trim to relevant lines.
- Separate facts from assumptions: if you're guessing at root cause, say so explicitly.
- Acceptance criteria must be testable: each criterion should be verifiable by running a test or checking a specific behavior.
Ticket Template
Use the canonical template at ./assets/template.md.
Required sections in each generated ticket:
- Title
- Problem
- Expected Behavior
- Repro Steps
- Impact
- Acceptance Criteria
- Investigation Notes
Example: Good ticket
# [DYN-5678] String.FromObject node returns null for custom Python class instances
## Problem
When a Python Script node returns a custom class instance, passing it to `String.FromObject` produces `null` instead of calling `__str__` or `ToString()`. This breaks downstream string operations.
## Expected Behavior
`String.FromObject` should call the object's `ToString()` method (or Python `__str__`) and return the string representation, consistent with how it handles built-in types.
## Repro Steps
1. Open Dynamo Sandbox
2. Create a Python Script node with: `class Foo:\n def __str__(self): return "hello"\nOUT = Foo()`
3. Connect output to a `String.FromObject` node
4. Run the graph
5. Expected: `String.FromObject` outputs `"hello"`
6. Actual: `String.FromObject` outputs `null`
## Impact
- **Users affected**: Users with Python-heavy workflows using custom classes
- **Frequency**: Always (deterministic)
- **Severity**: Major (breaks string formatting workflows)
## Acceptance Criteria
- [ ] `String.FromObject` returns `__str__` result for Python objects with `__str__` defined
- [ ] `String.FromObject` returns `ToString()` result for .NET objects with custom `ToString()`
- [ ] NUnit test added covering the new behavior
- [ ] No regression on built-in types (int, float, list, dict)
## Investigation Notes
- **Root cause hypothesis**: The engine may be wrapping the Python return value in a way that loses the original type's `ToString()` override
Related Skills:
dynamo-pr-description
