Skip to content

Changelog

All notable changes of the issue assistant. The complete notes of every version, with each pull request, are on the releases page. Versions follow Semantic Versioning; a change of a template that repositories must install again is a new minor version, and one that breaks their settings a new major version.

Unreleased

1.5.0 (2026-10-14)

Added

  • A set-up in four steps, without looking up a hash. install takes the commit and the tag of the release from its own clone, so git clone --depth 1 --branch vX.Y.Z and install are enough; it refuses the object of an annotated tag, which git ls-remote lists first, with the commit to use instead, and a commit or tag that isn't its checkout, whose templates it writes. install --setup also creates the environment issue-assistant on GitHub, for the default branch only, and has the GitHub CLI ask for the engine's secret. install now writes everything that check asks for: the section What happens with your issue in SUPPORT.md (in German for a file such as SUPPORT.de.md) where it doesn't name the AI yet, the runner of the AI and the ignored queue in an existing .github/actionlint.yaml, and, together with the starter labels, a bug report form with an Area field for a repository without issue forms, whose answers the labels area: setup and area: docs map. Each step looks first, so running install again changes nothing but the workflows. The README's set-up ends with a step that tries the assistant on an existing issue as a dry run, and turning off GitHub's auto-close of issues by merged pull requests is a step of its own.
  • When a workflow or the firewall policy doesn't fit, check names the commands that write the templates of its release anew.
  • Your own lifecycle in a new section [lifecycle] of config.toml: the days until the reminder (remind_after_days, 15) and the closing (close_after_days, 30) of an issue without an answer, until a sure duplicate closes (duplicate_grace_days, 3), the window after a release in which the reporter's comment reopens the issue (reopen_after_release_days, 30), and how often the AI follows up (max_follow_ups, 2). The comments name the days that you set, in English and German, and so does the section What happens with your issue that install writes. check names a period that can't work, such as a closing before the reminder, and a description of needs-info, stale or possible-duplicate in labels.toml that names other days.
  • Exempt issues: the sweep never reminds or closes an issue with a label of exempt_labels, pinned and security unless you set others, and, if you like, one assigned to someone (exempt_assignees) or with enough 👍 (exempt_upvotes).
  • Old threads can lock: with lock_closed_after_days, the sweep locks issues closed for longer as resolved, with one line that points to a new issue, 25 in a sweep. It never locks before the window after a release is over, an exempt issue, or one that someone unlocked. It is off unless you set it.
  • A maintainer digest in the summary of the morning sweep: the open issues that wait on the maintainers (triage pending for more than 3 days, a reporter's answer, an objection to a duplicate notice), those that wait on their reporters with the day of the reminder or the closing, and the fixed ones that wait for a release, each a link, the longest waiting first and, among those of a day, the one with the most 👍.
  • How well the assistant does, on the first day of each month and in every sweep started by hand: for the 30 days before, the analyses posted, the median time from a new issue to its analysis, how many labels of the AI the maintainers kept and how many they added, what became of the duplicate notices and of the questions to reporters, and the 👍 and 👎 on the analyses. The summary holds numbers and links only, never the text of an issue.
  • Slash commands: maintainers steer the assistant from the issue, with a comment whose first line is the command. /assistant again asks for a new analysis, /assistant ask and a question gets the AI's answer from the code, checked as every answer before it is posted, /assistant duplicate #12 starts the closing of a duplicate after duplicate_grace_days (3 by default) and /assistant not-duplicate stops it, /assistant waiting marks the issue as waiting for its reporter, and /assistant mute and /assistant unmute keep the AI from starting anything on its own on the issue and let it again. The reporter may say not-duplicate, and ask once for a new analysis while the issue waits for triage, within the limits of the day. A 👀 on the comment shows that the command was carried out, a 😕 that it was refused, and the run says why. Run install again, which adds the task maintainer-question to Run workflow.
  • Answers in the reporter's language. Besides English and German, the assistant now writes French, Spanish, Portuguese, Italian and Dutch, with its own words from a catalog for each language in locales/, including the days of the lifecycle and the dates of reminders, such as 2 novembre 2026. In any other language, the AI writes in it and the headings and the footer stay English, with dates such as 2026-11-02. The reminders, closings and release notes of the sweep keep the language of the analysis, which its hidden marker records, and before an analysis the reporter's own words decide. A new language is one more file in locales/; the French, Spanish, Portuguese, Italian and Dutch texts are machine drafts that native speakers are welcome to improve.
  • Each task runs with its own model, turns and budget, from [engine] in config.toml. light_model runs the replies to one comment, which only say whether a maintainer's comment waits for the reporter or whether a problem persists after a release, on a cheaper model; max_turns (40) bounds a first analysis and a maintainer's question, a follow-up gets half of it and a reply a tenth, where every task had 40 turns before; max_budget_usd ($1.00) stops a run at that cost, so that no issue can make one run cost more; and effort sets how much a model thinks. check refuses values that the engine can't run with. The summary of every analysis job shows in one line, numbers only, what the run cost: its turns, time, dollars and tokens, also after a failure, with a warning that names the setting when the run stopped at its turns or its dollars. Install the workflows again to get it.

Changed

  • The rules of the assistant are the engine's system prompt, apart from its task, instead of the start of one prompt in which the issue's own words competed with them. context writes them into .issue-assistant/rules.md, and its output prompt keeps both for the workflows of earlier releases until you install them again.
  • Every analysis and follow-up says what it is and asks whether it helped. Its footer links How the assistant works, the part What happens with your issue of your SUPPORT.md, or of the first file of [transparency] files, and asks for a 👍 or 👎 on the comment; the summary of the morning sweep, or of one started by hand, counts them for the analyses and follow-ups of the last 30 days, as numbers only. On a duplicate notice, the footer says that a 👎 also keeps the issue open, as before.
  • A long analysis keeps its questions in view: more than three links to related issues and files fold into one line below the questions, such as Where to look: 5 links, that opens them. A reminder links the comment with the questions that it reminds of.
  • The comments speak of the maintainers, not of one maintainer, and the information needed says that an answer reopens the issue if it closes, not while it is still open.
  • An analysis reads a window of the repository instead of every issue and pull request: every open issue, the 1,000 closed issues and the 1,000 discussions that changed last, and for a new issue up to 30 older issues that a search for its errors and the words of its title finds, so that old duplicates are still found. In a repository with tens of thousands of issues, the context stays small and takes a few calls to GitHub instead of hundreds. [context] max_issues and max_discussions in config.toml set the numbers. Each other issue comes with an excerpt of 400 characters, the pull request that fixed it, and its whole text for the AI to read when the excerpt looks promising.
  • Deciding whether a maintainer's comment waits for the reporter, or whether the reporter's comment after a release says the problem persists, reads only the issue and that comment, no longer every issue and discussion of the repository.

Fixed

  • A link to a line of a Markdown file, or of another file that GitHub shows rendered, such as reStructuredText, AsciiDoc, a notebook or an SVG picture, opens the file's source at that line. Before, it opened the rendered page, where a line has no anchor. A path with a backtick stays one piece of code in its link.
  • Issues and discussions that the AI names as #123 stay links when they exist, up to ten of them, as the prompt asks it to name them. Before, every number but those of the duplicates and related issues showed as code.
  • An issue that waits for its reporter closes on the day that its reminder names. The morning sweep starts a few minutes later on some days than on others, and when it started later on the day of the reminder than on the day it named, the issue closed a day late. The waiting now counts days of the calendar, in UTC, and the reminder records its day.
  • An answer by an edit of the issue, which the questions offer, ends the waiting also when the event workflow missed it, so the issue no longer closes as unanswered, and a run again of the analysis no longer marks it needs-info. A second edit after a follow-up gets its own follow-up, as a second comment does.
  • A new title is no answer. Fixing a typo in it removed needs-info, stopped the reminder and started a follow-up of the AI with nothing new to read.
  • A comment of the reporter reopens an issue that closed for a missing answer also when an answer came in while the sweep closed it and took its labels. An issue that closed in another way since its last reopening stays closed.
  • No follow-up is posted once a maintainer joined the conversation while the AI wrote it.
  • A comment that someone else writes while the AI reads the reporter's comment after a release, such as "still broken for me too", no longer reopens an issue whose reporter just confirmed the fix: the AI judges the comment that started its run, not the newest one, and the issue reopens only for a comment of its reporter. In the same way, only the maintainer's comment that started the run can mark an issue as waiting for its reporter.

1.4.0 (2026-10-14)

Added

  • Try the assistant on an issue that exists nowhere: name a JSON file with the issue and its comments, as GitHub's REST API gives them, in the environment variable ISSUE_ASSISTANT_FIXTURE, and context and apply read that issue instead of one on GitHub and write nothing, as in a dry run. The project's own Canary analyzes such an issue every week with the engine, on the firewall runner, so that an update of the engine's action, a host that the firewall blocks or an expired secret shows before a release instead of as issues without an answer.

Fixed

  • A fix that the morning sweep finds at the very end of the 14 days that it looks back closes its issue with the release that shipped it, as every other fix does. Before, the sweep labeled the issue but no longer counted the fix by the time of the label, so the issue waited for the next release, and its comment didn't name the fix. The sweep also no longer reads the issues that a recent merge names and that are closed already, most of them, so a busy repository spends far fewer of the 1,000 requests an hour that its token has, which its other workflows need too.

Security

  • A table in the AI's text can no longer cut its code in two. GitHub splits every row of a table at each |, also inside code, so code such as `x|#1 https://example.com` in a row turned into text that referenced an issue and linked to another site, also in a table of one column, in a quote or in a list item. A line such as --|-- or :-:, which starts a table below its header, now shows as text, so the AI's text holds no table; the AI is asked not to write tables. A code block that closes with a shorter fence than it opens with, such as ~~~~~~ and ~~~, now counts as text too: GitHub's block ran on past it, into the next part of the comment, until the fence of the next code block closed it, and showed that code as text. A checked issue number right after an @, as in #0@GH-7, becomes code: once #0 was code, GitHub read @GH-7 as a mention of the user GH-7. A lone www., which GitHub links to the host www, becomes code. A link whose target holds a (, or entities that spell .., such as .., no longer stays a link: GitHub's target runs on past the ) that closes a (, and reads the entities, so either could lead out of the repository. New tests found all of these: they judge whole comments by a model of GitHub's rendering of their own, and fuzz them.

1.3.1 (2026-10-13)

Fixed

  • A fixed issue that waited for an answer gets fixed-in-next-release again also when GitHub fails to list the releases while the morning sweep sees the merge. Since 1.3.0 the sweep asked first whether a release already ships the fix, so such a failure kept needs-info or stale on the issue, and the same sweep could remind its reporter or close it as unanswered. Now the labels come first, and the release closes the issue as before.

1.3.0 (2026-10-13)

Changed

  • The action is ready for the GitHub Marketplace, as Read-only issue assistant, because another action there is already called Issue Assistant, and with a purple badge. Workflows keep using Dennis-Otto/issue-assistant as before. The README opens with what the assistant does, why an issue can't make its AI write, and three commands that install the latest release; the action, the repository and the website describe it as AI issue triage, and the repository has the topics that people browse, such as triage, claude-code and prompt-injection.
  • The website loads only the pictures that it shows: the copy for the other theme is no longer downloaded, so the home page needs about half the data, 650 KB instead of 1.25 MB on a phone. The still pictures are lossless WebP instead of PNG, at less than a third of the size, and keep their place on the page while they load.
  • On a phone, the animation of the life of an issue stands upright, with text that is readable, on GitHub and on the website. Readers who asked their system for less motion see a still picture of the first analysis instead. Diagrams on the website scroll sideways on a phone instead of shrinking their text to a few pixels.
  • The four workflows changed; run install again. Repositories of the repository blueprint get them with its next update. The Findings workflow also starts after the scans of Workflow security and OSV-Scanner on main, so their new findings are accepted or reported at once, not the next morning. The jobs without the AI run on ubuntu-24.04 instead of ubuntu-latest, the version of the AI's firewall runner, so a new image of Ubuntu never reaches your repository untested. actionlint 1.7.12 doesn't know the queue of a concurrency group yet: if your repository runs it, let it ignore that message for issue-assistant.yml, as step 9 of the set-up shows.

Security

  • Strangers can no longer run up the bill of the AI. Every new issue started a paid analysis, every answer of a reporter a follow-up, and every comment of a reporter in the 30 days after a release closed their issue another decision, without any limit and also all at once, so that a flood of issues could cost money or use up a subscription that other repositories share. Now the runs that people who don't maintain the repository start have limits, under [engine] in config.toml: 20 analyses of new issues, follow-ups and replies after a release in the 24 hours before (max_per_day), 3 analyses of the new issues of one reporter (max_per_author_per_day), and 2 comments of the reporter after each release (release_replies). Every new issue counts, also while the first analyses still run, so a flood at once starts no more; a follow-up or a reply after a release counts as it starts, and deleting comments gives a reporter no more of them. Over a limit, an issue keeps its labels and needs-triage for the maintainer, and the run notes which limit it reached; maintainers and runs by hand are never limited. Without the settings, the defaults apply, so no repository needs to change anything; check refuses a limit that isn't a whole number of 0 or more.
  • The jobs of the workflows that write, event, apply, sweep, sync-labels and findings, reach only GitHub: Harden-Runner blocks every host but api.github.com and github.com, and no step can use sudo or containers to lift the block. A compromised action or tool in a job with a write token can no longer send it anywhere else. The block holds in public repositories, and in private ones with a subscription or trial of StepSecurity, the maker of Harden-Runner; without one, the jobs run as before. StepSecurity receives the repository, run and job of each of these jobs and the hosts that its steps connect to. The action turns off the telemetry of the GitHub CLI, which would only knock at a blocked host.
  • One issue can no longer stall the AI analysis of a whole repository. Each analysis reads the text of every issue, and some crafted texts, such as a form heading ### followed by many blanks, or many <!-- or <a without an end, kept the reading busy for hours, so every later analysis ran until its job timed out. The answers of issue forms, HTML comments and tags are now read in time that grows only with the length of a text, at most GitHub's 65,536 characters. The AI reads at most 20,000 characters of each text of its issue, marked "(shortened)" after that, and a line that starts with a <!-- without its end hides the rest of a text from it, as GitHub hides it from people. A new fuzz target, fuzz/fuzz_issue_text.py, fails when reading a crafted text takes longer than half a second.
  • What the AI writes can no longer act outside its comments. An issue that steered it could put a workflow command, such as ::add-mask:: or a forged ::warning::, into the log of the run, end the code block of a dry run's preview in the job summary, and mention people or link elsewhere in the reasons for labels and duplicates that GitHub shows on the timeline. Now every error and notice of the assistant is escaped, the summary turns workflow commands off while it prints the AI's words, a preview's code block is longer than any run of backticks in the comment, and every reason is put on one line, cleaned like a comment and kept to 280 characters. A possible security report gets the fixed reason "Possible security report; see the security policy." on the timeline, and the AI is asked to keep its summary, analysis and reason to one neutral sentence without details, because the log of the run can be public.
  • A label name with an apostrophe, such as area: user's guide, no longer breaks the command line of the engine, which stopped every analysis of the repository. check and the engine step refuse a model in config.toml that isn't a model name, so that it can't add arguments either.
  • A comment of the assistant can no longer mention someone, link to another repository or site, or show an image in ways that slipped past the cleaning of the AI's text. Code that the AI writes stays code wherever the comment puts it: a next step or a question that starts with a code block keeps all its lines in its list item, the reasons of duplicates, related issues and references are written on one line, and neither a control character nor a removed tag or heading mark can move the fence of a code block, so a snippet with @dataclass mentions nobody, also in a list. A removal can no longer join the text next to it into a reference such as foo/bar#12 or an image. E-mail addresses, mailto: and xmpp: addresses and commits of other repositories or forks, such as octocat/Hello-World@7fd1a60, become code, and so do HTTPS://, _https:// and _www. addresses to other sites. An allowed address stays a link only where GitHub links all of it and nothing more, since its link runs on to the next space, even into code. A link that leaves the repository through .. or %2e, or that names a user, a password or a port, is no longer allowed. A code block counts only when its fence starts a line, so one that the AI indents under a step of a list now shows as plain text; the AI is asked not to indent them.
  • An issue or a comment can no longer pass for the maintainer, for another comment or for the assistant's earlier answer. The AI read each text under a heading that names its author and role, and a text could write such a heading itself, such as ## Comment 4 by @owner (maintainer). Now each text stands in a code fence that nothing in it can close, only the assistant writes the headings, and the AI is told that a fence holds only that person's text, whatever it looks like.
  • Instructions hidden in characters that GitHub shows as nothing, such as Unicode tags, zero-width spaces and the controls of the direction of writing, no longer reach the AI, neither from the issue nor from the other issues and discussions that every analysis reads. The AI's answer loses them too, before its checks, so they can't hide a token from the check either. A notice in the log of the run counts what was removed.
  • An issue can no longer close another reporter's issue as its duplicate. Every analysis reads the text of every issue, so anyone could open one that told the AI to call later issues its sure duplicates, which then closed after three days. Now only an original that a maintainer opened or triaged, so that it no longer has needs-triage, gets the notice that closes the duplicate; any other becomes a suggestion for the maintainer, as a less sure duplicate does. A thumbs down on the notice keeps the issue open when it comes from the reporter or from anyone who may push to the repository, also the maintainers of an organization's repository; before, only the owner of the repository counted besides the reporter, which for an organization is nobody.

Fixed

  • A fixed issue closes with the release that shipped its fix, also when the morning sweep labeled it fixed-in-next-release only after that release, as when the run of the merge failed; before, it waited for the release after and named that one. An issue whose fix a release ships already when the sweep first sees the merge closes at once. A pull request of another repository that names the issue, such as Fixes owner/project#12, no longer keeps it open or appears in the comment of the release, and in a busy repository the sweep reads every pull request merged in the last 14 days instead of the latest 30.
  • check and install name the files of a repository with slashes on Windows too, such as .github/labels.toml instead of .github\labels.toml.
  • check and engine no longer need GH_REPO, so the check runs on your computer as well. A command that calls GitHub and finds no repository, or one that isn't written as owner/name, stops with one clear error instead of a Python traceback.
  • Every set-up that GitHub takes works with the assistant. The labels of an issue form written as one text separated by commas, such as labels: bug, needs-triage, no longer fail check with an error for every letter. A label with a slash, such as kind/bug, is removed and updated instead of stopping the run. A label that the repository has in another case, such as Bug for bug, is renamed instead of failing to be created, since GitHub ignores the case of label names. An area dropdown with multiple: true adds the label of every option that the reporter chose; before, it added none.
  • Mistakes in the settings are named instead of crashing every command or passing unnoticed. A labels.toml or config.toml that isn't TOML, a section written as a key, such as engine = "claude", or a value of the wrong type, such as max_per_day = "5", stops with an error that names the file and the key, and check lists every such problem at once. A key that the assistant doesn't know, such as close_with_releases or a section [release], kept its default unnoticed; now check fails on it and names the key that was probably meant, and every other run warns of it. check also fails on labels that differ only in case or have more than 50 characters, and on a project.md that still holds the starter's first line, which the AI read before every task. So check may fail after the update where it passed before: fix what it names.
  • An accepted finding with the path tests no longer dismisses the alerts in testsuite/ too: a path covers its file, or the files of its folder. A key of findings.toml that the assistant doesn't know, such as paths, stops the findings command instead of accepting the findings of the rule in every file.
  • An analysis that links to a submodule or to a symbolic link that leads nowhere no longer fails; the link is left out. A link to a file with a blank or a bracket in its path, such as docs/user guide (old).md, now leads to the file.
  • A change of the templates can be released again. The workflows and the firewall policy that install writes now live in templates/, apart from this repository's own copies, which the repository blueprint brings; before, a pull request that changed a template failed the required check of the set-up. install writes exactly what it wrote before, so no repository needs to install again.
  • No comment is lost while the assistant works on an issue. The runs of one issue now wait in line, up to 100, first in, first out; before, a second comment during an analysis cancelled the run of the first one, so an answer of the reporter could stay without a follow-up and a "still broken" after a release could leave the issue closed.
  • The lifecycle no longer sweeps after every scheduled run of the release workflow, which runs every hour as a safety net and mostly releases nothing; the morning sweep catches a release that such a run made. A run of the lifecycle or the findings whose job has nothing to do takes no runner, and no longer cancels a waiting run that has work to do.
  • An analysis that links to an issue, a release or a line on GitHub, or names a path or a class such as src/main/java/com/example/OAuth2ClientConfiguration.java, is posted again; before, the whole answer was refused as if it held a token, and the run failed. A long run of letters and digits now counts as a key only when it has the + or = of Base64 or its letters read like noise, and never when it is the owner, repository or commit of a link to GitHub or a part of the path of a file that git tracks. Words such as task-runner-… no longer pass for a key that starts with sk-. Known kinds of tokens still refuse an answer wherever they are, and so do the addresses of Slack and Microsoft Teams webhooks now. The security page of the website shows what counts as a secret.
  • A rate limit or a failure of GitHub no longer changes what the assistant posts. Before, it read such an error as "doesn't exist": an analysis left out the duplicates and related issues that it couldn't look up, the AI read that the project had no release yet, and the discussions were missing from what it read. Now only "not found" means missing, and any other error stops the run with one clear error instead of a Python traceback; its summary lists what the run wrote before and the write that failed. A read that GitHub fails for a moment runs again after 2, 4 and 8 seconds, and a call that a secondary rate limit refused after a minute.
  • Running a failed job of the issue assistant again completes it. An analysis or a follow-up now adds its labels before its comment, and needs-info right after it, so that an issue never waits for an answer to a question that wasn't posted; before, a failure after the comment lost needs-info, possible-duplicate and the area labels for good, because a run again found the comment and did nothing, so the reporter was never reminded and a duplicate that the comment announced never closed. A run again now adds the labels that such a comment is missing, without a second comment, and leaves the labels that someone changed since then as they are.
  • One issue that GitHub fails no longer stops the daily sweep for every issue after it. Each issue and each step runs on its own: a failure is a warning, the others are done, and the run fails at the end so that GitHub tells you. The next sweep completes it without posting a reminder, a closing or a release comment twice, and an issue fixed by a merged pull request always gets its fixed-in-next-release label and stops waiting for an answer, even when its notice fails.

1.2.2

Security

  • Coverage-guided fuzzing with Atheris now checks the cleaning of the AI's text, in a new Fuzzing workflow. It found a link without a target, images whose target ends in a line break, and a reference followed by an underscore that ends an emphasis. Brackets outside the allowed links are now escaped, so no other link or image can form, and a reference counts whatever follows its number. After the fixes, ten minutes and about 600,000 inputs found nothing.

1.2.1

Fixed

  • The lifecycle also starts when a workflow named Release integration ends, as in ha-autodarts, whose releases are published with the GITHUB_TOKEN and start no workflow themselves.

1.2.0

Added

  • Findings of code scanning. The new Findings workflow and findings command dismiss the alerts of code scanning that .github/findings.toml accepts, each with its reason and comment, and fail while any other alert is open. The run names an open alert only by number and link, so nothing about a possible vulnerability reaches a public log or issue. check validates the file, and install writes the workflow and a starter.
  • Milestones of releases. A fixed issue that a release closes is filed under the milestone of the release, created closed when it is missing, so its page lists what the release fixed.
  • The lifecycle also starts when the repository's Release workflow ends, because a release published with the job's GITHUB_TOKEN starts no workflow.

Security

  • The cleaning of the engine's text now follows the rules of CommonMark for code and catches what property tests with Hypothesis found against a CommonMark parser: backtick runs of different lengths, code spans cut by a fence or a quote on the next line, mentions and references glued to each other or to code, entities such as &#64;, HTML that a removal leaves behind, www. addresses, link definitions, GH- references and addresses glued to other text. A mention or a reference that the AI was steered into writing could otherwise have reached GitHub as a real one.

Fixed

  • An address that Python can't read, such as http://[, no longer stops the posting of an answer.

1.1.0

Added

  • From the fix to the release. A merged pull request that fixes an issue marks it with the new lifecycle label fixed-in-next-release, and the issue stays open. The first published release that contains the fix closes it as completed, with a link to the release. If the reporter writes within 30 days that the problem persists, the AI's new release-reply task decides, and the issue reopens. The lifecycle workflow now also runs on merged pull requests and published releases. Repositories run install again, add the label to .github/labels.toml, and clear Auto-close issues with merged linked pull requests in their settings. Without releases, close_with_release = false in config.toml turns it off.

Fixed

  • install names the firewall policy with forward slashes on Windows too.
  • check says what to install when neither PyYAML nor yq can read the workflows, instead of failing with a traceback.
  • The notice about sensitive data says what the issue shows. A secret, such as a token, a key or a password, gets a warning to remove and replace it; other personal data, such as an e-mail address or the address of a private server, gets a note that leaves the choice to the reporter. Placeholders and variable names no longer count, and a follow-up only looks at the new comments.

1.0.1

Fixed

  • The templates are the three issue workflows with which this repository looks after its own issues, so Dependabot keeps their action pins current. install copies them with the release's commit hash in the pin of the action; check compares with them. Repositories set up with 1.0.0 run install again.
  • actionlint checks every workflow of this repository again.

1.0.0

The issue assistant as its own action, taken from ha-autodarts, for any repository:

  • A first analysis of new issues by an AI that only reads, labels with their reason, duplicates with a notice and a delay, follow-ups on answers, and needs-info for questions of the maintainer.
  • Reminders after 15 days, closing after 30 days and reopening on an answer.
  • Labels as code in .github/labels.toml.
  • The project's own description in .github/issue-assistant/project.md and settings in config.toml: the engine and its model, the hosts links may lead to, the field of the issue forms that chooses an area, and the files that tell reporters which AI reads their issue.
  • install writes the workflows and the firewall policy into a repository, and check keeps them equal to the templates.