@mindfoldhq/trellis 0.6.0-rc.0 → 0.6.0

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
@@ -0,0 +1,146 @@
1
+ # Bundled Skills
2
+
3
+ "Bundled skills" are multi-file built-in skills shipped inside the Trellis CLI npm package. Unlike marketplace skills (which a user installs separately into their own `.claude/skills/` or other platform skill root), bundled skills are written automatically into every supported platform's skill root by `trellis init` and kept in sync by `trellis update`. They are part of Trellis itself, not third-party content.
4
+
5
+ A bundled skill is a directory under `packages/cli/src/templates/common/bundled-skills/<skill>/` that already contains its own `SKILL.md` (with YAML frontmatter) plus optional `references/`, assets, or other supporting files. Trellis copies the whole directory tree as-is into each platform's skill root, so references stay lazy-loadable instead of being flattened into one oversized `SKILL.md`.
6
+
7
+ ## What Counts As Bundled (vs. Adjacent Concepts)
8
+
9
+ | Source path | Type | How it ships |
10
+ | --- | --- | --- |
11
+ | `templates/common/bundled-skills/<name>/` | Bundled skill (multi-file) | Whole directory copied to every platform skill root |
12
+ | `templates/common/skills/<name>.md` | Single-file workflow skill | Wrapped with frontmatter, written as `<root>/<name>/SKILL.md` |
13
+ | `templates/common/commands/<name>.md` | Slash command / prompt | Written to each platform's command directory (`.claude/commands/trellis/`, `.cursor/commands/trellis-*.md`, `.gemini/commands/trellis/*.toml`, etc.) |
14
+ | `templates/<platform>/skills/` | Platform-specific skill | Written only into that platform's directory (e.g. `.codex/skills/`) |
15
+ | User skills under `.claude/skills/<my-skill>/` etc. | Marketplace or user-authored | Not managed by Trellis at all |
16
+
17
+ The Trellis CLI never touches anything that is not produced by one of its own template loaders. Anything a user drops into a platform skill root by hand is left alone.
18
+
19
+ ## Current Bundled Skills (v0.6.0)
20
+
21
+ The set is discovered at runtime by listing directories under `templates/common/bundled-skills/`:
22
+
23
+ | Skill | Purpose |
24
+ | --- | --- |
25
+ | `trellis-meta` | This skill. Explains the local Trellis architecture and customization entry points to an AI working inside a user project. |
26
+ | `trellis-session-insight` | Wraps the `trellis mem` CLI so an AI knows when and how to reach into past Claude Code / Codex conversation logs. |
27
+ | `trellis-spec-bootstrap` | Platform-neutral workflow for creating or refreshing `.trellis/spec/` from the real codebase (with optional GitNexus / ABCoder integration). |
28
+ | `trellis-channel` | Capability skill teaching an AI when to reach for `trellis channel` for multi-agent collaboration, forum/thread persistent boards, and dispatcher-wait patterns. |
29
+
30
+ The list is discovered at runtime, so adding a new directory under `bundled-skills/` is the only step required to register a new skill (see "Adding a New Bundled Skill" below).
31
+
32
+ ## Where Bundled Skills Land Per Platform
33
+
34
+ Each platform configurator calls `writeSkills(<root>, <workflowSkills>, resolveBundledSkills(ctx))` during `trellis init`. `resolveBundledSkills` reads every directory under `templates/common/bundled-skills/`, resolves placeholders, and returns a flat list of `{relativePath, content}` entries. `writeSkills` then mirrors them under the platform's skill root.
35
+
36
+ | Platform | Bundled skill root | Notes |
37
+ | --- | --- | --- |
38
+ | Claude Code | `.claude/skills/<skill>/` | `configureClaude` |
39
+ | Cursor | `.cursor/skills/<skill>/` | `configureCursor` |
40
+ | Codex | `.agents/skills/<skill>/` | `configureCodex` writes the shared `.agents/skills/` root, which Gemini CLI 0.40+ also reads |
41
+ | Gemini CLI | `.agents/skills/<skill>/` | Same shared root as Codex; the two configurators are required to produce byte-identical output |
42
+ | Kiro | `.kiro/skills/<skill>/` | `configureKiro` (skills-based platform — no commands) |
43
+ | Qoder | `.qoder/skills/<skill>/` | `configureQoder` |
44
+ | Codebuddy | `.codebuddy/skills/<skill>/` | `configureCodebuddy` |
45
+ | Copilot | `.github/skills/<skill>/` | `configureCopilot` |
46
+ | Droid | `.factory/skills/<skill>/` | `configureDroid` |
47
+ | Antigravity | `.agent/skills/<skill>/` | `configureAntigravity` |
48
+ | Windsurf | `.windsurf/skills/<skill>/` | `configureWindsurf` |
49
+ | Kilo | `.kilocode/skills/<skill>/` | `configureKilo` |
50
+ | OpenCode | (handled by `collectOpenCodeTemplates`) | Uses the same `resolveBundledSkills(ctx)` output |
51
+ | Pi, Reasonix | (their own collectors) | Same `resolveBundledSkills(ctx)` output |
52
+
53
+ Two paths exercise the same data:
54
+
55
+ 1. `configureX(cwd)` writes files during `trellis init`.
56
+ 2. `collectPlatformTemplates(platformId)` (in `configurators/index.ts`) returns a `Map<filePath, content>` that `trellis update` uses to detect drift and to populate `.trellis/.template-hashes.json`. Both must produce byte-identical output, so they both call `resolveBundledSkills(ctx)` and `collectSkillTemplates(root, …, resolveBundledSkills(ctx))`.
57
+
58
+ ## Dispatch Wiring (Code Path)
59
+
60
+ The mechanism that auto-dispatches bundled skills to platform skill roots lives in two files:
61
+
62
+ 1. `packages/cli/src/templates/common/index.ts`
63
+ - `listDirectories("bundled-skills")` enumerates the on-disk skills.
64
+ - `listBundledSkillFiles(skillDir)` walks each skill's directory recursively and returns `{relativePath, content}` for every file.
65
+ - `getBundledSkillTemplates()` returns the cached `CommonBundledSkill[]`.
66
+
67
+ 2. `packages/cli/src/configurators/shared.ts`
68
+ - `resolveBundledSkills(ctx)` flattens that list into `ResolvedSkillFile[]` with `<skill>/<relativePath>` paths and resolved placeholders.
69
+ - `writeSkills(skillsRoot, workflowSkills, bundledSkills)` writes both workflow skills and bundled skill files under `skillsRoot`.
70
+ - `collectSkillTemplates(skillsRoot, workflowSkills, bundledSkills)` returns the same shape as a `Map<filePath, content>` for the update / hash pipeline.
71
+
72
+ Every platform configurator that supports skills imports both helpers (see `claude.ts`, `cursor.ts`, `codex.ts`, `gemini.ts`, `kiro.ts`, `qoder.ts`, `codebuddy.ts`, `copilot.ts`, `droid.ts`, `antigravity.ts`, `windsurf.ts`, `kilo.ts`). The `index.ts` `PLATFORM_FUNCTIONS` registry also calls `resolveBundledSkills(ctx)` inside each `collectTemplates` closure so `trellis update` tracking stays consistent.
73
+
74
+ ## Adding a New Bundled Skill
75
+
76
+ The shape and dispatch wiring are already generic, so adding a skill requires only file changes plus distribution verification.
77
+
78
+ 1. **Create the directory tree.**
79
+
80
+ ```
81
+ packages/cli/src/templates/common/bundled-skills/<my-skill>/
82
+ SKILL.md # YAML frontmatter + body
83
+ references/ # optional
84
+ <topic>.md
85
+ assets/ # optional (anything readable as utf-8)
86
+ ```
87
+
88
+ 2. **Write a valid `SKILL.md` header.** The frontmatter must include at minimum:
89
+
90
+ ```yaml
91
+ ---
92
+ name: <my-skill>
93
+ description: "When the AI should reach for this skill. Triggering phrases go here."
94
+ ---
95
+ ```
96
+
97
+ The `description` is what each platform's auto-trigger mechanism matches against, so it should describe the user-intent triggers, not the skill's internals.
98
+
99
+ 3. **Use placeholders where appropriate.** Bundled skill content runs through `resolvePlaceholders(file.content, ctx)`. Any `{{platform_name}}`, `{{python_cmd}}`, etc. token supported by `resolvePlaceholders` will be substituted per platform.
100
+
101
+ 4. **No dispatch wiring is required.** `listDirectories("bundled-skills")` discovers the new directory automatically, so all platforms receive it on the next `trellis init` or `trellis update`.
102
+
103
+ 5. **Verify the distribution path** before shipping. Skipping any of these steps has historically caused features to be documented as bundled while the published npm tarball was missing the files:
104
+
105
+ - Source files exist on the branch being tagged.
106
+ - `pnpm --filter @mindfoldhq/trellis build` copies the asset into `dist/templates/common/bundled-skills/<skill>/`.
107
+ - `npm pack --dry-run --json` includes the expected `dist/**` paths.
108
+ - In a fresh temp project, `trellis init` writes `.claude/skills/<skill>/SKILL.md`, `.agents/skills/<skill>/SKILL.md`, etc.
109
+ - `.trellis/.template-hashes.json` lists the generated files.
110
+ - `trellis update --dry-run` in that temp project reports "Already up to date!".
111
+
112
+ 6. **Add a migration manifest entry** if the skill is added in a release that other projects will upgrade into. Without an explicit manifest entry the file will land via the standard "missing file" branch of `trellis update`, but a manifest makes the change visible in the changelog.
113
+
114
+ ## Overriding a Bundled Skill Locally
115
+
116
+ There is no formal "project-local skill" mechanism (e.g. `.trellis/skills/`). Bundled skills are platform-rooted, so any override is platform-rooted too.
117
+
118
+ The supported pattern relies on the existing template-hash diff in `trellis update`:
119
+
120
+ 1. Edit the local file directly. Example: `.claude/skills/trellis-meta/SKILL.md`.
121
+ 2. The file's hash now diverges from the entry in `.trellis/.template-hashes.json`.
122
+ 3. The next `trellis update` detects the user modification and leaves the file untouched (Trellis never overwrites user-modified files without an explicit `--force`).
123
+
124
+ Caveats:
125
+
126
+ - The override only applies to the one platform whose directory you edited. To override the same skill across, for example, Claude Code and Codex, you must edit both `.claude/skills/<name>/` and `.agents/skills/<name>/`.
127
+ - A future `trellis update --force` will overwrite local edits. Keep the override under version control so it can be reapplied if needed.
128
+ - Marketplace skills installed under the same platform skill root with a different folder name (e.g. `.claude/skills/my-custom-meta/`) are untouched by Trellis and are the cleaner option when the goal is to add behavior, not to mutate the bundled skill.
129
+ - Team-private conventions belong in `.trellis/spec/` or in a separate marketplace-style local skill, not in modifications to `trellis-meta` itself. See `customize-local/add-project-local-conventions.md`.
130
+
131
+ ## Removing a Bundled Skill From a Project
132
+
133
+ There is no per-project opt-out flag for bundled skills. Two options:
134
+
135
+ 1. **Delete the directory in each platform skill root.** `trellis update` will see the file missing, compare against `.template-hashes.json`, and treat the deletion the same as any other user modification — it will not silently re-create the directory unless `--force` is passed.
136
+
137
+ 2. **Pin a Trellis version that did not ship the skill.** The bundled-skill set is determined at build time, so installing an older release of the CLI is the only way to permanently exclude a skill that the current release ships.
138
+
139
+ A third option — globally disabling all bundled skills — is not supported. The dispatch is unconditional in every configurator. Adding such a flag would require changing `PLATFORM_FUNCTIONS` in `configurators/index.ts` and every `configureX` function.
140
+
141
+ ## Operating Rules
142
+
143
+ - Treat `templates/common/bundled-skills/` as the single source of truth for what bundled skills exist. Do not hand-maintain platform-by-platform skill lists.
144
+ - Do not add platform-specific logic inside a bundled `SKILL.md`. If a behavior is platform-specific, put it in `templates/<platform>/skills/` instead.
145
+ - Do not couple bundled skills to a specific CLI binary (e.g. `trellis mem`) without surfacing the dependency in the skill's description and references — users on older releases may not have the command.
146
+ - Do not store project-private content in a bundled skill. Bundled skills are public, shipped to every user; project rules belong in `.trellis/spec/` or a local skill.
@@ -0,0 +1,69 @@
1
+ # Local Multi-Agent Channel Runtime
2
+
3
+ `trellis channel` is the local multi-agent collaboration runtime shipped with the Trellis CLI. It lets the main AI session spawn peer workers (Claude Code, Codex, or any agent definition under `.trellis/agents/`), exchange durable messages through an event log, and coordinate review or brainstorm loops without hand-stitching shell pipelines.
4
+
5
+ This reference covers how channels are wired into the user project so an AI customizing the project knows what to edit. For runtime usage (commands, forum/thread patterns, worker spawn flags), defer to the bundled `trellis-channel` capability skill.
6
+
7
+ ## Local System Model
8
+
9
+ The channel runtime spans three local surfaces:
10
+
11
+ 1. **Storage layer** in the user's home directory: durable event logs and worker state files.
12
+ 2. **Agent definitions** inside the project at `.trellis/agents/`: platform-agnostic role cards consumed by `trellis channel spawn --agent <name>`.
13
+ 3. **Project configuration** in `.trellis/config.yaml`: worker guard thresholds and other channel knobs.
14
+
15
+ ## Core Paths
16
+
17
+ | Path | Purpose |
18
+ | --- | --- |
19
+ | `~/.trellis/channels/<project>/<channel>/events.jsonl` | Per-channel append-only event log. Sequence-locked, replay-safe. |
20
+ | `~/.trellis/channels/<project>/<channel>/<channel>.lock` | Channel-level write lock. |
21
+ | `~/.trellis/channels/<project>/<channel>/<worker>.spawnlock` | Per-worker spawn lock used by the OOM guard. |
22
+ | `~/.trellis/channels/<project>/<channel>/.seq` | Sequence sidecar for ordered event assignment. |
23
+ | `~/.trellis/channels/_global/<channel>/...` | Channels created with `--scope global`. The project bucket is replaced by a shared key. |
24
+ | `.trellis/agents/check.md` | Default Check Agent role definition consumed by `--agent check`. |
25
+ | `.trellis/agents/implement.md` | Default Implement Agent role definition consumed by `--agent implement`. |
26
+ | `.trellis/config.yaml` (`channel.*` block) | Worker guard thresholds and channel defaults. |
27
+
28
+ The project bucket name is derived from the absolute project path (slashes flattened, non-alphanumerics replaced with `-`), matching Claude Code's `~/.claude/projects/<sanitized-cwd>/` convention. Override with `TRELLIS_CHANNEL_ROOT` (root directory) or `TRELLIS_CHANNEL_PROJECT` (bucket name) for testing or sandboxing.
29
+
30
+ ## When To Reach For The Channel Runtime
31
+
32
+ Channels are heavier than a single Bash call or a one-shot sub-agent dispatch. Use them only when at least one of these conditions holds:
33
+
34
+ - The work needs **two or more agents to converse** through more than one turn (cross-AI brainstorm, peer review, dispatcher + worker).
35
+ - A worker should run as a **peer process** that the main session can interrupt, watch progress on, or wait for asynchronously.
36
+ - The conversation must be **durable and inspectable** later (forum/thread channels, issue boards, decision trails).
37
+ - Multiple workers must **share an event log** so each can see what the others reported.
38
+
39
+ Prefer cheaper primitives when:
40
+
41
+ - A single-shot Bash command or single Agent tool call is enough -> do that directly.
42
+ - The user just needs a static review against a file -> read the file and reply inline.
43
+ - The need is "remember what we discussed last week" -> use `trellis mem` instead of a channel.
44
+
45
+ ## Customization Points
46
+
47
+ | Need | Edit location |
48
+ | --- | --- |
49
+ | Change default channel worker idle timeout | `channel.worker_guard.idle_timeout` in `.trellis/config.yaml`. Accepts `5m`, `30s`, etc. Set `0` to disable idle cleanup. |
50
+ | Change live worker budget | `channel.worker_guard.max_live_workers` in `.trellis/config.yaml`. Set `0` to disable the spawn-time budget check. |
51
+ | Override worker guard per spawn | Pass `--idle-timeout` / `--max-live-workers` on `trellis channel spawn`, or set `TRELLIS_CHANNEL_WORKER_IDLE_TIMEOUT` / `TRELLIS_CHANNEL_MAX_LIVE_WORKERS` in the environment. |
52
+ | Change what the default Check or Implement worker does | Edit `.trellis/agents/check.md` or `.trellis/agents/implement.md`. These are platform-agnostic role cards; the channel runtime injects them when `--agent check|implement` is passed. |
53
+ | Add a new role card | Drop `<name>.md` into `.trellis/agents/`. `trellis channel spawn --agent <name>` will pick it up. |
54
+ | Relocate channel storage (CI sandbox, ephemeral runs) | Set `TRELLIS_CHANNEL_ROOT=/path/to/dir`. Channel events move with it; existing channels stay at the old root. |
55
+ | Switch storage scope | Pass `--scope project` (default) or `--scope global` on every channel subcommand. The bucket directory changes; nothing else does. |
56
+
57
+ Precedence for the worker guard is: CLI flag > environment variable > `.trellis/config.yaml` > built-in default. Built-in defaults are `idle_timeout: 5m` and `max_live_workers: 6`.
58
+
59
+ ## Relationship To Other Local Layers
60
+
61
+ - **Workflow layer**: workflows that use channel dispatch (such as `channel-driven-subagent-dispatch`) instruct the main agent to call `trellis channel spawn --agent check` or `--agent implement` instead of a platform sub-agent. If `.trellis/agents/check.md` or `implement.md` is missing, `trellis workflow --template <id>` prints a non-blocking warning at install time. Restore them with `trellis update` if they are deleted by accident.
62
+ - **Task layer**: channel workers do not own task state. The supervising main session passes the active task path through the worker inbox; the worker resolves task artifacts from disk.
63
+ - **Spec layer**: workers read `.trellis/spec/` the same way the main session does. Channel runtime does not bypass spec context loading.
64
+ - **Platform integration layer**: channel runtime is platform-neutral. It does not depend on `.claude/`, `.codex/`, or any other platform directory. The adapters that normalize provider output (Claude `stream-json`, Codex `app-server`) live inside the Trellis CLI binary, not in the project.
65
+ - **Platform sub-agent files vs. channel workers**: editing `.claude/agents/trellis-implement.md` (and its peers in other platform `.X/agents/` directories) does NOT change channel-runtime worker behavior — channel workers load `.trellis/agents/<name>.md`. The platform-specific agent files are for direct sub-agent dispatch from the main AI session, not for channel-spawned workers. See `platform-files/agents.md` for the per-platform agent surface, and the `trellis-meta/SKILL.md` rule that codifies this split.
66
+
67
+ ## Runtime Usage
68
+
69
+ For command syntax, forum/thread patterns, worker handles, progress inspection, and the `--kind done` / `--kind turn_finished` dispatcher wait pattern, load the bundled `trellis-channel` skill (auto-installed under each platform's skills directory after `trellis init` / `trellis update`). This reference only covers the local file layout and customization knobs; it does not duplicate command syntax that may change between releases.
@@ -19,7 +19,8 @@ This page lists common Trellis file locations in a user project by platform. Whe
19
19
  | CodeBuddy | `--codebuddy` | `.codebuddy/` | `.codebuddy/skills/` | `.codebuddy/agents/` | `.codebuddy/hooks/` + `.codebuddy/settings.json` |
20
20
  | GitHub Copilot | `--copilot` | `.github/` | `.github/skills/` | `.github/agents/` | `.github/copilot/hooks/` + prompts |
21
21
  | Factory Droid | `--droid` | `.factory/` | `.factory/skills/` | `.factory/droids/` | `.factory/hooks/` + settings |
22
- | Pi Agent | `--pi` | `.pi/` | `.pi/skills/` | `.pi/agents/` | `.pi/extensions/trellis/` + `.pi/settings.json` |
22
+ | Pi Agent | `--pi` | `.pi/` | `.pi/skills/` | `.pi/agents/` | `.pi/extensions/trellis/` (native `trellis_subagent` tool) + `.pi/settings.json` |
23
+ | Reasonix | `--reasonix` | `.reasonix/` | `.reasonix/skills/` | None — sub-agents are skills with `runAs: subagent` frontmatter | None |
23
24
 
24
25
  ## Capability Groups
25
26
 
@@ -38,9 +39,18 @@ These platforms usually have `trellis-research`, `trellis-implement`, and `trell
38
39
  - GitHub Copilot
39
40
  - Factory Droid
40
41
  - Pi Agent
42
+ - Reasonix (delivered as skills with `runAs: subagent` under `.reasonix/skills/`, not as a separate `agents/` directory)
41
43
 
42
44
  When changing implementation/check/research behavior, look for the corresponding platform agent files first.
43
45
 
46
+ ### Native Trellis Sub-Agent Tool
47
+
48
+ Some platforms expose a first-class tool that the host runtime understands. The model calls it like any other tool and the host renders progress cards, validates the agent name against `.<platform>/agents/`, and enforces dispatch modes.
49
+
50
+ - Pi Agent — `trellis_subagent` tool, defined in `.pi/extensions/trellis/index.ts`. Supports `single` / `parallel` / `chain` dispatch modes and emits live `trellis-subagent-progress` events.
51
+
52
+ When changing sub-agent dispatch behavior on these platforms, edit the extension file, **not** the agent markdown — the agent markdown defines responsibilities, but the host extension owns dispatch, validation, and progress rendering.
53
+
44
54
  ### Main-Session Workflow Platforms
45
55
 
46
56
  These platforms rely more on workflows/skills to guide the main session:
package/package.json CHANGED
@@ -1,6 +1,6 @@
1
1
  {
2
2
  "name": "@mindfoldhq/trellis",
3
- "version": "0.6.0-rc.0",
3
+ "version": "0.6.0",
4
4
  "description": "AI capabilities grow like ivy — Trellis provides the structure to guide them along a disciplined path",
5
5
  "type": "module",
6
6
  "main": "./dist/index.js",
@@ -34,7 +34,7 @@
34
34
  "inquirer": "^9.3.7",
35
35
  "undici": "^6.21.0",
36
36
  "zod": "^4.4.2",
37
- "@mindfoldhq/trellis-core": "0.6.0-rc.0"
37
+ "@mindfoldhq/trellis-core": "0.6.0"
38
38
  },
39
39
  "devDependencies": {
40
40
  "@eslint/js": "^9.18.0",