DEV Community: Maisam Abbas

Unscript — A Sanity-Powered Writing Agent That Actually Knows Why It Changes Your Text

Maisam Abbas — Sun, 27 Sep 2026 12:13:41 +0000

This is a submission for the Sanity Challenge, Path One: Ship an Agent That Queries Real Content.

What I Built

I built Unscript, a terminal-based writing transformation agent that uses structured knowledge from Sanity to make writing feel more natural, clear, and human without treating every piece of text the same way.

The main idea started with a simple problem:

Most writing tools can change text. The harder part is deciding how the text should be changed and what should be preserved.

Instead of putting all of the rules inside the prompt, I wanted the agent to have an actual knowledge layer that it could query.

That became Unscript.

Unscript combines:

A terminal-first user experience
A structured Sanity Knowledge Base
Sanity Context MCP
Gemini 3.1 Flash-Lite
Deterministic validation
Source-aware retrieval
Configurable writing levels and content types

The resulting flow is:

User
  ↓
Unscript CLI
  ↓
Agent
  ↓
Sanity Context MCP
  ↓
Structured Knowledge
  ↓
Gemini 3.1 Flash-Lite
  ↓
Transformation
  ↓
Validation
  ↓
Polished CLI Output

The important part is that the model does not have to invent the writing rules on its own.

The rules live in structured content.

Why I Built It This Way

I did not want to build another text box with a prompt behind it.

I wanted the knowledge itself to be part of the product.

For example, Unscript needs to understand that transforming an article is different from transforming a short message. It also needs to know what tone is being requested, which writing patterns should be avoided, which parts of the original text must remain intact, and what level of transformation the user selected.

That information is modeled separately in Sanity.

The Knowledge Base contains structured categories for:

Writing Patterns
Content Types
Humanization Levels
Tone Rules
Transformation Rules
Preservation Rules
Sources
User Decisions

This gives the agent something much more useful than a large collection of unstructured instructions.

It can retrieve the relevant pieces of knowledge for the specific transformation it is performing.

The Agent Workflow

When a user runs the humanization flow, Unscript does not immediately send the text to Gemini.

It first builds the context required for the transformation.

The agent goes through several stages:

1. Analyze the input
       ↓
2. Classify the content
       ↓
3. Determine the requested transformation level
       ↓
4. Retrieve relevant knowledge from Sanity
       ↓
5. Transform the text
       ↓
6. Validate the result
       ↓
7. Display the result and knowledge used

This separation was important to me because it makes the system easier to reason about.

The model handles the language transformation, while Sanity provides the structured rules and knowledge that guide that transformation.

The main flow includes:

Unscript
  ├── Inspect Knowledge
  ├── Inspect Environment
  ├── Help
  └── Humanize Text

Inspect Knowledge

The first part of the demo shows the knowledge available to the agent.

Unscript connects to the Sanity Context MCP endpoint and retrieves structured knowledge from the Sanity Knowledge Base.

The output shows information such as:

Knowledge rules
Writing patterns
Sources
Preservation rules
Provenance

The demo then switches to Sanity Studio to show where that structured content actually lives.

This was important to demonstrate because the knowledge isn't mocked inside the CLI.

It exists as real Sanity content.

Inspect Environment

The environment inspection checks the pieces required by the application, including the configured Sanity Context MCP connection and Gemini integration.

Help

The help screen explains the available Unscript commands and how to move through the terminal interface.

Humanize Text

The main demo then enters the actual transformation workflow.

I select:

Content Type → Article
Tone → Friendly
Transformation → Custom

Unscript asks for the text, retrieves the relevant knowledge through Sanity Context MCP, sends the transformation task to Gemini 3.1 Flash-Lite, validates the result, and displays the final output.

The result also exposes the knowledge that influenced the transformation instead of simply showing a new paragraph and hiding everything that happened behind it.

For the demonstrated run, the retrieved context included:

9 rules
7 writing patterns
3 sources
4 preservation rules

along with the transformed result and provenance information.

How I Used Sanity

Sanity is the knowledge layer of Unscript.

I created a Sanity project called:

Unscript Knowledge

The structured content is stored in the production dataset.

The project contains schemas for:

writingPattern
contentType
humanizationLevel
toneRule
transformationRule
preservationRule
source
userDecision

These schemas let the knowledge remain structured instead of becoming one large prompt.

For example, a transformation rule can exist as its own piece of knowledge, while a preservation rule can independently describe something that must not be changed.

Sources are also represented separately so retrieved knowledge can retain provenance.

Sanity Context MCP

The most important part of the Sanity integration is the Sanity Context MCP endpoint.

Unscript connects to:

https://api.sanity.io/v1/context/organizations/o8io0s3zz/mcp/unscript-knowledge

The agent establishes an MCP session and performs the required MCP initialization flow.

The runtime sequence includes:

initialize
    ↓
notifications/initialized
    ↓
