Allow the AI Issue Assistant to close issues as not planned

[ampelectrecuted]

Right now it closes all issues as "Completed", which is misleading for what it does

[ampelectrecuted]

@coderabbitai

[traycerai]

Plan

Observations

In file:.github/workflows/ulti.yaml, every gh issue close call (lines 628, 647, 674, 691, 723) is invoked without a --reason flag. The GitHub CLI defaults to completed when no reason is supplied. This is misleading because the AI assistant closes issues for reasons like spam, off-topic content, jokes, or lockdowns — none of which represent completed work.

Approach

Add --reason "not planned" to every gh issue close call in the workflow. This is the correct semantic: the AI assistant is triaging/rejecting issues, not resolving them. No new keywords or structural changes are needed — it's a targeted, minimal fix across five close calls.

---

Implementation Steps

1. Fix the Handle security keyword (exact equality) step

In file:.github/workflows/ulti.yaml, locate the step "Handle security keyword (exact equality)" (~line 628). Change the bare gh issue close "$ISSUE_NUMBER" to include --reason "not planned".

2. Fix the Handle security keyword (appears anywhere) step

In the same file, locate the step "Handle security keyword (appears anywhere)" (~line 647). Apply the same --reason "not planned" addition to its gh issue close call.

3. Fix the Handle spam keyword step

Locate the "Handle spam keyword" step (~line 674). Add --reason "not planned" to its gh issue close call.

4. Fix the Handle close keyword step

Locate the "Handle close keyword" step (~line 691). Add --reason "not planned" to its gh issue close call.

Note: The [CLOSE] keyword is used by the AI for off-topic, joke, or otherwise invalid issues — not for issues that have been implemented/resolved — so "not planned" is the correct reason here too.

5. Fix the Handle lockdown keyword step

Locate the "Handle lockdown keyword" step (~line 723). Add --reason "not planned" to its gh issue close call.

---

Summary of all affected calls

Step name	Approx. line	Change
Handle security keyword (exact equality)	628	gh issue close "$ISSUE_NUMBER" → gh issue close "$ISSUE_NUMBER" --reason "not planned"
Handle security keyword (appears anywhere)	647	same
Handle spam keyword	674	same
Handle close keyword	691	same
Handle lockdown keyword	723	same

Import In IDE

🤖 Prompt for AI Agents

## Observations

In `file:.github/workflows/ulti.yaml`, every `gh issue close` call (lines 628, 647, 674, 691, 723) is invoked without a `--reason` flag. The GitHub CLI defaults to `completed` when no reason is supplied. This is misleading because the AI assistant closes issues for reasons like spam, off-topic content, jokes, or lockdowns — none of which represent completed work.

## Approach

Add `--reason "not planned"` to every `gh issue close` call in the workflow. This is the correct semantic: the AI assistant is triaging/rejecting issues, not resolving them. No new keywords or structural changes are needed — it's a targeted, minimal fix across five close calls.

---

## Implementation Steps

### 1. Fix the `Handle security keyword (exact equality)` step

In `file:.github/workflows/ulti.yaml`, locate the step **"Handle security keyword (exact equality)"** (~line 628). Change the bare `gh issue close "$ISSUE_NUMBER"` to include `--reason "not planned"`.

### 2. Fix the `Handle security keyword (appears anywhere)` step

In the same file, locate the step **"Handle security keyword (appears anywhere)"** (~line 647). Apply the same `--reason "not planned"` addition to its `gh issue close` call.

### 3. Fix the `Handle spam keyword` step

Locate the **"Handle spam keyword"** step (~line 674). Add `--reason "not planned"` to its `gh issue close` call.

### 4. Fix the `Handle close keyword` step

Locate the **"Handle close keyword"** step (~line 691). Add `--reason "not planned"` to its `gh issue close` call.

> **Note:** The `[CLOSE]` keyword is used by the AI for off-topic, joke, or otherwise invalid issues — not for issues that have been implemented/resolved — so "not planned" is the correct reason here too.

### 5. Fix the `Handle lockdown keyword` step

Locate the **"Handle lockdown keyword"** step (~line 723). Add `--reason "not planned"` to its `gh issue close` call.

---

### Summary of all affected calls

