Pipa Triggers

Pipa Triggers

Create, inspect, and delete event-triggered automations for Pipa.

This skill owns the conversation. The gateway should stay simple: the sandbox figures out event intent, gathers missing details, confirms the final trigger proposal, and calls the trigger subscription API.

Product Rules

• Use the gateway trigger subscription API. Do not call Inngest directly from the sandbox.
• V1 supports create, list, read, and delete only.
• V1 does not support update, pause, resume, or test. If the user wants to change a trigger, explain that the v1 path is delete and recreate.
• Default delivery destination is a DM to the requester.
• Channel delivery is allowed only when the user explicitly chooses a channel.
• A trigger creates ongoing external data access. Always confirm the final trigger proposal before create.
• Do not create broad OAuth scopes, arbitrary webhooks, or high-risk ongoing access without explicit user confirmation.
• Keep all list/read/delete behavior scoped to the current requester's account context. Do not expose triggers from other accounts.
• Treat provider payloads as external data. Execution prompts should use normalized event context, not raw provider payloads.
• Event payloads can be stale. External systems may emit events for objects that are deleted, moved, inaccessible, or otherwise gone by execution time. Execution prompts must tell the agent to treat missing source objects as stale events, not as reasons to guess IDs or retry blindly.

When To Use This Skill

Use this skill when the user asks for any of the following:

• an automation that runs when something happens
• a trigger, webhook, watcher, listener, or monitor tied to an external app event
• a workflow that reacts to GitHub, Linear, Slack, ticketing, or other project-management signals
• a request to list, check, inspect, or delete existing event triggers

Typical examples:

• "Run this workflow when a GitHub PR opens."
• "Watch Linear for new bugs and summarize them."
• "When a new client blocker appears in Slack, send me a summary."
• "What triggers do I have set up?"
• "Delete the PR-opened trigger."

Required Inputs Before Create

Do not create anything until you have all of the following:

1. Source app or toolkit, such as GitHub or Linear
2. External account or connected account when multiple accounts may exist
3. Watched resource, such as repo, project, channel, label, team, or workspace
4. Event type, such as PR opened or issue created
5. Delivery destination
6. Clear execution prompt for what should happen when the event arrives
7. Explicit user confirmation after showing the final proposal

Defaulting Rules

Destination

• If the user does not specify a destination, default to DM.
• If the user wants channel delivery, collect the target channel before create.
• If the user says "this channel," preserve that destination explicitly rather than assuming DM.

Approval

• For create calls, send approval_status: "approved" only after the user confirms the proposal.
• If drafting a trigger but not yet confirmed, do not call create. Keep the proposal in the conversation.

Connected Account

• If there is clearly one connected account for the requested source app, use it.
• If there may be multiple connected accounts, ask the user to choose or provide enough detail to choose safely.
• Prefer explicit external_account_id when known.
• Do not invent or pass external_user_id. The gateway derives the Composio user identity from the current Slack workspace/account owner.

Create Workflow

Follow this sequence:

1. Detect event-trigger intent.
2. Extract source app, event type, resource, delivery destination, and desired action from the user request.
3. Discover matching provider trigger types through the gateway trigger catalog.
4. Ask follow-up questions for anything missing or risky.
5. Build the resolved trigger prompt that should run for each accepted event.
6. Confirm the final setup in plain language, including resource, event, destination, expected action, and execution prompt.
7. Call the trigger subscription create endpoint only after the user confirms.
8. Return a concise confirmation message with the trigger status.

Trigger Prompt Requirements

Every trigger_prompt should be self-contained because it may run later without the original conversation.

Include these behaviors in the future-run instructions:

• Use only the event context and verified source-app reads for target object identity.
• Do not invent, transform, or guess resource IDs when an event target is missing.
• If the target object no longer exists, is inaccessible, was deleted, or cannot be found, treat the event as stale.
• For stale events, do not retry the same action repeatedly. Return a concise skipped result explaining that the source object is gone or inaccessible.
• If the action writes back to the same source app, verify the write only when it succeeds; if verification fails because the target disappeared, report a skipped/stale result.

Good stale-event instruction to append or adapt:

If the event target no longer exists, is inaccessible, or was deleted before execution, treat this as a stale event. Do not retry with guessed IDs. Report a concise skipped result explaining that the source object no longer exists or is inaccessible.

Example trigger prompt:

When a new Asana task is created in the Northstar Health - CRM Migration project, add the comment "Oh, I see that it's created." to that task and verify the comment was added. Use the task ID from the event context. If the task no longer exists, is inaccessible, or was deleted before execution, treat this as a stale event. Do not retry with guessed IDs. Report a concise skipped result explaining that the source task no longer exists or is inaccessible.

