@senior: issue #17 — search past issues as knowledge base (gitea-api skill + pm prompt)

.gitea/workflows/agent.yml

@@ -300,6 +300,37 @@ jobs:
           Tip: `#12`-style references in a comment map to `/repos/{owner}/{repo}/issues/12`. To
           find the owner/repo for a `#N` in *this* repo, just use `${GITHUB_REPOSITORY}`.
 
+          ### Search for similar/related past issues by keyword (knowledge base)
+
+          When a new issue looks like something the maintainer may have answered before, search
+          for similar issues **before** asking clarifying questions — reuse prior answers instead
+          of re-asking. Two variants:
+
+          ```bash
+          API="${GITHUB_SERVER_URL}/api/v1"
+          # Same-repo: list issues on THIS repo matching keywords (all states, issues+PRs).
+          # ${GITHUB_REPOSITORY} is "owner/repo" for the current repo.
+          curl -sS -H "Authorization: token $AGENT_TOKEN" \
+            "$API/repos/${GITHUB_REPOSITORY}/issues?q=deploy+traefik&type=issues&state=all&limit=20" \
+            | jq -r '.[] | "#\(.number) [\(.state)] \(.title)"'
+          # Then read a matched issue's thread (see the "Open a referenced issue" example above).
+
+          # Cross-repo: search issues across ALL repos the token can see on this instance.
+          # Use the owner's name when you know it (e.g. the homelab repo), or leave it open.
+          curl -sS -H "Authorization: token $AGENT_TOKEN" \
+            "$API/repos/issues/search?q=deploy+traefik&type=issues&state=all&limit=20" \
+            | jq -r '.[] | "\(.repository.full_name)#\(.number) [\(.state)] \(.title)"'
+          ```
+
+          Tips:
+          - Pick keywords from the new issue's title/body (service names, error strings, the
+            action being requested). Try a couple of phrasings if the first returns nothing.
+          - `state=all` matters — past answers are usually on *closed* issues, which `state=open`
+            would hide.
+          - When you find a match, open its thread and read the maintainer's answers there; cite
+            the matched issue (e.g. `homelab#103`) in your plan and reuse those answers. Only ask
+            about things genuinely not covered by the precedent you found.
+
           ### List/read an Actions (workflow) run's jobs and logs
 
           ```bash
@@ -420,6 +451,15 @@ jobs:
             if [ "$NAME" = "pm" ]; then
               ACTION="$ACTION
              As PM you work in two phases and NEVER skip the approval gate:
+             KNOWLEDGE-BASE — BEFORE presenting a plan or asking any clarifying question, search for
+             similar/related PAST issues (in this repo AND other repos on this instance, e.g. homelab)
+             using the gitea-api skill's keyword-search example (same-repo issue-list with
+             ?q=<keywords>&type=issues&state=all, and the cross-repo /repos/issues/search variant).
+             Read the matched threads and REUSE the maintainer's prior answers instead of re-asking
+             settled questions — cite the matched issue number(s) (e.g. homelab#103) in your plan.
+             Only ask about things genuinely not covered by precedent you found. This is the single
+             most important part of your job: the maintainer should never have to answer the same
+             question twice.
              PLAN — when the task is clear, present a SHORT plan naming which teammate should build it
              (@junior for small/low-risk, @senior/@lead for complex, @qa to verify), then END by asking
              '@ffaerber ready to start building? reply yes to proceed.' Do NOT include a DELEGATE line yet.