auto start pm on issue #19

Closed
opened 2026-07-03 14:11:32 +02:00 by ffaerber · 2 comments
Owner

if i create a issue the pm should start looking add the issue. its the same like the ffaerber/homelab repo

if i create a issue the pm should start looking add the issue. its the same like the ffaerber/homelab repo
Author
Owner

@pm here

@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 @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:

  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.

🤖 **@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.
Sign in to join this conversation.
2 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: gitea/agents#19