initial_context
    ↓
tools/list
    ↓
groq_query

The groq_query capability is then used to retrieve the relevant structured knowledge.

This means the agent isn't simply querying a local JSON file or a hard-coded array.

The knowledge comes through Sanity's Context MCP layer.

Why Structured Content Matters Here

This is probably the most important part of the project.

A normal keyword search might find a phrase such as "make writing more conversational."

But Unscript needs more context than that.

It needs to know:

What type of content is being transformed?
What tone was selected?
What transformation level was requested?
Which patterns should be changed?
Which patterns should be preserved?
Which rules apply to this particular type of writing?
Where did the rule come from?

That is where structured content becomes useful.

Instead of treating knowledge as a flat document, Unscript can retrieve different pieces of related knowledge and use them together.

For example:

Article
  +
Friendly Tone
  +
Selected Humanization Level
  +
Transformation Rules
  +
Preservation Rules
  +
Writing Patterns
  +
Source Information

becomes the context used for the transformation.

That is the part of the project that would be difficult to reproduce with a simple keyword search.

Knowledge Base

The initial Knowledge Base is populated with structured content across the different schemas.

The current knowledge set contains:

Sources                  3
Content Types            8
Humanization Levels      5
Tone Rules               8
Transformation Rules    14
Preservation Rules      10
Writing Patterns        10
User Decisions           0

That gives the agent a deliberately separated knowledge model rather than one giant prompt.

The sources include established writing guidance such as:

U.S. Digital.gov / GSA plain-language guidance
Microsoft Writing Style Guide
Google writing guidance

The goal was not to copy these sources into one enormous instruction block.

Instead, relevant ideas were modeled into structured knowledge that the agent can retrieve and apply.

Gemini 3.1 Flash-Lite

Gemini 3.1 Flash-Lite handles the actual language transformation.

Sanity provides the context.

Gemini performs the transformation.

Unscript then validates the result before presenting it.

Conceptually:

Sanity
  =
What should guide the transformation?

Gemini
  =
How should the text be transformed?

Unscript
  =
Did the result follow the required constraints?

Keeping those responsibilities separate made the architecture much easier to control.

Validation

The transformation does not end when Gemini returns text.

Unscript performs deterministic validation after the model response.

This gives the application a second layer between the model and the final terminal output.

The validation stage checks the result against the requirements established by the agent and the retrieved knowledge.

This was especially important for preservation rules.

A writing transformation should not accidentally remove information simply because the model thinks the sentence sounds better.

The agent therefore treats transformation and preservation as separate concerns.

Provenance

Another part I wanted to expose was where the knowledge came from.

The retrieved context is not presented as mysterious model knowledge.

The result can show the sources and knowledge used by the agent.

This creates a clearer chain:

Source
  ↓
Structured Sanity Knowledge
  ↓
Sanity Context MCP
  ↓
Agent Retrieval
  ↓
Gemini Transformation
  ↓
Validation
  ↓
Final Result

That makes the application easier to inspect and debug.

It also makes the Sanity integration meaningful rather than decorative.

The Terminal Experience

I intentionally built Unscript as a CLI.

The reason is simple: I wanted the tool to feel like something a developer could actually use from a terminal rather than another generic AI webpage.

The interface includes:

Interactive command navigation
Human-readable status information
Environment inspection
Knowledge inspection
Interactive transformation flow
Structured result output
Retrieved knowledge information
Validation information
Clean handling of terminal input

I also spent time fixing edge cases around terminal input.

For example, partial-line Ctrl+D handling and the interaction between editing, backspacing, and the prompt needed to be handled properly.

Those details are easy to ignore when building a demo, but they matter when the application is actually being used from a terminal.

Technical Architecture

The complete architecture looks like this:

┌──────────────────────────────┐
│          User                │
└──────────────┬───────────────┘
               │
               ▼
┌──────────────────────────────┐
│       Unscript CLI           │
│                              │
│  commands / prompts / UI     │
└──────────────┬───────────────┘
               │
               ▼
┌──────────────────────────────┐
│       Unscript Agent         │
│                              │
│ analyze                       │
│ classify                      │
│ select level                  │
│ retrieve knowledge            │
│ transform                     │
│ validate                      │
└──────────────┬───────────────┘
               │
               ▼
┌──────────────────────────────┐
│      Sanity Context MCP      │
└──────────────┬───────────────┘
               │
               ▼
┌──────────────────────────────┐
│     Unscript Knowledge       │
│                              │
│ writing patterns             │
│ content types                │
│ humanization levels          │
│ tone rules                   │
│ transformation rules         │
│ preservation rules           │
│ sources                      │
│ user decisions               │
└──────────────┬───────────────┘
               │
               ▼
┌──────────────────────────────┐
│    Gemini 3.1 Flash-Lite     │
│                              │
│   language transformation    │
└──────────────┬───────────────┘
               │
               ▼
