Add @openagt/init: one command gives a project its skills

.agents/skills/browser/SKILL.md

@@ -1,6 +1,8 @@
 ---
 name: browser
 description: A real browser you drive from the shell, to see or act on a web page (open it, read it, click, type, take a screenshot), such as checking that the app you changed works.
+metadata:
+  version: 0.1.0
 ---
 
 # The browser

.agents/skills/discord/SKILL.md

@@ -1,6 +1,8 @@
 ---
 name: discord
 description: Post a message to the team's Discord channel from the shell, when a task asks you to tell people something there.
+metadata:
+  version: 0.1.0
 ---
 
 # Discord

.agents/skills/maintainability/SKILL.md

@@ -2,6 +2,8 @@
 name: maintainability
 description: Refactor a part of the code to make it as maintainable as possible.
 disable-model-invocation: true
+metadata:
+  version: 0.1.0
 ---
 
 Refactor a part of the project to make it as maintainable as possible. Nobody will answer you: never ask, decide yourself. The part is what follows the command: a folder, a file, or a feature in words; when nothing follows it, it is the whole project. Look for maintainability red flags in it, and fix them. Commit each change on your branch. Then publish the work as far as whoever started you said; when they said nothing, publish nothing. A pull request's body lists each red flag you found and how you fixed it. If you find nothing worth fixing, say so and stop, publishing nothing.

.agents/skills/maintenance/SKILL.md

@@ -2,6 +2,8 @@
 name: maintenance
 description: Find the parts of the code that need refactoring and put their maintainability and security work on the agent queue. Queues only.
 disable-model-invocation: true
+metadata:
+  version: 0.1.0
 ---
 
 Find what needs refactoring, and queue the work. Nobody will answer you: never ask, decide yourself. The part is what follows the command: a folder, a file, or a feature in words; when nothing follows it, it is the whole project. Analyze it, and look for the subsets of the code that need refactoring: a folder, a module, a feature, each one that makes sense to work on alone. For each subset that needs it, put two entries on the agent queue, usually at a low priority, each naming the subset clearly so that an agent who reads only the entry knows what to work on: one asking to refactor that subset to make it as maintainable as possible, finding its maintainability red flags and fixing them; one asking for an exhaustive security audit of that subset, listing every aspect considered with a verdict, each security issue found fixed in its own commit. Skip a subset whose work is already on the queue. You only queue work, you never do it: the only thing you change is the queue. A write to the queue that is rejected because someone else wrote first is tried once more, after reading again. If nothing needs refactoring, say so and stop. If this project has no AI queue, show an error to the user and stop.

.agents/skills/market-research/SKILL.md

@@ -2,6 +2,8 @@
 name: market-research
 description: Research the market of the project's product, and write a ticket for each opportunity no ticket covers yet.
 disable-model-invocation: true
+metadata:
+  version: 0.1.0
 ---
 
 Make a thorough market research for this project's product. Nobody will answer you: never ask, decide yourself. First learn what the product does today: its README, its documentation, its main user-facing surfaces, and every open ticket. Then research its market: who else solves the same problem, how, for whom and at what price; what the users of such products ask for; where this product stands out and where it falls short. Give a source for every fact that does not come from the project itself. Then write a new ticket, in the project's ticket format, for each opportunity the research shows that is not already built and that no open ticket covers. You change nothing else. Your last message is the written result: the research, then the tickets you wrote, one line each. If this project has no ticketing system, show an error to the user and stop.

.agents/skills/orchestration/SKILL.md

@@ -1,6 +1,8 @@
 ---
 name: orchestration
 description: "Split your task across subagents: plan it, get the person's yes, start other agents on the parts, each in its own checkout on a branch started from yours, and land their work on your branch."
+metadata:
+  version: 0.1.0
 ---
 
 # Orchestration

.agents/skills/plan-tickets/SKILL.md

@@ -7,6 +7,8 @@ schedule:
   waits-for: when a ticket that is not waiting, claimed, in review or queued has no plan, or an outdated one
   when: |-
     npx @openagt/skill-tickets@0.1 list | jq --argjson q "$(npx @openagt/skill-queue@0.1)" '[.[] | select(((.planned | not) or .outdated) and .pr == null and (.waiting | not) and (.locked | not) and ((.file | rtrimstr(".md")) as $s | $q | any(contains($s)) | not)) | .file]'
+metadata:
+  version: 0.1.0
 ---
 
 Queue plans for the tickets that need one. Nobody will answer you: never ask, decide yourself. You only queue work, you never do it: write no plan yourself, the only thing you change is the queue.

.agents/skills/plan/SKILL.md

@@ -2,6 +2,8 @@
 name: plan
 description: Write a ticket for the task typed after the command and, under it, a plan naming the ways to do it and the one to take. Changes nothing else.
 disable-model-invocation: true
