Simplify games list output to show only game IDs for AI-friendly parsing

[Copilot]

Problem

The gabs games list command was producing verbose, confusing output that made it difficult for AI agents to parse and identify available games:

2025-09-14T13:17:52.763+0200	INFO	util/log.go:57	starting gabs	{"version": "0.1.0", "commit": "unknown", "built": "unknown", "subcmd": "games"}
Configured Games (1):
  rimworld - rimworld (SteamAppId via 294100)

When an AI tried to discover if a game like "rimworld" exists, this verbose format caused confusion with multiple identifiers (game name, Steam App ID, launch mode details) and unnecessary logging noise.

Solution

Simplified the output to show only game IDs, one per line:

rimworld
minecraft

This format is:

• Easy to parse: Clean list of identifiers
• Noise-free: No startup logs or verbose details
• Ready to use: Game IDs work directly in commands like rimworld.cmd_here

Changes Made

CLI Command (cmd/gabs/main.go)

• Modified listGames() to output only game IDs
• Suppressed startup logging specifically for games list to keep output clean
• Updated help text to clarify the simplified behavior

MCP Tool (internal/mcp/stdio_server.go)

• Updated games.list tool to return simplified output for AI consumption
• Changed tool description to reflect new behavior

Tests

• Updated TestCurrentGameCommandBehavior/GamesList to verify simplified output
• Updated TestGameStopFix/GamesListIsSimplified to ensure no verbose details
• All tests now pass with new expectations

Backward Compatibility

For users who need detailed game information, it's still available via:

• gabs games show <id> - Full configuration details
• games.status <id> - Runtime status and limitations

Other games subcommands retain their normal logging and verbose output for debugging purposes.

Impact

This change directly addresses the core issue: AI agents can now easily discover and use game identifiers without getting confused by extraneous information. The command now serves its primary purpose of listing available games in the simplest possible format.

---

✨ Let Copilot coding agent set things up for you — coding agent works faster and does higher quality work when set up for your repo.

[pardeike]

@copilot Here comes an open question, not a suggestion. Do you think 'id' is a good term for 'game id'? How about 'handle' or some other term? Discuss different aspects of this and focus on reducing user/AI confusion.

[Copilot]

@copilot Here comes an open question, not a suggestion. Do you think 'id' is a good term for 'game id'? How about 'handle' or some other term? Discuss different aspects of this and focus on reducing u...

Looking at the terminology question from different angles:

"ID" (current) vs alternatives:

Pros of "ID":

• Familiar to developers (database IDs, API identifiers)
• Clear technical meaning: unique identifier
• Already consistent throughout codebase (gameId, game.ID, config "id" field)
• Standard in JSON APIs and configuration files

"Handle" alternative:

• More user-friendly, less technical sounding
• Common in social platforms (@username handles)
• Suggests something you "grab onto" to interact with
• Less database-centric terminology

"Key" alternative:

• Clear mapping concept (key → configuration)
• Familiar from key-value stores
• Short and simple
• But might confuse with security keys/tokens

From AI confusion perspective:
The issue wasn't really the term itself - it was the verbose output mixing IDs with launch details. The simplified output (just "rimworld", "minecraft") works well with any terminology.

Recommendation:
I lean toward keeping "ID" because:

1. Zero migration needed (consistent throughout codebase)
2. Clear to both humans and AI agents
3. Standard in APIs and configuration systems
4. The real issue (verbose output) is now fixed

The simplified format makes the identifier instantly usable regardless of what we call it. Thoughts on this analysis?