┌──────────────────────────────┐
│       Validation             │
│                              │
│   deterministic checks       │
└──────────────┬───────────────┘
               │
               ▼
┌──────────────────────────────┐
│       Final CLI Result       │
│                              │
│ transformed text             │
│ retrieved knowledge          │
│ provenance                   │
│ validation                   │
└──────────────────────────────┘

Implementation

Unscript is built as a TypeScript CLI.

The project was developed around a few principles:

1. Knowledge should live outside the model

Writing rules are structured in Sanity rather than being permanently embedded in the application prompt.

2. Retrieval should be inspectable

The agent should be able to show what it retrieved and where that knowledge came from.

3. Transformation should be separate from validation

The model generates the transformation, but deterministic application logic is responsible for checking the result.

4. The CLI should be usable on its own

The terminal experience is part of the product rather than just a debugging interface.

5. Real services should be used in the demo

The Sanity project, Sanity Context MCP endpoint, and Gemini integration are real parts of the runtime.

Testing

I did not want the project to only work for the exact demo recording.

The project went through separate checks during development, including:

TypeScript compilation
ESLint
Prettier
Production build
CLI runtime checks
Sanity schema validation
MCP initialization
Knowledge retrieval
Gemini integration
Transformation flow
Deterministic validation
Terminal input edge cases

The final project reached a clean test/build state with the complete end-to-end flow working against the real Sanity Context MCP integration.

What I Learned

The biggest thing I learned from building Unscript is that structured content changes how an agent can be designed.

It is tempting to put everything into one prompt:

Here are some rules.
Now transform this text.

That can work for a small prototype.

But once the rules become more complex, the prompt becomes the application.

That was exactly what I wanted to avoid.

With Sanity, the knowledge becomes something that can be modeled, inspected, changed, queried, and reused.

The agent can then treat that knowledge as an external system rather than a giant hard-coded instruction.

That separation makes the whole application easier to understand.

Why Sanity Is Actually Part of the Product

I did not use Sanity simply because the challenge required a Sanity project.

If Sanity were removed from Unscript, the architecture would lose an important part of its purpose.

The application depends on structured knowledge for:

Content classification
Humanization levels
Tone selection
Transformation rules
Preservation rules
Writing patterns
Source information
Knowledge retrieval

The model is therefore not the entire product.

The knowledge layer is part of the product.

That is the main reason I chose Path One.

Source Code

https://github.com/maisamabbas0323/unscript.git

Sanity Project

Project ID: b209xsoi
Dataset: production

Sanity Context MCP

https://api.sanity.io/v1/context/organizations/o8io0s3zz/mcp/unscript-knowledge

Demo Video

https://youtube.com/watch?v=ZopcANma17Q\&si=jhlLzNV6l999JFDY)

Sanity Project Details

Project: Unscript Knowledge
Project ID: b209xsoi
Dataset: production
Organization: o8io0s3zz

The Sanity Studio contains the schemas and structured documents used by the agent's Knowledge Base.

Final Thoughts

Unscript started with a simple question:

What if a writing agent did not have to keep all of its knowledge inside the model?

The result became a terminal application where Sanity acts as the structured knowledge layer, Sanity Context MCP connects that knowledge to the agent, Gemini 3.1 Flash-Lite performs the language transformation, and Unscript validates and presents the result.

The interesting part for me is not simply that the application can rewrite text.

It is that the reasoning context behind the transformation can be structured, queried, inspected, and connected back to its sources.

That is what I wanted to explore with the Sanity Challenge.

Built With

Sanity
Sanity Content Lake
Sanity Context MCP
Sanity Studio
TypeScript
Gemini 3.1 Flash-Lite
MCP
GROQ
Node.js
Terminal CLI

Challenge

Sanity Challenge — Path One: Ship an Agent That Queries Real Content

Doneehub - Weekenchallenge Submission

Maisam Abbas — Sat, 05 Sep 2026 12:52:17 +0000

Turn what you have into what someone needs.

What I Built

Doneehub is a people-first generosity platform built around a simple idea:

You already have something that can help. Doneehub helps you figure out what that something could become.

Generosity is often presented as if it starts with money. In reality, people have many other resources: time, technical skills, knowledge, transportation, food, unused items, professional experience, or simply the willingness to help.

Doneehub brings those resources together and turns them into practical possibilities.

The heart of the project is the Generosity Compiler. A user can describe what they have—for example, an old laptop and technical skills, a few free hours and transportation, or a small amount of money and limited time. Doneehub then interprets that combination and helps turn it into realistic action ideas, requirements, and next steps.

The project also includes GoogleHelp, a general-purpose Gemini workspace that can help with questions, explanations, writing, rewriting, planning, learning, brainstorming, analysis, and problem solving.

The goal was not to build another social feed filled with invented activity or impressive-looking numbers. I wanted to build something quieter and more useful: a tool that helps a person move from intention to action.