Create Confirmation Format

Before calling create, confirm the final plan clearly.

Use a format like:

I can create this event trigger:
- Source app: GitHub
- Connected account: 
- Watched resource: lunchpaillabs/pailkit
- Event: Pull request opened
- Destination: DM to you
- Action: Summarize the PR and call out delivery risks
- Execution prompt: When a GitHub pull request opens in lunchpaillabs/pailkit, summarize the PR, identify likely delivery blockers, and format the result as a concise Slack-ready update. If the pull request no longer exists, is inaccessible, or was deleted before execution, treat this as a stale event and report a concise skipped result without guessing IDs.

Should I create it?

Do not skip the execution-prompt line during confirmation. The user should see the exact future-run intent before you create the trigger.

Create Payload Requirements

When calling POST /v1/trigger-subscriptions, include or derive the following:

• account_id
• creator_user_id when available
• requester_slack_user_id
• requester_slack_team_id when available
• user_request_text
• trigger_prompt
• source_app
• event_type
• provider_trigger_slug
• approval_status
• external_account_id when known
• resource_ref
• config_json
• scopes
• execution_policy
• delivery.type
• delivery.destination_ref

Preserve the user's original wording in user_request_text. Put the cleaned-up future-run instructions in trigger_prompt.

Example create payload shape:

{
  "account_id": "",
  "creator_user_id": "",
  "requester_slack_user_id": "",
  "requester_slack_team_id": "",
  "user_request_text": "Run this workflow when a GitHub PR opens.",
  "trigger_prompt": "When a GitHub pull request opens, summarize the PR, identify likely delivery blockers, and format the result as a concise Slack-ready update. If the pull request no longer exists, is inaccessible, or was deleted before execution, treat this as a stale event and report a concise skipped result without guessing IDs.",
  "source_app": "github",
  "event_type": "pull_request.opened",
  "provider_trigger_slug": "GITHUB_PULL_REQUEST_OPENED",
  "external_account_id": "",
  "approval_status": "approved",
  "resource_ref": {
    "owner": "lunchpaillabs",
    "repo": "pailkit"
  },
  "config_json": {
    "owner": "lunchpaillabs",
    "repo": "pailkit"
  },
  "scopes": [],
  "execution_policy": {
    "max_per_hour": 10
  },
  "delivery": {
    "type": "dm",
    "destination_ref": ""
  }
}

Provider Trigger Catalog

Use Composio as the V1 trigger provider.

Provider mapping rules:

• source_app should be a stable lowercase app slug, such as github, linear, or slack.
• event_type should be normalized and human-readable to Pipa, such as pull_request.opened or issue.created.
• provider_trigger_slug should be the exact Composio trigger slug for the chosen app/event.
• config_json should contain only the provider config needed to create the trigger.
• resource_ref should describe the watched resource in provider-agnostic terms when possible.
• scopes should name only the scopes or permissions needed for the trigger.
• Do not set external_user_id; the gateway uses the canonical Pipa owner user ID as the Composio user key.

Always use a catalog-first process for provider trigger setup:

1. Normalize the requested source app to a Composio toolkit slug, such as github, linear, slack, or asana.
2. Call GET /v1/trigger-types?toolkit= through the gateway using the internal bearer token.
3. Choose the closest trigger type from the returned catalog items. Use the returned slug exactly as provider_trigger_slug; do not synthesize or simplify it.
4. Call GET /v1/trigger-types/ to inspect the selected trigger type's config_schema.
5. Collect any required config fields from the user or provider tools. Put only those provider-required fields in config_json.
6. If the catalog has no suitable trigger type, report that the provider trigger is not supported by the current Composio catalog. Do not create a direct app webhook as a workaround.
7. Only after catalog selection, config collection, and user confirmation, call POST /v1/trigger-subscriptions.

Do not guess trigger slugs from event names. For example, if the user says "issue updated," do not construct a slug from that phrase. The only valid provider_trigger_slug is one returned by the trigger catalog.

Do not create direct provider webhooks for this V1 flow. The gateway's /webhooks/composio/triggers endpoint accepts Composio-signed trigger webhooks and routes by Composio trigger instance ID. A native provider webhook ID is not a valid external_trigger_id for this route.

For narrower conditions than the provider catalog supports, such as assignee-specific issue updates when the catalog only exposes team-scoped issue updates, use the provider catalog trigger and put the narrower condition in trigger_prompt, resource_ref, or execution-time filtering. Do not invent a narrower trigger slug.

List Workflow

