create-issue-interaction-ui

Topics in the source

• Create a new issue-thread interaction UI (Developer/maintainer skill)
• When to use
• When NOT to use
• Mental model
• The canonical worked example
• Order of operations
• 1. Shared contract (smallest, lands first)
• 2. Server service and routes

Developer/maintainer skill. Do NOT install this on production Paperclip agents. This skill walks a Paperclip contributor through introducing a new issue-thread interaction kind from shared contract to issue-detail wiring, helpers, and docs. It is intentionally a developer/maintainer skill: the audience is a human or coding agent making code changes inside paperclipai/paperclip, not the operational agents that run inside a deployed Paperclip company. Do NOT install this on production Paperclip agents. This guide is for repository contributors changing Paperclip itself. A new interaction kind is being introduced (compact picker, structured rating, in-thread approval card, etc.). An existing interaction needs a parallel variant with a distinct payload shape, validation, or resolution outcome (and askuserquestions is the wrong fit because option count, target binding, or result shape differs). A reviewer asks for "the same audit, staleness, supersede, and continuation semantics as the other interactions" on a new card. Adding fields to an existing interaction kind that does not need a new payload schema. Patch the existing validators/UI in place instead. Changing how Paperclip agents c

This is an excerpt. Refer to the complete source and its current requirements.