Demo

Live Demo:

https://doneehub.vercel.app/

Code

GitHub Repository:

https://github.com/maisamabbas0323/doneehub

Doneehub is built as a local-first web application. The repository contains the frontend, Gemini integration, UI components, reusable services, and project configuration.

How I Built It

I wanted the technical architecture to stay simple enough that the product itself could remain the focus.

Doneehub does not require authentication and does not use a database. User preferences and configuration are kept locally in the browser.

The application follows a simple flow:

Doneehub
   |
   +-- GoogleHelp
   |      |
   |      +-- User's Gemini API Key
   |                   |
   |                   v
   |             Google Gemini API
   |
   +-- Local Browser State

One Gemini Configuration

Rather than asking users to configure an API key separately for every feature, Doneehub uses one centralized Gemini configuration.

The user enters their Gemini API key through GoogleHelp. The key is stored locally, masked after saving, and can be tested, replaced, or removed.

A shared Gemini client/service is responsible for the communication layer so that Gemini-powered features behave consistently throughout the application.

Generosity Compiler

The Generosity Compiler was the main product idea I wanted to explore.

Instead of starting with:

“What should I donate?”

it starts with:

“What do I already have?”

The user can combine different resources and constraints. Gemini interprets the combination and produces practical possibilities rather than simply returning a generic list of charities.

For example:

Resources:
- Old laptop
- Web development skills
- 4 hours available each weekend

Goal:
- Help someone learn technology

The result can become a structured set of possible directions, action steps, things to verify, and practical considerations.

The important distinction is that generated ideas are not presented as verified real-world opportunities unless supporting information actually exists.

GoogleHelp

GoogleHelp is the broader Gemini workspace inside Doneehub.

It supports normal conversation and useful everyday tasks such as:

Explaining difficult concepts
Rewriting text
Summarizing user-provided material
Brainstorming ideas
Planning projects
Learning assistance
Coding questions
Problem solving
Writing and editing

I wanted it to feel like a workspace rather than a stereotypical chatbot screen.

Proper Markdown Rendering

One small but important detail was the presentation of Gemini responses.

Instead of showing raw text such as:

# Heading
**important text**
- first item

Doneehub renders the Markdown into readable interface content.

The renderer supports headings, emphasis, lists, links, blockquotes, code, tables, and other common Markdown structures while sanitizing unsafe content.

This makes generated information much easier to scan and actually use.

Real Information, Not Fake Data

A major design decision was to avoid fabricating the world around the user.

Doneehub does not create fake:

Organizations
Beneficiaries
Donation totals
Testimonials
Events
Opportunities
Locations
Impact statistics
Verification claims
Live prices
Availability

When current information is needed, it should come from a trustworthy public source or API. Gemini can then help interpret or organize that information, but generated text is not treated as proof that something exists.

That distinction became one of the most important principles of the project.

Prize Categories

Best Use of Google AI

Doneehub is submitted for Best Use of Google AI.

Google Gemini is not used as a decorative chatbot added to the application. It is part of the core interaction model.

The Generosity Compiler depends on Gemini to interpret combinations of resources and turn them into practical contribution ideas.

GoogleHelp provides a broader Gemini workspace for reasoning, explanation, writing, planning, learning, and problem solving.

The application also uses structured responses where predictable application data benefits from them, while normal conversational responses can remain natural Markdown.

The important part is that Gemini is used to solve an actual product problem:

How can we help someone understand how their existing resources could become useful to another person?

What Makes Doneehub Different

There are many platforms that tell people where to donate.

Doneehub starts one step earlier.

It asks:

What do you have?

Maybe the answer is:

Two free hours.
A working laptop you no longer use.
A car.
Knowledge about accounting.
A kitchen that can prepare extra food.
Programming skills.
A willingness to teach.
A small amount of money.
Professional experience.

Those things can have value even when they do not look like traditional donations.

Doneehub is designed to help users discover that value and turn it into an actionable next step.

Design Direction

The visual design deliberately avoids the familiar “AI product” aesthetic.

Instead, Doneehub uses a calm editorial direction:

Near-black backgrounds
Warm off-white typography
Muted gray supporting text
Restrained warm accent color
Strong typography and hierarchy
Compact navigation
Subtle borders
Purposeful whitespace
Minimal motion
Responsive layouts

There are no unnecessary AI badges, glowing gradients, robots, holograms, neon effects, fake dashboards, or invented social activity.

The intention is for Doneehub to feel like a real product made for people—not a collection of AI-generated screens.

Challenges I Ran Into

The hardest part was not making Gemini return text.

The harder question was deciding what the application could honestly claim.

A generosity product can easily become misleading if generated suggestions are presented as verified opportunities. It can also become superficial if it fills the interface with fake impact statistics, fictional beneficiaries, or invented success stories.