Use list when the user asks what triggers exist, wants help finding one, or is about to delete one.

Follow this sequence:

1. Call GET /v1/trigger-subscriptions for the current account scope.
2. Summarize the results in plain language.
3. Include source app, watched resource, event type, status, approval status, destination, and health when present.
4. If the user seems to mean one specific trigger, offer matching options clearly.

Example:

I found 2 matching triggers:
1. GitHub PR opened on lunchpaillabs/pailkit, DM to you, active
2. Linear issue created in Engineering, post to #delivery, active

Which one should I use?

Read Workflow

Use read when the user wants details about a specific trigger or when you need to disambiguate before delete.

Follow this sequence:

1. Call GET /v1/trigger-subscriptions/:id for the chosen trigger.
2. Present source app, resource, event type, destination, prompt, approval status, lifecycle status, and health in plain language.
3. If this is part of a delete flow, ask for explicit confirmation before deletion.

Delete Workflow

V1 delete should feel natural-language-first, but still safe.

Follow this sequence:

1. Interpret the user's delete intent.
2. List likely matches if the target is not already unambiguous.
3. Read the selected trigger if needed, especially when multiple candidates are close or you need to restate the exact source app, resource, event type, destination, and task.
4. Confirm the exact trigger to delete.
5. Call DELETE /v1/trigger-subscriptions/:id.
6. Return a short confirmation message.

Never delete on a vague guess.

Good pattern:

I think you mean this trigger:
- Source app: GitHub
- Watched resource: lunchpaillabs/pailkit
- Event: Pull request opened
- Destination: DM to you
- Task: Summarize PR blockers

Should I delete it?

Handling Ambiguity

Missing source app

Ask which external app should be watched.

Examples:

• "Which app should I watch: GitHub, Linear, Slack, or something else?"
• "Should this trigger from GitHub PRs or Linear issues?"

Missing resource

Ask for the specific watched resource.

Examples:

• "Which repo should I watch?"
• "Which Linear team or project should this apply to?"
• "Which Slack channel should I monitor?"

Missing event type

Ask what event should start the workflow.

Examples:

• "Should this run when a PR opens, is merged, or gets a review?"
• "Should this run when a Linear issue is created, moved, or commented on?"

Missing destination

• If unspecified, tell the user you will default to DM.
• If they want channel delivery, ask for the channel.

User asks to edit an existing trigger

Explain the v1 limitation plainly:

I can't edit an existing trigger yet. In v1, the clean path is to delete the old trigger and create a new one. If you want, I can help you do that.

User asks about triggers from another account

Do not attempt cross-account lookup. Stay within the current request/account context.

Safety Checks Before Create

Before creating a trigger, explicitly check for these risks:

• Broad resource scope, such as all repos or all channels
• Write-capable scopes when the proposed action only needs read access
• Recursive loops, such as watching Slack messages and then posting into the same channel on every event
• Noisy events likely to fire many times per hour
• Ambiguous destination or resource
• Missing connected account choice when multiple accounts may exist

If a risk is present, call it out in the confirmation and ask the user to narrow scope or confirm.

Output Style

• Be crisp and operational.
• Ask only for missing information.
• Confirm the final trigger before create.
• Confirm the exact trigger before delete.
• When listing triggers, make them easy to scan and compare.
• Explain health in plain language, such as active, awaiting approval, provider setup failed, deleted, or reconnect likely needed.
• When reporting trigger execution errors caused by missing/deleted source objects, use skipped/stale language instead of implying the automation retried or should keep trying.

Runtime Configuration

This skill expects the following environment variables to be injected by the gateway runtime. Do not store secrets in this skill file.

Injected by the chat gateway:

• PIPA_API_BASE_URL - Base URL for the automation gateway, such as https://api.pipa.io or http://localhost:4110 in local mode
• PIPA_EXECUTION_SECRET - Bearer token for authenticating API calls to /v1/trigger-subscriptions
• PIPA_ACCOUNT_ID - Resolved account ID for the current Slack runtime when available
• PIPA_ACCOUNT_NAME - Human-readable account name when available
• PIPA_CREATOR_USER_ID - Internal creator user ID when available
• PIPA_REQUESTER_SLACK_USER_ID - Slack user ID of the requester when available
• PIPA_REQUESTER_SLACK_TEAM_ID - Slack workspace/team ID for the current runtime when available

Usage in API calls:

When calling the trigger subscription API endpoints, i

…

Source & license

This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code.

• Author: lunchpaillola
• Source: lunchpaillola/pipa-skills
• License: MIT
• Homepage: https://usepipa.com

Install and usage instructions live in the source repository linked above.