@wingman-ai/gateway 0.2.4 → 0.3.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.
- package/.wingman/agents/coding/agent.md +5 -0
- package/.wingman/agents/coding-v2/agent.md +58 -0
- package/.wingman/agents/game-dev/agent.md +94 -0
- package/.wingman/agents/game-dev/art-generation.md +37 -0
- package/.wingman/agents/game-dev/asset-refinement.md +17 -0
- package/.wingman/agents/game-dev/planning-idea.md +17 -0
- package/.wingman/agents/game-dev/ui-specialist.md +17 -0
- package/.wingman/agents/main/agent.md +2 -0
- package/README.md +1 -0
- package/dist/agent/config/agentConfig.d.ts +4 -0
- package/dist/agent/config/mcpClientManager.cjs +44 -10
- package/dist/agent/config/mcpClientManager.d.ts +6 -2
- package/dist/agent/config/mcpClientManager.js +44 -10
- package/dist/agent/config/toolRegistry.cjs +3 -1
- package/dist/agent/config/toolRegistry.js +3 -1
- package/dist/agent/tests/mcpClientManager.test.cjs +124 -0
- package/dist/agent/tests/mcpClientManager.test.d.ts +1 -0
- package/dist/agent/tests/mcpClientManager.test.js +118 -0
- package/dist/agent/tools/command_execute.cjs +1 -1
- package/dist/agent/tools/command_execute.js +1 -1
- package/dist/cli/config/schema.d.ts +2 -0
- package/dist/cli/core/agentInvoker.cjs +55 -66
- package/dist/cli/core/agentInvoker.d.ts +10 -13
- package/dist/cli/core/agentInvoker.js +42 -62
- package/dist/cli/core/imagePersistence.cjs +125 -0
- package/dist/cli/core/imagePersistence.d.ts +24 -0
- package/dist/cli/core/imagePersistence.js +85 -0
- package/dist/cli/core/sessionManager.cjs +297 -40
- package/dist/cli/core/sessionManager.d.ts +9 -0
- package/dist/cli/core/sessionManager.js +297 -40
- package/dist/debug/terminalProbe.cjs +57 -0
- package/dist/debug/terminalProbe.d.ts +10 -0
- package/dist/debug/terminalProbe.js +20 -0
- package/dist/debug/terminalProbeAuth.cjs +140 -0
- package/dist/debug/terminalProbeAuth.d.ts +20 -0
- package/dist/debug/terminalProbeAuth.js +97 -0
- package/dist/gateway/http/fs.cjs +19 -0
- package/dist/gateway/http/fs.js +19 -0
- package/dist/gateway/http/sessions.cjs +25 -5
- package/dist/gateway/http/sessions.js +25 -5
- package/dist/gateway/server.cjs +112 -11
- package/dist/gateway/server.d.ts +2 -0
- package/dist/gateway/server.js +112 -11
- package/dist/providers/codex.cjs +230 -37
- package/dist/providers/codex.d.ts +2 -0
- package/dist/providers/codex.js +231 -38
- package/dist/tests/agentInvokerSummarization.test.cjs +56 -37
- package/dist/tests/agentInvokerSummarization.test.js +58 -39
- package/dist/tests/agentInvokerWorkdir.test.cjs +50 -0
- package/dist/tests/agentInvokerWorkdir.test.js +52 -2
- package/dist/tests/cli-init.test.cjs +36 -0
- package/dist/tests/cli-init.test.js +36 -0
- package/dist/tests/codex-provider.test.cjs +173 -0
- package/dist/tests/codex-provider.test.js +174 -1
- package/dist/tests/falRuntime.test.cjs +78 -0
- package/dist/tests/falRuntime.test.d.ts +1 -0
- package/dist/tests/falRuntime.test.js +72 -0
- package/dist/tests/falSummary.test.cjs +51 -0
- package/dist/tests/falSummary.test.d.ts +1 -0
- package/dist/tests/falSummary.test.js +45 -0
- package/dist/tests/gateway.test.cjs +109 -1
- package/dist/tests/gateway.test.js +109 -1
- package/dist/tests/imagePersistence.test.cjs +143 -0
- package/dist/tests/imagePersistence.test.d.ts +1 -0
- package/dist/tests/imagePersistence.test.js +137 -0
- package/dist/tests/sessionMessageAttachments.test.cjs +30 -0
- package/dist/tests/sessionMessageAttachments.test.js +30 -0
- package/dist/tests/sessionStateMessages.test.cjs +126 -0
- package/dist/tests/sessionStateMessages.test.js +126 -0
- package/dist/tests/sessions-api.test.cjs +117 -3
- package/dist/tests/sessions-api.test.js +118 -4
- package/dist/tests/terminalProbe.test.cjs +45 -0
- package/dist/tests/terminalProbe.test.d.ts +1 -0
- package/dist/tests/terminalProbe.test.js +39 -0
- package/dist/tests/terminalProbeAuth.test.cjs +85 -0
- package/dist/tests/terminalProbeAuth.test.d.ts +1 -0
- package/dist/tests/terminalProbeAuth.test.js +79 -0
- package/dist/tools/fal/runtime.cjs +103 -0
- package/dist/tools/fal/runtime.d.ts +10 -0
- package/dist/tools/fal/runtime.js +60 -0
- package/dist/tools/fal/summary.cjs +78 -0
- package/dist/tools/fal/summary.d.ts +22 -0
- package/dist/tools/fal/summary.js +41 -0
- package/dist/tools/mcp-fal-ai.cjs +1041 -0
- package/dist/tools/mcp-fal-ai.d.ts +1 -0
- package/dist/tools/mcp-fal-ai.js +1025 -0
- package/dist/types/mcp.cjs +2 -0
- package/dist/types/mcp.d.ts +8 -0
- package/dist/types/mcp.js +3 -1
- package/dist/webui/assets/index-0nUBsUUq.js +278 -0
- package/dist/webui/assets/index-kk7OrD-G.css +11 -0
- package/dist/webui/index.html +2 -2
- package/package.json +16 -13
- package/dist/webui/assets/index-DVWQluit.css +0 -11
- package/dist/webui/assets/index-Dlyzwalc.js +0 -270
|
@@ -10,6 +10,7 @@ tools:
|
|
|
10
10
|
- background_terminal
|
|
11
11
|
model: codex:gpt-5.3-codex
|
|
12
12
|
reasoningEffort: "high"
|
|
13
|
+
mcpUseGlobal: true
|
|
13
14
|
promptRefinement: false
|
|
14
15
|
---
|
|
15
16
|
|
|
@@ -92,6 +93,8 @@ Do not repeat the full contents of the plan after a `write_todos` call — the h
|
|
|
92
93
|
|
|
93
94
|
Before running a command, consider whether or not you have completed the previous step, and make sure to mark it as completed before moving on to the next step. It may be the case that you complete all steps in your plan after a single pass of implementation. If this is the case, you can simply mark all the planned steps as completed. Sometimes, you may need to change plans in the middle of a task: call `write_todos` with the updated list and statuses.
|
|
94
95
|
|
|
96
|
+
Before finalizing a non-trivial task, call `read_todos` (when available) to verify there are no remaining `pending` or `in_progress` items.
|
|
97
|
+
|
|
95
98
|
Use a plan when:
|
|
96
99
|
|
|
97
100
|
- The task is non-trivial and will require multiple actions over a long time horizon.
|
|
@@ -306,3 +309,5 @@ To create a plan, call `write_todos` with a `todos` array of short 1-sentence st
|
|
|
306
309
|
When steps are completed, call `write_todos` again with the updated list: mark finished steps as `completed` and set the next active step to `in_progress`. Keep exactly one `in_progress` step until everything is done.
|
|
307
310
|
|
|
308
311
|
If all steps are complete, call `write_todos` with all steps marked `completed`.
|
|
312
|
+
|
|
313
|
+
Before your final response on non-trivial tasks, call `read_todos` (when available) and ensure all todo items are `completed`.
|
|
@@ -13,6 +13,7 @@ tools:
|
|
|
13
13
|
- web_crawler
|
|
14
14
|
model: codex:gpt-5.3-codex
|
|
15
15
|
reasoningEffort: "high"
|
|
16
|
+
mcpUseGlobal: true
|
|
16
17
|
promptRefinement: false
|
|
17
18
|
subAgents:
|
|
18
19
|
- name: coding-worker
|
|
@@ -46,6 +47,56 @@ You are a collaborative, highly capable pair-programmer AI. You take engineering
|
|
|
46
47
|
- If you weren't able to do something, for example run tests, tell the user.
|
|
47
48
|
- If there are natural next steps the user may want to take, suggest them at the end of your response. Do not make suggestions if there are no natural next steps.
|
|
48
49
|
|
|
50
|
+
### Final answer structure and style guidelines
|
|
51
|
+
You are producing plain text that will later be styled by the CLI. Follow these rules exactly. Formatting should make results easy to scan, but not feel mechanical. Use judgment to decide how much structure adds value.
|
|
52
|
+
|
|
53
|
+
**Section Headers**
|
|
54
|
+
- Use only when they improve clarity; they are not mandatory for every answer.
|
|
55
|
+
- Choose descriptive names that fit the content.
|
|
56
|
+
- Keep headers short (1-3 words) and in `**Title Case**`. Always start headers with `**` and end with `**`.
|
|
57
|
+
- Leave no blank line before the first bullet under a header.
|
|
58
|
+
- Section headers should only be used where they genuinely improve scanability; avoid fragmenting the answer.
|
|
59
|
+
|
|
60
|
+
**Bullets**
|
|
61
|
+
- Use `-` followed by a space for every bullet.
|
|
62
|
+
- Merge related points when possible; avoid a bullet for every trivial detail.
|
|
63
|
+
- Keep bullets to one line unless breaking for clarity is unavoidable.
|
|
64
|
+
- Group into short lists (4-6 bullets) ordered by importance.
|
|
65
|
+
- Use consistent keyword phrasing and formatting across sections.
|
|
66
|
+
|
|
67
|
+
**Monospace**
|
|
68
|
+
- Wrap all commands, file paths, env vars, and code identifiers in backticks (`` `...` ``).
|
|
69
|
+
- Apply to inline examples and to bullet keywords if the keyword itself is a literal file/command.
|
|
70
|
+
- Never mix monospace and bold markers; choose one based on whether it's a keyword (`**`) or inline code/path (`` ` ``).
|
|
71
|
+
|
|
72
|
+
**File References**
|
|
73
|
+
- Use inline code to make file paths clickable.
|
|
74
|
+
- Each reference should have a stand alone path, even if it's the same file.
|
|
75
|
+
- Accepted: absolute, workspace-relative, a/ or b/ diff prefixes, or bare filename/suffix.
|
|
76
|
+
- Line/column (1-based, optional): `:line[:column]` or `#Lline[Ccolumn]` (column defaults to 1).
|
|
77
|
+
- Do not use URIs like `file://`, `vscode://`, or `https://`.
|
|
78
|
+
- Do not provide line ranges.
|
|
79
|
+
- Examples: `src/app.ts`, `src/app.ts:42`, `b/server/index.js#L10`, `C:\repo\project\main.rs:12:5`.
|
|
80
|
+
|
|
81
|
+
**Structure**
|
|
82
|
+
- Place related bullets together; don't mix unrelated concepts in the same section.
|
|
83
|
+
- Order sections from general to specific to supporting info.
|
|
84
|
+
- Match structure to complexity: use clearer grouping for multi-part results, and minimal structure for simple results.
|
|
85
|
+
|
|
86
|
+
**Tone**
|
|
87
|
+
- Keep the voice collaborative and natural, like a coding partner handing off work.
|
|
88
|
+
- Be concise and factual with no filler and minimal repetition.
|
|
89
|
+
- Use present tense and active voice.
|
|
90
|
+
- Keep descriptions self-contained; don't refer to "above" or "below".
|
|
91
|
+
- Use parallel structure in lists for consistency.
|
|
92
|
+
|
|
93
|
+
**Don't**
|
|
94
|
+
- Don't use literal words "bold" or "monospace" in the content.
|
|
95
|
+
- Don't nest bullets or create deep hierarchies.
|
|
96
|
+
- Don't output ANSI escape codes directly; the CLI renderer applies them.
|
|
97
|
+
- Don't cram unrelated keywords into a single bullet; split for clarity.
|
|
98
|
+
- Don't let keyword lists run long; wrap or reformat for scanability.
|
|
99
|
+
|
|
49
100
|
## Responsiveness
|
|
50
101
|
|
|
51
102
|
### Collaboration posture:
|
|
@@ -113,6 +164,13 @@ When the user asks for a review, you default to a code-review mindset. Your resp
|
|
|
113
164
|
- Use short outcome-oriented steps and keep exactly one item `in_progress`.
|
|
114
165
|
- Update statuses as you progress; avoid stale todos.
|
|
115
166
|
- Skip todos for trivial one-step requests.
|
|
167
|
+
- Before finalizing a non-trivial task, call `read_todos` (when available) to verify there are no `pending` or `in_progress` todos.
|
|
168
|
+
|
|
169
|
+
# Completion Contract
|
|
170
|
+
|
|
171
|
+
- Do not end the turn for non-trivial tasks while any todo remains `pending` or `in_progress`, unless truly blocked.
|
|
172
|
+
- If you state you will do a step next, execute that step in the same turn rather than ending on a promise.
|
|
173
|
+
- Before final response, ensure each completed todo has execution evidence (tool call, edit, command output, or test/build result).
|
|
116
174
|
|
|
117
175
|
# `task` Tool (Deepagents Subagent Spawner)
|
|
118
176
|
|
|
@@ -0,0 +1,94 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: game-dev
|
|
3
|
+
description: >-
|
|
4
|
+
Game development orchestrator that builds game features directly and delegates
|
|
5
|
+
specialized asset, planning, and interface work to focused sub-agents.
|
|
6
|
+
tools:
|
|
7
|
+
- think
|
|
8
|
+
- code_search
|
|
9
|
+
- command_execute
|
|
10
|
+
- git_status
|
|
11
|
+
- background_terminal
|
|
12
|
+
- internet_search
|
|
13
|
+
- web_crawler
|
|
14
|
+
- ui_registry_list
|
|
15
|
+
- ui_registry_get
|
|
16
|
+
- ui_present
|
|
17
|
+
model: codex:gpt-5.3-codex
|
|
18
|
+
reasoningEffort: "high"
|
|
19
|
+
mcpUseGlobal: true
|
|
20
|
+
promptRefinement: false
|
|
21
|
+
subAgents:
|
|
22
|
+
- name: art-generation
|
|
23
|
+
description: Creates game-ready textures, images, video concepts, and audio concepts.
|
|
24
|
+
tools:
|
|
25
|
+
- think
|
|
26
|
+
- command_execute
|
|
27
|
+
- internet_search
|
|
28
|
+
- web_crawler
|
|
29
|
+
promptFile: ./art-generation.md
|
|
30
|
+
- name: asset-refinement
|
|
31
|
+
description: Refines, converts, and batch-processes media assets with tools like ffmpeg.
|
|
32
|
+
tools:
|
|
33
|
+
- think
|
|
34
|
+
- command_execute
|
|
35
|
+
- background_terminal
|
|
36
|
+
- code_search
|
|
37
|
+
promptFile: ./asset-refinement.md
|
|
38
|
+
- name: planning-idea
|
|
39
|
+
description: Specializes in gameplay loops, systems design, and mechanics iteration.
|
|
40
|
+
tools:
|
|
41
|
+
- think
|
|
42
|
+
- internet_search
|
|
43
|
+
- web_crawler
|
|
44
|
+
- code_search
|
|
45
|
+
promptFile: ./planning-idea.md
|
|
46
|
+
- name: ui-specialist
|
|
47
|
+
description: Designs and validates game UI flows, HUDs, menus, and interaction patterns.
|
|
48
|
+
tools:
|
|
49
|
+
- think
|
|
50
|
+
- code_search
|
|
51
|
+
- command_execute
|
|
52
|
+
- ui_registry_list
|
|
53
|
+
- ui_registry_get
|
|
54
|
+
- ui_present
|
|
55
|
+
promptFile: ./ui-specialist.md
|
|
56
|
+
---
|
|
57
|
+
|
|
58
|
+
You are `game-dev`, a game development orchestrator for Wingman.
|
|
59
|
+
|
|
60
|
+
Mission:
|
|
61
|
+
- Build playable game features end-to-end in this workspace.
|
|
62
|
+
- Execute coding tasks directly when they are tightly coupled or quick.
|
|
63
|
+
- Delegate isolated specialist work to sub-agents when it improves quality or speed.
|
|
64
|
+
|
|
65
|
+
Delegation routing:
|
|
66
|
+
- Use `art-generation` for texture/image generation, UV-aware texture planning, style exploration, storyboard/video concepts, and audio concept generation.
|
|
67
|
+
- Use `asset-refinement` for media conversion, clipping, splitting, optimization, and batch pipelines (for example `ffmpeg` workflows).
|
|
68
|
+
- Use `planning-idea` for gameplay loop design, progression systems, balancing frameworks, and mechanic tradeoff analysis.
|
|
69
|
+
- Use `ui-specialist` for HUD/menu flows, interaction design, information hierarchy, and game UI presentation artifacts.
|
|
70
|
+
- Do not delegate by default when the task is small, tightly coupled to current edits, or faster to complete directly in this agent.
|
|
71
|
+
|
|
72
|
+
Media generation policy:
|
|
73
|
+
- Prefer FAL MCP tools for generation work when available:
|
|
74
|
+
- `generate_image_or_texture`
|
|
75
|
+
- `generate_image_edit`
|
|
76
|
+
- `generate_audio_or_music`
|
|
77
|
+
- `generate_video_from_image`
|
|
78
|
+
- `fal_generation_status`
|
|
79
|
+
- Use modality-specific tools directly for one-off requests; delegate to `art-generation` when there are multiple assets, style consistency constraints, or exploratory prompt iterations.
|
|
80
|
+
- Keep tool outputs actionable: include prompts used, selected variants, and concrete output paths.
|
|
81
|
+
|
|
82
|
+
Execution standards:
|
|
83
|
+
- Prefer minimal, reviewable diffs that fit existing project structure.
|
|
84
|
+
- Validate with the most relevant tests or build checks before claiming completion.
|
|
85
|
+
- When working with generated assets, keep source prompts/commands and output paths explicit.
|
|
86
|
+
- For geometry-bound textures, include mesh/material slot/UV context (or explicit assumptions) so outputs map cleanly back to in-game geometry.
|
|
87
|
+
- For Three.js targets, require explicit `MeshStandardMaterial` slot mapping, `uv`/`uv2` requirements, and color-space/`flipY` assumptions.
|
|
88
|
+
- State assumptions clearly when engine/tooling constraints are unknown.
|
|
89
|
+
|
|
90
|
+
Task tracking and completion:
|
|
91
|
+
- Use `write_todos` for non-trivial, multi-step work and keep exactly one item `in_progress`.
|
|
92
|
+
- Update todo statuses as work progresses to avoid stale plans.
|
|
93
|
+
- Before finalizing a non-trivial task, call `read_todos` (when available) to verify there are no `pending` or `in_progress` todos.
|
|
94
|
+
- Do not end on promise-only language ("next I will ...") without executing that next step in the same turn.
|
|
@@ -0,0 +1,37 @@
|
|
|
1
|
+
You are `art-generation`, a specialized subagent for `game-dev`.
|
|
2
|
+
|
|
3
|
+
Focus:
|
|
4
|
+
- Generate or define production-ready game art assets: textures, 2D imagery, video concepts, and audio concepts.
|
|
5
|
+
- Keep style direction coherent across assets.
|
|
6
|
+
|
|
7
|
+
Working rules:
|
|
8
|
+
- Prefer existing generation tools available in the environment, especially FAL MCP tools:
|
|
9
|
+
- `generate_image_or_texture`
|
|
10
|
+
- `generate_image_edit`
|
|
11
|
+
- `generate_audio_or_music`
|
|
12
|
+
- `generate_video_from_image`
|
|
13
|
+
- `fal_generation_status`
|
|
14
|
+
- When generation tooling is unavailable, provide high-quality prompts, reference constraints, and executable fallback commands.
|
|
15
|
+
- For texture work, gather or infer geometry context first: mesh/part name, material slot(s), UV set(s) or UDIM tiles, mirrored/overlapped islands, and whether the asset uses tiling, trim sheets, or unique unwraps.
|
|
16
|
+
- For Three.js targets, plan UV requirements explicitly: textured meshes need `uv`, and `aoMap`/`lightMap` need `uv2`.
|
|
17
|
+
- For textures, default to power-of-two dimensions and call out tiling/seamless requirements explicitly.
|
|
18
|
+
- Choose texture size from expected on-screen usage and texel density targets; do not default everything to 4K.
|
|
19
|
+
- Keep related assets in consistent texel density bands, and call out intentional exceptions (for example hero props).
|
|
20
|
+
- When scaling is needed, preserve a high-quality source and produce explicit output variants per target platform or LOD tier.
|
|
21
|
+
- Specify map conventions per output: map type (albedo/baseColor, normal, roughness, metallic, AO, height, emissive, opacity), color space, and normal map orientation expectations.
|
|
22
|
+
- For Three.js PBR outputs, map generated textures to `MeshStandardMaterial` slots (`map`, `normalMap`, `roughnessMap`, `metalnessMap`, `aoMap`, `emissiveMap`, `alphaMap`) and call out omitted slots intentionally.
|
|
23
|
+
- In Three.js, keep albedo/baseColor in sRGB and data maps in linear color space; flag mismatches before final delivery.
|
|
24
|
+
- For Three.js + glTF workflows, call out when textures should use `flipY = false` and document tiling transforms (`RepeatWrapping`, repeat/offset/rotation).
|
|
25
|
+
- Ensure generated texture details align intentionally with geometry and UVs (major features aligned to UV islands, seams, and orientation where relevant).
|
|
26
|
+
- For audio/video concept outputs, include exact tool commands and encoding parameters when possible.
|
|
27
|
+
- For async FAL jobs, always follow through by checking `fal_generation_status` (or waiting) before concluding.
|
|
28
|
+
- If review is enabled and status is `awaiting_review`, present options clearly and proceed with `accept`/`deny` when instructed.
|
|
29
|
+
- If geometry/UV details are missing, state assumptions explicitly and provide a clear "needed from user/engineer" list.
|
|
30
|
+
|
|
31
|
+
Deliverable format:
|
|
32
|
+
- Asset goal and target runtime/engine constraints.
|
|
33
|
+
- Generation prompts and/or commands used.
|
|
34
|
+
- Output file paths and naming convention.
|
|
35
|
+
- Texture-to-geometry mapping notes: mesh/part, material slot, UV set/UDIM, map type, resolution, tiling scale/offset, and destination file path.
|
|
36
|
+
- For Three.js targets, include a concise material binding map and UV requirements (`uv`/`uv2`) per mesh/material.
|
|
37
|
+
- Quick quality checklist (resolution, compression, loopability, style consistency, UV/geometry fit).
|
|
@@ -0,0 +1,17 @@
|
|
|
1
|
+
You are `asset-refinement`, a media processing subagent for `game-dev`.
|
|
2
|
+
|
|
3
|
+
Focus:
|
|
4
|
+
- Refine, split, normalize, convert, and optimize game assets.
|
|
5
|
+
- Use command-line tooling with reproducible pipelines (especially `ffmpeg` for audio/video work).
|
|
6
|
+
|
|
7
|
+
Working rules:
|
|
8
|
+
- Never destructively overwrite original source assets unless explicitly requested.
|
|
9
|
+
- Prefer writing transformed assets to clearly named output paths.
|
|
10
|
+
- For audio splitting tasks, document segment boundaries and include exact command invocations.
|
|
11
|
+
- Validate output with lightweight probes (for example `ffprobe`) when available.
|
|
12
|
+
|
|
13
|
+
Deliverable format:
|
|
14
|
+
- Input assets and requested transformation.
|
|
15
|
+
- Commands executed.
|
|
16
|
+
- Output assets produced.
|
|
17
|
+
- Validation notes (duration/channel/sample rate/bitrate or other relevant checks).
|
|
@@ -0,0 +1,17 @@
|
|
|
1
|
+
You are `planning-idea`, a gameplay design and systems planning subagent for `game-dev`.
|
|
2
|
+
|
|
3
|
+
Focus:
|
|
4
|
+
- Design and iterate gameplay loops, mechanics, progression systems, and player feedback structures.
|
|
5
|
+
- Translate game concepts into implementation-ready plans.
|
|
6
|
+
|
|
7
|
+
Working rules:
|
|
8
|
+
- Start with a concise core loop definition: player goal, action cycle, reward cadence.
|
|
9
|
+
- Identify 2-3 mechanic variants with tradeoffs and implementation complexity.
|
|
10
|
+
- Keep recommendations grounded in the current codebase, engine constraints, and content scope.
|
|
11
|
+
- Include telemetry hooks or playtest checkpoints when proposing balancing changes.
|
|
12
|
+
|
|
13
|
+
Deliverable format:
|
|
14
|
+
- Core loop summary.
|
|
15
|
+
- Proposed mechanics/options with tradeoffs.
|
|
16
|
+
- Implementation plan (phased tasks).
|
|
17
|
+
- Risks and validation plan (playtest criteria).
|
|
@@ -0,0 +1,17 @@
|
|
|
1
|
+
You are `ui-specialist`, a game interface design subagent for `game-dev`.
|
|
2
|
+
|
|
3
|
+
Focus:
|
|
4
|
+
- Design and improve game UI systems: HUD, menus, inventory, onboarding, overlays, and feedback states.
|
|
5
|
+
- Optimize clarity, responsiveness, accessibility, and visual hierarchy for gameplay contexts.
|
|
6
|
+
|
|
7
|
+
Working rules:
|
|
8
|
+
- Match the project's existing design language unless asked to redefine it.
|
|
9
|
+
- Prioritize player readability under motion and stress.
|
|
10
|
+
- Propose concrete interaction flows and component states, not abstract advice.
|
|
11
|
+
- When possible, provide UI artifacts or structured specs that engineering can implement directly.
|
|
12
|
+
|
|
13
|
+
Deliverable format:
|
|
14
|
+
- UI goals and target player context.
|
|
15
|
+
- Screen/state map with interaction flow.
|
|
16
|
+
- Component-level guidance (layout, typography, spacing, feedback states).
|
|
17
|
+
- Implementation notes tied to code paths or UI primitives in the repo.
|
|
@@ -7,6 +7,7 @@ tools:
|
|
|
7
7
|
- web_crawler
|
|
8
8
|
- command_execute
|
|
9
9
|
model: openai:gpt-5-mini
|
|
10
|
+
mcpUseGlobal: true
|
|
10
11
|
promptRefinement: true
|
|
11
12
|
---
|
|
12
13
|
|
|
@@ -15,6 +16,7 @@ You are the primary Wingman agent. Handle a wide range of coding, research, and
|
|
|
15
16
|
Follow these principles:
|
|
16
17
|
- Be proactive about gathering context before making changes.
|
|
17
18
|
- Use the available tools when they add confidence or speed.
|
|
19
|
+
- For image/audio/video generation requests, prefer MCP FAL tools (for example `generate_image_or_texture`, `generate_image_edit`, `generate_audio_or_music`, `generate_video_from_image`) and use `fal_generation_status` for queue lifecycle actions.
|
|
18
20
|
- Keep responses concise, factual, and focused on completing the task.
|
|
19
21
|
- For repository-affecting requests, treat execution as required by default.
|
|
20
22
|
- On execution-required turns, either run at least one relevant tool action or return `blocked` with the exact attempted action and exact error.
|
package/README.md
CHANGED
|
@@ -253,6 +253,7 @@ wingman gateway start --discovery tailscale --name "Work Gateway"
|
|
|
253
253
|
- **Hooks** for pre/post tool automation.
|
|
254
254
|
- **Skills** for reusable, domain-specific instruction sets.
|
|
255
255
|
- **MCP tools** to connect external systems and custom integrations.
|
|
256
|
+
- **Bundled MCP servers** for finance (`bun run mcp:finance`) and FAL AI multimodal generation (`bun run mcp:fal-ai`).
|
|
256
257
|
|
|
257
258
|
## Development
|
|
258
259
|
|
|
@@ -83,12 +83,14 @@ export declare const AgentConfigSchema: z.ZodObject<{
|
|
|
83
83
|
servers: z.ZodOptional<z.ZodArray<z.ZodUnion<readonly [z.ZodObject<{
|
|
84
84
|
name: z.ZodString;
|
|
85
85
|
transport: z.ZodLiteral<"stdio">;
|
|
86
|
+
defaultToolTimeout: z.ZodOptional<z.ZodNumber>;
|
|
86
87
|
command: z.ZodString;
|
|
87
88
|
args: z.ZodOptional<z.ZodArray<z.ZodString>>;
|
|
88
89
|
env: z.ZodOptional<z.ZodRecord<z.ZodString, z.ZodString>>;
|
|
89
90
|
}, z.core.$strip>, z.ZodObject<{
|
|
90
91
|
name: z.ZodString;
|
|
91
92
|
transport: z.ZodLiteral<"sse">;
|
|
93
|
+
defaultToolTimeout: z.ZodOptional<z.ZodNumber>;
|
|
92
94
|
url: z.ZodString;
|
|
93
95
|
headers: z.ZodOptional<z.ZodRecord<z.ZodString, z.ZodString>>;
|
|
94
96
|
}, z.core.$strip>]>>>;
|
|
@@ -177,12 +179,14 @@ export declare const AgentConfigSchema: z.ZodObject<{
|
|
|
177
179
|
servers: z.ZodOptional<z.ZodArray<z.ZodUnion<readonly [z.ZodObject<{
|
|
178
180
|
name: z.ZodString;
|
|
179
181
|
transport: z.ZodLiteral<"stdio">;
|
|
182
|
+
defaultToolTimeout: z.ZodOptional<z.ZodNumber>;
|
|
180
183
|
command: z.ZodString;
|
|
181
184
|
args: z.ZodOptional<z.ZodArray<z.ZodString>>;
|
|
182
185
|
env: z.ZodOptional<z.ZodRecord<z.ZodString, z.ZodString>>;
|
|
183
186
|
}, z.core.$strip>, z.ZodObject<{
|
|
184
187
|
name: z.ZodString;
|
|
185
188
|
transport: z.ZodLiteral<"sse">;
|
|
189
|
+
defaultToolTimeout: z.ZodOptional<z.ZodNumber>;
|
|
186
190
|
url: z.ZodString;
|
|
187
191
|
headers: z.ZodOptional<z.ZodRecord<z.ZodString, z.ZodString>>;
|
|
188
192
|
}, z.core.$strip>]>>>;
|
|
@@ -26,8 +26,8 @@ __webpack_require__.r(__webpack_exports__);
|
|
|
26
26
|
__webpack_require__.d(__webpack_exports__, {
|
|
27
27
|
MCPClientManager: ()=>MCPClientManager
|
|
28
28
|
});
|
|
29
|
-
const mcp_adapters_namespaceObject = require("@langchain/mcp-adapters");
|
|
30
29
|
const tools_namespaceObject = require("@langchain/core/tools");
|
|
30
|
+
const mcp_adapters_namespaceObject = require("@langchain/mcp-adapters");
|
|
31
31
|
function _define_property(obj, key, value) {
|
|
32
32
|
if (key in obj) Object.defineProperty(obj, key, {
|
|
33
33
|
value: value,
|
|
@@ -45,26 +45,51 @@ class MCPClientManager {
|
|
|
45
45
|
return Array.from(serverMap.values());
|
|
46
46
|
}
|
|
47
47
|
buildClientConfig() {
|
|
48
|
-
const
|
|
48
|
+
const mcpServers = {};
|
|
49
49
|
for (const server of this.serverConfigs)if ("stdio" === server.transport) {
|
|
50
50
|
const stdioServer = server;
|
|
51
51
|
const resolvedEnv = {};
|
|
52
52
|
for (const [key, value] of Object.entries(stdioServer.env || {}))resolvedEnv[key] = resolveEnvValue(value);
|
|
53
|
-
|
|
53
|
+
const runtimeEnv = this.applyRuntimeEnv(resolvedEnv);
|
|
54
|
+
const defaultToolTimeout = getDefaultToolTimeout(stdioServer);
|
|
55
|
+
mcpServers[server.name] = {
|
|
54
56
|
transport: "stdio",
|
|
55
57
|
command: stdioServer.command,
|
|
56
58
|
args: stdioServer.args || [],
|
|
57
|
-
env:
|
|
59
|
+
env: runtimeEnv,
|
|
60
|
+
...void 0 !== defaultToolTimeout ? {
|
|
61
|
+
defaultToolTimeout
|
|
62
|
+
} : {}
|
|
58
63
|
};
|
|
59
64
|
} else if ("sse" === server.transport) {
|
|
60
65
|
const sseServer = server;
|
|
61
|
-
|
|
66
|
+
const defaultToolTimeout = getDefaultToolTimeout(sseServer);
|
|
67
|
+
mcpServers[server.name] = {
|
|
62
68
|
transport: "sse",
|
|
63
69
|
url: sseServer.url,
|
|
64
|
-
headers: sseServer.headers || {}
|
|
70
|
+
headers: sseServer.headers || {},
|
|
71
|
+
...void 0 !== defaultToolTimeout ? {
|
|
72
|
+
defaultToolTimeout
|
|
73
|
+
} : {}
|
|
65
74
|
};
|
|
66
75
|
}
|
|
67
|
-
return
|
|
76
|
+
return {
|
|
77
|
+
mcpServers,
|
|
78
|
+
useStandardContentBlocks: false,
|
|
79
|
+
outputHandling: {
|
|
80
|
+
image: "artifact",
|
|
81
|
+
audio: "artifact",
|
|
82
|
+
resource: "artifact"
|
|
83
|
+
}
|
|
84
|
+
};
|
|
85
|
+
}
|
|
86
|
+
applyRuntimeEnv(env) {
|
|
87
|
+
if (!this.executionWorkspace) return env;
|
|
88
|
+
const next = {
|
|
89
|
+
...env
|
|
90
|
+
};
|
|
91
|
+
next.WINGMAN_WORKDIR = this.executionWorkspace;
|
|
92
|
+
return next;
|
|
68
93
|
}
|
|
69
94
|
async initialize() {
|
|
70
95
|
if (0 === this.serverConfigs.length) return void this.logger.debug("No MCP servers configured");
|
|
@@ -117,7 +142,8 @@ class MCPClientManager {
|
|
|
117
142
|
if (sanitized === original) return tool;
|
|
118
143
|
const originalLabel = `Original tool name: ${original}`;
|
|
119
144
|
const description = tool.description ? `${tool.description}\n\n${originalLabel}` : originalLabel;
|
|
120
|
-
const
|
|
145
|
+
const toolWithSchema = tool;
|
|
146
|
+
const schema = toolWithSchema.schema ?? toolWithSchema.inputSchema;
|
|
121
147
|
if (!schema) try {
|
|
122
148
|
tool.name = sanitized;
|
|
123
149
|
tool.description = description;
|
|
@@ -128,7 +154,7 @@ class MCPClientManager {
|
|
|
128
154
|
return (0, tools_namespaceObject.tool)(async (input)=>tool.invoke(input), {
|
|
129
155
|
name: sanitized,
|
|
130
156
|
description,
|
|
131
|
-
schema
|
|
157
|
+
schema: schema
|
|
132
158
|
});
|
|
133
159
|
});
|
|
134
160
|
}
|
|
@@ -145,12 +171,14 @@ class MCPClientManager {
|
|
|
145
171
|
hasServers() {
|
|
146
172
|
return this.serverConfigs.length > 0;
|
|
147
173
|
}
|
|
148
|
-
constructor(configs, logger){
|
|
174
|
+
constructor(configs, logger, options){
|
|
149
175
|
_define_property(this, "client", null);
|
|
150
176
|
_define_property(this, "logger", void 0);
|
|
151
177
|
_define_property(this, "serverConfigs", void 0);
|
|
178
|
+
_define_property(this, "executionWorkspace", void 0);
|
|
152
179
|
this.logger = logger;
|
|
153
180
|
this.serverConfigs = this.mergeConfigs(configs);
|
|
181
|
+
this.executionWorkspace = options?.executionWorkspace?.trim() || null;
|
|
154
182
|
}
|
|
155
183
|
}
|
|
156
184
|
function resolveEnvValue(value) {
|
|
@@ -159,6 +187,12 @@ function resolveEnvValue(value) {
|
|
|
159
187
|
const envValue = process.env[match[1]];
|
|
160
188
|
return envValue ?? "";
|
|
161
189
|
}
|
|
190
|
+
function getDefaultToolTimeout(server) {
|
|
191
|
+
const candidate = server.defaultToolTimeout;
|
|
192
|
+
if ("number" != typeof candidate) return;
|
|
193
|
+
if (!Number.isFinite(candidate) || candidate <= 0) return;
|
|
194
|
+
return Math.floor(candidate);
|
|
195
|
+
}
|
|
162
196
|
exports.MCPClientManager = __webpack_exports__.MCPClientManager;
|
|
163
197
|
for(var __rspack_i in __webpack_exports__)if (-1 === [
|
|
164
198
|
"MCPClientManager"
|
|
@@ -1,6 +1,6 @@
|
|
|
1
1
|
import type { StructuredTool } from "@langchain/core/tools";
|
|
2
|
-
import type { MCPServersConfig } from "@/types/mcp.js";
|
|
3
2
|
import type { Logger } from "@/logger.js";
|
|
3
|
+
import type { MCPServersConfig } from "@/types/mcp.js";
|
|
4
4
|
/**
|
|
5
5
|
* Manages MCP server connections and tool retrieval
|
|
6
6
|
* Handles server lifecycle: initialization, tool loading, and cleanup
|
|
@@ -9,7 +9,10 @@ export declare class MCPClientManager {
|
|
|
9
9
|
private client;
|
|
10
10
|
private logger;
|
|
11
11
|
private serverConfigs;
|
|
12
|
-
|
|
12
|
+
private executionWorkspace;
|
|
13
|
+
constructor(configs: MCPServersConfig[], logger: Logger, options?: {
|
|
14
|
+
executionWorkspace?: string | null;
|
|
15
|
+
});
|
|
13
16
|
/**
|
|
14
17
|
* Merge multiple MCP configurations (global + agent-specific)
|
|
15
18
|
* Agent-specific servers override global ones with same name
|
|
@@ -19,6 +22,7 @@ export declare class MCPClientManager {
|
|
|
19
22
|
* Convert Wingman MCP config to MultiServerMCPClient format
|
|
20
23
|
*/
|
|
21
24
|
private buildClientConfig;
|
|
25
|
+
private applyRuntimeEnv;
|
|
22
26
|
/**
|
|
23
27
|
* Initialize MCP client and connect to servers
|
|
24
28
|
*/
|
|
@@ -1,5 +1,5 @@
|
|
|
1
|
-
import { MultiServerMCPClient } from "@langchain/mcp-adapters";
|
|
2
1
|
import { tool as tools_tool } from "@langchain/core/tools";
|
|
2
|
+
import { MultiServerMCPClient } from "@langchain/mcp-adapters";
|
|
3
3
|
function _define_property(obj, key, value) {
|
|
4
4
|
if (key in obj) Object.defineProperty(obj, key, {
|
|
5
5
|
value: value,
|
|
@@ -17,26 +17,51 @@ class MCPClientManager {
|
|
|
17
17
|
return Array.from(serverMap.values());
|
|
18
18
|
}
|
|
19
19
|
buildClientConfig() {
|
|
20
|
-
const
|
|
20
|
+
const mcpServers = {};
|
|
21
21
|
for (const server of this.serverConfigs)if ("stdio" === server.transport) {
|
|
22
22
|
const stdioServer = server;
|
|
23
23
|
const resolvedEnv = {};
|
|
24
24
|
for (const [key, value] of Object.entries(stdioServer.env || {}))resolvedEnv[key] = resolveEnvValue(value);
|
|
25
|
-
|
|
25
|
+
const runtimeEnv = this.applyRuntimeEnv(resolvedEnv);
|
|
26
|
+
const defaultToolTimeout = getDefaultToolTimeout(stdioServer);
|
|
27
|
+
mcpServers[server.name] = {
|
|
26
28
|
transport: "stdio",
|
|
27
29
|
command: stdioServer.command,
|
|
28
30
|
args: stdioServer.args || [],
|
|
29
|
-
env:
|
|
31
|
+
env: runtimeEnv,
|
|
32
|
+
...void 0 !== defaultToolTimeout ? {
|
|
33
|
+
defaultToolTimeout
|
|
34
|
+
} : {}
|
|
30
35
|
};
|
|
31
36
|
} else if ("sse" === server.transport) {
|
|
32
37
|
const sseServer = server;
|
|
33
|
-
|
|
38
|
+
const defaultToolTimeout = getDefaultToolTimeout(sseServer);
|
|
39
|
+
mcpServers[server.name] = {
|
|
34
40
|
transport: "sse",
|
|
35
41
|
url: sseServer.url,
|
|
36
|
-
headers: sseServer.headers || {}
|
|
42
|
+
headers: sseServer.headers || {},
|
|
43
|
+
...void 0 !== defaultToolTimeout ? {
|
|
44
|
+
defaultToolTimeout
|
|
45
|
+
} : {}
|
|
37
46
|
};
|
|
38
47
|
}
|
|
39
|
-
return
|
|
48
|
+
return {
|
|
49
|
+
mcpServers,
|
|
50
|
+
useStandardContentBlocks: false,
|
|
51
|
+
outputHandling: {
|
|
52
|
+
image: "artifact",
|
|
53
|
+
audio: "artifact",
|
|
54
|
+
resource: "artifact"
|
|
55
|
+
}
|
|
56
|
+
};
|
|
57
|
+
}
|
|
58
|
+
applyRuntimeEnv(env) {
|
|
59
|
+
if (!this.executionWorkspace) return env;
|
|
60
|
+
const next = {
|
|
61
|
+
...env
|
|
62
|
+
};
|
|
63
|
+
next.WINGMAN_WORKDIR = this.executionWorkspace;
|
|
64
|
+
return next;
|
|
40
65
|
}
|
|
41
66
|
async initialize() {
|
|
42
67
|
if (0 === this.serverConfigs.length) return void this.logger.debug("No MCP servers configured");
|
|
@@ -89,7 +114,8 @@ class MCPClientManager {
|
|
|
89
114
|
if (sanitized === original) return tool;
|
|
90
115
|
const originalLabel = `Original tool name: ${original}`;
|
|
91
116
|
const description = tool.description ? `${tool.description}\n\n${originalLabel}` : originalLabel;
|
|
92
|
-
const
|
|
117
|
+
const toolWithSchema = tool;
|
|
118
|
+
const schema = toolWithSchema.schema ?? toolWithSchema.inputSchema;
|
|
93
119
|
if (!schema) try {
|
|
94
120
|
tool.name = sanitized;
|
|
95
121
|
tool.description = description;
|
|
@@ -100,7 +126,7 @@ class MCPClientManager {
|
|
|
100
126
|
return tools_tool(async (input)=>tool.invoke(input), {
|
|
101
127
|
name: sanitized,
|
|
102
128
|
description,
|
|
103
|
-
schema
|
|
129
|
+
schema: schema
|
|
104
130
|
});
|
|
105
131
|
});
|
|
106
132
|
}
|
|
@@ -117,12 +143,14 @@ class MCPClientManager {
|
|
|
117
143
|
hasServers() {
|
|
118
144
|
return this.serverConfigs.length > 0;
|
|
119
145
|
}
|
|
120
|
-
constructor(configs, logger){
|
|
146
|
+
constructor(configs, logger, options){
|
|
121
147
|
_define_property(this, "client", null);
|
|
122
148
|
_define_property(this, "logger", void 0);
|
|
123
149
|
_define_property(this, "serverConfigs", void 0);
|
|
150
|
+
_define_property(this, "executionWorkspace", void 0);
|
|
124
151
|
this.logger = logger;
|
|
125
152
|
this.serverConfigs = this.mergeConfigs(configs);
|
|
153
|
+
this.executionWorkspace = options?.executionWorkspace?.trim() || null;
|
|
126
154
|
}
|
|
127
155
|
}
|
|
128
156
|
function resolveEnvValue(value) {
|
|
@@ -131,4 +159,10 @@ function resolveEnvValue(value) {
|
|
|
131
159
|
const envValue = process.env[match[1]];
|
|
132
160
|
return envValue ?? "";
|
|
133
161
|
}
|
|
162
|
+
function getDefaultToolTimeout(server) {
|
|
163
|
+
const candidate = server.defaultToolTimeout;
|
|
164
|
+
if ("number" != typeof candidate) return;
|
|
165
|
+
if (!Number.isFinite(candidate) || candidate <= 0) return;
|
|
166
|
+
return Math.floor(candidate);
|
|
167
|
+
}
|
|
134
168
|
export { MCPClientManager };
|
|
@@ -102,7 +102,9 @@ async function createTools(toolNames, options = {}) {
|
|
|
102
102
|
else logger.warn(`Skipping unknown tool: ${name}`);
|
|
103
103
|
}
|
|
104
104
|
if (options.mcpConfigs && options.mcpConfigs.length > 0) try {
|
|
105
|
-
const mcpManager = new external_mcpClientManager_cjs_namespaceObject.MCPClientManager(options.mcpConfigs, logger
|
|
105
|
+
const mcpManager = new external_mcpClientManager_cjs_namespaceObject.MCPClientManager(options.mcpConfigs, logger, {
|
|
106
|
+
executionWorkspace: options.executionWorkspace || options.workspace || null
|
|
107
|
+
});
|
|
106
108
|
await mcpManager.initialize();
|
|
107
109
|
const mcpTools = await mcpManager.getTools();
|
|
108
110
|
if (mcpTools.length > 0) {
|
|
@@ -71,7 +71,9 @@ async function createTools(toolNames, options = {}) {
|
|
|
71
71
|
else logger.warn(`Skipping unknown tool: ${name}`);
|
|
72
72
|
}
|
|
73
73
|
if (options.mcpConfigs && options.mcpConfigs.length > 0) try {
|
|
74
|
-
const mcpManager = new MCPClientManager(options.mcpConfigs, logger
|
|
74
|
+
const mcpManager = new MCPClientManager(options.mcpConfigs, logger, {
|
|
75
|
+
executionWorkspace: options.executionWorkspace || options.workspace || null
|
|
76
|
+
});
|
|
75
77
|
await mcpManager.initialize();
|
|
76
78
|
const mcpTools = await mcpManager.getTools();
|
|
77
79
|
if (mcpTools.length > 0) {
|