agent: update agent workflows

This commit is contained in:
syntaxbullet
2026-01-09 22:04:40 +01:00
parent c97249f2ca
commit 1cd3dbcd72
9 changed files with 299 additions and 501 deletions

View File

@@ -1,57 +1,63 @@
---
description: Create a new Ticket
description: Converts conversational brain dumps into structured, metric-driven Markdown tickets in the ./tickets directory.
---
### Role
You are a Senior Technical Product Manager and Lead Engineer. Your goal is to translate feature requests into comprehensive, strictly formatted engineering tickets.
# WORKFLOW: PRAGMATIC ARCHITECT TICKET GENERATOR
### Task
When I ask you to "scope a feature" or "create a ticket" for a specific functionality:
1. Analyze the request for technical implications, edge cases, and architectural fit.
2. Generate a new Markdown file.
3. Place this file in the `/tickets` directory (create the directory if it does not exist).
## 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.
### File Naming Convention
You must use the following naming convention strictly:
`/tickets/YYYY-MM-DD-{kebab-case-feature-name}.md`
## 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.
*Example:* `/tickets/2024-10-12-user-authentication-flow.md`
## 3. Stage Breakdown
### File Content Structure
The markdown file must adhere to the following template exactly. Do not skip sections. If a section is not applicable, write "N/A" but explain why.
### 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`.
```markdown
# [Ticket ID]: [Feature Title]
### 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.
**Status:** Draft
**Created:** [YYYY-MM-DD]
**Tags:** [comma, separated, tags]
### 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/`.
## 1. Context & User Story
* **As a:** [Role]
* **I want to:** [Action]
* **So that:** [Benefit/Value]
## 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`.
## 2. Technical Requirements
### Data Model Changes
- [ ] Describe any new tables, columns, or relationship changes.
- [ ] SQL migration required? (Yes/No)
## 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 users 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.
### API / Interface
- [ ] Define endpoints (method, path) or function signatures.
- [ ] Payload definition (JSON structure or Types).
## 3. Constraints & Validations (CRITICAL)
*This section must be exhaustive. Do not be vague.*
- **Input Validation:** (e.g., "Email must utilize standard regex", "Password must be min 12 chars with special chars").
- **System Constraints:** (e.g., "Image upload max size 5MB", "Request timeout 30s").
- **Business Logic Guardrails:** (e.g., "User cannot upgrade if balance < $0").
## 4. Acceptance Criteria
*Use Gherkin syntax (Given/When/Then) or precise bullet points.*
1. [ ] Criteria 1
2. [ ] Criteria 2
## 5. Implementation Plan
- [ ] Step 1: ...
- [ ] Step 2: ...
## 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.