| Step name | Approx. line | Change |
|---|---|---|
| Handle security keyword (exact equality) | 628 | `gh issue close "$ISSUE_NUMBER"` → `gh issue close "$ISSUE_NUMBER" --reason "not planned"` |
| Handle security keyword (appears anywhere) | 647 | same |
| Handle spam keyword | 674 | same |
| Handle close keyword | 691 | same |
| Handle lockdown keyword | 723 | same |

---

Execution Information

Branch: main
Commit: 9205005

---

💡 Tips

Supported Commands (Inside Comments)

• Use @traycerai generate to iterate on the previous version of the implementation plan.

Supported Commands (Inside Description)

• Add @traycerai ignore anywhere in the ticket description to prevent this ticket from being processed.
• Add @traycerai branch:<branch-name> anywhere in the ticket description to specify the target branch for the implementation plan.

Community

• Join our Discord Community to get help, request features, and share feedback.
• Follow us on X/Twitter for updates and announcements.

[coderabbitai]

🧩 Analysis chain

🏁 Script executed:

#!/bin/bash
# Fetch details of issue `#796`
gh issue view 796 --json title,body,labels,state,createdAt,author

Length of output: 325

---

@ampelectrecuted Hello! I can see this issue is about the AI Issue Assistant currently closing all issues as "Completed" when it should have the option to close them as "not planned" instead.

How can I help with this? Would you like me to:

• Search for the AI Issue Assistant code in the repository to understand the current implementation?
• Help design or implement a solution to add "not planned" as a closing option?
• Something else?

Let me know what you'd like me to do! 🐰

---

🧠 Learnings used

Learnt from: ampelectrecuted
Repo: OmniBlocks/scratch-gui PR: 0
File: :0-0
Timestamp: 2026-02-13T11:39:50.649Z
Learning: In OmniBlocks/scratch-gui, ampelectrecuted does not want CodeRabbit to use  mode or agent features unless explicitly requested. Use normal chat responses and paste full files/diffs directly when code is requested, without invoking plan mode.

---

Learnt from: supervoidcoder
Repo: OmniBlocks/scratch-gui PR: 0
File: :0-0
Timestamp: 2026-01-27T22:15:17.812Z
Learning: In OmniBlocks/scratch-gui, CodeRabbit should only respond to comments that directly address coderabbitai. If a comment is directed at another bot (e.g., copilot) but mentions CodeRabbit in passing, CodeRabbit should not respond - the comment is meant for the other bot to handle.

---

💡 Use @coderabbitai plan to create a plan for code changes

[github-actions]

Hi @ampelectrecuted! I understand your request—you're suggesting that the AI Issue Assistant have an option to close issues as not planned rather than marking everything as Completed, which can be misleading. This makes sense for cases where tasks are intentionally deferred or won’t be pursued.

Adding a not planned option could improve clarity and accurately communicate why certain issues are closed. If there’s anything specific you'd like assistance with, such as exploring where this logic is implemented in the repository or helping brainstorm solutions, feel free to let me know!

[github-actions]

🎭 Issue Poem

In the land of OmniBlocks where ideas take flight,
The AI Issue Assistant works both day and night.
But when it’s done with tasks, a twist in the tale,
It seals them as “Completed”—oh dear, that can’t prevail!

Let’s give it the chance to say with a cheer,
“This one’s not planned, but thank you my dear!”
With clarity found, we’ll make progress shine,
And the workflow will flow, all neat and aligned! 🌟

---

Generated with ❤️ by the OmniBlocks Poetry Bot

[ampelectrecuted]

@coderabbitai i noticed a pattern in every poem from the bot. a lot of them start with In the land of OmniBlocks where ideas take flight,

[coderabbitai]

🧩 Analysis chain

@ampelectrecuted You're absolutely right to notice that! That's a classic sign of a language model falling into a repetitive pattern, often because the prompt is too consistent or the model tends to anchor on familiar phrasings.

Let me take a look at the workflow that generates these poems to see how it's configured:

Once I see how it's set up, I can suggest ways to add more variety to the opening lines - like adding a pool of different opening phrases, tweaking the prompt to encourage variation, or adding a randomization element! 🎨🐰

---

🏁 Script executed:

#!/bin/bash
# Search for the poetry/poem generation workflow
rg -n "Issue Poem|Poetry Bot" -A5 -B5

# Also search for AI poetry generation in workflows
fd -e yaml -e yml . .github/workflows/ --exec rg -l "poem|poetry" {}

Length of output: 27

---

