A spec describes what to build; work items track the building. Linking the two means anyone reading the spec can see the work it turned into, and anyone working an item can open the spec it came from.
A spec can link to any number of work items, and a work item to any number of specs. A link is a note about the spec, not a change to it: making or removing one never changes what the article says, adds nothing to its history, and never needs approval, even in a category where changes do.
Links are for your team only. Your clients never see them; see What your clients see.
Open the article in the editor. The Work items panel in the right-hand column lists every work item the spec links to, newest link first, and its header counts them (2 items). Each row shows the item's number and title, and Archived when the item has been archived.
Until the spec has a link, the panel says No work items linked yet.
Open a work item. When it is linked to at least one spec, its drawer ends with a Specs section (1 spec, 2 specs) listing each spec's title and its state: draft, published or archived. Click a title to open the spec in the article editor.
The section is read-only: links are made and removed on the spec. It shows only to people who hold a Knowledge Base permission, and only when there is something to show.
The link appears at the top of the panel, and in the item's Specs section, straight away. Linking an item that is already linked changes nothing.
You need Create knowledge-base articles and must be able to open both the spec and the work item. You do not need to be able to edit the spec's words: a link is not an edit. See Who can do what.
When the work is not in DevStride yet, create it from the spec. Every item made this way is linked to the spec as it is created.
The new items are created in the order you typed them, exactly as if you had added each one by hand, so the usual rules apply: you need to be able to add items under the parent you chose, and the type must be one that can go there.
If the spec's stage names a work type, that type is used. The Item type box is locked to it, and a note says so: Specs in Ready for development create Story items. You set the work type for each stage under Spec stages. If that type has since been archived, nothing is created and the dialog says The work type this spec's stage requires is archived or no longer exists; pick another type for the stage first.
If some titles fail, the rest are still created. The dialog stays open with only the titles that were refused, each with its reason in red. Fix what the reason names (a different parent, say) and click the button again. The items that were created are already in the Work items panel.
Creating work items needs Create knowledge-base articles and Create Items And Workstreams. Without both, the Create work items button does not appear.
When you move a spec into a stage that names a work type, and the spec has no work items yet, the editor asks straight away: Create its work items? This spec is now Ready for development. Create its work items?
The dialog is the same one as above, with the stage's work type already fixed. Fill in the titles and parent and create them, or click Not now to leave it for later; the Create work items button stays in the Work items panel.
The question is asked only:
On Manage articles, click No work items, the last button in the All / Draft / Published / Archived group. The list then shows only articles with no linked work items. Click it again to show everything. Unlike the state buttons, it is an on/off switch, so it works together with whichever state you pick.
It combines with the other filters. Choose a stage as well to answer "which specs are ready for development but have nothing built yet?" It also works while you search. When nothing is left, the list says Every spec here already has work items.
A few things to know:
The Spec Reached a Stage automation trigger runs when a spec moves into a stage, so the work can be created, or the team told, without anyone opening a dialog.
In the list, the rule reads When a spec reaches Ready for development.
It runs whenever a spec moves into the chosen stage, however the stage was set: in the editor, by the AI Assistant or through the API. Clearing a spec's stage never runs it.
On a Spec Reached a Stage automation, Create Work Item has an extra switch: Link the new item to the spec. It is on by default, so each item the automation creates appears in the spec's Work items panel. Switch it off to create the item without a link.
The item's title, type and place come from the action, as in any automation; the stage's work type does not apply to it. If the link cannot be made, the item is still created and the run in Run history says why the link was skipped.
Notifications and webhooks can include the spec's Spec Title, Spec Stage, Spec Previous Stage and Spec Id. The spec's text is never passed to an automation.
Saving a Spec Reached a Stage automation switched on needs Edit any member's knowledge-base articles (shown on the Permissions page as Manage All Kb Articles), as well as the usual automation permissions. The automation runs for every spec in the workspace, drafts and specs not shared with you included, and can send their titles on; this permission is the one that can already see them all.
People without it do not see Spec Reached a Stage in the trigger list. Anyone who can edit an existing one can still switch it off: a save that leaves the automation disabled is always allowed.
For the rest of the automation builder, see Setting up basic automations.
Nothing. Links are staff-only: the customer Help center never shows a spec's work items, and a client working on a spec draft cannot see or change them.
AI assistants connected through the DevStride MCP Server can do the same work, with your permissions:
| Tool | What it does |
|---|---|
list_kb_article_work_items | The work items a spec links to, and how each link was made: by hand, created from the spec, or by an automation. |
list_work_item_kb_articles | The specs a work item links to. |
link_kb_article_work_items | Link a spec to up to 50 existing work items at once. If any of them cannot be found or read, nothing is linked. |
unlink_kb_article_work_item | Remove one link. The in-app AI Assistant always asks you to approve this call. |
create_work_items_from_kb_article | Create up to 20 work items under a parent, each linked to the spec, following the stage's work type exactly as the dialog does. |
find_kb_articles with hasWorkItems: "false" finds the specs that have none yet.
| To | You need |
|---|---|
| See a spec's Work items panel, or a work item's Specs section | Any Knowledge Base permission, plus access to the spec (and, for each item listed, permission to read it) |
| Link or unlink a work item | Create knowledge-base articles, and access to the spec and the work item. Edit access to the spec is not needed |
| Create work items from a spec, or be offered them on a stage move | Create knowledge-base articles and Create Items And Workstreams, plus the right to add items under the parent you choose |
| Switch on a Spec Reached a Stage automation | Edit any member's knowledge-base articles, plus the automation permissions |
| Set a stage's work type | Manage Knowledge Base Settings |
See Knowledge Base permissions.
Watching Articles and Categories
Watch an article, or a whole category, to be told in the app when a spec changes stage, gets a new published version, or has a change proposed or decided, and see or manage who else is watching.
Overview
The AI Assistant answers how-to questions from this documentation, looks up your own workspace, and makes changes you approve. Where it is, what it can do, and where every other AI feature in DevStride lives.