I checked how issue-triggering works in this repo today.
Root cause found: The shared reusable workflow (.gitea/workflows/agent.yml) already fully supports auto-starting @pm on a new issue — its trigger gate (line 12-13) allows the issues event, and its routing logic (agent.yml:64-71) says "On a new issue, @pm auto-assesses" by defaulting name=pm when no other agent is mentioned.
The problem is this repo's own caller workflow, .gitea/workflows/ai-agent.yml, only subscribes to:
on:issue_comment:types:[created]
It never listens for the issues: opened event at all, so a brand-new issue never triggers a run — the caller's own header comment even states it explicitly: "creating an issue does not auto-start anyone." That line is stale/intentional-but-outdated relative to what you now want.
This matches your description of ffaerber/homelab's behavior — that repo's caller apparently does subscribe to issues: opened, this one doesn't (yet).
Plan
Small, low-risk, single-file YAML change in this repo:
In .gitea/workflows/ai-agent.yml, add an issues: trigger (types: [opened]) alongside the existing issue_comment trigger.
Update the file's header comment (currently says issue-creation does not auto-start anyone) to reflect the new behavior.
No changes needed to the shared agent.yml — its gate (issue.user.login == 'ffaerber') and auto-@pm-routing already handle this safely.
This is exactly the kind of small, low-risk config/YAML change that fits @junior.
@ffaerber ready to start building? reply yes to proceed.
🤖 **@pm**
## Research
I checked how issue-triggering works in this repo today.
**Root cause found:** The shared reusable workflow (`.gitea/workflows/agent.yml`) already fully supports auto-starting `@pm` on a new issue — its trigger gate (line 12-13) allows the `issues` event, and its routing logic (`agent.yml:64-71`) says *"On a new issue, `@pm` auto-assesses"* by defaulting `name=pm` when no other agent is mentioned.
The problem is this repo's own **caller** workflow, `.gitea/workflows/ai-agent.yml`, only subscribes to:
```yaml
on:
issue_comment:
types: [created]
```
It never listens for the `issues: opened` event at all, so a brand-new issue never triggers a run — the caller's own header comment even states it explicitly: *"creating an issue does not auto-start anyone."* That line is stale/intentional-but-outdated relative to what you now want.
This matches your description of `ffaerber/homelab`'s behavior — that repo's caller apparently *does* subscribe to `issues: opened`, this one doesn't (yet).
## Plan
Small, low-risk, single-file YAML change in this repo:
1. In `.gitea/workflows/ai-agent.yml`, add an `issues:` trigger (`types: [opened]`) alongside the existing `issue_comment` trigger.
2. Update the file's header comment (currently says issue-creation does *not* auto-start anyone) to reflect the new behavior.
3. No changes needed to the shared `agent.yml` — its gate (`issue.user.login == 'ffaerber'`) and auto-`@pm`-routing already handle this safely.
This is exactly the kind of small, low-risk config/YAML change that fits **@junior**.
@ffaerber ready to start building? reply yes to proceed.
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
if i create a issue the pm should start looking add the issue. its the same like the ffaerber/homelab repo
@pm here
🤖 @pm
Research
I checked how issue-triggering works in this repo today.
Root cause found: The shared reusable workflow (
.gitea/workflows/agent.yml) already fully supports auto-starting@pmon a new issue — its trigger gate (line 12-13) allows theissuesevent, and its routing logic (agent.yml:64-71) says "On a new issue,@pmauto-assesses" by defaultingname=pmwhen no other agent is mentioned.The problem is this repo's own caller workflow,
.gitea/workflows/ai-agent.yml, only subscribes to:It never listens for the
issues: openedevent at all, so a brand-new issue never triggers a run — the caller's own header comment even states it explicitly: "creating an issue does not auto-start anyone." That line is stale/intentional-but-outdated relative to what you now want.This matches your description of
ffaerber/homelab's behavior — that repo's caller apparently does subscribe toissues: opened, this one doesn't (yet).Plan
Small, low-risk, single-file YAML change in this repo:
.gitea/workflows/ai-agent.yml, add anissues:trigger (types: [opened]) alongside the existingissue_commenttrigger.agent.yml— its gate (issue.user.login == 'ffaerber') and auto-@pm-routing already handle this safely.This is exactly the kind of small, low-risk config/YAML change that fits @junior.
@ffaerber ready to start building? reply yes to proceed.