# Track which Dart work has a written spec and which does not

> A live desk showing every active Dart board, how much of its in flight work has a spec, and which specs went stale while the work moved on.

- Workflow type: app
- Services: Dart, Slack
- Categories: Product, Engineering
- Published: 2026-08-17

## What it does

- Lists your active Dart boards with a coverage score: how many in flight tasks have a spec behind them and how many have nothing written at all.
- Flags specs that have not been touched since the tasks under them last moved, so you can see where the writing fell behind the work.
- Drills into any board for two working lists: the tasks with no spec, and the old docs nobody references any more with the date each was last edited.
- Lets you start a spec straight from a task, seeded with its title and description, or send the owner a Slack message asking them to write it.

## What you'll need

- A Dart workspace with tasks and docs in it
- A Slack account, if you want to ask teammates for the specs that are not yours to write
- A rough idea of how your team connects docs to tasks, such as a naming convention or a tag, which you set on first run and can change any time

## Prompt

Build me a spec coverage desk for our Dart workspace. Dart keeps tasks and docs side by side, but nothing tells us which work shipped with no written spec. I want one screen that shows where our documentation covers the work in flight and where it does not, and lets me fix the gaps without leaving the app.

The main screen is a table of active dartboards. Load the workspace configuration first with Get User Space Configuration so the app knows the real dartboard names, statuses, priorities and tags for my workspace instead of guessing. For each dartboard pull its tasks with List Tasks and its docs with List Docs, then show one row per dartboard with the number of in flight tasks, how many of those have a linked spec, how many have none, a coverage percentage, and a count of stale specs. Sort the worst coverage to the top, because that is the row I need to act on.

A spec counts as stale when its last edited date is older than the most recent activity on the tasks that reference it. The point is to catch docs where the writing fell behind while the work kept moving, not docs that are simply old and finished. Show the gap in days so I can tell a spec that is a week behind from one that is three months behind.

Important nuance: Dart has no operation that returns the docs linked to a task, so the task to doc relationship has to be resolved inside the handlers, and the rule that does it must be visible and editable in the app rather than buried in code. The default rule is that a task counts as documented when a doc title appears in the task description, or when a doc is referenced in the task's comments, which you read with List Comments. In a settings panel let me change this: match on a tag I choose, or on a naming convention such as docs titled Spec: followed by the task title. Print the active rule in plain language at the top of the desk with an edit link next to it, and recalculate coverage as soon as I change it. Teams name things differently, so this cannot be a black box that quietly reports the wrong number.

Bake in a coverage filter so a long backlog does not drown the signal. Let me pick which statuses count as in flight and set a minimum priority, defaulting to active statuses only and to tasks at medium priority or above. Anything below the bar is excluded from the counts entirely rather than counted as undocumented, and the header should state what the current filter is. Persist my filter and my matching rule between visits so I am not reconfiguring the desk every morning.

Clicking a dartboard row opens a detail view with two lists. The first is the undocumented tasks: title, assignee, status, priority and last activity date, and when I open one, the full detail from Get Task. The second is the orphan docs: docs on that dartboard that no in flight task references any more, each with the date it was last edited, so I can see what to archive, merge or repurpose.

From a selected undocumented task give me a Start a spec button. It creates a doc with Create Doc seeded from the task title and description, laid out with a short starter structure of problem, scope and open questions. It then posts the doc reference back onto the task with Create Comment so the link is visible to anyone reading the task inside Dart, and updates the task with Update Task to tag it as documented using whichever tag I configured in the matching rule. Show me the seeded draft before anything is created so I can edit the title and the starting text.

On a stale doc give me an option to append a short What changed section using Update Doc Text, listing the tasks that moved since the doc was last edited. That way the next person to open the spec knows it is behind the work and roughly by how much, instead of trusting a document that quietly went out of date.

If the missing spec is not mine to write, give me a Request spec button on any undocumented task. Find the task owner in Slack, open a direct message with Open a Conversation to get the channel, and send a short note with Send a Message that names the task, links to it and asks for a spec. Send it as me rather than as a bot, since this is a personal ask to a teammate. Let me see and edit the message text before it goes out.

Behaviour rules across the app: nothing writes to Dart or Slack unless I press a button. Refresh coverage on demand with a refresh control rather than polling constantly. Page through the Dart list results so large workspaces load fully instead of silently truncating at the first page. If a dartboard has no tasks above the filter, show it as excluded rather than as zero percent coverage, so I do not misread an empty board as a failing one.

## How to customize

- Choose which statuses count as in flight and set a minimum priority, so a long backlog does not drown the coverage signal
- Edit the matching rule that decides when a task counts as documented, whether that is a title mentioned in the task, a tag, or your own naming convention
- Change how far behind a doc has to fall before it gets flagged as stale

## FAQ

### How does it know whether a task has a spec?

Dart does not offer a direct way to ask which docs belong to a task, so the app works it out by matching. Out of the box it counts a task as documented when a doc title shows up in the task description or in its comments. You can change that to a tag or a naming convention, and the rule is shown in plain language at the top of the screen rather than hidden away.

### Will this work if my team names docs differently?

Yes. The matching rule is editable in the app, so if your team writes specs called something like Spec: followed by the task name, or tags them a particular way, you can set that up on first run and the coverage numbers recalculate straight away.

### Does it change anything in my Dart workspace on its own?

No. It only reads until you press a button. Creating a spec, commenting the link back onto a task, tagging work as documented and appending a what changed note all happen when you choose them, and you get to review the text first.

### Why does one of my boards show almost no coverage?

Usually because the filter is letting too much of the backlog in. Set the minimum priority higher or narrow the list of statuses that count as in flight, and the score will reflect the work actually moving rather than everything ever filed.

### What if the missing spec is not mine to write?

Pick the task and use the request button. It finds the owner in Slack, opens a direct message and sends them a short note naming the task and asking for a spec. The message comes from you rather than a bot, and you can edit it before it sends.

Use this prompt in General Input: https://www.generalinput.com/prompts/track-which-dart-work-has-a-written-spec-and-which-does-not