[Idea] Add a 'Tools & Workflows' page featuring gstack + community prompt library

[KonstantinMB]

What problem does this solve?

Founders who use ExploreYC are also the kind of people who build with AI tools daily. Right now the site is a passive directory — you look up companies. There's no surface that says "here's how you might use this with the rest of your stack."

A "Tools & Workflows" section could:

• Help founders/builders discover tools they didn't know about (starting with gstack, since it's what this very repo is partially being built/QA'd with).
• Become a community-curated prompt library — share the prompts and workflows that actually work for founder tasks (idea validation, customer research, fundraising prep, hiring, etc.).
• Give the site a recurring-visit reason beyond "look up YC companies."

What I'm thinking (rough)

A new route /tools (or /workflows) with:

1. A short "what gstack is + why we use it" intro
2. A handful of example prompts for common founder tasks, copy-pastable
3. Each prompt shows: title, scenario, the prompt itself, expected output, "copy" button
4. A submission form where anyone can propose a new prompt — name, scenario, prompt body, optional X/GitHub handle for credit
5. Submissions go into a moderation queue (admin approves before showing publicly) — keeps spam out
6. Public prompts get an upvote button — so the best ones float to the top

Three scope tiers to pick from

Tier 1 — "Tools page" (half-day)
A static page with hand-curated prompts. No submission, no upvotes. Markdown-driven. Ship fast, see if anyone cares.

Tier 2 — "Submission form, manual moderation" (1-2 days)
Tier 1 + a submission form that emails the maintainer or files a GitHub issue with the prompt-submission label. Maintainer manually merges good ones into the static list.

Tier 3 — "Real prompt library with DB-backed moderation + upvotes" (3-5 days)
Tier 2 + Supabase table for prompts, admin UI to approve/reject, upvote tracking, sorted views. Becomes a real community surface.

Pre-build questions (worth discussing before anyone codes)

1. Off-mission risk — ExploreYC's pitch is "explore the YC portfolio." Adding a prompt library widens the surface area. Does it dilute the core, or strengthen it? My instinct: strengthens it if the prompts are founder-specific, dilutes it if they're generic AI prompts.
2. gstack-specific or tool-agnostic? Single-tool spotlight vs. "tools we use" page with multiple tools.
3. Storage — Supabase table (prompt_submissions) or GitHub-issue-as-database (use the existing repo issues with a prompt label as the source of truth)?
4. Moderation — admin queue with manual approve, or trust + spam-filter after the fact?
5. Attribution — give submitters a credit line (X/GitHub handle)? Yes seems obviously right.

Acceptance criteria — TBD

This issue is intentionally scoped open because the scope itself is the decision. Once we converge on a tier and answer the questions above, we'll spin out a concrete implementation issue (or multiple) from this thread.

Who should comment

• Anyone who uses gstack or similar tools in their founder workflow — what prompts would you actually want to share?
• Anyone who's built a community prompt library before — what worked, what broke?
• Designers — what's the right page layout for this so it doesn't feel like ad space?

Where this came from

Suggested by @KonstantinMB (maintainer) during a build session — the day-to-day of building ExploreYC has been using gstack for QA + dogfooding, and it felt natural to share that workflow rather than hide it.

[Guru6163]

would love to work on this

[mheilimo]

I would keep the workflow as the primary object and tools as replaceable tags. That keeps /tools tied to founder jobs instead of becoming another AI directory.

For Tier 1, each Markdown card could require: trigger; inputs; steps; expected output plus one example; evidence boundary and failure state; compatible tools; and contributor.

Start with four lanes: validate a problem, test a market or competitor claim, prepare a fundraise, and review hiring needs.

For prompts that assess a startup claim, the output schema should include the claim, verbatim source or locator, date, support state (supported, contradicted, or missing), confidence, missing evidence, and next cheapest test. That makes the reasoning reviewable.

I would use an issue-form-to-reviewed-PR flow for Tier 2 and moderate before publication. Credit contributors and label maker or affiliate relationships. Add upvotes and Supabase only after the static library shows repeat use.

I work on DDScore at Playful Pixels Oy. Our 12-dimension founder view is one disclosed reference for a pre-pitch evidence-gap workflow. It produces a first-pass report and does not provide investment advice or replace full due diligence.