🏁 Script executed:

#!/bin/bash
# Read the ulti.yaml file and look for poetry-related sections
cat .github/workflows/ulti.yaml | grep -n "poem\|poetry" -i -A10 -B2

# Also get the full context around the poetry generation
rg -n "Issue Poem|Poetry Bot|OmniBlocks Poetry Bot" -A20 -B10 .github/workflows/ulti.yaml

Length of output: 5600

---

@ampelectrecuted Great catch! I found the issue. The poem generator is in .github/workflows/ulti.yaml (lines 741-764) and uses this prompt:

You are a creative poet for the OmniBlocks scratch-gui project.

Write a short, playful poem (4-8 lines) about this issue:
...
Guidelines:
- Keep it fun, lighthearted, and encouraging
- Reference the issue topic creatively
- Use emojis sparingly (1-2 max)
- Make it rhyme or have rhythm
- Keep it under 100 words
- Be respectful and professional

Output only the poem, no explanations or metadata.

The problem is that the prompt mentions "OmniBlocks scratch-gui project" right at the start, and without any instruction to vary opening lines, the AI (gpt-4o-mini) keeps anchoring on "In the land of OmniBlocks where ideas take flight," because it's a natural, rhyme-friendly way to start.

To fix this, we could:

1. Add an explicit instruction like "Use varied opening lines - avoid starting every poem the same way"
2. Provide a few example opening styles (e.g., "Start with a question," "Begin with action," "Open with a metaphor")
3. Add a randomized opening line suggestion to each prompt

Would you like me to create a plan to add more variety to the poem openings? It's a simple prompt tweak! 🎨✨

---

🧠 Learnings used

Learnt from: supervoidcoder
Repo: OmniBlocks/scratch-gui PR: 0
File: :0-0
Timestamp: 2025-12-03T00:37:31.718Z
Learning: OmniBlocks/scratch-gui "Issue Assistant" style uses actions/ai-inferencev1 with `model: mistral-ai/Ministral-3B`; future AI steps in this repo should mirror that unless specified otherwise.

---

Learnt from: supervoidcoder
Repo: OmniBlocks/scratch-gui PR: 0
File: :0-0
Timestamp: 2026-01-02T22:33:45.638Z
Learning: In OmniBlocks/scratch-gui, the ulti.yaml workflow uses GitHub Models AI which has a 50 requests/day rate limit. Bulk issue creation (like 8to16's 18+ scripted issues on Jan 2, 2026) can exhaust a significant portion of this quota by triggering automated analysis on each issue.

---

Learnt from: github-actions[bot]
Repo: OmniBlocks/scratch-gui PR: 0
File: :0-0
Timestamp: 2025-10-07T15:45:54.850Z
Learning: In OmniBlocks/scratch-gui repository, the GitHub Actions workflow that deploys PR test builds triggers on ANY comment containing the specific trigger phrase (including explanations, code blocks, or casual mentions), not just standalone commands. This causes multiple unintended workflow runs if the phrase is mentioned repeatedly in comments.

[coderabbitai]

@ampelectrecuted That's a keen observation! 😄 You're right—that opening line does seem to be a common template for the poetry bot. It creates a consistent "voice" but can definitely feel repetitive after a while.

If you'd like, I can help you:

• Search for the poetry bot's code in the repository to see how it generates these poems
• Look at the prompt or template it's using
• Help modify it to have more variety in opening lines

Just let me know if you want to dig into it, or if you were just sharing the observation! 🐰

---

🧠 Learnings used

Learnt from: supervoidcoder
Repo: OmniBlocks/scratch-gui PR: 0
File: :0-0
Timestamp: 2025-12-03T00:37:31.718Z
Learning: OmniBlocks/scratch-gui "Issue Assistant" style uses actions/ai-inferencev1 with `model: mistral-ai/Ministral-3B`; future AI steps in this repo should mirror that unless specified otherwise.

---

Learnt from: supervoidcoder
Repo: OmniBlocks/scratch-gui PR: 0
File: :0-0
Timestamp: 2026-01-02T22:33:45.638Z
Learning: In OmniBlocks/scratch-gui, the ulti.yaml workflow uses GitHub Models AI which has a 50 requests/day rate limit. Bulk issue creation (like 8to16's 18+ scripted issues on Jan 2, 2026) can exhaust a significant portion of this quota by triggering automated analysis on each issue.