Script-creator agent

DevScripts ships these files for AI assistants:

Using them is optional. If you use an AI tool at all, the pull request template asks you to confirm that the scripts were built with AGENTS.md and the agent file as guidance and that you reviewed and corrected the output.

What the agent doesCopy Anchor Link

The agent takes an application name and its repository URL, for example MyApp https://github.com/owner/repo, and works in four steps:

1. Gather information. It reads the upstream repository for the runtime, database, build steps, default port, configuration paths and every value a user has to supply during the install.
2. Check eligibility. For a new script it looks up the real star count and age of the repository and compares them with the application requirements: 1,000+ stars, 6+ months old, actively maintained, official releases. If one is clearly unmet it stops and tells you the numbers instead of generating files.
3. Generate three files in one go: ct/<slug>.sh, install/<slug>-install.sh and json/<slug>.json.
4. Validate the result against its checklist, then summarise what it created and the address the application will be reachable at.

Its output is exactly these three files. Nothing in its workflow installs the script on a host; that part is yours.

Using itCopy Anchor Link

As an agent. The file has the front matter of a GitHub Copilot custom agent (description, tools, argument-hint) and lives where Copilot looks for them, .github/agents/. Open your DevScripts fork in an editor whose Copilot Chat offers custom agents, select pve-script-creator and give it the name and URL:

MyApp https://github.com/owner/repo

Any other assistant. Work inside a checkout of your DevScripts fork so the assistant can read the repository, and tell it to follow both files:

Read AGENTS.md and .github/agents/pve-script-creator.agent.md and follow them exactly.
Create the ct, install and json files for MyApp (https://github.com/owner/repo).
Read the upstream Dockerfile, compose file and .env.example before writing anything.

The last line matters. AGENTS.md has two rules above all others: do not invent a helper call, and do not guess how the application installs. A script written from assumptions is rejected however clean it looks.

What is still your jobCopy Anchor Link

An assistant produces a draft. Before you open the pull request:

1. Run it. Install from your branch on a real host, open the application, run update in the container. Testing from a fork has the commands. A generated script has not been run until you run it.
2. Check var_arm64. An assistant can only look at the release assets. yes is correct once the script has actually run on arm64.
3. Check the helper calls. Every setup_* and fetch_and_deploy_* call in the draft must exist in core with those arguments. Helper functions lists them.
4. Check persistence. Where does the application keep user data, and does update_script leave it alone?
5. Go through the review checklist.

Disclosing itCopy Anchor Link

The "AI Assistance" section of the pull request template has two boxes, and exactly one must be ticked:

• No AI used
• AI was used, which also confirms that AGENTS.md and the agent file were the guidance and the output was reviewed

Below the boxes, name the model and, if it applies, the reasoning level and what it was used for, for example "Claude Sonnet 4.5, high reasoning, used to draft the install script, then manually reviewed and tested". The DevScripts check flags a pull request where neither "No AI used" is ticked nor this sentence is written.

The disclosure is informational. What gets a pull request closed without review is a script that is clearly generated and was not revised to match the coding rules, disclosed or not.

Pull request text and review repliesCopy Anchor Link

The agent file ends with rules for the part after the code, and they apply to people as well:

• The description is two to five sentences: what the application is, what deviates from the standard pattern, how it was tested, and the model. No extra headings, tables or decision lists.
• Apply a review suggestion exactly as written, then resolve its thread. Do not regenerate the file to answer a review.
• Replies to review comments are one or two sentences.