| # | WBS | Task | Tags | Ver | Comp | +Dep | Timeline |
|---|
A shareable plain-text report — totals & overall progress on top, then every active task with its estimate, version and completion. Disabled tasks are excluded. Copy it straight into chat or email.
A single read-only HTML file to hand to someone outside the app — groups expand and collapse, and Print / Save as PDF in it opens everything first, so the PDF holds the whole plan. Carries the header totals & progress, the task tree (estimates, versions, components, ❓ TBD, completion), task comments and a by-version summary. Disabled tasks are excluded. It is deliberately unlinked: no plan URL, guid or storage mode anywhere in the file, nothing is fetched when it opens, and no snapshot is embedded — a reader can't get back to this plan from it. Jira ticket keys are the one exception, linked only when Project → Settings defines a ticket URL.
Your plan as an indented outline (estimates in days). Copy it out, or edit / paste your own
and click Import. Indentation (or a leading N.) defines the hierarchy; end a line
with an estimate like - 1d, - 4h, - 1w (also -1w).
Units: 1w = 5d, 1d = 8h. Lines starting with “Total” are ignored.
The full plan as JSON — includes name, changes, lastModified
(and version in server mode). Copy / Download it as a backup, or
Choose file / paste your own and click Import. Replacing restores the whole plan; appending
adds the imported tasks to the current one. Downloads are named after the project, version and date.
Every leaf task on its own numbered line as 1. A > B > C - 2d — the full path to the
task followed by its estimate. Parent (roll-up) tasks are excluded; the last number is the total count.
Leaf tasks as Jira-importable CSV — Summary (the full
A > B > C path), Issue key, Issue Type=Task,
Status, Sprint (= version), Components,
Original estimate (seconds, 1d=8h). Download or Copy it, then import
that file into Jira. Disabled tasks are excluded. This tab only produces a file — it never
reads one.
Link a Jira CSV export to tasks you already have, to fill in the missing
Issue keys. Matched by Issue key first, then by the full
A > B > C path — › and » count as
>, and spacing/case are ignored. This writes only the Jira key, and only
onto tasks that haven't got one: it never renames a task, never changes its status, and never
creates anything. The next step shows a diff so you can untick any link you don't want.
Pull a Jira CSV export into the plan: matched tasks can take Jira's name, status,
version, component and estimate, and unmatched issues can be created with their hierarchy.
Matched by Issue key first, then by the full A > B > C path
(› / » count as >). The next step shows a
diff so you choose exactly what is written. To link keys only, use Import Jira keys.
Paste or upload a Jira CSV export, then Compare. Your plan is the source of
truth — each matched ticket lists what to change in Jira (rename, status, version,
component, estimate) so it matches. Tickets are matched by Issue key first, then
by full A > B > C path. Nothing here writes to your plan or to Jira — it's a to-do list for editing Jira by
hand, with ⧉ to copy each new value. To change the plan instead, use
Import from Jira.
Define the release versions you want to plan against — one per line (e.g. 1.0.0,
1.1, 1.3.0). Order is kept as listed. Then pick a version per task from the
Ver column dropdown. Removing a version here leaves any task still on it marked (?).
Rename a version with old -> new (e.g. 1.0.1 -> V 1.0.1) —
all tasks assigned to old are relinked to new.
Define the components — one per line (e.g. Frontend, API,
Infra). Order is kept as listed. Then pick a component per task from the
Comp column dropdown. Removing one here leaves any task still on it marked (?).
Rename with old -> new (e.g. API -> Backend API) —
all tasks assigned to old are relinked to new.
Define named estimate streams — one per line (e.g. UI, Backend,
QA). Each becomes its own Est column; a task's total is their sum, which
drives the timeline and roll-ups. With two or more streams a Σ sum column is shown
(hide the per-stream ones via View → Show sum only). Leave this empty for a single estimate.
Rename with old -> new (e.g. UI -> Frontend) — each task's
value moves to the new name.
Jira ticket URL — a link template for issue keys. Use {key} where the key goes
(e.g. https://your-org.atlassian.net/browse/{key}); if you omit {key} the
key is appended to the end. When set, each task's Jira key badge becomes a link that opens the
ticket in a new tab. Leave blank to show the keys as plain labels.
Level delimiter — separates the levels in the Jira Summary breadcrumb
(A > B > C). Used for both export and import. Default >.
Dependencies — a task's own tag marks it as a feature; its dependency tags
(the 🔗 chips) point at features it needs. When enabled, each task shows the
rolled-up estimate of the feature(s) it depends on as extra work (e.g.
5d + 18d deps) — counted once per feature and not added to the task's own
estimate. The Gantt is also ordered by dependency, and a ⚠ warning appears for a
dependency cycle or a version conflict (a feature planned for a later version
than a task that needs it).
Matches are found by Jira Issue key first, then by full A > B > C path.
The next step shows a diff so you can choose exactly what to merge (key, status, version,
component, estimate) before anything is written.
Every save is a version. Use this version picks that one version as your new starting point: its contents are saved as a new latest version. Nothing is deleted and no versions in between are undone — they stay in this list, so you can always come back.