You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
- Convert `/init` from a hardcoded slash command into a built-in agent skill.
- Allow `/{skill-name}` invocations with no trailing message (send a tiny default message).
- Update project “Initialize” banner to send `/init`.
- Document built-in skill precedence + `/init` override behavior.
Signed-off-by: Thomas Kosiewski <tk@coder.com>
---
<details>
<summary>📋 Implementation Plan</summary>
- Remove `/init` from the hardcoded slash-command registry + ChatInput branching.
- Treat `/init` as a normal **built-in agent skill** (discovered via `agentSkills.list`).
- Allow invoking a skill with **no trailing message** (e.g. `/init`) so it can fully replace “macro” slash commands.
- **Registry**: `/init` is a hardcoded slash command (`initCommandDefinition`) in `src/browser/utils/slashCommands/registry.ts`, parsed as `{ type: "init" }`.
- **UI special-case**: `src/browser/components/ChatInput/index.tsx` intercepts `parsed.type === "init"` and replaces the input text with `src/browser/assets/initMessage.txt` (`?raw`).
- **Project banner**: `src/browser/components/ProjectPage.tsx` restores the same text and auto-sends it; it also flips project-scope agent mode to `exec`.
- **Backend**: no special handling—`/init` ultimately becomes a normal user message containing a large prompt (currently wrapped in `<system>…</system>`).
- `src/browser/components/ChatInput/index.tsx`
- Imports `initMessage` from `@/browser/assets/initMessage.txt?raw`.
- Two `/init` special-cases: `handleSend` checks `parsed?.type === "init"` in both the **creation** path (~line 1402) and **workspace** path (~line 1567).
- Two “skill invocation requires trailing message” toasts:
- **Creation** skill path: toast around ~line 1421.
- **Workspace** skill path: toast around ~line 1496.
- `src/browser/components/ProjectPage.tsx`
- Imports `initMessage` from `@/browser/assets/initMessage.txt?raw` and uses it in the Agents init banner flow.
- `src/browser/utils/slashCommands/registry.ts`
- Defines `initCommandDefinition` and registers it.
- `src/browser/utils/slashCommands/types.ts`
- Includes `{ type: "init" }` in `ParsedCommand` union.
- `src/browser/utils/slashCommands/parser.test.ts`
- Contains tests asserting `/init` parses to `{ type: "init" }`.
**Net LoC estimate (product code only): ~+30–80**
Core idea: make `init` a built-in skill and invoke it like any other skill. To support `/init` with no extra text, we must avoid sending an empty message because `AgentSession.sendMessage` rejects empty messages.
When the user invokes a skill with no trailing message, send a tiny default message (while still displaying the raw command via `muxMetadata.rawCommand`). Example:
- Raw input: `/init`
- Message sent to backend: `Run the "init" skill.`
- `muxMetadata`: `{ type: "agent-skill", rawCommand: "/init", skillName: "init", scope: "built-in" }`
This keeps the system general (no `/init` special casing) and satisfies the backend’s non-empty constraint.
Skill resolution already supports overrides in this order:
1. **Project**: `.mux/skills/<name>/SKILL.md`
2. **Global**: `~/.mux/skills/<name>/SKILL.md`
3. **Built-in**: `src/node/builtinSkills/<name>.md`
So yes—once `init` is shipped as a built-in skill, a user can override it by creating `~/.mux/skills/init/SKILL.md` (and a project can override that via `.mux/skills/init/SKILL.md`).
<details>
<summary>Tradeoff</summary>
This changes `/init` from an editable “template prefill” into an immediate command. If we still want editability later, we can add a separate “insert skill into input” UI affordance, but that’s not required for this cleanup.
</details>
1) **Allow skills to be sent without a message (creation + workspace ChatInput)**
- In `src/browser/components/ChatInput/index.tsx`, update both “unknown slash command → agent skill” paths:
- **Creation path** (~line 1421): remove the “Please add a message after /{skill}” toast + early return.
- **Workspace path** (~line 1496): same.
- If trailing text is empty, send a synthetic default message, e.g.
```ts
const userText = afterPrefix.trimStart() || `Run the "${skillName}" skill.`;
```
- Keep setting `muxMetadata = { type: "agent-skill", rawCommand: messageText, ... }` so the UI shows the original `/skill` (not the synthetic message).
2) **Add built-in skill `init`**
- Create `src/node/builtinSkills/init.md` (frontmatter: `name: init`, description matching current `/init`).
- Move/copy the existing `src/browser/assets/initMessage.txt` content into the skill body (keep as-is initially for minimal behavior change).
- Regenerate bundled skill content (`scripts/gen_builtin_skills.ts` → `builtInSkillContent.generated.ts`).
- Notes / gotchas:
- Frontmatter must start at the very top of the file (`---` as first bytes).
- Keep skill content < 1MB.
3) **Remove `/init` as a hardcoded slash command + UI branch**
- Delete `initCommandDefinition` from `src/browser/utils/slashCommands/registry.ts`.
- Remove `{ type: "init" }` from `src/browser/utils/slashCommands/types.ts`.
- Remove the `parsed.type === "init"` branches in `ChatInput` (both creation + workspace).
- Update/remove `/init` parsing expectations in `src/browser/utils/slashCommands/parser.test.ts`.
- Result: `/init` will be parsed as an unknown command and then resolved via `agentSkills.list` as a skill.
4) **Update the project “Initialize” banner to invoke the skill**
- In `src/browser/components/ProjectPage.tsx`:
- Replace `restoreText(initMessage)` with `restoreText("/init")` (and keep the auto-send behavior).
- Keep the existing “switch project-scope mode to exec” behavior.
5) **Remove the old browser asset**
- Delete `src/browser/assets/initMessage.txt` and remove its imports once no longer referenced.
6) **Docs**
- Update docs to reflect that `/init` is now just the `init` skill (and can be overridden by users/projects via `~/.mux/skills/init/SKILL.md` / `.mux/skills/init/SKILL.md`).
7) **Validation checklist**
- Typing `/init` and hitting send triggers the init skill (no “empty message” backend error; no “add a message” toast).
- Project page “Initialize” banner still runs init automatically.
- `/init` appears once in suggestions (as a skill, not a hardcoded command).
- Other skills still work both with and without trailing messages.
**Net LoC estimate (product code only): ~+20–60**
Keep “prefill editable template” UX, but fetch the template body from `agentSkills.get("init")` instead of a browser asset.
Tradeoff: still requires `/init`-specific behavior (or introducing a generalized “insert skill into input” feature).
<details>
<summary>Follow-up: reduce other “prompt template” slash commands</summary>
Once skills can be invoked with no trailing message, we can eliminate other *macro-style* slash commands by applying the same pattern:
- Move the instruction text into `src/node/builtinSkills/<name>.md`.
- Remove the hardcoded command definition + `ChatInput` branch.
- Let `/<name>` resolve via `agentSkills.list`.
Keep hardcoded slash commands only for **UI/backend actions** (clear history, model/provider settings, MCP management, etc.).
</details>
</details>
---
_Generated with `mux` • Model: `openai:gpt-5.2` • Thinking: `xhigh` • Cost: $30.06_
Change-Id: Iaf4c066db3fc75bf52993552b2d0d6ee9655bb28
If a skill exists in both locations, **project-local overrides global**.
25
+
If a skill exists in multiple locations, the precedence order is: **project-local > global > built-in**.
25
26
26
27
<Info>
27
28
mux reads skills using the active workspace runtime. For SSH workspaces, skills are read from the
@@ -82,7 +83,8 @@ mux injects an `<agent-skills>` block into the system prompt listing the availab
82
83
83
84
You can apply a skill in two ways:
84
85
85
-
-**Explicit (slash command)**: type `/{skill-name} ...` in the chat input. mux will send your message normally, but inject the skill content into the system context for that send.
86
+
-**Explicit (slash command)**: type `/{skill-name}` (optionally followed by a message: `/{skill-name} ...`) in the chat input. mux will send your message normally (or a small default message if you omit one), and inject the skill content into the system context for that send.
87
+
- Example: `/init` runs the built-in `init` skill to bootstrap `AGENTS.md`. You can override it with `~/.mux/skills/init/SKILL.md` (or `.mux/skills/init/SKILL.md` for a single project).
86
88
- Type `/` to see skills in the suggestions list.
87
89
-**Agent-initiated (tool call)**: the agent can load skills on-demand.
description: Bootstrap an AGENTS.md file in a new or existing project
4
+
---
5
+
1
6
<system>
2
7
Use your tools to create or improve an AGENTS.md file in the root of the workspace which will serve as a contribution guide for AI agents.
3
8
If an AGENTS.md file already exists, focus on additive improvement (preserve intent and useful information; refine, extend, and reorganize as needed) rather than replacing it wholesale.
4
9
Inspect the workspace layout, code, documentation and git history to ensure correctness and accuracy.
5
10
6
11
Ensure the following preamble exists at the top of the file before any other sections. Do not include the surrounding code fence backticks; only include the text.
12
+
7
13
```md
8
14
You are an experienced, pragmatic software engineering AI agent. Do not over-engineer a solution when a simple one is possible. Keep edits minimal. If you want an exception to ANY rule, you MUST stop and get permission first.
9
15
```
10
16
11
17
Recommended sections:
18
+
12
19
- Project Overview (mandatory)
13
-
- Basic details about the project (e.g., high-level overview and goals).
- List important directories and basic code structure tips.
18
-
- Project architecture.
23
+
- List important code files.
24
+
- List important directories and basic code structure tips.
25
+
- Project architecture.
19
26
- Essential commands (mandatory)
20
-
- build
21
-
- format
22
-
- lint
23
-
- test
24
-
- clean
25
-
- development server
26
-
- other *important* scripts (use `find -type f -name '*.sh'` or similar)
27
+
- build
28
+
- format
29
+
- lint
30
+
- test
31
+
- clean
32
+
- development server
33
+
- other _important_ scripts (use `find -type f -name '*.sh'` or similar)
27
34
- Patterns (optional)
28
-
- List any important or uncommon patterns (compared to other similar codebases), with examples (e.g., how to authorize an HTTP request).
29
-
- List any important workflows and their steps (e.g., how to make a database migration).
30
-
- Testing patterns.
35
+
- List any important or uncommon patterns (compared to other similar codebases), with examples (e.g., how to authorize an HTTP request).
36
+
- List any important workflows and their steps (e.g., how to make a database migration).
37
+
- Testing patterns.
31
38
- Anti-patterns (optional)
32
-
- Search git history and comments to find recurring mistakes or forbidden patterns.
33
-
- List each pattern and its reason.
39
+
- Search git history and comments to find recurring mistakes or forbidden patterns.
40
+
- List each pattern and its reason.
34
41
- Code style (optional)
35
-
- Style guide to follow (with link).
42
+
- Style guide to follow (with link).
36
43
- Commit and Pull Request Guidelines (mandatory)
37
-
- Required steps for validating changes before committing.
38
-
- Commit message conventions (read `git log`, or use `type: message` by default).
39
-
- Pull request description requirements.
44
+
- Required steps for validating changes before committing.
45
+
- Commit message conventions (read `git log`, or use `type: message` by default).
46
+
- Pull request description requirements.
40
47
41
48
You can add other sections if they are necessary.
42
49
If the information required for mandatory sections isn't available due to the workspace being empty or sparse, add TODO text in its place.
43
50
Optional sections should be scrapped if the information is too thin.
44
51
45
52
Some investigation tips:
46
-
- Read existing lint configs, tsconfig, and CI workflows to find any style or layout rules.
47
-
- Search for "TODO", "HACK", "FIXME", "don't", "never", "always" in comments.
48
-
- Examine test files for patterns.
49
-
- Read PR templates and issue templates if they exist.
50
-
- Check for existing CONTRIBUTING.md, CODE_OF_CONDUCT.md, or similar documentation files.
53
+
54
+
- Read existing lint configs, tsconfig, and CI workflows to find any style or layout rules.
55
+
- Search for "TODO", "HACK", "FIXME", "don't", "never", "always" in comments.
56
+
- Examine test files for patterns.
57
+
- Read PR templates and issue templates if they exist.
58
+
- Check for existing CONTRIBUTING.md, CODE_OF_CONDUCT.md, or similar documentation files.
51
59
52
60
Some writing tips:
61
+
53
62
- Each "do X" should have a corresponding "don't Y" where applicable.
54
63
- Commands should be easily copy-pastable and tested.
55
64
- Terms or phrases specific to this project should be explained on first use.
56
65
- Anything that is against the norm should be explicitly highlighted and called out.
57
66
58
67
Above all things:
68
+
59
69
- The document must be clear and concise. Simple projects should need less than 400 words, but larger and more mature codebases will likely need 700+. Prioritize completeness over brevity.
60
70
- Don't include useless fluff.
61
71
- The document must be in Markdown format and use headings for structure.
@@ -64,14 +74,16 @@ Above all things:
64
74
- Maintain a professional, instructional tone.
65
75
66
76
If the workspace is empty or sparse, ask the user for more information. Avoid hallucinating important decisions. You can provide suggestions to the user for language/technology/tool choices, but always respect the user's decision.
0 commit comments