Feature: Create API Endpoint for Slack Bot Prompt Submissions

[sirkitree]

Goal:

Implement a secure API endpoint to accept prompt submissions originating from the Lullabot Slack bot via the /add-prompt command, as outlined in Lullabot/lullabot-slackbot#71.

Requirements:

1. Endpoint:
   • Route: Define a suitable route (e.g., /api/submit-prompt).
   • Method: Accept POST requests.
   • Authentication: Require an Authorization: Bearer <SHARED_SECRET> header. The SHARED_SECRET should be configurable via environment variables for secure deployment.
2. Request Payload (JSON):
   • Expect a JSON body with the following fields:
     • content: (string) The full text content of the original Slack message.
     • author: (string) The display name or username of the original Slack message author.
     • invoker: (string) The display name or username of the Slack user who invoked the /add-prompt command.
     • permalink: (string) The permalink URL to the original Slack message.
3. Core Logic:
   • Validate the incoming request (Authentication, presence of required fields).
   • Authenticate with the GitHub API using a securely stored token (e.g., a GitHub PAT or GitHub App credential managed within this project's secrets, NOT passed from the Slack bot).
   • Create a new issue in this repository (lullabot/prompt_library).
     • Title: New Prompt Submission from Slack: @[Original Slack Author Name] (using the author field from the payload).
     • Body:

       [Full text content from payload's `content` field]
       
       ---
       *Metadata:*
       *   Submitted via `/add-prompt` by: @[Invoking Slack User Name] (from `invoker` field)
       *   Original Author: @[Original Slack Author Name] (from `author` field)
       *   Original Slack Message: [Link from `permalink` field]
       

     • Labels: Apply default labels like new-prompt, from-slack (configurable via environment variables if desired).
4. Response Payload (JSON):
   • On successful issue creation: Return status 201 Created with JSON body:

     {
       "success": true,
       "issueUrl": "https://github.com/Lullabot/prompt_library/issues/[new_issue_number]"
     }

   • On failure (authentication error, validation error, GitHub API error): Return appropriate error status (e.g., 400, 401, 500) with JSON body:

     {
       "success": false,
       "error": "Descriptive error message"
     }

Depends On: Lullabot/lullabot-slackbot#71

[sirkitree]

Based on the requirement for a secure API endpoint to receive submissions and create GitHub issues, we'll need a small backend component, as GitHub Pages only serves static content.

Here's an analysis and a few minimal, secure, and potentially free options:

Analysis:

• Need: A server-side function to handle POST requests, validate a shared secret, and use the GitHub API to create an issue.
• Constraint: Cannot run directly on GitHub Pages.

Proposed Solutions:

1. Cloudflare Workers:

   • Description: Run serverless JavaScript/TypeScript functions at the edge. Provides a direct HTTP endpoint.
   • Pros: Generous free tier, built-in secrets management, fast execution, straightforward for simple APIs.
   • Cons: Requires using the Cloudflare platform.
   • Info: Cloudflare Workers Docs

2. GitHub Actions (via repository_dispatch):

   • Description: Use a GitHub Actions workflow triggered by a repository_dispatch event sent from the Slack bot (requires the bot to make a GitHub API call). The action then processes the payload and creates the issue.
   • Pros: Keeps everything within the GitHub ecosystem, uses existing Actions infrastructure, secure secrets management.
   • Cons: Less direct API interaction (bot triggers an event, not a specific endpoint), slightly more complex trigger mechanism for the bot.
   • Info: GitHub Actions repository_dispatch

3. Other Serverless Functions (e.g., Vercel, Netlify, AWS Lambda):

   • Description: Host the endpoint function on platforms like Vercel, Netlify, or AWS Lambda.
   • Pros: Many offer free tiers suitable for this, mature platforms designed for API endpoints.
   • Cons: Introduces another platform/provider to manage.
   • Info:
     • Vercel Serverless Functions
     • Netlify Functions
     • AWS Lambda Free Tier

Recommendation:

Cloudflare Workers seems like a very strong fit due to its direct endpoint capability and generous free tier. However, using GitHub Actions is a viable alternative if keeping infrastructure consolidated within GitHub is preferred.

We should decide on the preferred approach before planning the implementation details.

[sirkitree]

I'm kind of fascinated with this github actions workflow option. So I've created a pull request for that. It actually seems really simple. So, like, is it really this simple? Am I missing something?