@everyone 🧵**Quick Survey — please answer on a scale of 1–5** 1 = Never / Not useful · 5 = Strong yes / Very useful 1. What is your preferred way for creating specs and tickets: a. From Traycer's IDE extension b. From Traycer's Web-based form factor 2. What would be your preferred way to handoff work from Traycer to your coding agents: a. 1-click handoff from IDE via Traycer's extension b. Configure Traycer's CLI using skills in your coding agent. Ask your agent to work on the Epic/Tickets assigned to you c. Configure Traycer's MCP in your coding agent. Ask your agent to work on the Epic/Tickets assigned to you d. Use Traycer's built-in smart YOLO orchestrator to handoff work to your agent as Traycer verifies the work done by agents 3. Integration with existing tools: a. For Specs: 2-way sync with tools such as Notion, Google Docs, Confluence b. For Tickets: 2-way sync with tools such as Linear, Jira, GitHub Issues 4. Traycer will remember key details about your product and your working style through persistent Memories (already on the roadmap) 5. What else do you expect Traycer's Epic mode to do for you?

1. IDE 2. One click handoff 3. B 4. 5

### 1. Preferred way for creating specs and tickets → (a) IDE Extension We live in VS Code. Context switching to browser breaks flow. The extension already delivers epics/tickets right where we work — keep it there. But web is good too, manager from another machine. ### 2. Preferred way to handoff work to coding agents → (c) MCP Server The ideal flow: Traycer exposes an MCP with tools that coding agents can call directly: -

list_epic_tickets(epicId)

→ returns tickets with status -

get_ticket(ticketId)

→ full details, specs, acceptance criteria -

update_ticket_status(ticketId, status)

→ todo / inprogress / inreview / done -

add_ticket_comment(ticketId, comment)

→ implementation reports, review notes This way the agent reads tickets, works on them, and updates status directly in Traycer — no intermediate tools, no duplication. Traycer becomes the single source of truth. Option (d) is also compelling for teams that want fully autonomous execution, but for our workflow we prefer the agent orchestrating its own subagents while Traycer tracks state. ### 3. Integration with existing tools → (b) For Tickets: 2-way sync with GitHub Issues We already use GitHub for repos. Syncing tickets to GitHub Issues would feel natural and integrate with existing PR/commit workflows. For Specs: we work primarily in markdown. If Traycer exposes specs via MCP, that's sufficient — no need for Notion/Confluence sync in our case. ### 4. What else should Epic mode do? Based on real pain points from our workflow: 1. MCP as the primary interface — Let agents read/update tickets via API instead of filesystem paths in tmp. Less fragile, more portable. 2. Spec injection on demand — Instead of reading spec files from disk, the agent should be able to pull spec content via MCP when needed. Cleaner, works across machines.

As a solo developer: 1. a:5, b:1. I only use the Traycer extension in Cursor. I wasn't aware you could use the web, I don't know why I would want to. 2. a:5, b:2, c:2. I only ever used the Traycer extension's handoff button, I haven't tried the other methods and don't know what the tradeoffs would be. 3. a:1, b:1. I don't use any other tool for specs or tickets. I do use Trello as a kanban board to track tasks sized from simple bugs to epics. 4. As long as I can see and edit the memories: 3. So far I've used an explicit repository (agents.md, architeture.md, etc) that can be shared with other agents. 5. Haven't used Epic mode enough to have a strong opinion, but I'm really liking it. Strong 5! 🙂

1. a:5, b:1 didn't know you could use the web tbh 2. a:4, b:5 we have a lot of skills / agents that help keep standards across the team and models, c:3 I could see value in this to further break down tickets and keep the same context between chats d:2 we still keep the humans in the loop so YOLO is rarely used. 3. a:5 We have stopped making tickets in the traditional sense where all information and story and all that jazz is in the ticket and instead have migrated to just planning the placeholders to show the timeline of work and we utilize notion for all the information on the feature / linked meeting summaries / etc. b:4 Although not super useful for me personally I know others would probably value this. 4. This is huge. I have varying success with all the agents/rules/etc markdown files and whether it gets listened to so having more explicit memories that help guide these things would be great. 5. I think the UX mockups that it generates are great but I noticed that sometimes a lot of the questions are focused on architecture / implementation and rarely am I prompted about how I want the UX to be and it feels late in the process to begin chatting about the way it looks

Ah this should be a clickable poll IMHO. Would place a lower barrier to answer

You can vote in the clickable poll in [this thread](https://discord.com/channels/1230383226376163328/1469449674342531274)

Awesome!! 👌