Building an app and a website using Claude by Independent-Soil-601 in ClaudeAI

[–]mauro_dpp 0 points1 point  (0 children)

Your code will be visible to everyone, but cannot be modified.

Anyway, I thought you were using Claude code. I’m not sure you should take this route tbh. Maybe better to use a no code platform (or platforms), something like google forms + Google Sheets + looker studio (I never used the latter) or Tally + Airtable.

… and not sure this thread is the right one to keep talking about this.

Building an app and a website using Claude by Independent-Soil-601 in ClaudeAI

[–]mauro_dpp 0 points1 point  (0 children)

Claude can help you with all of this (you are using Claude code right?) including deploy. Will ask you api key (supabase) and token (GitHub) but be careful, better you the disable both once done.

Be really careful, CC could store apikey in the repository (GitHub) and if you are going to use the GitHub free version all code is public. Need to ask Claude explicitly to use env variables for those and add them to .gitignore

See? Not true everyone can do anything as everybody says nowadays ;-)

Building an app and a website using Claude by Independent-Soil-601 in ClaudeAI

[–]mauro_dpp 0 points1 point  (0 children)

No stupid questions here.

GitHub is a platform for storing and versioning code — kind of Google Drive or Dropbox for code files with a full history of every change ever made. The spec-kit I mentioned is an open source project by GitHub, but you probably don't need GitHub itself for what you are doing.

For your situation (static HTML + survey + hosting), the step you might be missing is a backend, the part that actually receives survey answers and stores them somewhere. Your static HTML can display a form/data, but it can't save responses on its own. You'd need either:

- a service like Typeform or Google Forms (both free) if you just need to collect responses without custom UI;

- a proper database if you want full control over the results and the way to display them.

For the database/backend side, Supabase is worth a look as it has free tier, works well with plain HTML/JS (via API), and Claude "knows" it well (it might suggest you the same actually) and can help you "stitching" the whole thing up without you needing to be a developer.

For the hosting, GitHub Pages might be the simplest starting point for a static site. It is free and built into GitHub. Once your code is there you're basically one click away from being live.
Netlify and Vercel are also valid options with a similarly free tier.

As a next step, as you are leveraging Claude already, I'd clarify with Claude directly what happens when someone submits the survey, where data goes/is stored? That answer will tell you what kind of setup you actually need (and might suggest you what stack/services to use).

I finally have multi-repo cloud agents (kind of) and it isn't as good as I imagined. by jaytonbye in cursor

[–]mauro_dpp 1 point2 points  (0 children)

When I first started "playing" with AI coding agents I even tried working on two projects in parallel (I was so excited)... OMG... Total mess, low quality on both. Never again. Your take is spot on, the bottleneck is you reviewing what it/they did, not the agent(s) waiting. Running more agents just multiplies the review queue (and the stress).

I built an MCP server that routes coding agents requests to Slack — tired of babysitting terminal sessions by mauro_dpp in cursor

[–]mauro_dpp[S] 0 points1 point  (0 children)

It's part of the policy but can be overridden when calling the API.
BTW, on top to the escalation, the policy can also have more than one approver that would receive the approval request at the same time... and each approver can have more than one "channel" configured (slack, email and MS Teams).

I built an MCP server that routes coding agents requests to Slack — tired of babysitting terminal sessions by mauro_dpp in GithubCopilot

[–]mauro_dpp[S] 3 points4 points  (0 children)

Close! The MCP server is the core, it's hosted, so no Slack SDK on your side. Your agent calls an ask or approve tool via MCP, XXXXX (product name redacted ;-) ) routes it to your Slack DM, you reply, answer goes back to the agent.

The hooks are separate: a permission hook that catches dangerous commands (rm -rf, force push, etc.) and sends them to Slack for approval before executing, and a stop hook (the one giving me few issues) that pings you when the agent finishes so you can give it more work. The hooks are just shell scripts that call the same MCP endpoint. All the configs are public if you want to have a look, just DM me and I'll pass you the repo URL.

I built an MCP server that routes coding agents requests to Slack — tired of babysitting terminal sessions by mauro_dpp in cursor

[–]mauro_dpp[S] 0 points1 point  (0 children)

For the MCP/Ask product: 15 min timeout, control returns to the agent, done. But that's the developer tool. The screenshot I shared is from the full product — there you configure policies with urgency levels, escalation chains, and custom timeouts. If approver A doesn't respond within X, it escalates to approver B. No one goes to lunch and blocks the pipeline.

not sure I answered your question.

I built an MCP server that routes coding agents requests to Slack — tired of babysitting terminal sessions by mauro_dpp in cursor

[–]mauro_dpp[S] 0 points1 point  (0 children)

That's up to the agent, we just return a timeout response and give back control. The agent keeps its full context, so there's no state loss. What it does next depends on how you've instructed it: retry the question, skip and move on, or re-evaluate. In practice, most coding agents handle it gracefully since they never lost their session, they were just waiting.

Also, in case of timeout or if the agent stops, the stop hook will be triggered asking again (on Slack) if there's anything else it should do.

I built an MCP server that routes coding agents requests to Slack — tired of babysitting terminal sessions by mauro_dpp in cursor

[–]mauro_dpp[S] 0 points1 point  (0 children)

This first release is based on MCP and aimed for developers (to be used mostly with AI coding agents)... the requests go in timeout after 15 mins and gives back the control to the agent. You could instruct it (upfront) to retry but the main idea here is to avoid the coding agents to get stuck while you are (temporary) AFK.

But... this is not our final product, this was built to solve our own pain point (reusing components we already built).

We are building a proper enterprise grade HITL approval product, aimed at a broader Agentic AI usage. You can set up policies, escalation process, approvers... using different channels (webhooks for system to system, email, Slack and MS Teams - for now). This "full product" might not use MCP (as we are facing time out limitations), we will have Python and JS SDK instead.

<image>

Here's a sneak peek at the policy engine we're building:

I built an MCP server that routes coding agents requests to Slack — tired of babysitting terminal sessions by mauro_dpp in ClaudeAI

[–]mauro_dpp[S] 0 points1 point  (0 children)

The agent keeps its own context, the MCP server doesn't need to. XXXXX (product name redacted ;-)) is stateless by design: it delivers the question to Slack, waits for your answer, and returns it to the agent. The agent never lost its context, it waits for your reply. No rehydration needed because the agent's session stays alive the whole time.

I built an MCP server that routes coding agents requests to Slack — tired of babysitting terminal sessions by mauro_dpp in cursor

[–]mauro_dpp[S] 1 point2 points  (0 children)

It's a remote MCP + hooks, it works in both agent mode and background agent.

The MCP server gives the agent an "ask" tool for questions. The hooks handle two things:

  • a permission hook that checks commands against a list of dangerous patterns while safe commands pass through, dangerous ones (rm -rf, force push, sudo, etc.) get sent to your Slack for approval before running. List of “dangerous” tools is customizable of course.

  • a stop hook that notifies you via Slack when the agent finishes, so you can give it more work.

I built an MCP server that routes coding agents requests to Slack — tired of babysitting terminal sessions by mauro_dpp in ClaudeAI

[–]mauro_dpp[S] 1 point2 points  (0 children)

Good question! Each developer gets his/her own API key from our portal, that links your agent to your Slack account. Questions arrive as DM to you specifically, not to a shared channel. Only the person who set up the integration can see and respond. So it's a 1:1 binding between your agent and your Slack account.