I therefore treated the boundary between generated assistance and verified information as a product requirement rather than an afterthought.

Another challenge was making the Gemini integration useful without turning every screen into a chatbot.

That led to the Generosity Compiler: a focused workflow where Gemini has a clear job and the output is directly connected to something the user can act on.

What I Learned

The project reinforced a simple lesson:

Good AI product design is often less about generating more and more about helping users make better decisions with what is generated.

The useful part of Gemini is not simply that it can produce an answer. The useful part is that it can help connect pieces of information that a person already has and turn them into a clearer plan.

That became the guiding idea behind Doneehub.

What's Next

There is a lot more that could be built on top of this foundation.

Some possible next steps are:

More resource combinations
Better structured generosity plans
More trustworthy public-source integrations
Stronger source traceability
More localized opportunities
Better planning workflows
Additional accessibility improvements
Stronger validation for structured Gemini responses
More offline-friendly functionality

The architecture is intentionally simple so these capabilities can be added without turning the product into an unnecessarily complicated platform.

Built With

TypeScript
React
Tailwind CSS
Google Gemini API
Browser-local storage/state

The exact package versions and available scripts are defined in the repository's package.json.

Running Locally

Clone the repository:

git clone https://github.com/maisamabbas0323/doneehub.git
cd doneehub

Install dependencies:

npm install

Start the development server:

npm run dev

Build the project:

npm run build

If the repository's configured scripts differ, package.json is the authoritative source.

Gemini Configuration

Open GoogleHelp inside Doneehub and configure a Gemini API key.

The application is designed around a user-provided key rather than a project-owned secret.

For security:

Never commit API keys.
Never hardcode secrets.
Never place keys in URLs.
Never log keys.
Never include keys in screenshots or documentation.

Because the key is used client-side, it should be treated accordingly and managed by the user.

Privacy and Architecture

Doneehub intentionally has:

No authentication
No user accounts
No application database
No Supabase
No project-owned secret API key

The product is local-first wherever practical.

This keeps the architecture lightweight and makes the core experience understandable: the user brings their resources, their intentions, and their Gemini configuration; Doneehub helps turn those inputs into useful possibilities.

License

Doneehub is released under the MIT License.

See LICENSE for the complete license text.

Repository

https://github.com/maisamabbas0323/doneehub

Submission Note

This project was built for the Weekend Challenge: Generosity Edition.

The central idea is simple:

Turn what you have into what someone needs.

Doneehub

Maisam Abbas — Sat, 05 Sep 2026 12:48:12 +0000

Turn what you have into what someone needs.

What I Built

Doneehub is a people-first generosity platform built around a simple idea:

You already have something that can help. Doneehub helps you figure out what that something could become.

Doneehub brings those resources together and turns them into practical possibilities.

Demo

Live Demo:

https://doneehub.vercel.app/

Code

GitHub Repository:

https://github.com/maisamabbas0323/doneehub

Doneehub is built as a local-first web application. The repository contains the frontend, Gemini integration, UI components, reusable services, and project configuration.

How I Built It

I wanted the technical architecture to stay simple enough that the product itself could remain the focus.

Doneehub does not require authentication and does not use a database. User preferences and configuration are kept locally in the browser.

The application follows a simple flow:

Doneehub
   |
   +-- GoogleHelp
   |      |
   |      +-- User's Gemini API Key
   |                   |
   |                   v
   |             Google Gemini API
   |
   +-- Local Browser State

One Gemini Configuration

Rather than asking users to configure an API key separately for every feature, Doneehub uses one centralized Gemini configuration.

The user enters their Gemini API key through GoogleHelp. The key is stored locally, masked after saving, and can be tested, replaced, or removed.

A shared Gemini client/service is responsible for the communication layer so that Gemini-powered features behave consistently throughout the application.

Generosity Compiler

The Generosity Compiler was the main product idea I wanted to explore.

Instead of starting with:

“What should I donate?”

it starts with:

“What do I already have?”

The user can combine different resources and constraints. Gemini interprets the combination and produces practical possibilities rather than simply returning a generic list of charities.

For example:

Resources:
- Old laptop
- Web development skills
- 4 hours available each weekend

Goal:
- Help someone learn technology

The result can become a structured set of possible directions, action steps, things to verify, and practical considerations.

The important distinction is that generated ideas are not presented as verified real-world opportunities unless supporting information actually exists.

GoogleHelp

GoogleHelp is the broader Gemini workspace inside Doneehub.

It supports normal conversation and useful everyday tasks such as:

Explaining difficult concepts
Rewriting text
Summarizing user-provided material
Brainstorming ideas
Planning projects
Learning assistance
Coding questions
Problem solving
Writing and editing

I wanted it to feel like a workspace rather than a stereotypical chatbot screen.

Proper Markdown Rendering

One small but important detail was the presentation of Gemini responses.

Instead of showing raw text such as:

# Heading
**important text**
- first item

