Note: Productboard Spark is currently in open beta and available to all customers. The beta is a standalone experience that doesn't integrate with existing Productboard workspaces.
If you're on an Enterprise plan and workspace integration is important to you, contact your Productboard representative to discuss options. Otherwise, you can join the Spark beta here.
Skills are reusable instruction sets that tell Spark how to handle a specific type of task. Some skills are built into Spark and guide you through structured PM workflows step by step. Others are custom skills you create yourself, which means you can save your own workflows, automate repetitive prompts, and package domain knowledge into reusable commands you can invoke any time.
In this article:
- What are skills?
- Skill types
- Using skills
- Productboard skills
- Managing skills
- Creating a skill
- Best practices
- FAQ
- See also
How do skills work?
Skills are saved instruction sets that tell Spark how to handle a specific type of task. Once a skill is active, Spark can apply it automatically when the context is relevant, or you can trigger it directly using a /slash command.
Skills can include a prompt, an attached Python or shell script, and static resource files such as JSON, CSV, or templates. Scripts run in a sandbox, so they don't affect your Productboard workspace directly.
Skill types
There are three types of skills available in Spark.
Productboard skills are available to all Spark users by default and can't be edited or deleted. Personal and workspace skills are ones you create yourself. See Creating a skill for details.
Using skills
The sections below describe how skills work when you run them.
Starting a skill
There are a few ways to a start a skill:
- Simply ask Spark to do something. If it notices it has access to a relevant skill, it'll use that skill automatically.
- You can explicitly instruct Spark to use a skill. In any Spark chat, type "/[skill-name]" to invoke that skill. You can combine the invocation with more instructions in the same chat field.
- A selection of core Productboard skills appear on the Spark home page. You can click on these at any time to start a new chat with that skill. For more on these skills, see Productboard skills below.
Skill steps and progress
Some skills may present multiple steps, visualized above the chat input. These steps show your progress and indicate which steps haven't started, are in progress, or are complete. You can't skip steps or reorder them; skills are designed to be completed sequentially to ensure quality outputs.
Interactive buttons and chat responses
During a skill, Spark may present pre-defined button options to choose from, or you can type your own freeform response. This flexibility lets you follow the suggested path or provide custom input based on your specific needs. Some steps may also include buttons to connect external tools or integrations if needed.
For details about MCPs and file attachment connectors, see Connect external tools to Productboard Spark.
Ending a skill and continuing in chat
Once you complete a skill, you can continue working in the same chat as a regular conversation. However, you can't end a skill mid-workflow. If you need to work on something unrelated, start a new chat.
Managing skills
You can create and refine personal and workspace skills from the Skills page. From Main navigation, click Skills to open it.
Creating a skill
You have three ways to create a skill:
- Write it yourself: Create a skill manually from within the skill editor.
- Use the built-in command: Type /create-skill in Spark and follow the prompts.
-
Upload a package: Import a
.skillfile that bundles a prompt, scripts, and resource files together.
Tip: If you're creating a skill for the first time, try /create-skill. Spark will guide you through each field and suggest a prompt structure based on what you describe.
Writing a skill yourself
From the Skills page, click Add Skill Create a skill to open the skill creation window.
Give your new skill a name, description, and instructions. The instructions define how the skill will behave and what it will output — be thorough about what you'd like the skill to do.
Tip: Adding markdown notation like headers and bolding to your instructions helps Spark parse the text more reliably.
At the bottom of the window are the Visibility and Trigger fields:
- Visibility refers to the skill's type. Admins can change this from Personal to Workspace, making the skill available to all members.
- Trigger controls how the skill is invoked. If the trigger includes Agent, Spark can start the skill automatically based on chat context. If it includes Slash command, users can start it by typing "/[skill-name]" in a Spark chat field. Choose Disabled if you're not ready for the skill to be used yet.
When you're done, click Create skill.
Adding resources and scripts
Once your skill is created, scroll to the bottom of the page and click Add resource to attach Python or shell scripts and static resource files to your skill.
- Scripts contain executable code for deterministic or repetitive tasks, so Spark doesn't have to reason through them step by step. They run without being fully loaded into context, reducing memory overhead.
- Resource files like documentation, schemas, templates, or assets are loaded selectively, so only relevant content is pulled in at a given time. This is useful for static information that's too bulky to include in the main skill instructions.
For more information on script formatting, see Scripts below.
Creating a skill with the /create-skill command
To have Spark walk you through creating a new skill:
- Start a new Spark chat.
- Enter "/create-skill" in the chat field.
- Follow the prompts to build the skill.
Spark will ask questions to better understand what you're trying to build. Once it has what it needs, it will draft the skill and present its name, description, and instructions for your review. You can continue refining it in chat, or tell Spark to complete the skill.
The skill is available for immediate use and appears on the Skills page, where you can edit it manually or add resources if you wish.
Uploading a skill
From the Skills page, click Add Skill Upload a skill to open your file browser.
Accepted file types and structure
Upload your skill as one of the following archive formats:
- .zip: standard ZIP archive
- .skill: also a ZIP archive, with a different file extension
Your archive must contain a SKILL.md file. Everything else is optional. Here's an example of a valid archive layout:
my-skill.zip
├── SKILL.md
├── scripts/
│ ├── my_script.py
│ └── helper.sh
└── references/
└── template.md
A few rules to keep in mind:
- SKILL.md can sit at the archive root or inside a single top-level directory.
- Only direct children of scripts/, references/, assets/, and resources/ are processed. Nested subdirectories are ignored.
- All script and resource files must be valid UTF-8 text. Binary files are skipped, and you'll see a warning.
SKILL.md and frontmatter structure
Your SKILL.md file has two parts: an optional frontmatter block at the top, followed by your skill instructions in Markdown.
--- name: my-skill-name description: Short description shown in autocomplete argument-hint: optional hint shown after /slash-command user-invocable: true disable-model-invocation: false --- Your skill instructions go here in Markdown...
Here's more information about how to structure your frontmatter fields:
Size limits
Here's information about file size limits when uploading skills to Spark:
Scripts
Skills support Python and shell scripts.
Warning: The available Python sandbox packages aren't publicly documented. Test your dependencies carefully before importing.
Supported script file types and validation rules:
- .py: Syntax-validated via AST parser. Any syntax error blocks the import entirely.
-
.sh / .bash: Must include a shebang line (e.g.,
#!/bin/bash). A missing shebang triggers a warning but doesn't block the import.
Two additional rules apply to all scripts:
- Script descriptions are auto-extracted from the first docstring (Python) or first comment (shell).
- Filenames can't contain
/or,characters.
Import preview
Before your skill is saved, you'll see a preview showing:
- Parsed metadata, like name, description, argument hint, and flags.
- Extracted script descriptions.
- A list of any warnings, including skipped files and missing recommended frontmatter.
Review warnings before confirming the import. They don't always block the import, but they often point to issues worth fixing.
Content quality recommendations
The import validator checks your instructions for a few recommended elements. These warnings are non-blocking — your skill will still import — but including them leads to more reliable skill behavior.
The validator looks for:
- Numbered workflow steps (e.g., Step 1: …)
- An output format section
- Input/output examples
- Constraints or non-goals
If any of these are missing, you'll see a warning in the import preview. Consider adding them before finalizing your skill.
Productboard skills
Productboard includes several built-in skills designed to support your most critical PM workflows. Unlike personal or workspace skills, these can't be edited, but they can be used by anyone with access to Spark. You can view all Productboard skills on the Skills page.
A core set of the most important Productboard skills can be triggered directly from the Spark home page and are described in detail below.
Product Brief
A product brief is a short document — often a one-pager — that captures an individual customer problem or business opportunity. It focuses on problem identification, opportunity sizing, high-level solution direction, success metrics, target users and segments, and market context. The purpose is to share with stakeholders for feedback, discuss priority, and compare opportunities for planning decisions.
A product brief comes early in the discovery phase to assess whether an opportunity is worth pursuing. Once approved, it evolves into a Product Requirements Document (PRD) or Product Specification, which includes detailed features, technical requirements, user stories, and acceptance criteria needed for development.
What it does
The Product Brief skill guides you through creating a concise, well-structured product brief that captures the essence of your initiative or opportunity. It walks you through defining the problem, articulating the solution, identifying success metrics, and outlining next steps.
When to use it
Use the Product Brief skill when you need to quickly document a new customer problem, idea, or opportunity. It's ideal for creating alignment with stakeholders, communicating your vision to the team, or preparing for leadership reviews.
What you'll get
A product brief that includes a problem statement, proposed solution, target users, goals and success metrics, and risks and open questions. The brief is created as a document in Productboard that you can share, edit, and collaborate on with your team.
Feedback Analysis
A feedback analysis is a systematic synthesis of customer feedback that identifies patterns, themes, and insights from user conversations, support tickets, interviews, and other feedback sources. It examines what customers are saying, which problems occur most frequently, which segments are affected, and what underlying needs are being expressed — surfacing actionable product insights. The purpose is to validate opportunities, prioritize features based on customer evidence, identify pain points, and ground product decisions in real user needs.
Feedback analyses can be created at different stages: during discovery to validate problem hypotheses, during planning to prioritize roadmap items, or during retrospectives to understand adoption challenges.
What it does
The Feedback Analysis skill helps you make sense of customer feedback at scale. It guides you through importing or referencing your feedback, identifying patterns and themes, and synthesizing insights that reveal what customers truly need.
When to use it
Use the Feedback Analysis skill when you need to understand what customers are telling you and translate it into product action. It's ideal for validating new opportunities before building, prioritizing features on your roadmap, understanding why adoption is lagging, or identifying emerging themes that signal unmet needs.
Note: You must have sufficient customer feedback captured in Productboard to run the Feedback Analysis skill. If you have limited feedback, collect more customer input before running it.
What you'll get
A synthesis of key themes and insights from your customer feedback, organized by topic or user intent, along with recommendations for how these insights should influence your product roadmap or strategy.
Competitor Analysis
A competitor analysis is a strategic document that systematically evaluates your product's position relative to competitors. It examines competitor offerings, strengths, weaknesses, positioning, pricing strategies, and target customers to identify competitive threats, market gaps, and differentiation opportunities. The purpose is to inform product strategy, validate market positioning, identify feature priorities, and provide context for stakeholder decisions.
Competitor analysis isn't a one-time exercise — it's an ongoing discipline that should be refreshed quarterly or when significant market changes occur.
What it does
The Competitor Analysis skill helps you choose a competitor and deep dive into how they're solving similar problems. It guides you through identifying relevant competitors, comparing their approaches to your product, and synthesizing findings into strategic insights.
When to use it
Use this skill when you're exploring a new market opportunity, evaluating your competitive positioning, or researching how others have solved a problem you're tackling. It's valuable during discovery phases, competitive reviews, or when preparing for strategic planning sessions.
What you'll get
A competitor analysis document that includes a competitive landscape overview, individual competitor profiles with strengths and weaknesses, a feature and capability comparison matrix, strategic positioning analysis, and actionable recommendations for differentiation and competitive response. The analysis is created as a document in Productboard that you can share, edit, and update as the competitive landscape evolves.
Note: The Competitor Analysis skill analyzes one competitor at a time.
Spec
A spec (short for product specification) is an engineering-ready document that translates a validated problem or approved brief into the detailed requirements engineers need to build. It covers the problem statement, goals, non-goals, user stories, requirements, success metrics, timeline considerations, and dependencies. The purpose is to give your engineering team enough clarity to begin building without repeated clarification loops.
Unlike a product brief — which focuses on whether something is worth building — a spec focuses on how it should be built. Where context is missing, the Spec skill uses explicit [TBD] placeholders rather than inventing answers, so the document remains trustworthy from the start.
What it does
The Spec skill launches from any initiative — with or without an existing brief. Spark confirms your problem statement, fetches available workspace context, and generates a full draft across all required sections. Wherever grounding is missing, Spark inserts a [TBD] placeholder and logs it as an open question with an owner tag (PM, Eng, Design, Legal, or Data) and a suggested resolution action. Spark then surfaces the most impactful open questions one at a time so you can work through them in chat or edit the document directly.
When to use it
Use the Spec skill after a brief has been approved and your team is ready to move into delivery. It's also useful when you need to turn a well-defined problem statement into a first draft quickly, even without an existing brief. If you're facing repeated pre-sprint alignment calls or engineers are regularly asking the same clarifying questions, the Spec skill is a good fit.
What you'll get
A full spec draft covering Problem Statement, Goals, Non-Goals, User Stories, Requirements, Success Metrics, Timeline Considerations, and Dependencies. Any section Spark can't ground in available context appears as a [TBD] placeholder — never invented content. An Open Questions section lists each placeholder with an owner and a suggested next action. The completed spec is saved to your initiative folder at /Initiatives/<name>/Spec.md, with collision handling to prevent silent overwrites.
Best practices
- Prepare your context. Context matters for getting high-quality outputs. You can add context by using existing documents or customer feedback from your workspace, attaching files to the conversation, or bringing in data from external tools through MCP connectors and file attachments. To learn more, see Context management in Spark.
- Be specific in your instructions. The more precisely you describe the task in a custom skill, the more reliably Spark invokes it in the right context.
- Use resource files for reference data. If your skill depends on a template, taxonomy, or dataset, bundle it as a resource file rather than pasting it into the prompt.
-
Name skills clearly. The skill name becomes the slash command trigger. Use a short, action-oriented name:
release-notes, notmy-release-notes-skill-v2. - Provide thoughtful responses. Take time to answer each skill step's questions thoroughly. The quality of your input directly affects the quality of the output.
- Promote selectively. Before promoting a skill to the workspace, test it thoroughly as a personal skill to avoid inconsistent outputs for your team.
- Review and refine outputs. Skills create solid foundations, but review the generated content and refine it to match your specific context and voice.
FAQ
A prompt is a one-off instruction you type into a chat. A skill is a saved instruction set that Spark can reuse, either automatically when the context is right, or on demand via a /slash command. Skills can also include scripts and resource files that a plain prompt can't.
Only admins can create workspace skills or promote a personal skill to the workspace level. Any user can create personal skills for their own use.
A skill only appears as a slash command if the Allow slash command toggle is enabled when you create or edit it. Open the skill from the Skills page and check that the trigger is set to Slash command.
No. Scripts can only be included by uploading a skill archive (.zip or .skill file). The skill editor doesn't support script uploads. Once a skill is created, you can add resource files from the skill's detail page, but scripts must be packaged in the archive at upload time.
No. Scripts run in an isolated sandbox and don't make changes to your workspace directly.
Yes, if you're an admin. From the Skills page, click the skill, then click Edit skill. At the bottom of the window, change the skill's visibility to Workspace. Test the skill thoroughly as a personal skill before promoting it, to avoid inconsistent outputs for your team.