+metadata:
+  version: 0.1.0
 ---
 
 Plan the task that follows the command, and stop there. Nobody will answer you: never ask, decide yourself; a question you would have asked is an option in the plan. When nothing follows the command, say so and stop. Read the open tickets first: when one already covers the task, plan under it instead of writing a second. Otherwise write one ticket for the task. Under the ticket write its plan: the ways you see to do the work and the one you recommend, with why. You only write the ticket and its plan: you queue nothing, and you change no code. Your last message names the ticket and the way you recommend: a person reads it, and queues the ticket once the plan is right. If this project has no ticketing system, show an error to the user and stop.

.agents/skills/post-merge-cleanup/SKILL.md

@@ -7,6 +7,8 @@ schedule:
   waits-for: when a pull request merged since the last clean-up has no clean-up yet
   when: |-
     gh pr list --state merged --limit 50 --json number,body --search "merged:>=$(npx @openagt/skill-logs@0.1 --limit 200 | jq -r '[.[] | select(.intent == "/post-merge-cleanup" and .status == "done")][0].startedAt // (now - 86400 | todate)')" | jq '[.[] | select(.body | contains("Post-merge cleanup done.") | not) | .number]'
+metadata:
+  version: 0.1.0
 ---
 
 Write what merged work decided and taught into the project's knowledge files. Nobody will answer you: never ask, decide yourself.

.agents/skills/queue/SKILL.md

@@ -1,6 +1,8 @@
 ---
 name: queue
 description: Where the project's agent queue lives, how to read it and change it, and its format.
+metadata:
+  version: 0.1.0
 ---
 
 # The agent queue

.agents/skills/readability/SKILL.md

@@ -2,6 +2,8 @@
 name: readability
 description: Refactor a part of the code to make it as easy as possible for humans to read, rating every file and function before and after.
 disable-model-invocation: true
+metadata:
+  version: 0.1.0
 ---
 
 Refactor a part of the project to make it as easy as possible for humans to read. Nobody will answer you: never ask, decide yourself. The part is what follows the command: a folder, a file, or a feature in words; when nothing follows it, it is the whole project. Below, a function means any unit of logic: a function, a class, a procedure.

.agents/skills/research/SKILL.md

@@ -2,6 +2,8 @@
 name: research
 description: Rate how obviously well a part of the code solves each problem it solves, and name the problems worth researching alternatives for. Changes nothing.
 disable-model-invocation: true
+metadata:
+  version: 0.1.0
 ---
 
 Measure the problem variability of a part of the project. Nobody will answer you: never ask, decide yourself. The part is what follows the command: a folder, a file, or a feature in words; when nothing follows it, it is the whole project. List every high-level flow the part implements, that is every problem it solves. Rate each problem from 0 to 10 by one criterion: 10 when the code solves it in an obviously optimal way, 0 when it is highly unclear whether it could be solved in a better way. Give the reason for each rating. You change nothing: no file, no commit, no ticket, no queue entry. Your last message is the written result: every problem with its rating and its reason, lowest rating first; then the problems worth a deep-dive into alternative solutions, the low-rated ones, each with what that deep-dive should look at. A person reads it and decides what comes next.

.agents/skills/security-audit/SKILL.md

@@ -2,6 +2,8 @@
 name: security-audit
 description: Audit a part of the code for security issues, exhaustively, fixing each issue found.
 disable-model-invocation: true
+metadata:
+  version: 0.1.0
 ---
 
 Audit a part of the project for security. Nobody will answer you: never ask, decide yourself. The part is what follows the command: a folder, a file, or a feature in words; when nothing follows it, it is the whole project. Scrutinize all of its code for potential security issues, and make it exhaustive: every file of the part. List every aspect you considered, and give each a verdict, with an explanation when the verdict is not obvious. Fix each security issue you find in its own commit on your branch. Then publish the work as far as whoever started you said; when they said nothing, publish nothing. A pull request's body is the list of aspects with their verdicts. Your last message is the same list. If you find no issue, your last message is the list and you stop, publishing nothing.

.agents/skills/suggest-new-features/SKILL.md

@@ -2,6 +2,8 @@
 name: suggest-new-features
 description: Think like a product manager and write a ticket for each net-new feature the product should have next.
 disable-model-invocation: true
+metadata:
+  version: 0.1.0
 ---
 
 Suggest new features. Nobody will answer you: never ask, decide yourself. Study what this product does today: its README, its documentation, its main user-facing surfaces, and every open ticket. Think like a product manager and propose the net-new features the product should have next: capabilities a user would want, not bugs, refactors or chores. Skip anything an open ticket already covers, and anything already built. Favour features that fit the product's direction and are worth building. Write each proposed feature as a new ticket in the project's ticket format. You change nothing else. Your last message is a short summary of what you proposed, one line per ticket. If nothing is worth proposing, say so and stop. If this project has no ticketing system, show an error to the user and stop.

