heyhey - Home

Showing 25 of 58 from the live probe.

• Unified Search

  Search across content types (tasks, design docs, plans, and messages) in a project. Returns ranked results with relevance scores and text snippets for context. Provide EITHER `query` (a single search, returning a flat { results, total, hasMore }) OR `queries` (a batch of up to 5 searches run in one call, returning { groups } — one ordered group per input query so you can correlate results back to the query that produced them). Exactly one of `query`/`queries` is required. Use `queries` to fan ou

• Task Search

  Search for tasks within a project with optional filtering by status, priority, and initiative. Returns tasks ranked by relevance with content snippets.

• Search Features

  Search for FEATURE-type tasks within a project. Pre-filters to features only — callers never need to specify task type. Supports optional filtering by status, priority, and initiative. Returns features ranked by relevance with content snippets.

• Search Goals

  Search for GOAL-type tasks within a project. Pre-filters to goals only — callers never need to specify task type. Supports optional filtering by status, priority, and initiative. Returns goals ranked by relevance with content snippets.

• Plan Search

  Search for plans within a project with optional filtering by status and owner. Returns plans ranked by relevance with content snippets and plan metadata.

• Search Design Docs

  Search for design documents (ADRs, decisions, brainstorms, plan documents) within a project. Supports filtering by template type, lifecycle status, and tags. Returns documents ranked by relevance with content excerpts.

• Create Work Item

  Propose a CREATE proposal for a work item of any type (STANDARD, FEATURE, GOAL, BUG, CONTRACT, workflow, workflow_step, TASK_MONITOR, or project-defined custom types). Per-type rules — allowed sections, required fields, parentage, the feature-only tag, and workflow-only graph payloads — are enforced from the central work-item type config. See get_tool_guidance({ toolName: "create_work_item", workItemType }) for the authoring conventions of the type you are creating.

• Edit Work Item

  Propose an UPDATE proposal for a work item of any type. The target's type is resolved server-side and that type's update rules — allowed sections, settable fields — are applied from the central work-item type config. See get_tool_guidance({ toolName: "edit_work_item", workItemType }) for the authoring conventions.

• Edit Tasks

  Propose a batch of UPDATE proposals for tasks. See get_tool_guidance({ toolName: "edit_work_item" }) for the authoring conventions — the per-task discipline applies to every edit in the batch.

• Create Design Doc

  Propose a CREATE proposal for a BRAINSTORM design document. See get_tool_guidance({ toolName: "create_design_doc" }) for the authoring conventions.

• Edit Design Doc

  Propose an UPDATE proposal for a design document. See get_tool_guidance({ toolName: "edit_design_doc" }) for the authoring conventions.

• Update Proposal

  Update an existing proposal record. Use this to modify the proposed changes (updates), influences, or version metadata of a proposal that is still in DRAFT state. Cannot update proposals that have already been APPROVED or REJECTED.

• Get Proposal

  Fetch the current state of a proposal by ID. Returns status, action, targetEntityType, targetEntityId, conversationId, and timestamps. Use this to resolve a local handle (e.g. the stage or step UUID returned by create_stage / create_step) to the real materialized entity ID once the proposal has been APPROVED — the proposal's targetEntityId is rewritten at enactment time to match the entity actually created. Works for DRAFT, APPROVED, and REJECTED proposals.

• Start Proposal Group

  Start one explicit hidden BUILDING proposal group. Returns the stable group identity and persisted empty authoring snapshot. For the first grouped mutation, pass the returned currentRevision as groupContext.expectedRevision. Membership is never inferred.

• Get Proposal Group Authoring Snapshot

  Read the persisted BUILDING authoring snapshot for one explicitly identified proposal group. Call this after drafting and dependency changes and immediately before finalization, then pass its currentRevision as groupContext.expectedRevision.

• Replace Proposal Group Prerequisites

  Replace one member's complete all-of prerequisite set. Pass the latest snapshot currentRevision as groupContext.expectedRevision; prerequisites must be members of that same group.

• Remove Proposal Group Member

  Remove one persisted member from an explicitly identified BUILDING group. Pass the latest snapshot currentRevision as groupContext.expectedRevision.

• Finalize Proposal Group

  Validate and atomically freeze the explicitly identified persisted BUILDING revision for review. Pass the immediately preceding authoring snapshot currentRevision as groupContext.expectedRevision. Validation failures return every field-addressable issue and leave the group hidden and mutable.

• Create Work Item Type

  Propose a new custom work-item type for user review. Before authoring the definition, call get_tool_guidance({ toolName: "create_work_item_type" }) for the canonical review questionnaire and complete configuration contract. Creation requires one completed review of every question.

• Edit Work Item Type

  After calling get_work_item_type, propose a bounded edit to an active project-owned work-item type (CANONICAL_OVERRIDE or PROJECT_CUSTOM). Submit the complete definition and preserve every unchanged definition axis for user review. For a canonical-seeded type, approval creates or updates a complete project override over the immutable global canonical definition; it does not mutate the global seed. List work-item type keys such as STANDARD in allowedParentTypes. When this list is non-empty, TASK

• Get Work Item Type

  Read the complete project-effective work-item type summary before editing it. Use the returned definition as the base for a read-modify-submit edit.

• Search Implementation Hints

  Search implementation hints for the active coding session's service. Returns hints ranked by semantic relevance, scoped to the session's project and service context (derived from request headers, not tool parameters).

• Create Implementation Hint

  Create a new implementation hint for the active service. Use at the end of an implementation session to record patterns, conventions, or guidance discovered while working on a feature. Service is resolved from the X-Service-ID request header; agent session from X-Agent-Session-ID.

• Edit Implementation Hint

  Update an existing implementation hint. Use to refine guidance discovered in a prior session, correct outdated details, or update the confidence score. Service is resolved from the X-Service-ID request header.

• Delete Implementation Hint

  Delete an implementation hint. Use when the code or feature the hint describes no longer exists, to keep the hint index clean and accurate.