---
description: Execute Jira-backed design and research tasks in the design facet using Confluence as the durable artifact space, including interview, review, and document-refinement loops.
polytoken:
  tags: [jira, confluence, design, research, documentation, workflow]
---

# Jira Design Tasker

Use this skill in the design facet when the operator asks you to work a Jira-backed design/research task, update durable design documents, or turn a broad design question into reviewed Confluence artifacts and follow-up Jira tasks.

Announce: "using the jira-design-tasker skill to run a Jira-backed design workflow"

This is not an implementation workflow. Do not edit product code except for small workflow/documentation-support changes the operator explicitly requests. When design work becomes executable implementation, create or propose separate Jira implementation tasks and, if needed, hand off through the plan/execute workflow.

## Source of truth

For this repository, Jira project `PM` is both the human source of truth and the agent working truth when Jira tools are available and permitted.

Confluence space `PM` is the durable home for design artifacts, product decisions, research summaries, and demo narrative.

Local Markdown is supporting material only unless a task explicitly says otherwise.

## Project configuration

Default project settings for this repository:

- Atlassian cloudId: `eab0a222-1a38-4539-a21d-44fb3466b28b`
- Jira project: `PM`
- Confluence space key: `PM`; numeric space ID for page APIs: `98315`; overview/root page ID: `98479`
- Overall design plan: `Polymodel Overall Design Plan`, page ID `131306`; parent epic for design tasks: `PM-4` (`Initial development`, Epic)
- Jira transitions: To Do `11`, In Progress `21`, In Review `31`, Done `41`

These are project contracts. If a tool call contradicts them or the board/space appears reconfigured, re-verify and ask the operator before substituting IDs.

## Task shape

A good design task has:

- a Jira issue describing the question or design slice;
- a linked Confluence page or a planned page location;
- explicit scope and non-goals;
- durable references and evidence sources;
- interview questions for operator/domain knowledge;
- a review/refinement loop;
- a final Jira comment that summarizes what changed and where the artifact lives.

Design tasks usually produce one of:

- design brief;
- decision record;
- research synthesis;
- product/UX plan;
- architecture options note;
- implementation-roadmap proposal;
- follow-up Jira task set.

## 1. Load Jira and Confluence context

Start from a Jira issue when available.

1. Read the Jira issue with `getJiraIssue`, including comments when possible.
2. Confirm the issue is design/research work, not implementation work.
3. Find linked Confluence pages or create a new child page under the relevant parent, normally page `131306` or the PM root `98479`.
4. Read the current relevant Confluence page(s), including open inline/footer comments.
5. Identify current decisions, open questions, stale content, and missing references.

If no Jira issue exists and the operator asks for durable work, ask whether to create one unless the work is too small and immediate.

## 2. Claim or coordinate the design task

Do not silently take over active human work.

If the task is in To Do and the operator wants you to proceed:

- transition Jira to In Progress (`21`) if appropriate;
- add a concise comment such as `Design task started by Polytoken session <session-id>. Durable artifact: <Confluence link or TBD>.`

If the issue is already In Progress, inspect comments and ask before assuming ownership unless the operator explicitly directed you to continue it.

For exploratory design sessions without a Jira issue, keep state in the Confluence page and create Jira tasks only when useful.

## 3. Research before asking, then interview deliberately

Use existing sources before interrupting the operator:

- current repo files and project instructions;
- PM Jira issues and comments;
- PM Confluence pages and inline comments;
- durable references such as:
  - `https://tangled.org/nonbinary.computer/weaver`
  - `https://tangled.org/nonbinary.computer/vodplace`
  - `https://tangled.org/microcosm.blue`
  - relevant public specs and product references.

Ask the operator only for domain knowledge, preferences, constraints, or decisions that materially change the design. Use `ask_user_question` with a self-contained context explainer.

When the operator provides comments inline in Confluence, fold current decisions into page content instead of leaving important state only in comment threads.

## 4. Draft the durable artifact

Write Confluence pages as current-state documents, not chat transcripts.

Recommended structure:

- Status and purpose;
- Current decision or current direction;
- Scope and non-goals;
- Evidence and durable references;
- Options considered, if a decision is needed;
- Recommended next step;
- Risks and open questions;
- Follow-up Jira tasks or implementation candidates.

Keep history short. Link to comments, prior pages, or Jira issues instead of carrying obsolete exploration inline.

When updating a page that has inline comments, preserve or intentionally replace the relevant anchored text. If a comment has become resolved by the page update, say so in the final report; resolve comments only when the operator asks or the workflow explicitly permits it.

## 5. Review and refinement loop

Before treating a Confluence artifact as ready:

1. Run an independent review appropriate to the artifact size.
   - Small/local design note: at least one `code-reviewer` or `general-purpose` reviewer focused on clarity, missing assumptions, and actionability.
   - Larger design/architecture decision: use a panel if the operator or project guidance requires it.
2. Ask reviewers for Critical/High/Medium/Low findings with evidence and suggested fixes.
3. Fix or rebut Critical/High findings before finalizing. For Medium/Low, either fix, record as follow-up, or explain why not.
4. Use the `refining-human-documents` skill before finalizing human-facing durable documents. If possible, delegate the refinement pass to a subagent so the main thread keeps domain context clean.
5. Re-read or fetch the final artifact after updating it to verify the durable page reflects the intended state.

The review goal is shipping-quality design truth: clear, concise, evidence-backed, current, and actionable.

## 6. Create follow-up Jira tasks

Create Jira tasks when the design artifact identifies work that is:

- specific enough to own;
- valuable independently;
- bounded by scope/non-goals;
- connected to a validation or review expectation.

Distinguish task types in the summary:

- `Design:` for design/research tasks;
- `Spike:` for implementation experiments intended to answer a question;
- `Implement:` for build tasks after design is settled.

For each Jira issue include:

- link to the relevant Confluence page;
- goal and non-goals;
- evidence/references;
- acceptance criteria or deliverable;
- review expectations;
- dependencies on other Jira tasks or design decisions.

Avoid creating large ambiguous implementation tickets from unresolved design questions.

## 7. Jira updates and final state

At useful milestones, update Jira with concise comments:

- design task started / artifact location;
- major decision or pivot;
- artifact ready for review;
- final summary and links.

When the artifact is ready for operator review, transition to In Review (`31`) if the team wants design tasks to use the same review lane.

After explicit operator acceptance, transition to Done (`41`). If the operator requests more work, keep or return the issue to In Progress as appropriate.

## 8. Final response to the operator

Report:

- Jira issue key(s) touched or created;
- Confluence page(s) created or updated;
- decisions captured;
- open questions that remain;
- review/refinement performed;
- follow-up Jira tasks created or recommended;
- any risks or assumptions that still need operator confirmation.

Keep the report concise. Link durable artifacts instead of restating them in full.