.agents/skills/suggest-new-tickets/SKILL.md

@@ -2,6 +2,8 @@
 name: suggest-new-tickets
 description: Suggest new tickets for the project, and write each one in the project's ticket format.
 disable-model-invocation: true
+metadata:
+  version: 0.1.0
 ---
 
 Suggest new tickets. Nobody will answer you: never ask, decide yourself. Read the project, its README, its documentation and its code, and every open ticket. Think of the work the project should do next: bugs, missing pieces, cleanups worth their cost, features. Skip anything an open ticket already covers. Write each suggestion as a new ticket in the project's ticket format. You change nothing else. Your last message lists the tickets you wrote, one line each. If nothing is worth suggesting, say so and stop. If this project has no ticketing system, show an error to the user and stop.

.agents/skills/suggest-tickets-to-work-on/SKILL.md

@@ -2,6 +2,8 @@
 name: suggest-tickets-to-work-on
 description: Pick and rank the tickets worth working on next, each with the priority it should get on the agent queue. Changes nothing.
 disable-model-invocation: true
+metadata:
+  version: 0.1.0
 ---
 
 Suggest which tickets to work on next. Nobody will answer you: never ask, decide yourself. Read every open ticket, with its plan when it has one. Pick the tickets worth working on next and rank them, by a mix of sensible criteria: what the work is worth, its effort and its uncertainty, what it unblocks. Skip a ticket already on the agent queue, one held by someone, and one in review, the one with a pull request named on it. You change nothing: you queue nothing and write no ticket. Your last message is the written result: the picked tickets in rank order, each with its file, its title, the priority it should get on the agent queue (the ticket's own priority, 5 when it has none), one line saying why, and whether you are confident it should go next or only think so. A person reads it and queues the ones they approve. If nothing is worth picking, say so and stop. If this project has no ticketing system, show an error to the user and stop.

.agents/skills/tickets/SKILL.md

@@ -1,6 +1,8 @@
 ---
 name: tickets
 description: Where the project's tickets live, how to read and change them, how to claim a ticket so no two agents work the same one, how to queue one, and the formats.
+metadata:
+  version: 0.1.0
 ---
 
 # Tickets

.agents/skills/triage/SKILL.md

@@ -13,6 +13,8 @@ schedule:
     waits-for: when a planned ticket is consensual work and is not waiting, claimed, in review or queued
     when: |-
       npx @openagt/skill-tickets@0.1 list | jq --argjson q "$(npx @openagt/skill-queue@0.1)" '[.[] | select(.planned and .pr == null and (.waiting | not) and (.locked | not) and (.outdated | not) and .effort != null and .uncertainty != null and .uncertainty <= 3 and (.effort > 2 or .uncertainty > 2) and (.file as $f | $q | any(contains($f)) | not)) | .file]'
+metadata:
+  version: 0.1.0
 ---
 
 Choose work for the agent queue. Nobody will answer you: never ask, decide yourself. You only queue work, you never do it: the only thing you change is the queue. The word after the command is the mode: `quick`, `consensual`, or nothing for both.

.agents/skills/update-tickets/SKILL.md

@@ -7,6 +7,8 @@ schedule:
   waits-for: when an issue changed or a pull request that closes a ticket merged since the last import, or nothing was imported yet
   when: |-
     { gh issue list --state all --limit 1 --json number --search "updated:>=$(npx @openagt/skill-tickets@0.1 meta | jq -r .lastImportedAt)"; gh pr list --state merged --limit 100 --json number,body --search "merged:>=$(npx @openagt/skill-tickets@0.1 meta | jq -r .lastImportedAt)" | jq '[.[] | select(.body | test("(?m)^Closes tickets/\\w")) | {number}]'; npx @openagt/skill-tickets@0.1 meta | jq --argjson t "$(npx @openagt/skill-tickets@0.1 list)" '[select(.lastImportedAt == null and ($t | length) == 0) | "first import"]'; } | jq -s add
+metadata:
+  version: 0.1.0
 ---
 
 Bring the tickets up to date with the project's issue tracker and its merged pull requests. Nobody will answer you: never ask, decide yourself.

.agents/skills/ux/SKILL.md

@@ -2,6 +2,8 @@
 name: ux
 description: Review every UI flow of a part of the product, rate its user experience, and improve the badly rated flows.
 disable-model-invocation: true
+metadata:
+  version: 0.1.0
 ---
 
 Review the UI flows of a part of the project. Nobody will answer you: never ask, decide yourself. The part is what follows the command: a folder, a file, or a feature in words; when nothing follows it, it is the whole project. Before changing anything, list every UI flow of the part in your messages; skip none. Rate each flow's user experience from 0 (unusable) to 10 (perfect), with the reason for the rating. Then improve the flows with a bad rating, one commit per flow you improve. Mostly 10s means you were lazy: scrutinize every detail and take the time it takes; work until the result is exceptionally good, without anyone pushing you. Commit each change on your branch. Then publish the work as far as whoever started you said; when they said nothing, publish nothing. A pull request's body is your summary, and so is your last message: the list of flows again, each with its old rating, its new rating, and the commits that changed it. If no flow needs improving, say so with the ratings and stop, publishing nothing.

.agents/skills/work-queue/SKILL.md

@@ -6,6 +6,8 @@ schedule:
   waits-for: when the queue holds a task nobody has claimed
   when: |-
     npx @openagt/skill-queue@0.1 | jq --argjson t "$(npx @openagt/skill-tickets@0.1 list)" '[.[] | . as $e | select($t | any(.[]; .locked and ((.file | rtrimstr(".md")) as $s | $e | contains($s))) | not)]'
+metadata:
+  version: 0.1.0
 ---
 
 Work one task off the project's agent queue. Nobody will answer you: never ask, decide yourself.

packages/agent-data/package.json

@@ -1,7 +1,7 @@
 {
   "name": "@openagt/agent-data",
   "version": "0.0.2",
-  "description": "A branch of the project's repository used as a file store for coding-agent skills. Checked out under .branches/; every write is one sync-commit-push cycle that re-applies when it loses a race, from a long-lived process or one-shot from any clone.",
+  "description": "What OpenAgent's packages share about a project: making a folder a project, and a branch of the project's repository used as a file store for coding-agent skills. Checked out under .branches/; every write is one sync-commit-push cycle that re-applies when it loses a race, from a long-lived process or one-shot from any clone.",
   "license": "MIT",
   "repository": {
     "type": "git",

packages/agent-data/src/hook-lines.test.ts

@@ -0,0 +1,27 @@
+import { strict as assert } from 'node:assert'
+import { test } from 'node:test'
+import { lineRuns } from './hook-lines.js'
+
+const TOOL = { name: '@openagt/agent-scheduler', commands: ['agent-scheduler'] }
+
+test('a line runs a tool by its bare command, by a path, or by its package\'s name with or without a version', () => {
+  for (const line of [
+    'agent-scheduler start',
+    'npx agent-scheduler start',
+    'npx @openagt/agent-scheduler start',
+    'npx @openagt/agent-scheduler@0.1 start',
+    'npx @openagt/agent-scheduler@^0.1.2 start',
+    'FOO=1 agent-scheduler start',
+    './node_modules/.bin/agent-scheduler start',
+    'node /opt/tools/bin/agent-scheduler start --foreground',
+    'cd sub&&agent-scheduler start',
+    '"agent-scheduler" stop --unless-keep-alive',
+    'echo `agent-scheduler status`',
+  ])
+    assert.equal(lineRuns(line, TOOL), true, line)
+})
+
+test('a name inside another word, and a line that names nothing of the tool, do not run it', () => {
+  for (const line of ['npx my-agent-scheduler-wrapper start', 'echo agent-scheduler-is-not-here', 'agent-runner run --detach "$PROMPT"', 'npx @other/agent-scheduler-plus start', ''])
+    assert.equal(lineRuns(line, TOOL), false, line)
+})

packages/agent-data/src/hook-lines.ts

@@ -0,0 +1,12 @@
+/**
+ * Whether a shell line runs a tool: one of the tool's commands, bare or by a path, or its
+ * package's name, with or without a version, stands in the line as a word of its own. How a
+ * project's hook lines are read for "does this project run the scheduler": by the dashboard, to
+ * give the project the tool's page, and by the tool itself, to write no second line beside one
+ * that already runs it and to take its own lines back. A name inside another word is not it.
+ */
+export function lineRuns(line: string, tool: { name: string; commands: readonly string[] }): boolean {
+  return line
+    .split(/[\s"'`=;|&()<>]+/)
+    .some(word => word.replace(/@[\w.^~<>=*-]+$/, '') === tool.name || tool.commands.includes(word.slice(word.lastIndexOf('/') + 1)))
+}

packages/agent-data/src/index.ts

@@ -1,4 +1,7 @@
-export { BRANCHES_DIR, DATA_BRANCH } from './names.js'
+export { BRANCHES_DIR, DATA_BRANCH, OPENAGENT_DIR } from './names.js'
+export { installProject, nodeInstallFs, FIRST_COMMIT_MESSAGE, type InstallResult, type InstallDeps, type InstallFs } from './install.js'
+export { gitignorePath, openagentGitignore } from './openagent-gitignore.js'
+export { lineRuns } from './hook-lines.js'
 export {
   type GitRunner,
   GitTimeoutError,