Doneehub renders the Markdown into readable interface content.

The renderer supports headings, emphasis, lists, links, blockquotes, code, tables, and other common Markdown structures while sanitizing unsafe content.

This makes generated information much easier to scan and actually use.

Real Information, Not Fake Data

A major design decision was to avoid fabricating the world around the user.

Doneehub does not create fake:

Organizations
Beneficiaries
Donation totals
Testimonials
Events
Opportunities
Locations
Impact statistics
Verification claims
Live prices
Availability

That distinction became one of the most important principles of the project.

Prize Categories

Best Use of Google AI

Doneehub is submitted for Best Use of Google AI.

Google Gemini is not used as a decorative chatbot added to the application. It is part of the core interaction model.

The Generosity Compiler depends on Gemini to interpret combinations of resources and turn them into practical contribution ideas.

GoogleHelp provides a broader Gemini workspace for reasoning, explanation, writing, planning, learning, and problem solving.

The application also uses structured responses where predictable application data benefits from them, while normal conversational responses can remain natural Markdown.

The important part is that Gemini is used to solve an actual product problem:

How can we help someone understand how their existing resources could become useful to another person?

What Makes Doneehub Different

There are many platforms that tell people where to donate.

Doneehub starts one step earlier.

It asks:

What do you have?

Maybe the answer is:

Two free hours.
A working laptop you no longer use.
A car.
Knowledge about accounting.
A kitchen that can prepare extra food.
Programming skills.
A willingness to teach.
A small amount of money.
Professional experience.

Those things can have value even when they do not look like traditional donations.

Doneehub is designed to help users discover that value and turn it into an actionable next step.

Design Direction

The visual design deliberately avoids the familiar “AI product” aesthetic.

Instead, Doneehub uses a calm editorial direction:

Near-black backgrounds
Warm off-white typography
Muted gray supporting text
Restrained warm accent color
Strong typography and hierarchy
Compact navigation
Subtle borders
Purposeful whitespace
Minimal motion
Responsive layouts

There are no unnecessary AI badges, glowing gradients, robots, holograms, neon effects, fake dashboards, or invented social activity.

The intention is for Doneehub to feel like a real product made for people—not a collection of AI-generated screens.

Challenges I Ran Into

The hardest part was not making Gemini return text.

The harder question was deciding what the application could honestly claim.

I therefore treated the boundary between generated assistance and verified information as a product requirement rather than an afterthought.

Another challenge was making the Gemini integration useful without turning every screen into a chatbot.

That led to the Generosity Compiler: a focused workflow where Gemini has a clear job and the output is directly connected to something the user can act on.

What I Learned

The project reinforced a simple lesson:

Good AI product design is often less about generating more and more about helping users make better decisions with what is generated.

The useful part of Gemini is not simply that it can produce an answer. The useful part is that it can help connect pieces of information that a person already has and turn them into a clearer plan.

That became the guiding idea behind Doneehub.

What's Next

There is a lot more that could be built on top of this foundation.

Some possible next steps are:

More resource combinations
Better structured generosity plans
More trustworthy public-source integrations
Stronger source traceability
More localized opportunities
Better planning workflows
Additional accessibility improvements
Stronger validation for structured Gemini responses
More offline-friendly functionality

The architecture is intentionally simple so these capabilities can be added without turning the product into an unnecessarily complicated platform.

Built With

TypeScript
React
Tailwind CSS
Google Gemini API
Browser-local storage/state

The exact package versions and available scripts are defined in the repository's package.json.

Running Locally

Clone the repository:

git clone https://github.com/maisamabbas0323/doneehub.git
cd doneehub

Install dependencies:

npm install

Start the development server:

npm run dev

Build the project:

npm run build

If the repository's configured scripts differ, package.json is the authoritative source.

Gemini Configuration

Open GoogleHelp inside Doneehub and configure a Gemini API key.

The application is designed around a user-provided key rather than a project-owned secret.

For security:

Never commit API keys.
Never hardcode secrets.
Never place keys in URLs.
Never log keys.
Never include keys in screenshots or documentation.

Because the key is used client-side, it should be treated accordingly and managed by the user.

Privacy and Architecture

Doneehub intentionally has:

No authentication
No user accounts
No application database
No Supabase
No project-owned secret API key

The product is local-first wherever practical.

License

Doneehub is released under the MIT License.

See LICENSE for the complete license text.

Repository

https://github.com/maisamabbas0323/doneehub

Submission Note

This project was built for the Weekend Challenge: Generosity Edition.

The central idea is simple:

Turn what you have into what someone needs.

Caninography

Maisam Abbas — Mon, 17 Aug 2026 03:13:42 +0000

This is a submission for Weekend Challenge: Dog Days Edition

I built Caninography, a small digital archive for exploring dog breeds from around the world.

I wanted it to feel more like a digital museum than a normal dog website.

