/testgen-flow-data-collection

name: testgen-flow-data-collection
description: "Phase 1 Data Collection of testgen-flow"
alwaysApply: false
disable-model-invocation: true
user-invocable: false
baseSchema: docs/schemas/phase.md

<testgen_flow_data_collection>

<description_and_purpose> Extract all relevant data from the Issue Tracker ticket and related Wiki / documentation sources to establish baseline for gap analysis and requirements generation. </description_and_purpose>

<workflow_context>

• Phase 1 of 7 in `testgen-flow`
• Input: initial user request + `initial-data.md`
• Output: `raw-data.md` with extracted Issue Tracker and Wiki data
• Prerequisite: Phase 0 complete
• Collection skill: `data-collection` (single canonical collector). This phase resolves each in-scope provider and passes its role + provider to the skill; the skill loads the role-named binding.
• **Provider resolution (merge evidence; providers are NOT hardcoded):**

1. Providers were resolved in Phase 0 (`testgen-project-config.md` data sources, prefilled from `gain.json` `sdlc.issue_tracker(_project)` / `sdlc.wiki(_project)`). 2. Reconcile with explicit user names/handles (which win for this run) and recognizable provider URLs in `initial-data.md` (valid evidence when unambiguous). 3. Evidence conflicting or ambiguous → ask only about the unresolved provider/input; never silently choose between conflicting systems. 4. Wiki scope clearly absent → `SKIPPED_NO_CONFIG` (record the gap + skip that source, do not fabricate a provider). The Issue Tracker source is required.

• Integrations: Issue Tracker + Wiki per the parent Terminology (Jira and Confluence are the canonical examples throughout this phase).

</workflow_context>

<phase_steps> 1. Extract Issue Tracker ticket data 2. Get Wiki documentation 3. Create raw data document 4. Update state file </phase_steps>

<extract_ticket step="1.1"> 1. **Read `plans/testgen-{TICKET-KEY}/initial-data.md`** (contributes the original user prompt and a pointer to the project config) and the original user request. 2. Resolve the **Issue Tracker provider** per `<workflow_context>`. If unresolvable with scope active, re-read config; still absent → record the gap and stop Phase 1. 3. Extract ticket key from user input (parse from URL if needed). **Ticket-key extraction failure path:** if no key can be parsed (no URL, malformed input, ambiguous candidates): stop Phase 1, ask the user once for the exact ticket key (`PROJ-NNN` form), do not proceed until the user provides it. After 2 unsuccessful re-asks, record `Phase 1 blocked: ticket key unresolvable` in `testgen-state.md` and stop. 4. USE SKILL `data-collection` with role `Issue Tracker`, the resolved provider, the resolved ticket key, and the ticket section of `<create_raw_data>`'s minimum-output contract; the skill loads its issue binding and adapts the canonical Jira examples to the target system. Retrieve fields: summary, description, status, issuetype, priority, labels, components, assignee, reporter, comments (up to 10). Redaction runs inside `data-collection` via `sensitive-data` before write.

</extract_ticket>

<get_wiki step="1.2"> 1. Resolve the **Wiki provider** per `<workflow_context>`. If no Wiki is in scope, apply `SKIPPED_NO_CONFIG`: record `Wiki Source: Skipped — no Wiki configured` and proceed ticket-only. 2. USE SKILL `data-collection` with role `Wiki`, the resolved provider, the Wiki input handle(s), and the Wiki section of `<create_raw_data>`'s contract. The skill's documentation binding owns URL parsing, direct-URL-vs-search precedence, child-page traversal, truncation, deduplication, permission fallbacks, AND the authenticated reads/searches in one binding — no second skill to reconcile against; its canonical Confluence examples adapt to the target system. Redaction runs inside `data-collection` via `sensitive-data` before write. 3. **Search-term seed (passed to `data-collection` when no URLs supplied):** project key (from ticket key), labels, component names, key terms from summary/description. 4. **Fallback**: when the binding reports zero pages after URL + search + its ask-once user fallback, record `Wiki Source: not available — proceeded ticket-only` in the data collection summary and continue. Do NOT fabricate documentation content. </get_wiki>

<create_raw_data step="1.3"> **Minimum-output contract (asserted by this phase independent of skill internals):** `raw-data.md` MUST capture, at minimum — ticket: summary, description, status, priority, labels, components, comments; Wiki (when not skipped): page title, URL, content. Missing any of these = phase incomplete, regardless of what the `data-collection` role bindings define internally. The template below shows Jira/Confluence field names as canonical examples — adapt labels to the resolved providers.

1. Create `plans/testgen-{TICKET-KEY}/raw-data.md` with structure:

# Raw Data - [TICKET-KEY]

**Extracted**: [DateTime]
**Phase**: 1 - Data Collection
**Providers**: [resolved Issue Tracker / Wiki]
**Wiki Source**: [User-provided URLs / Auto-search / User-provided after search / Skipped]

---

## Issue Tracker Ticket Data

### Ticket: [KEY]
**URL**: [Ticket URL]
**Summary**: [Summary]
**Type**: [Issue Type]
**Status**: [Status]
**Priority**: [Priority]
**Created**: [Date]
**Updated**: [Date]

### Description
[Full description - rendered if HTML, otherwise raw]

### Labels
- [Label1]
- [Label2]

### Components
- [Component1]
- [Component2]

### Assignee
**Name**: [Assignee Name]
**Email**: [If available]

### Reporter
**Name**: [Reporter Name]
**Email**: [If available]

### Comments (Recent)
1. **[Author]** ([Date]): [Comment text]
2. **[Author]** ([Date]): [Comment text]
[...]

### Custom Fields
[List any custom fields found, e.g., Epic Link, Story Points, Sprint, etc.]

---

## Wiki Documentation

### Page 1: [Page Title]
**URL**: [Wiki page URL]
**Space**: [Space Key]
**Labels**: [Labels]
**Updated**: [Date]
**Type**: Parent / Child of [Parent Title]

#### C