forked from syntaxbullet/AuroraBot-discord
63 lines
4.0 KiB
Markdown
63 lines
4.0 KiB
Markdown
---
|
||
description: Converts conversational brain dumps into structured, metric-driven Markdown tickets in the ./tickets directory.
|
||
---
|
||
|
||
# WORKFLOW: PRAGMATIC ARCHITECT TICKET GENERATOR
|
||
|
||
## 1. High-Level Goal
|
||
Transform informal user "brain dumps" into high-precision, metric-driven engineering tickets stored as Markdown files in the `./tickets/` directory. The workflow enforces a quality gate via targeted inquiry before any file persistence occurs, ensuring all tasks are observable, measurable, and actionable.
|
||
|
||
## 2. Assumptions & Clarifications
|
||
- **Assumptions:** The agent has write access to the `./tickets/` and `/temp/` directories. The current date is accessible for naming conventions. "Metrics" refer to quantifiable constraints (latency, line counts, status codes).
|
||
- **Ambiguities:** If the user provides a second brain dump while a ticket is in progress, the agent will prioritize the current workflow until completion or explicit cancellation.
|
||
|
||
## 3. Stage Breakdown
|
||
|
||
### Stage 1: Discovery & Quality Gate
|
||
- **Stage Name:** Requirement Analysis
|
||
- **Purpose:** Analyze input for vagueness and enforce the "Quality Gate" by extracting metrics.
|
||
- **Inputs:** Raw user brain dump (text).
|
||
- **Actions:** 1. Identify "Known Unknowns" (vague terms like "fast," "better," "clean").
|
||
2. Formulate exactly three (3) targeted questions to convert vague goals into comparable metrics.
|
||
3. Check for logical inconsistencies in the request.
|
||
- **Outputs:** Three questions presented to the user.
|
||
- **Persistence Strategy:** Save the original brain dump and the three questions to `/temp/pending_ticket_state.json`.
|
||
|
||
### Stage 2: Drafting & Refinement
|
||
- **Stage Name:** Ticket Drafting
|
||
- **Purpose:** Synthesize the original dump and user answers into a structured Markdown draft.
|
||
- **Inputs:** User responses to the three questions; `/temp/pending_ticket_state.json`.
|
||
- **Actions:** 1. Construct a Markdown draft using the provided template.
|
||
2. Generate a slug-based filename: `YYYYMMDD-slug.md`.
|
||
3. Present the draft and filename to the user for review.
|
||
- **Outputs:** Formatted Markdown text and suggested filename displayed in the chat.
|
||
- **Persistence Strategy:** Update `/temp/pending_ticket_state.json` with the full Markdown content and the proposed filename.
|
||
|
||
### Stage 3: Execution & Persistence
|
||
- **Stage Name:** Finalization
|
||
- **Purpose:** Commit the approved ticket to the permanent `./tickets/` directory.
|
||
- **Inputs:** User confirmation (e.g., "Go," "Approved"); `/temp/pending_ticket_state.json`.
|
||
- **Actions:** 1. Write the finalized Markdown content to `./tickets/[filename]`.
|
||
2. Delete the temporary state file in `/temp/`.
|
||
- **Outputs:** Confirmation message containing the relative path to the new file.
|
||
- **Persistence Strategy:** Permanent write to `./tickets/`.
|
||
|
||
## 4. Data & File Contracts
|
||
- **State File:** `/temp/pending_ticket_state.json`
|
||
- Schema: `{ "original_input": string, "questions": string[], "answers": string[], "draft_content": string, "filename": string, "step": integer }`
|
||
- **Output File:** `./tickets/YYYYMMDD-[slug].md`
|
||
- Format: Markdown
|
||
- Sections: `# Title`, `## Context`, `## Acceptance Criteria`, `## Suggested Affected Files`, `## Technical Constraints`.
|
||
|
||
## 5. Failure & Recovery Handling
|
||
- **Incomplete Inputs:** If the user fails to answer the 3 questions, the agent must politely restate that metrics are required for high-precision engineering and repeat the questions.
|
||
- **Inconsistencies:** If the user’s answers contradict the original dump, the agent must flag the contradiction and ask for a tie-break before drafting.
|
||
- **Missing Directory:** If `./tickets/` does not exist during Stage 3, the agent must attempt to create it before writing the file.
|
||
|
||
## 6. Final Deliverable Specification
|
||
- **Format:** A valid Markdown file in the `./tickets/` folder.
|
||
- **Quality Bar:**
|
||
- Zero fluff in the Context section.
|
||
- All Acceptance Criteria must be binary (pass/fail) or metric-based.
|
||
- Filename must strictly follow `YYYYMMDD-slug.md` (e.g., `20240520-auth-refactor.md`).
|
||
- No "Status" or "Priority" fields. |