You can explore breeds, their origins, history, countries, characteristics and connections between them.

The whole design is dark, clean and visual. I also kept it silent, so there is no distracting audio or player UI.

GitHub:

https://github.com/maisamabbas0323/canonigraphy.git

How I Built It

I built it with React, Vite and TypeScript.

For the visual side, I focused a lot on typography, photography, smooth transitions and responsive layouts.

I also added an interactive world atlas and a constellation-style view to explore breed relationships.

For the content, I used Google Gemini to help create short and interesting breed information.

I didn't wanted to make another chatbot. Instead, Gemini stays behind the experience and helps make the archive content more rich while people simply explore it.

Prize Categories

Best Use of Google AI

Caninography is submitted for Best Use of Google AI.

I used Google Gemini to generate concise, breed-specific information based on the archive data.

The idea was to use AI in the background, not put a chatbot in front of the user.

Built With
React
Vite
TypeScript
Google Gemini
CSS
SVG
Canvas

A Little About The Idea

I always felt dog breed information is mostly shown as simple lists.

So I thought:

What if a dog archive felt like a museum?

That small idea became Caninography.

A place to explore their stories, origins and history — one breed at a time.

Beyond The Plate — Every Dish Has a Story | DEV Frontend Challenge

Maisam Abbas — Wed, 12 Aug 2026 11:57:25 +0000

This is a submission for Frontend Challenge - Comfort Food Edition, Perfect Landing_

What I Built

For this challenge I wanted to build something a little different than a traditional recipe or food website.

Beyond The Plate is an editorial-style web experience that explores the stories behind comfort food from around the world. Instead of only showing recipes, it tells where a dish comes from, why people love it, how it became part of a culture, and what makes it special.

The project currently features 300+ authentic dishes from countries across every continent. Each dish includes real historical background, cultural traditions, ingredients, nutrition, cooking instructions, and related dishes to encourage people to keep exploring.

I spent a lot of time making the interface feel calm and immersive. The goal was to make visitors feel like they were walking through a digital museum instead of scrolling another food website.

Some highlights:

300+ authentic dishes from around the world
Real recipes with ingredients and cooking steps
Cultural stories and historical background
Nutrition dashboard with macro breakdowns
Editorial gallery with authentic food photography
Fully responsive from mobile to large desktop
Premium animations using Framer Motion and GSAP
Built with React, TypeScript and Vite
Accessibility focused
Custom design system inspired by museums and editorial magazines

I tried to keep everything feeling premium while still being easy to read and explore.

Demo

Live Demo

beyond-the-plate-seven.vercel.app

GitHub Repository

https://github.com/maisamabbas0323/beyond-the-plate.git

Screenshots

Home

Discover

### Culture

Nutrition

Recipes

Gallery

About

Journey

This project started much smaller.

At first I only wanted to build a nice landing page for the challenge, but after working on it for a while I kept asking myself, "What if every comfort food could tell its own story?"

That idea slowly turned into a much bigger project.

I spent most of my time researching real dishes instead of making things up. I wanted every recipe, every country, and every cultural reference to be authentic. That part actually took longer than building the UI.

The design also changed many times. I rebuilt the hero section more than once because it never felt quite right. I experimented with different layouts, typography, animations, and colors until everything started feeling like a digital food exhibition instead of a normal website.

One of my favorite parts was adding the little interactions throughout the site. Small hover effects, smooth scrolling, floating cards, subtle animations, and transitions make the experience feel much more alive without becoming distracting.

There were definitely a few frustrating moments too. Getting everything responsive across different screen sizes took a lot more work than I expected, and I probably changed the spacing and typography dozens of times before I was happy with it. But looking back, I'm glad I kept improving those details because they made a big difference.

If I continue working on Beyond The Plate after this challenge, I'd love to add:

interactive world maps
multilingual support
offline PWA support
more authentic dishes and regional cuisines
bookmarking and personal collections
seasonal food collections
audio stories for every dish

Overall, this was a really fun challenge. It pushed me to think beyond just building another landing page and instead create something that people might actually enjoy exploring.

Thanks to the DEV community for organizing another great Frontend Challenge. ❤️

The Last Spark

Maisam Abbas — Sun, 12 Jul 2026 15:38:13 +0000

The Last Spark - Learn your passion with google ais

This is a submission for Weekend Challenge: Passion Edition

What I Built

I built The Last Spark, an AI-powered passion learning web app where users can pick a passion like Cybersecurity, Football, Cooking, Programming, Music, or even create there own custom passion. After selecting a difficulty, Google Gemini generates a complete learning journey with chapters, study notes, timed quizzes, and a final AI report based on the selected passion. My goal was to make learning feel more like playing a game instead of reading long boring articles.

Demo

Live Demo: https://the-last-spark.vercel.app/

Code

GitHub Repository: https://github.com/maisamabbas0323/the-last-spark

How I Built It

