@groupby/ai-dev 0.2.1 → 0.2.3

package/toolsets/toolsets/rzlv-flow/skills/atlassian-orchestrator/SKILL.md

@@ -1,643 +0,0 @@
----
-name: atlassian-orchestrator
-description: Pull surrounding Jira ticket context (parent epic, linked Confluence docs, related stories) and create or update Jira/Confluence structures. Creates epic folder structures with technical architecture docs, decisions, and strategic context. Imports existing Jira tickets into local mirrors. Use when you need to enrich a ticket's context, create a new epic structure, import tickets locally, add items to an existing structure, or sync documentation to Confluence.
----
-
-Enriches Jira ticket context by pulling the full surrounding chain (parent epic, sibling stories, linked Confluence pages) and can create, import, extend, or sync Jira/Confluence structures. Operates in five modes: context enrichment, epic structure creation, ticket import, structure continuation, and Confluence sync.
-
-## Requirements
-
-Requires: Atlassian MCP (`atlassian-rovo`). See the rzlv-flow toolset README for setup.
-
-## Resources to Load
-
-Before executing, read these resource files — they are critical for correct behavior:
-
-- `docs/ai/resources/fcmp-protocol.md` — follow for all Jira and Confluence read/write operations
-- `docs/ai/resources/jira-file-structure.md` — directory layout and ownership rules for local Jira mirrors
-- `docs/ai/resources/confluence-file-structure.md` — Confluence mirror layout, Leaf Bundle pattern, and dual-mode (structured/flexible) rules
-- `docs/ai/resources/sync-state-format.md` — YAML frontmatter schema for ticket and page files
-- `docs/ai/resources/confluence-page-templates/` — (optional) starter scaffolds for consistent Confluence page structure
-
-## Core Principles
-
-These principles govern all modes of operation:
-
-- **FCMP is non-negotiable** — ALL Atlassian operations follow Fetch-Compare-Merge-Push. Never blind write.
-- **Confluence BEFORE Jira** — When creating both, sync Confluence pages first to get page IDs, then create Jira tickets with Confluence links embedded. Single Jira sync pass.
-- **Ownership boundaries** — This skill creates and owns `_docs/` folders. Never touch `_work/` folders (owned by `jira-ticket-focus` / developer workflows).
-- **Document every assumption** — Any inference must include: source (what triggered it), confidence (High 80%+, Medium 50-80%, Low <50%), impact (what breaks if wrong), and how the PM can verify.
-- **Graceful degradation** — If MCP fails, generate the local structure anyway and set sync status to `pending_sync`. Report what requires manual sync.
-- **Human in the loop** — Confirm Atlassian targets (instance, project, space) before any sync operation. Never update Jira/Confluence without user confirmation.
-- **Check before creating** — Search for existing content before creating to avoid duplicates.
-
-## Modes
-
-This skill supports five modes. The user may invoke one directly or the appropriate mode can be inferred from context:
-
-1. **Context enrichment** — Pull the full surrounding context for a ticket (default if user says "get context for PROJ-123")
-2. **Epic structure creation** — Create a new epic with folder structure, stories, and documentation (if user says "create epic structure" or provides an epic definition)
-3. **Confluence sync** — Publish local documentation to Confluence (if user says "sync to Confluence" or "publish to Confluence")
-4. **Import ticket** — Import an existing Jira ticket (and its hierarchy) into local mirror structure (if user says "import PROJ-123" or "pull down this ticket")
-5. **Continue structure** — Add new items to an existing local structure (if user says "add a story to this epic" or "continue structure")
-
-If the mode is unclear, ask:
-
-```
-What would you like to do?
-1. Pull full context for a ticket (epic, stories, Confluence docs)
-2. Create a new epic folder structure with documentation
-3. Sync local documentation to Confluence
-4. Import an existing Jira ticket into local structure
-5. Add new items to an existing structure
-
-Choose [1]:
-```
-
----
-
-## Mode 1: Context Enrichment
-
-Use when the user wants to understand the full picture around a Jira ticket — its parent epic, sibling stories, linked documentation, and Confluence pages.
-
-### Step 1: Resolve Ticket
-
-- Use `focused_ticket` from conversation context if available.
-- Accept a Jira key directly (e.g. "PROJ-123").
-- Accept a number from `numbered_ticket_list` if available from a prior `jira-daily-triage` run.
-- If the key is incomplete, prepend `confirmed_project` from session context.
-
-### Step 2: Fetch Ticket Details
-
-Use `mcp_atlassian-rovo_fetch()` to retrieve:
-
-- Summary, description, acceptance criteria
-- Status, assignee, priority, story points
-- Labels, components, fix versions
-- Linked issues (blocks, is blocked by, relates to)
-- Linked Confluence pages (remote links)
-
-### Step 3: Fetch Parent Epic
-
-Detect the parent epic (same logic as `jira-ticket-focus`):
-
-1. Check `fields.parent` — if `parent.fields.issuetype.name == "Epic"`, that is the epic.
-2. Check for an Epic Link custom field (varies by instance; commonly `customfield_10014` or similar).
-3. If no epic is found, note the ticket is orphaned.
-
-If an epic is found, fetch its full details:
-- Epic summary, description, goals
-- All child stories/tasks via JQL: `"Epic Link" = {EPIC-KEY} ORDER BY status ASC, priority DESC`
-- Any linked Confluence pages on the epic
-
-### Step 4: Fetch Linked Confluence Pages
-
-For any Confluence links found on the ticket or epic:
-
-- Fetch page content via `mcp_atlassian-rovo_fetch()` using the page ARI
-- Extract key information: title, body summary, last updated
-- Note the space and parent page hierarchy
-
-Also check for local `_docs/` content if the epic folder exists locally:
-- `{epic-folder}/_docs/technical-architecture.md`
-- `{epic-folder}/_docs/decisions.md`
-- `{epic-folder}/_docs/strategic-context.md`
-
-### Step 5: Fetch Sibling Stories
-
-If an epic was found, retrieve sibling stories to understand the broader work:
-
-```
-JQL: "Epic Link" = {EPIC-KEY} AND key != {TICKET-KEY} ORDER BY status ASC, priority DESC
-```
-
-Summarize each sibling: key, summary, status, assignee.
-
-### Step 6: Present Enriched Context
-
-Display the full context chain in a structured format.
-
-### Output Format (Context Enrichment)
-
-```
-## 🔍 Context: {TICKET-KEY} — {Summary}
-
-**Status:** {status} | **Assignee:** {assignee} | **Priority:** {priority} | **Points:** {points}
-
-### Parent Epic
-**{EPIC-KEY}:** {Epic Summary}
-{Epic description excerpt — first 2-3 sentences}
-- **Goal:** {epic goal if identifiable}
-- **Stories:** {total} ({done} done, {in_progress} in progress, {todo} to do)
-
-### Sibling Stories
-| # | Ticket | Summary | Status | Assignee |
-|---|--------|---------|--------|----------|
-| 1 | PROJ-101 | User login flow | Done | @alice |
-| 2 | PROJ-102 | Session management | In Progress | @bob |
-| 3 | PROJ-103 | Password reset | To Do | Unassigned |
-
-### Linked Documentation
-{FOR EACH LINKED CONFLUENCE PAGE:}
-- **{Page Title}** — {space} — [link]({confluence_url})
-  {Brief summary or excerpt}
-
-{IF LOCAL _docs/ EXISTS:}
-### Local Documentation (_docs/)
-- `technical-architecture.md` — {brief summary}
-- `decisions.md` — {brief summary}
-- `strategic-context.md` — {brief summary}
-
-{IF NO DOCS FOUND:}
-### Documentation
-No linked Confluence pages or local _docs/ found. Consider creating documentation with epic structure creation (mode 2).
-
-### Linked Issues
-{FOR EACH LINKED ISSUE:}
-- **{link_type}** {LINKED-KEY}: {summary} ({status})
-
-### Suggested Actions
-{Based on what's missing:}
-1. {IF no _docs/} Create epic documentation structure
-2. {IF no Confluence pages} Sync documentation to Confluence
-3. {IF orphaned} This ticket has no parent epic — consider linking it
-```
-
----
-
-## Mode 2: Epic Structure Creation
-
-Use when the user wants to create a new epic folder structure with documentation. The input can come from a PM document, a `context-analyst` output, manual input, or an existing Jira epic that lacks local structure.
-
-### Step 1: Get Epic Definition
-
-Accept the epic definition from one of these sources:
-
-- **Existing Jira epic** — User provides an epic key. Fetch from Jira and use its details.
-- **Document input** — User provides or points to a document (e.g. from `context-analyst` output) containing goals, scope, stories, and technical details.
-- **Manual input** — User describes the epic. Ask for:
-  1. Epic title / summary
-  2. Brief description and goals
-  3. Known stories or tasks (optional)
-  4. Technical approach or constraints (optional)
-
-### Step 2: Resolve Project and Instance
-
-- Use `confirmed_project` and instance from session context if available.
-- Otherwise, ask for the Jira project key and instance identifier.
-
-### Step 3: Create Local Folder Structure
-
-Create the folder structure per `jira-file-structure.md`:
-
-```
-docs/jira/{instance}/{project}/{EPIC-KEY}-{slug}/
-├── epic.md                         # Epic sync state + metadata
-├── _docs/                          # Generated documentation
-│   ├── technical-architecture.md   # Architecture decisions and design
-│   ├── decisions.md                # Decision log and rationale
-│   └── strategic-context.md        # Business context and alignment
-└── stories/                        # Story folders (created per story)
-```
-
-**For `epic.md`:**
-- Populate YAML frontmatter per `sync-state-format.md`.
-- If sourced from Jira, fill in all `sync` fields from the fetched data.
-- If sourced from a document or manual input, set `sync.status: "draft"` and leave Jira fields empty until creation.
-- Body: Epic summary, description, goals, scope.
-
-**For `_docs/` files:**
-
-The `_docs/` folder contains generated documentation mapped to Confluence page categories. The standard doc types are:
-
-| Doc Type | File | Description |
-|----------|------|-------------|
-| `strategic-context` | `strategic-context.md` | Business goals, product vision, strategic decisions |
-| `technical-architecture` | `technical-architecture.md` | System design, tech decisions, implementation patterns |
-| `decisions` | `decisions.md` | Consolidated decision log with rationale |
-| `research-and-findings` | `research-and-findings.md` | User research, discoveries, clarifications (if applicable) |
-| `assumptions` | `assumptions.md` | Assumptions with confidence levels and validation needs (if applicable) |
-
-At minimum, create `technical-architecture.md`, `decisions.md`, and `strategic-context.md`. Create `research-and-findings.md` and `assumptions.md` only if the input contains relevant content.
-
-- Populate from the input if details are available; otherwise create a template with section headings.
-- For `assumptions.md`, every assumption must include: source, confidence level (High/Medium/Low), impact if wrong, and how to verify.
-
-Each `_docs/` file gets Confluence sync frontmatter per `sync-state-format.md` with `mode: "structured"` and empty sync fields (populated after Confluence sync).
-
-### Step 4: Create Story Folders (Optional)
-
-If stories were provided in the input:
-
-For each story, create:
-```
-stories/{STORY-KEY}/{STORY-KEY}.md
-```
-
-Populate with sync state frontmatter. Set `structure.epic` to the epic key and `structure.parent` to the relative path to `epic.md`.
-
-If stories are not yet in Jira, set `sync.status: "draft"`.
-
-### Step 5: Optionally Create in Jira
-
-If the epic and stories don't exist in Jira yet, offer to create them:
-
-```
-Local structure created. Would you like to create these in Jira?
-1. Create epic and all stories in Jira now
-2. Create only the epic in Jira (stories later)
-3. Skip — keep as local drafts for now
-
-Choose [3]:
-```
-
-If creating in Jira:
-- Create the epic first via MCP. Store the returned key and ARI.
-- Create stories with the epic link set.
-- Update local files with the returned Jira keys and ARIs.
-- Follow FCMP protocol (though these are new resources, no conflict is possible on creation).
-
-### Step 6: Optionally Sync to Confluence
-
-After creating the local structure, offer Confluence sync:
-
-```
-Would you like to publish documentation to Confluence?
-1. Sync all _docs/ to Confluence now (structured mode)
-2. Skip — I'll sync later
-
-Choose [2]:
-```
-
-If syncing, proceed to Mode 3 (Confluence Sync — Structured).
-
-### Output Format (Epic Structure Creation)
-
-```
-## 🏗️ Epic Structure Created: {EPIC-KEY} — {Epic Summary}
-
-### Files Created
-- `docs/jira/{instance}/{project}/{EPIC-KEY}-{slug}/epic.md`
-- `docs/jira/{instance}/{project}/{EPIC-KEY}-{slug}/_docs/technical-architecture.md`
-- `docs/jira/{instance}/{project}/{EPIC-KEY}-{slug}/_docs/decisions.md`
-- `docs/jira/{instance}/{project}/{EPIC-KEY}-{slug}/_docs/strategic-context.md`
-- `docs/jira/{instance}/{project}/{EPIC-KEY}-{slug}/stories/` (directory)
-{IF STORIES CREATED:}
-- `docs/jira/{instance}/{project}/{EPIC-KEY}-{slug}/stories/{STORY-KEY}/{STORY-KEY}.md` (×{n})
-
-{IF CREATED IN JIRA:}
-### Jira Issues Created
-- Epic: {EPIC-KEY} — {summary}
-{FOR EACH STORY:}
-- Story: {STORY-KEY} — {summary}
-
-{IF SYNCED TO CONFLUENCE:}
-### Confluence Pages
-- {page_title}: {confluence_url}
-
-### Next Steps
-{Based on what was done:}
-1. {IF draft only} Run `atlassian-orchestrator` again to create in Jira when ready
-2. {IF Jira created but no Confluence} Sync documentation to Confluence when ready
-3. Use `jira-ticket-focus` to start working on individual stories
-```
-
----
-
-## Mode 3: Confluence Sync
-
-Publish local documentation to Confluence. Supports two sub-modes per `confluence-file-structure.md`:
-
-### Sub-mode 3a: Structured Sync
-
-Used when syncing `_docs/` content from a Jira epic folder to Confluence following the predefined hierarchy.
-
-#### Step 1: Identify Source Content
-
-- Locate the epic folder and its `_docs/` directory.
-- List all `.md` files in `_docs/`.
-- Read each file to prepare for publishing.
-
-#### Step 2: Determine Confluence Target
-
-- Check if Confluence pages already exist (look for `sync.confluence_page_id` in each file's frontmatter).
-- If pages exist, this is an update — follow FCMP protocol.
-- If pages don't exist, determine the target:
-  - Use the initiative/epic hierarchy from `confluence-file-structure.md`.
-  - Ask the user for the Confluence space key if not known:
-    ```
-    Which Confluence space? (e.g. ENG, PROJ):
-    ```
-  - Ask for the parent page:
-    ```
-    Parent page for this epic's documentation? (page title or ID):
-    ```
-
-#### Step 3: Sync to Confluence
-
-For each `_docs/` file, in order:
-
-1. **FETCH** — If updating, fetch the current Confluence page state.
-2. **COMPARE** — If updating, compare local content against the remote page.
-3. **MERGE** — If conflicts, follow the FCMP merge protocol.
-4. **PUSH** — Create or update the Confluence page via MCP.
-   - Convert markdown to Confluence storage format.
-   - For new pages: set the parent page and space.
-   - For updates: include the version number for optimistic locking.
-
-After each page is created/updated:
-- Store `confluence_page_id` and `confluence_url` in the local file's frontmatter.
-- Set `mode: "structured"` in the frontmatter.
-- Set `source.doc_type` to the appropriate type (e.g. `technical-architecture`, `decisions`).
-
-#### Step 4: Link Back to Jira
-
-After Confluence pages are created:
-- Add Confluence page URLs as remote links on the Jira epic (if the epic exists in Jira).
-- Follow FCMP for the Jira update.
-
-### Sub-mode 3b: Flexible Sync
-
-Used for ad-hoc publishing of any markdown document to Confluence.
-
-#### Step 1: Accept Content
-
-- User specifies the file to publish (a local markdown file path).
-- Read the file content.
-
-#### Step 2: Determine Confluence Target
-
-Ask the user:
-
-```
-Where should this page go in Confluence?
-1. Space key (e.g. ENG):
-2. Parent page (title or ID, or "root" for top-level):
-3. Page title (default: {filename without extension}):
-```
-
-#### Step 3: Publish
-
-- If the file already has `sync.confluence_page_id` in its frontmatter, this is an update — follow FCMP.
-- Otherwise, create a new page via MCP.
-- Convert markdown to Confluence storage format.
-- Store page metadata in the file's frontmatter.
-- Set `mode: "flexible"` in the frontmatter.
-
-#### Step 4: Optional Jira Link
-
-```
-Link this page to a Jira ticket? (ticket key or "skip"):
-```
-
-If a ticket key is provided, add as a remote link on the Jira ticket.
-
-### Output Format (Confluence Sync)
-
-```
-## 📄 Confluence Sync Complete
-
-{FOR EACH PAGE:}
-### {Page Title}
-- **Space:** {space_key}
-- **URL:** {confluence_url}
-- **Status:** {Created | Updated (v{old} → v{new}) | No changes}
-{IF CONFLICT RESOLVED:}
-- **Conflict:** Resolved ({strategy})
-
-{IF LINKED TO JIRA:}
-### Jira Links Added
-- {EPIC-KEY}: Linked to {n} Confluence pages
-
-### Summary
-- Pages created: {n}
-- Pages updated: {n}
-- Pages unchanged: {n}
-```
-
----
-
-## Mode 4: Import Ticket
-
-Import an existing Jira ticket (and optionally its full hierarchy — parent epic, child stories) into the local mirror structure. Use when the ticket already exists in Jira but has no local representation.
-
-### Step 1: Get Ticket Key
-
-- Accept a Jira ticket key (e.g. "PROJ-123").
-- Accept `focused_ticket` from conversation context.
-- If the key is incomplete, prepend `confirmed_project`.
-
-### Step 2: Fetch Ticket via MCP
-
-Use `mcp_atlassian-rovo_fetch()` to retrieve:
-
-- Issue type, summary, description, acceptance criteria
-- Status, assignee, priority, story points
-- Parent (epic or story)
-- Child issues (if epic: stories; if story: subtasks)
-- Linked Confluence pages
-
-### Step 3: Determine Local Path
-
-Based on the ticket type and parent:
-
-- **Epic** → `docs/jira/{instance}/{project}/{EPIC-KEY}-{slug}/epic.md`
-- **Story with epic** → `docs/jira/{instance}/{project}/{epic-folder}/stories/{STORY-KEY}/{STORY-KEY}.md`
-- **Orphan** → `docs/jira/{instance}/{project}/_orphans/{TICKET-KEY}/{TICKET-KEY}.md`
-- **Subtask** → Under the parent story's `subtasks/` folder
-
-Check for existing local structure first — if the epic folder already exists, use it.
-
-### Step 4: Create Local Structure
-
-1. Create the ticket file with YAML frontmatter per `sync-state-format.md`.
-2. Populate all `sync` fields from the fetched Jira data.
-3. Set `sync.status: "synced"` and `sync.last_synced` to now.
-4. Write the description and acceptance criteria to the file body.
-
-### Step 5: Fetch Children Recursively (Optional)
-
-If the ticket is an epic, offer to import its children:
-
-```
-This epic has {n} child stories. Import them?
-1. Import all child stories
-2. Import only — list children for reference
-3. Skip children
-
-Choose [1]:
-```
-
-If importing children:
-- Create `stories/` folder structure.
-- For each child, create the ticket file with full sync state.
-- If a child has subtasks, recurse into those as well.
-
-### Step 6: Generate `_docs/` Stubs (for Epics)
-
-If importing an epic, create `_docs/` folder with stub files:
-
-```
-_docs/
-├── technical-architecture.md    # "Imported from Jira — enrich with technical details"
-├── decisions.md                 # "Imported from Jira — add decisions as they're made"
-└── strategic-context.md         # "Imported from Jira — add business context"
-```
-
-Flag these for PM/developer enrichment.
-
-### Output Format (Import)
-
-```
-## 📥 Imported: {TICKET-KEY} — {Summary}
-
-**Type:** {issue_type} | **Status:** {status} | **Assignee:** {assignee}
-**Local Path:** {relative_path}
-
-### Structure Created
-- {TICKET-KEY}.md (synced, version {version})
-{IF EPIC WITH CHILDREN:}
-- _docs/ (stub templates — needs enrichment)
-- stories/ ({n} stories imported)
-  {FOR EACH CHILD:}
-  - {CHILD-KEY}: {summary} ({status})
-
-{IF CONFLUENCE PAGES LINKED:}
-### Linked Confluence Pages
-- {page_title}: {confluence_url}
-
-### Next Steps
-1. {IF epic} Enrich _docs/ with architecture and decisions
-2. Use `jira-ticket-focus` to start working on a specific story
-3. {IF no Confluence} Consider syncing documentation to Confluence
-```
-
----
-
-## Mode 5: Continue Structure
-
-Add new items (epics, stories, tasks, bugs) to an existing local structure while maintaining consistency with siblings and parent context.
-
-### Step 1: Detect Current Context
-
-- Identify what level we're at: initiative, epic, or story folder.
-- Load the parent's context from its file and `_docs/`.
-- Load sibling items for consistency (naming conventions, scope patterns, frontmatter format).
-
-### Step 2: Accept New Item Definition
-
-Ask the user:
-
-```
-What would you like to add?
-1. Type: {Epic | Story | Task | Bug}
-2. Parent: {folder path or ticket key}
-3. Brief description
-
-Or provide all at once, e.g.: "Add a story to PROJ-100 for user password reset"
-```
-
-### Step 3: Load Parent Context
-
-- Read the parent's acceptance criteria, goals, and scope.
-- Load `_docs/` content for architectural context.
-- Review sibling items to ensure:
-  - Consistent naming conventions
-  - Complementary scope (no overlap with existing siblings)
-  - Similar structure and frontmatter format
-
-### Step 4: Generate New Item
-
-Create the new item's file(s):
-
-- Match the parent's naming convention for the folder name.
-- Use consistent YAML frontmatter (copy structure from a sibling).
-- Set `structure.parent` as a relative path to the parent file.
-- Include acceptance criteria derived from the description and parent context.
-- Set `sync.status: "draft"`.
-
-### Step 5: Optionally Create in Jira
-
-```
-Local file created. Create in Jira?
-1. Create in Jira now (with parent link)
-2. Keep as local draft
-
-Choose [2]:
-```
-
-If creating: set parent/epic link, include Confluence links if parent has them, follow FCMP.
-
-### Step 6: Optionally Add to Confluence
-
-If the parent has Confluence pages:
-
-```
-Parent has Confluence documentation. Add a child page?
-1. Create Confluence page under parent
-2. Skip
-
-Choose [2]:
-```
-
-### Output Format (Continue Structure)
-
-```
-## ➕ Added: {TICKET-KEY or "Draft"} — {Summary}
-
-**Type:** {type} | **Parent:** {parent key/path}
-**Local Path:** {relative_path}
-
-### Context Used
-- Parent: {parent summary}
-- Siblings: {n} existing items reviewed for consistency
-
-{IF CREATED IN JIRA:}
-### Jira
-- Created: {TICKET-KEY} — {summary}
-- Parent: {PARENT-KEY}
-
-### Next Steps
-1. {IF draft} Create in Jira when ready
-2. Use `jira-ticket-focus` to start working on this item
-```
-
----
-
-## Ownership Rules
-
-This skill owns:
-
-- `_docs/` folders within epic structures — this skill creates and maintains these files
-- Confluence page generation and sync — both structured and flexible modes
-- Epic folder creation — including `epic.md` structure
-
-This skill does NOT own:
-
-- `_work/` folders — owned by `jira-ticket-focus` / developer workflows
-- Story ticket files — shared ownership with `jira-ticket-focus` and other skills
-- Sprint/status operations — owned by other jira-* skills
-
-## Session Context
-
-After running, update conversational context with:
-
-- **last_orchestrator_mode** — Which mode was used (context, create, sync)
-- **last_epic_key** — The epic key that was operated on (if applicable)
-- **last_epic_path** — Local path to the epic folder (if applicable)
-- **confluence_pages_synced** — List of page URLs created/updated (if applicable)
-
-## Doc-Type Mapping Reference
-
-When creating `_docs/` content and syncing to Confluence, map source material to these Confluence page categories:
-
-| Category | Confluence Title | Sources |
-|----------|-----------------|---------|
-| Strategic Context | "Strategic Context" | PRD, product context, initiative context docs |
-| Technical Architecture | "Technical Architecture" | Architecture docs, technical notes, system design |
-| Decisions | "Decision Log" | Decision logs from any level (consolidated) |
-| Research & Findings | "Research & Findings" | UX research, user research, clarification logs |
-| Assumptions | "Assumptions & Validations" | Assumption logs with confidence levels (consolidated) |
-| Implementation Guidance | "Implementation Guidance" | Technical design docs (only if substantial) |
-
-**Exclude from Confluence:** Individual story/task/bug files, implementation notes, subtask context, edge case lists, and test scenarios. These stay local only.