|
1 | 1 | You are helping the user submit product feedback for altimate-code. Feedback is filed as a GitHub issue. |
2 | 2 |
|
3 | | -If $ARGUMENTS is provided, use it as the initial description and skip asking for a description. Still confirm the title and category before submitting. |
| 3 | +// altimate_change start — reduce /feedback follow-up loop (#974) |
| 4 | +If $ARGUMENTS is provided, use it as the initial description. Infer a concise title and category from it when reasonable. |
| 5 | + |
| 6 | +Do not interview the user. Ask at most one round of clarifying questions, and only when essential information is genuinely missing. Essential information is: title, category, and description. If the description is straightforward, proceed directly to filing. |
| 7 | + |
| 8 | +Keep the category/label follow-up behavior: if the category is unclear, ask the user to pick one of the labels below. Bundle that label question with any other essential missing question in the same message. After the user's answer, do not ask more clarifying questions; use best judgment and submit. |
| 9 | + |
| 10 | +Do not ask optional "anything else?", wording-confirmation, or separate session context questions. Do not ask the user to confirm before filing unless they explicitly requested a review step. |
| 11 | +// altimate_change end |
4 | 12 |
|
5 | 13 | Step 1 — Collect feedback details: |
6 | 14 |
|
7 | | -Ask the user for the following information. Collect each piece one at a time: |
| 15 | +Infer these fields from the user's message and $ARGUMENTS first. Ask one combined follow-up only for essential fields that cannot be inferred: |
8 | 16 |
|
9 | 17 | 1. **Title**: A short summary of the feedback (one line). |
10 | | -2. **Category**: Ask the user to pick one: |
| 18 | +2. **Category**: Choose one, or ask the user to pick one if unclear: |
11 | 19 | - bug — Something is broken or not working as expected |
12 | 20 | - feature — A new capability or feature request |
13 | 21 | - improvement — An enhancement to existing functionality |
14 | 22 | - ux — Feedback on usability, flow, or developer experience |
15 | | -3. **Description**: A detailed explanation of the feedback. If $ARGUMENTS was provided, present it back and ask if they want to add anything or if it looks good. |
| 23 | +3. **Description**: A detailed explanation of the feedback. If $ARGUMENTS was provided, use it as the description unless it is empty or too vague to file. |
16 | 24 |
|
17 | 25 | Step 2 — Session context (opt-in): |
18 | 26 |
|
19 | | -Ask the user if they want to include session context with their feedback. Explain what this includes: |
| 27 | +Do not ask a separate session-context question. Set `include_context` to true only if the user explicitly asks to include session/debug context; otherwise set it to false. |
| 28 | + |
| 29 | +If the single essential follow-up is needed, you may mention that they can optionally say "include context". Explain that this includes: |
20 | 30 | - Working directory name (basename only, not the full path) |
21 | 31 | - Session ID (for debugging correlation) |
22 | 32 | - No code, credentials, or personal data is included |
23 | 33 |
|
24 | | -If they opt in, set `include_context` to true when submitting. |
25 | | - |
26 | | -Step 3 — Confirm and submit: |
| 34 | +Step 3 — Submit: |
27 | 35 |
|
28 | | -Show a summary of the feedback before submitting: |
| 36 | +Once the essential fields are available, submit directly. Internally prepare this summary: |
29 | 37 | - **Title**: ... |
30 | 38 | - **Category**: ... |
31 | 39 | - **Description**: ... |
32 | 40 | - **Session context**: included / not included |
33 | 41 |
|
34 | | -Ask the user to confirm. If they confirm, call the `feedback_submit` tool with: |
| 42 | +Call the `feedback_submit` tool with: |
35 | 43 | - `title`: the feedback title |
36 | 44 | - `category`: the selected category |
37 | 45 | - `description`: the full description |
|
0 commit comments