The project is built with React, TypeScript, Vite, Tailwind CSS, Framer Motion, and Google Gemini 3.1 Flash Lite. Gemini creates the study content, chapters, questions, explanations, and final reports in real time based on what the user chooses. I spent most of my time making the UI smooth, responsive, and trying to give it a premium gaming feel with animated cards, timers, progress tracking, and reports. There was lot of debugging and redesign during development, but it was really fun to build.

Prize Categories

✅ Best Use of Google AI

Thanks for checking out my project. Hope you enjoy it as much as I enjoyed building it 😊

An AI-Powered Chess Experience with Google Gemini

Maisam Abbas — Sun, 21 Jun 2026 06:18:18 +0000

Turning a Classic Game into an AI-Powered Experience with Gemini

When I started working on my June Solstice Game Jam project, I knew I didn't want to build just another game.

I wanted to create something that combined strategy, learning, and artificial intelligence in a way that felt natural and useful.

Chess immediately came to mind.

For centuries, chess has been a symbol of intelligence, planning, and decision-making. At the same time, AI has become one of the most exciting technologies of our generation. Combining the two felt like the perfect challenge.

The result was Solstice Chess, a modern AI-powered chess experience built with Google Gemini.

What I Built

Solstice Chess is a web-based chess platform that combines traditional chess gameplay with AI-powered analysis and assistance.

Players can jump into a game, choose a difficulty level, and receive intelligent insights powered by Gemini.

The goal wasn't simply to build a chess board.

The goal was to create an experience where players could improve, learn, and understand the reasoning behind moves rather than simply playing against a computer.

Core Features

Interactive chess gameplay
Multiple AI difficulty levels
Gemini-powered move analysis
Position evaluation
Strategic recommendations
Modern responsive interface
Fast browser-based experience

Project Screenshots

Landing Page

The landing page introduces players to the project through a clean, premium interface inspired by modern AI products.

Gameplay Interface

The gameplay screen focuses on clarity and usability while keeping the chessboard at the center of attention.

Gemini Integration

Players can connect Gemini and unlock AI-powered analysis and chess insights.

Why I Built This

One thing I've always found interesting about chess is that beginners often struggle to understand why a move is good or bad.

Many chess engines provide evaluations, but they don't always explain their reasoning in a way that's easy to understand.

That's where Gemini became exciting.

Instead of only showing moves, Gemini can help explain strategic ideas, identify weaknesses, and provide insights that feel more like guidance than raw calculations.

I wanted the AI to feel less like an opponent and more like a coach.

The Technical Approach

The project was built as a modern web application with a strong focus on user experience.

Frontend

The interface was designed around a premium dark theme with clean typography and a distraction-free layout.

My goal was to create something that felt modern and professional while remaining easy to use.

Chess Logic

The chess system handles:

Legal move validation
Piece movement
Turn management
Difficulty settings
Board state updates

Maintaining correct game state was one of the most important parts of development.

Gemini AI

Gemini serves as the intelligence layer of the application.

It can be used to:

Analyze positions
Explain moves
Provide strategic feedback
Offer educational commentary

This transforms a standard chess game into a learning experience.

Challenges I Faced

Like most projects, things didn't go smoothly from day one.

One of the biggest challenges was balancing functionality with simplicity.

I wanted powerful AI features without overwhelming players with information.

Another challenge was designing an interface that felt modern while keeping the focus on the chessboard itself.

Several parts of the UI were redesigned multiple times before reaching the final version.

What I'm Most Proud Of

The feature I'm most proud of isn't a single button or screen.

It's the overall experience.

I love that a player can open the application, start a game, receive AI insights, and learn something new without needing to install anything or study complicated tools.

That combination of accessibility and intelligence is exactly what I hoped to achieve.

What I Learned

Building Solstice Chess taught me valuable lessons about:

AI integration
Product design
User experience
State management
Game development
Problem solving

It also reinforced something I've learned repeatedly as a developer:

The most challenging part of building software isn't always creating features.

It's creating an experience that feels simple.

What's Next?

This project is only the beginning.

Future ideas include:

Multiplayer mode
Game history and replays
Personalized AI coaching
Opening explorer
Advanced analytics
Cloud synchronization

There are many directions this project could grow, and I'm excited to continue exploring them.

Code

GitHub Repository:

https://github.com/abxdev12/solstice-shift

Live Demo:

solstice-shift.vercel.app

Prize Category

Best Google AI Usage

Google Gemini plays a central role in Solstice Chess by providing intelligent analysis, strategic feedback, and educational guidance that enhances the traditional chess experience.

Best Ode to Alan Turing

Chess and artificial intelligence share a long history together. Solstice Chess celebrates that connection by combining one of humanity's oldest strategy games with modern generative AI technology.

Thank you for reading and checking out Solstice Chess.

If you're interested in AI, game development, or chess, I'd love to hear your thoughts and feedback.