122 lines
4.5 KiB
Markdown
122 lines
4.5 KiB
Markdown
---
|
|
name: discuss
|
|
description: Single-persona interactive discussion of a Gitea issue. The persona reads the issue and all comments, lists open items in their scope, and walks through each with the user. When done, posts the discussion result as a Gitea comment.
|
|
---
|
|
|
|
# Single-Persona Issue Discussion
|
|
|
|
You will adopt a single persona, read a Gitea issue in full, and have an interactive discussion with the user — working through every open item in that persona's scope. At the end you post the agreed outcomes as a comment on the issue.
|
|
|
|
## Arguments
|
|
|
|
The user provides an issue URL and a persona shorthand, e.g.:
|
|
`http://heim-nas:3005/marcel/familienarchiv/issues/162 ui`
|
|
|
|
Parse the URL to extract:
|
|
- `owner` — e.g. `marcel`
|
|
- `repo` — e.g. `familienarchiv`
|
|
- `issue_number` — e.g. `162`
|
|
|
|
Map the persona shorthand to a file in `.claude/personas/`:
|
|
|
|
| Shorthand | File |
|
|
|---|---|
|
|
| `dev` | `developer.md` |
|
|
| `arch` | `architect.md` |
|
|
| `ui` | `ui_expert.md` |
|
|
| `ops` | `devops.md` |
|
|
| `qa` or `tester` | `tester.md` |
|
|
| `sec` or `security` | `security_expert.md` |
|
|
|
|
If the shorthand doesn't match any of the above, tell the user the valid options and stop.
|
|
|
|
---
|
|
|
|
## Step 1 — Gather Issue Context
|
|
|
|
Use the Gitea MCP tools in parallel:
|
|
1. Full issue (title, body, labels) via `issue_read` with method `get`
|
|
2. All existing comments via `issue_read` with method `get_comments`
|
|
|
|
Read both before proceeding.
|
|
|
|
---
|
|
|
|
## Step 2 — Read the Persona
|
|
|
|
Read the persona file from `.claude/personas/`. Fully internalize their identity, priorities, domain focus, and blind spots as described.
|
|
|
|
---
|
|
|
|
## Step 3 — Identify Open Items
|
|
|
|
As the persona, read the entire issue body and all existing comments. From your domain perspective, build a numbered list of **open items** — questions, risks, gaps, decisions, or ambiguities that you would want to resolve before or during implementation.
|
|
|
|
An open item is anything the persona would genuinely care about that is either:
|
|
- Not answered in the issue or its comments, or
|
|
- Answered but in a way that raises follow-up questions from this persona's perspective
|
|
|
|
Be specific and reference the issue text. Do not repeat observations that are already fully resolved in the comments. Do not produce generic items — each must be grounded in the actual issue content.
|
|
|
|
**Present this list to the user** in the persona's voice, with a short intro in character. Format:
|
|
|
|
```
|
|
## [Persona emoji + Name] — [Role]
|
|
|
|
I've read through the issue and comments. Here are the open items I want to work through with you:
|
|
|
|
1. **[Short title]** — [One-sentence description of the concern or question]
|
|
2. **[Short title]** — ...
|
|
...
|
|
|
|
Let's go through them one by one. Ready to start with item 1?
|
|
```
|
|
|
|
Then **stop and wait for the user to respond** before proceeding.
|
|
|
|
---
|
|
|
|
## Step 4 — Interactive Discussion
|
|
|
|
Work through the open items **one at a time**:
|
|
|
|
1. Present the item in full from the persona's perspective — their concern, why it matters to them, what they want to understand or decide
|
|
2. Ask a focused, specific question (not multiple questions at once)
|
|
3. Wait for the user's response
|
|
4. React as the persona — accept, push back, propose alternatives, or note follow-up implications
|
|
5. When the item feels resolved (the user has answered and you've responded), mark it as done and move to the next item
|
|
|
|
Stay in character throughout. The persona's tone, priorities, and blind spots should be evident in every message.
|
|
|
|
If the user says "skip", "next", or similar — acknowledge it briefly and move on. Mark the item as skipped (unresolved).
|
|
|
|
When all items are done, show a brief summary:
|
|
- Resolved items (what was agreed or decided)
|
|
- Skipped / unresolved items (noted for the comment)
|
|
|
|
Ask: **"Ready to post the discussion summary to the issue?"**
|
|
|
|
Wait for explicit confirmation before posting.
|
|
|
|
---
|
|
|
|
## Step 5 — Post the Comment
|
|
|
|
After user confirmation, post a single comment to the issue using the Gitea MCP `issue_write` tool with method `add_comment`.
|
|
|
|
The comment should:
|
|
- Open with the persona header: `## [emoji] [Name] — [Role]` and a one-liner about what this comment captures
|
|
- List resolved items with the agreed outcome or decision
|
|
- List unresolved / skipped items briefly, noting they were raised but not settled
|
|
- Close with a short sentence from the persona about their overall read of the issue
|
|
|
|
Keep it scannable — bullet points per item, no walls of text.
|
|
|
|
---
|
|
|
|
## Step 6 — Report Back
|
|
|
|
After posting, tell the user:
|
|
- The comment was posted (with the Gitea URL if available)
|
|
- A one-line summary of the most important thing that came out of the discussion
|