DEV Community: Maisam Abbas

Ghost Reel: Turning Ideas into Documentaries — A Mobile Documentary Studio

Maisam Abbas — Fri, 30 Oct 2026 09:03:09 +0000

This is a submission for the Hacktoberfest Open-Source AI Challenge Week 4: Ghost in the Machine.

What I Built

I built Ghost Reel, a mobile documentary production workspace designed to help creators transform ideas and research into structured documentary projects.

The inspiration behind Ghost Reel came from a simple observation: creating a documentary involves many different steps. You need to research a subject, organise information, identify important facts, develop a compelling story, write a script, prepare narration, plan scenes, and eventually bring everything together into a finished video.

These activities are often spread across multiple applications and services. Moving between them can make the creative process unnecessarily complicated.

I wanted to bring the early stages of this entire process into one place.

Ghost Reel is designed to make documentary production feel like a connected workflow. Instead of starting with an empty video editor, creators can begin with a topic, develop their research, generate and refine a script, prepare narration, and organise the documentary scene by scene.

It is not intended to be just another AI chat interface. It is a dedicated workspace for documentary projects.

Getting started

Prerequisites

Node.js 18 or later
npm 10+ (ships with Node 18) — the project uses package-lock.json
Expo Go app on your iOS or Android device (App Store · Google Play)

You do not need Xcode or Android Studio to run Ghost Reel. Expo Go handles everything.

1 — Clone the repository

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

2 — Install dependencies

npx expo install

Always use npx expo install (not npm install directly) — it resolves package versions that are compatible with the installed Expo SDK.

3 — Start the development server

npx expo start

Expo will print a QR code in the terminal.

4 — Open on your device

Open Expo Go on your phone.
Scan the QR code with your camera (iOS) or the Expo Go in-app scanner (Android).
Ghost Reel will bundle and open on your device.

Make sure your phone and computer are on the same Wi-Fi network. If the QR scan fails, press w in the terminal to open the web version, or a/i to open an Android/iOS simulator if you have one installed.

The workflow

A documentary project in Ghost Reel follows a structured process:

Create a documentary project.
Choose a topic and provide an optional research URL.
Gather information and research the subject.
Generate a structured documentary script.
Edit, revise, and approve the script.
Generate narration for individual scenes.
Organise the scenes using the storyboard.
Configure captions and export preferences.
Continue toward the final video-production stage.

Each stage has a specific purpose, helping creators keep their research, writing, and production planning organised.

1. Project Management

Ghost Reel provides a project-based workspace.

Creators can create new documentary projects, organise their work, revisit existing projects, and archive projects they no longer need.

Rather than treating every interaction as a separate conversation, Ghost Reel keeps the work connected to a documentary project.

This makes it easier to return to an earlier idea and continue developing it without starting over.

2. Research and Information Gathering

Good documentaries need more than interesting writing. They need research.

Ghost Reel includes a research workflow that can fetch and parse web pages, gather information, and extract factual claims from source material.

The purpose is to establish a research foundation before writing the documentary.

This helps separate the information gathered during research from the storytelling decisions made during script development.

The research stage is particularly important because documentary writing should not simply invent events or present unsupported statements as facts.

3. AI-Assisted Script Generation

Once the research is ready, Ghost Reel can generate a structured documentary script using Google AI Studio.

The script is organised into multiple scenes rather than delivered as one long block of text.

This structure helps creators think about the documentary visually and narratively.

A documentary needs a beginning that establishes the subject, a middle that develops the story, and an ending that gives the audience something meaningful to take away.

The goal is to use AI to assist with this process while keeping the creator involved in reviewing and shaping the final story.

4. Script Editing and Revision

Generated content should not automatically become the final documentary.

Ghost Reel includes a script-editing workflow where creators can revise the generated material, make changes, approve scenes, and track revision history.

This is an important part of the application because the creator should remain responsible for the documentary's direction.

AI can help organise ideas and produce a first draft, but the final decisions about accuracy, tone, structure, and storytelling belong to the person making the documentary.

5. Narration with ElevenLabs

A documentary is not only about what appears on screen. Narration plays an important role in how the audience understands the story.

Ghost Reel integrates ElevenLabs for scene-based narration generation.

Creators can generate narration audio for individual scenes and prepare those audio files as part of the documentary project.

Instead of treating narration as one large audio file, the workflow connects narration to the individual scenes.

This creates a more organised foundation for future editing and video production.

6. Storyboard and Scene Organisation

The storyboard provides a scene-by-scene view of the documentary.

Each scene can be considered in terms of its narrative purpose, visual concept, and transition to the next part of the story.

This helps creators move from written storytelling toward visual planning.

The storyboard is especially useful because a documentary script and a finished documentary are not the same thing. A script explains what should be communicated, while a storyboard helps plan how that information could be presented visually.

7. Captions and Presentation Settings

Ghost Reel also includes caption configuration.

Creators can configure caption typography, positioning, and language.

These settings help establish a consistent presentation style across the documentary.

Captions are an important part of video accessibility and can also help viewers follow narration when watching without sound.

8. Export Preferences

The application includes export settings for preferences such as aspect ratio, resolution, and audio mix.

These settings establish the intended output requirements for the future video-production stage.

The complete rendering pipeline is still part of the roadmap, but the export configuration provides a foundation for it.

The Technology Behind Ghost Reel

Ghost Reel is built using a modern mobile development stack.

Technology	How it is used
Expo SDK 58	Mobile application foundation
React Native 0.88	Cross-platform application interface
TypeScript	Application logic and type safety
Expo Router	Navigation and routing
SQLite	Local project and application data
Expo SecureStore	Secure storage for provider credentials
React Hook Form	Form state and input management
Zod	Data validation
Google AI Studio	AI-assisted documentary script generation
Gemma	Open-weight model technology targeted for the AI workflow
ElevenLabs	Documentary narration generation

The application uses a local-first approach for project management.

SQLite provides on-device persistence, while Expo SecureStore is used for API credentials.

For supported provider workflows, requests are made directly to the relevant services rather than being routed through a custom intermediary backend.

This architecture was chosen to keep the application focused and avoid introducing infrastructure that the current workflow does not need.

It also means that Ghost Reel depends on the availability and requirements of its connected providers. Direct API integration does not mean the application works entirely offline.

Architecture and Development Decisions

One of the important decisions in building Ghost Reel was to treat documentary projects as persistent application data.

A documentary project contains more than a title. It has research, scripts, revisions, scenes, narration, captions, and production preferences.

Keeping these elements organised locally gives the application a foundation for more advanced editing and production features.

Another important decision was to separate provider integrations from the main application experience.

The application should provide a consistent workspace even when different services are responsible for different tasks.

Google AI Studio supports the script-generation workflow, while ElevenLabs provides narration capabilities.

The application also uses secure device storage for API credentials rather than placing them directly into ordinary project records.

The broader architectural goal is to make Ghost Reel extensible without making the application unnecessarily complicated.

Why Does Open Innovation Matter?

Open innovation matters because the future of technology should not be limited to a small number of companies, platforms, or closed ecosystems.

Developers should be able to experiment with different models, tools, libraries, and services. They should have the freedom to combine technologies and create products that solve real problems.

Open-source software makes this possible by allowing people to learn from existing work, contribute improvements, and build on shared foundations.

Open-weight AI models also create new opportunities. They allow developers to explore how models can be used, adapted, and integrated into different applications.

For Ghost Reel, this is particularly relevant.

Documentary production is a creative process, and creators should not be forced into one fixed AI provider or one particular workflow.

I want Ghost Reel to remain flexible enough to support different technologies as the project develops.

There is also an important distinction between open innovation and simply using an API. A service being accessible through an API does not automatically make it open source, and using an open-weight model does not make every component of an application open.

The goal is to use open technologies where they make sense while maintaining a clear understanding of the responsibilities and limitations of every integrated service.

The Spirit of It: Ghost in the Machine

The theme Ghost in the Machine gave me an opportunity to think about something beyond the technical side of the project.

A documentary is a way of preserving stories.

It can preserve an event, a discovery, a personal experience, a historical moment, or an idea that might otherwise disappear.

Sometimes the most important stories are not the loudest ones. They are the stories that need someone to research them, organise the information, and give them a voice.

That idea connects naturally with Ghost Reel.

The application uses technology to help creators develop stories, but the purpose is not to replace the storyteller.

The technology works behind the scenes. The human creator decides what matters, what should be investigated, what should be included, and how the final story should be told.

In that sense, Ghost Reel is about using modern tools to help preserve and communicate stories.

It is a documentary workspace for turning information into something people can understand, experience, and remember.

Prize Categories

I would like to submit Ghost Reel for consideration in the following categories.

1. Best Overall Project

Ghost Reel is designed as a complete documentary-production workflow rather than a single-purpose AI feature.

Its combination of project management, research, script generation, editing, narration, storyboarding, captions, and export configuration gives it a broader product direction.

The aim is to demonstrate how different technologies can work together inside one useful application.

2. Best Use of Gemma

Gemma is relevant to Ghost Reel's AI-assisted storytelling direction.

The goal is to use an open-weight model to help creators develop structured documentary scripts and organise storytelling ideas.

This category recognises the potential of open-weight AI in a practical creative application rather than treating the model as an isolated demonstration.

3. Best Use of ElevenLabs

ElevenLabs supports the narration side of Ghost Reel.

The application connects narration generation to individual documentary scenes, allowing creators to prepare audio as part of a larger production workflow.

This makes voice generation a meaningful part of the documentary process rather than a separate text-to-speech experiment.

4. Best Use of Browserbase

Browserbase is relevant to the research direction of Ghost Reel.

Research is one of the most important stages of documentary production. Browser-based capabilities can help make research workflows more useful when information is available through web pages that require more advanced browser interaction.

The intended direction is to improve how creators gather and work with information from online sources.

5. Best Use of Ultramarine (Paper Instruments)

Paper Instruments is another technology I would like to highlight in the project.

The goal is to explore how its capabilities can contribute to the documentary workflow and support the wider production experience.

The important idea is to use partner technology as part of a practical product workflow, not simply mention a technology because it is available.

What's Next?

Ghost Reel is an evolving project. The current version focuses on organising the documentary workflow and preparing the materials needed for production.

There are several major areas I want to develop next.

Video Rendering and MP4 Export

The next major step is to turn the prepared documentary materials into an actual video.

This includes combining narration, visuals, captions, scene timing, and transitions into a finished MP4 file.

Visual Asset Acquisition

A documentary needs visuals that support its story.

The next stage is to improve how visual assets are discovered, organised, and associated with individual scenes.

Timeline Editor

A scene-based timeline editor would give creators more control over the final documentary.

It could bring narration, visuals, captions, and transitions into one editing environment.

More Advanced Research

Research can become more powerful through additional integrations and improved source handling.

The aim is to make it easier to work with different types of web sources while keeping the research process organised.

Backup and Portability

Device backup and project portability are also part of the future direction.

Creators should be able to protect their work and continue developing projects across devices.

Final Thoughts

Building Ghost Reel has been an opportunity to bring together mobile development, AI-assisted writing, research, and audio generation into one creative product.

The project is not finished in every possible sense. Video rendering, visual asset acquisition, and the timeline editor are still future development goals.

But the foundation is there: a mobile workspace where a creator can start with an idea, organise research, develop a documentary script, prepare narration, and plan scenes.

My goal is to keep improving Ghost Reel until it becomes a complete documentary-production studio that creators can carry with them.

Project: Ghost Reel

GitHub Repository: https://github.com/maisamabbas0323/ghostreel.git

Built with: Expo, React Native, TypeScript, SQLite, Google AI Studio, and ElevenLabs.

$1,000,000 for Open Source. The people behind the code deserve more recognition.

Maisam Abbas — Sun, 25 Oct 2026 09:10:03 +0000

Think about the tools you use every day as a developer.

JavaScript libraries. Frameworks. Databases. Testing tools. Build systems.

Many of them exist because developers spend countless hours building, fixing, securing, and maintaining open-source software.

But here’s the question:

If companies build billion-dollar products using open-source software, who supports the people maintaining it?

On October 21, 2026, Sentry announced that it had increased its annual open-source funding to $1 million.

The funding supports maintainers, critical dependencies, and open-source foundations. It includes $495,000 distributed through thanks.dev and $100,000 allocated through ecosyste.ms Funds.

This matters because open source is not simply code that everyone can download.

It is people giving their time to build tools that the entire world depends on.

Maintainers deserve sustainable funding, recognition, and support—not just another issue report or pull request.

My takeaway?

If your company depends on open source, giving back should be part of the business model.

And if you are a developer, consider sponsoring the projects you rely on, contributing code, improving documentation, or helping maintainers with issue triage.

Small contributions can make a real difference.

Read Sentry’s announcement:
https://sentry-blog.sentry.dev/another-year-another-1-000-000-to-open-source-maintainers/

What do you think: Should companies be expected to financially support the open-source projects they depend on?

Flowloom: Connect It Once. Let It Run. — Building a More Human Way to Automate Work

Maisam Abbas — Fri, 23 Oct 2026 07:34:50 +0000

Flowloom:

This is my submission for the Hacktoberfest Open-Source AI Challenge — Week 3: Slow and Steady.

What if the smartest thing we could do with technology was make it possible to do less repetitive work?

Think about a normal day as a developer.

You open a browser, visit a website, collect information, clean up some text, ask an AI model to process it, check the result, move information into another tool, and repeat the same process the following day.

None of those individual steps may be particularly difficult. But together, they consume time, attention, and energy that could have been spent building something meaningful.

I started building Flowloom around a simple question:

What if we could connect those steps once, run them as a workflow, and stop repeating the same manual process every time?

Flowloom is my Electron.js desktop application for visual workflow automation. It brings together workflow design, execution, browser automation, open-model AI, voice feedback, and document-oriented integrations in one environment.

The idea is simple: less repetitive work, more control over how that work gets done.

And for this week's theme, Slow and Steady, that is exactly the problem I wanted to explore.

What I Built

Flowloom is a visual workflow automation desktop application designed to turn repetitive sequences of actions into reusable workflows.

Instead of treating every task as a separate script or manually coordinating different services, Flowloom gives users a visual environment where workflow steps can be connected, executed, and inspected.

A workflow can be thought of as a sequence of small responsibilities:

A trigger starts the process.
A data or text node prepares information.
A browser action interacts with a website.
A condition determines which path to follow.
A delay or wait node controls timing.
An AI-powered step processes information when needed.
Logs and execution history help explain what happened.

The goal is to make automation easier to understand without sacrificing the technical capabilities that make it useful.

The problem is not always the task. It is repeating the task.

Imagine having to collect information from a web page every morning.

First, you open the browser. Then you navigate to the page, locate the relevant information, copy it, clean up the text, and move it somewhere useful. If the information needs further analysis, you might send it to an AI model. If the process involves a decision, you need to evaluate the result before moving forward.

Now imagine doing that for several pages, every day.

You are not necessarily solving a new problem each time. You are repeating a process you already understand.

That is the kind of friction Flowloom aims to reduce.

Rather than manually coordinating every action, users can organize the steps into a reusable workflow. Once configured and verified, that workflow can be executed again, with its progress and results available for inspection.

This is what makes the idea interesting to me: the application is not just about automating a single action. It is about making entire sequences of work easier to repeat.

What Flowloom brings together

1. Visual workflow editing

The workflow editor is the starting point. Users can arrange nodes, connect steps, and organize the sequence of actions that make up an automation.

The visual approach helps make the structure of a workflow easier to understand. Instead of searching through a long script to discover what happens next, users can inspect the connected steps.

2. A real execution layer

A visual workflow is only useful if the application can execute it.

Flowloom includes an execution engine designed around workflow nodes, conditions, delays, cancellation, execution history, and logging. These capabilities provide the foundation for turning a diagram into a process that actually runs.

3. Browser automation

Many repetitive tasks happen inside a browser. Flowloom integrates Browserbase to support browser-oriented workflows, bringing web interaction into the same environment as the rest of the automation.

4. Open-model AI

Some workflows need more than fixed rules. They may need to interpret text, summarize information, or transform content.

Flowloom is designed to support Gemma through configurable provider options, including Google, OpenRouter, and Ollama, depending on the selected setup.

5. Voice feedback

Automation should not always require users to stare at a screen and monitor every step.

The ElevenLabs integration is intended to provide spoken feedback for important execution events, making it possible to hear relevant updates while working on something else.

6. Document-oriented workflows

Documents are another source of repetitive work. Paper Instruments' Ultramarine model offers a potential way to bring AI-powered research, analysis, and drafting into workflows, while its document-related tools can support additional document-processing use cases.

The key is to use each integration for a real responsibility rather than adding a service simply to make a technology list look impressive.

Why I Chose a Desktop Application

I chose Electron.js because I wanted Flowloom to feel like a tool developers can work with directly, rather than just another web page they need to keep open.

Desktop applications provide a natural environment for settings, local configuration, workflow management, and persistent application state.

Electron also allows the application to use familiar web technologies for its interface while providing access to desktop capabilities through a carefully designed application architecture.

That does not automatically make every operation local or offline. External integrations still require their respective services and network connections, and local model inference depends on the user's configuration and available hardware.

However, the desktop approach creates room to combine local workflow management with optional external services.

The result I am working toward is an application that feels approachable on the surface while giving users meaningful control over how their workflows are configured and executed.

The Architecture: One Workflow, Multiple Capabilities

One of the most important ideas behind Flowloom is that individual integrations should contribute to a common execution model.

Consider a hypothetical information-processing workflow:

A trigger starts the workflow.
A browser action visits a configured website.
The workflow passes the collected information to a processing step.
Gemma helps transform or summarize the text.
A condition evaluates the result.
A document-oriented step can process the relevant content when configured.
Logs record the execution so the user can inspect the outcome.

This is an example of the intended workflow pattern, not a claim that every combination of these steps has already been verified end to end.

The important architectural principle is that each step has a clear responsibility and can pass information to the next step.

That separation matters. A browser integration should handle browser-related work. An AI provider should handle the language task it has been given. A condition should make a decision based on its inputs. The execution engine should coordinate the sequence and make its state visible.

When these responsibilities are separated, the application becomes easier to extend, test, and maintain.

It also creates opportunities to replace one provider without having to redesign every workflow around it.

How I Built It

Flowloom is built with Electron.js, with a focus on a visual workflow editor, a reusable execution engine, persistent workflows, and integrations with external AI and automation services.

I approached the project incrementally rather than trying to build every capability in a single step.

First: Establish the desktop foundation

The first priority was to create the application structure, its interface, and its settings architecture.

A desktop application needs more than an attractive window. It needs a clear separation between the user interface and privileged operations, predictable configuration, and a structure that can support additional capabilities without becoming difficult to maintain.

Second: Build the workflow editor

The next step was the visual workflow environment.

The editor provides a way to represent a process as connected nodes. This matters because the workflow itself should be understandable, not hidden behind implementation details.

The interface is intended to make the relationship between individual actions visible and help users understand how one step leads to another.

Third: Make workflows executable

The execution engine connects the visual structure to actual behavior.

Conditions, delays, cancellation, logging, and execution history are important because real workflows do not always follow a perfect path. They may need to wait, branch, stop, or expose an error.

An automation tool should not simply display a successful-looking diagram. It should make it possible to understand what happened when the workflow ran.

Fourth: Integrate specialized services

The project then brings together different capabilities through configurable integrations.

Gemma supports the open-model direction of the project.

Browserbase provides the browser-automation integration.

ElevenLabs supports the voice-feedback experience.

Paper Instruments' Ultramarine offers an AI model for research, analysis, drafting, and other suitable text-processing tasks.

Each service has a different role. The purpose of the architecture is to let these capabilities contribute to a workflow rather than forcing users to treat them as completely separate tools.

Fifth: Focus on configuration and reliability

API credentials should be configured securely, not embedded in source code. Model identifiers should follow the actual provider's supported configuration. External service failures should not be disguised as successful execution.

These details may be less visible than the interface, but they are essential for a trustworthy automation application.

My aim is to keep improving Flowloom as a real developer tool, with meaningful execution behavior and clear feedback rather than a collection of attractive but disconnected demonstrations.

The Role of Gemma: Open-Model Intelligence Inside a Workflow

Gemma is particularly relevant to Flowloom because the project is not just about invoking an AI model in isolation. It is about making model capabilities available as part of a larger process.

A workflow may need to summarize text, transform information into a more useful format, or help prepare content for a later step.

With an open-weight model such as Gemma, developers have more flexibility over how they deploy and integrate language intelligence.

Depending on the chosen provider and configuration, a model can be accessed through a hosted service or run locally through a compatible setup.

That flexibility is valuable because not every workflow has the same requirements.

Some users prioritize convenience. Others care more about cost, data handling, local execution, or the ability to change models as their needs evolve.

Flowloom's configurable provider approach is intended to accommodate those different choices.

The broader idea is that an AI model should be one component in a workflow, not a permanent dependency that dictates how the entire application must operate.

Browserbase: Bringing the Browser Into the Workflow

Browsers are where much of everyday digital work happens.

Research, information gathering, repetitive navigation, and web-based tasks often require the same sequence of interactions over and over again.

Browserbase makes browser automation a natural part of Flowloom's direction.

Instead of treating browser activity as a separate process outside the workflow editor, the application can organize browser actions alongside conditions, text processing, and other steps.

That opens the door to more useful automation patterns.

For example, a user could design a workflow that visits a configured page, gathers relevant information, and passes it to a later processing step.

The value is not simply that a browser can be controlled programmatically. It is that browser actions can become part of a larger, reusable process.

Browser automation also introduces important responsibilities. Websites change, network requests fail, and some actions can have consequences. A serious implementation needs appropriate URL handling, error reporting, cancellation, and clear visibility into what the automation actually did.

Those considerations are part of making automation dependable rather than merely impressive in a short demonstration.

ElevenLabs: Giving Important Events a Voice

Most automation tools communicate through text, logs, and visual indicators.

That is useful, but it also means users may need to keep looking at the application to understand what is happening.

The ElevenLabs integration explores another possibility: spoken feedback for important workflow events.

For example, a configured workflow could announce a meaningful status change or provide a short notification when a relevant step finishes.

The objective is not to narrate every internal operation. Constant narration would quickly become another distraction.

Instead, voice feedback should be selective and useful.

This is especially interesting for people who are multitasking or who prefer receiving certain updates without continuously monitoring the application window.

Voice does not replace execution logs or detailed error information. It complements them by making important events easier to notice.

For Flowloom, that creates an opportunity to make automation feel less like watching a machine operate and more like receiving useful updates from a tool that is working in the background.

Paper Instruments and Ultramarine: AI for Document Work

Documents contain a large amount of the information people work with every day.

Reading reports, extracting important points, preparing summaries, and transforming unstructured text into something useful can all involve repetitive effort.

Paper Instruments' Ultramarine model is relevant to this problem because the Hacktoberfest partner category specifically encourages real applications involving research, analysis, drafting, or reasoning over documents.

In Flowloom, this offers an opportunity to explore document-oriented tasks as part of a workflow.

A configured process might take text from an earlier step, ask an AI model to analyze or summarize it, and pass the result to another step.

The document libraries offered by Paper Instruments may also be relevant where actual Word, PowerPoint, or Excel files need to be processed, subject to their documented capabilities and the implementation.

There is an important distinction here: an AI model processing text is not the same thing as a document-editing library manipulating a real file. Each capability should be integrated according to what it actually supports.

For this challenge, the most valuable use would be a real, reproducible document-processing workflow with a clear input, useful output, and transparent usage information.

Why Does Open Innovation Matter?

This is the part of Flowloom that matters beyond the integrations themselves.

Open innovation is not just about using a technology with an open-source label. It is about having the freedom to understand, adapt, replace, and build on the components that make an application useful.

For Flowloom, that freedom matters in several ways.

1. Model choice should remain a choice

Different models are useful for different tasks. Different providers have different costs, requirements, and deployment options.

A workflow application should not force every user into a single model provider if its tasks can be handled through a compatible alternative.

By designing around configurable providers, Flowloom can make room for different approaches to language intelligence.

2. Local inference can offer more control

When a compatible open-weight model runs locally, some processing can happen on the user's own machine rather than being sent to a hosted model service.

That can be valuable for privacy, experimentation, and reducing dependence on a remote inference endpoint.

It is not a guarantee that the entire Flowloom application works offline. Browserbase, ElevenLabs, and other hosted integrations still require network access when used. But local model inference can give users a meaningful option for the tasks it supports.

3. Interoperability makes experimentation easier

A workflow becomes more flexible when individual steps have clear inputs and outputs.

If an AI provider can be replaced without rewriting browser automation, or a document-processing step can be added without redesigning the entire interface, experimentation becomes easier.

That flexibility encourages developers to test alternatives and choose tools according to actual requirements rather than convenience alone.

4. Developers can learn from the building blocks

Open models and open-source tools allow developers to study implementation choices, explore alternative configurations, and contribute improvements.

That matters for a project like Flowloom because automation sits at the intersection of multiple technical areas: application architecture, workflow orchestration, AI integration, browser control, and user experience.

The more replaceable and understandable the components are, the easier it becomes to keep learning and improving.

5. Freedom should include practical trade-offs

Open-weight does not automatically mean free to run in every environment. Local inference requires compatible hardware and consumes resources. Hosted services can have usage charges. External integrations may introduce their own limits.

A useful open approach makes those trade-offs visible rather than pretending they do not exist.

For me, open innovation means being able to make those choices instead of having every decision made by a single provider.

The Lazy Payoff: Make Repetition a One-Time Design Problem

The theme of Slow and Steady is a reminder that saving effort does not always require building something enormous.

Sometimes the most useful improvement is to stop solving the same small problem every day.

Consider a task that takes five minutes and needs to be repeated ten times.

That is fifty minutes of repeated work.

If a reliable workflow reduces the amount of manual coordination required, the benefit can accumulate over time. The value becomes even more noticeable when the workflow is reused across many sessions.

But there is a catch: an automation only saves time if it works reliably enough to justify the effort of setting it up.

A workflow that silently fails, produces incorrect information, or requires constant manual repair can create more work than it removes.

That is why execution history, logs, cancellation, and clear error handling matter as much as the ability to connect nodes.

The objective is not to automate everything simply because automation is possible.

It is to identify repetitive work, design a process that genuinely helps, verify that it behaves as expected, and reuse it when the same need comes back.

I am not claiming a measured percentage of time saved without verified before-and-after results. The practical payoff I am targeting is reduced repetition and a more reusable way to coordinate everyday tasks.

Do the work of designing the process once. Let the process do its part afterward.

What Makes Flowloom Different From a Single-Purpose AI Tool?

A conventional AI interface usually starts with a question: what do you want the model to generate?

That is useful for one-off tasks. But many real-world processes involve more than generating text.

They may require navigating a website, passing information between steps, evaluating a condition, waiting for an operation to finish, processing a result, and recording what happened.

Flowloom explores a different starting point: what sequence of actions should happen, and how should those actions work together?

That shift from a single interaction to a reusable workflow changes the role of AI.

Instead of being the entire product, AI becomes one of several capabilities that can contribute to a larger process.

Browser automation can handle web interaction. An open model can process language. A condition can control the next step. Voice feedback can communicate an important event. Logs can preserve a record of execution.

The workflow provides the structure that connects them.

That does not make Flowloom a replacement for every specialized tool. Rather, it gives users a place to organize compatible capabilities around a particular task.

Challenges and Lessons

Building a desktop automation application introduces problems that are easy to underestimate.

A visual connection is not the same as a working integration. Every node needs a defined behavior, appropriate inputs, meaningful outputs, and error handling.

External services are not interchangeable in every detail. Providers have different authentication methods, API formats, limits, and capabilities. Configuration and integration code need to respect those differences.

Automation must remain observable. Users need to know whether a workflow is running, what has completed, and where a failure occurred.

User control matters. Cancellation, careful handling of credentials, and sensible restrictions around browser actions are essential when an application can perform real work.

A polished interface needs a reliable foundation. A clean workflow editor is valuable, but its usefulness depends on the execution engine underneath it.

These lessons reinforce the same principle: a successful automation application needs to balance ease of use with transparency and control.

How to Explore the Code

Flowloom is available on GitHub:

maisamabbas0323/flowloom

Clone the repository:

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

For installation and development, follow the repository's current README and setup instructions.

Depending on which integrations you want to use, you may need to configure credentials for the relevant services. Keep secrets in local environment configuration and never commit API keys to a public repository.

The project is being developed around the idea of a desktop workflow environment that can grow as additional nodes and integrations become useful.

If you explore the repository, I would be interested in feedback on workflow design, execution reliability, integration boundaries, and ways to make automation more understandable.

Prize Categories

For this submission, I am focusing on categories that align with Flowloom's actual technology and intended capabilities.

The official Week 3 challenge lists a $250 overall prize, six featured categories worth $200 each, and partner categories worth $100 each. A valid submission can be considered for the overall prize and every partner category it genuinely qualifies for, although a participant can win only once in the challenge. See the official Week 3 challenge page for the full rules and criteria.

Best Use of Gemma — $200

My strongest featured-category target.

Flowloom is built around the idea that open-model AI should contribute to useful, repeatable workflows rather than remain isolated in a chat interface.

Gemma can support language-processing tasks inside those workflows, while configurable provider options give users flexibility in how they access the model.

To make this category especially strong, the project should demonstrate a concrete Gemma-powered workflow: show the input, explain the task, display the resulting output, and make clear which provider and model were used.

The important point is not merely mentioning Gemma. It is demonstrating how the open-weight model makes the application more useful and why that use fits the Slow and Steady theme.

Best Use of Browserbase — $100

Browserbase fits Flowloom's goal of making browser tasks part of reusable workflows.

Rather than automating a website as a disconnected, one-off script, the application can organize browser interaction alongside other workflow steps.

A compelling entry would show a real browser action, explain the information it returns, and demonstrate how that output is used by the next step.

The strongest evidence would be a reproducible end-to-end workflow, with execution logs or screenshots that distinguish actual browser activity from a static mockup.

Best Use of ElevenLabs — $100

ElevenLabs adds a voice dimension to the workflow experience.

The idea is to communicate important execution events through spoken feedback, allowing users to stay informed without constantly watching the application.

For this category, the clearest demonstration would show a meaningful workflow event, the corresponding spoken output, and why that notification is more useful than simply adding narration everywhere.

A focused, practical use of voice is stronger than adding speech without a clear purpose.

Best Use of Ultramarine — Paper Instruments — $100

Paper Instruments' Ultramarine model is a separate partner-category opportunity.

The challenge specifically encourages using Ultramarine for real research, analysis, drafting, or document-oriented reasoning, and asks entrants to state what their run actually cost.

For Flowloom, the most convincing use would be a working node that accepts real input, performs a useful AI task through Ultramarine, and passes the result to a subsequent workflow step.

If the workflow processes a document, it should be clear whether the model is analyzing extracted text or a separate library is manipulating the actual file.

For a strong submission, I would include the model configuration, a small reproducible example, the resulting output, and the actual usage cost reported by the service. I would not invent cost savings or remaining credit.

The overall Hacktoberfest prize — $250

The overall prize is not tied to a single partner. It rewards the strength of the project as a whole.

For Flowloom, that means telling a clear story about the problem, explaining how the workflow engine works, showing that the integrations perform meaningful tasks, and demonstrating why open-model flexibility matters.

The project should stand on its own even if a judge does not focus on any individual partner integration.

The most important evidence is a working application that addresses repetitive work, uses open-source AI or an open-weight model meaningfully, and communicates its design and trade-offs clearly.

My strategy

I am prioritizing Best Use of Gemma as the featured category and exploring Browserbase, ElevenLabs, and Ultramarine as partner categories where the implementation supports a genuine entry.

I would rather demonstrate a smaller number of real, well-explained capabilities than claim every category based on a service name or an API key alone.

The challenge asks builders to show what they made, how it works, and why open innovation matters. That is the standard I want Flowloom to meet.

Prize eligibility is determined by the official rules and judges, not by the categories listed in a post.

What's Next?

Flowloom is an ongoing project, and the next steps are about making its workflows more dependable, understandable, and useful.

I want to continue improving the relationship between the visual editor and the execution engine, make integration behavior easier to inspect, and ensure that errors and limitations are visible rather than hidden behind a polished interface.

I also want to explore more real-world examples where multiple workflow steps work together to solve a problem that would otherwise require repetitive manual effort.

The larger vision is a desktop environment where developers can choose their AI models and services, design workflows visually, and reuse those workflows whenever the same task returns.

Not every task needs an agent. Not every problem needs another API. And not every useful automation needs to be complicated.

Sometimes, the most valuable thing software can do is give us back the time we spend repeating ourselves.

Final Thoughts

Building Flowloom has made me think about automation less as a collection of impressive capabilities and more as a question of how technology fits into everyday work.

A visual editor is useful when it makes a process easier to understand. An AI model is useful when it solves a real problem. Browser automation is useful when it removes repetitive interaction. Voice feedback is useful when it communicates something worth hearing.

The real opportunity appears when those capabilities work together in a reusable process.

That is the idea I wanted to explore with Flowloom: an application where open-model AI and specialized tools can contribute to a workflow that users can configure, run, and inspect.

The Slow and Steady theme is a good fit because meaningful productivity is not always about moving faster. Sometimes it is about removing the unnecessary work that keeps making us repeat the same steps.

Flowloom — Connect it once. Let it run.

Built with a simple goal: less repetition, more control, and more time for the work that matters.

Project: Flowloom on GitHub

Hacktoberfest #OpenSource #AI #Gemma #ElectronJS #Browserbase #ElevenLabs #Ultramarine #PaperInstruments #Automation #DeveloperTools

PHP2Shell: Two Critical PHP Vulnerabilities Every Developer Should Know About

Maisam Abbas — Fri, 23 Oct 2026 03:25:32 +0000

A security alert that every web developer should pay attention to.

According to The Hacker News, two critical vulnerabilities in PHP have been identified:

CVE-2026-109618
CVE-2026-109619

Both have a reported CVSS v4.0 score of 9.2/10. They could allow attackers to execute malicious code on vulnerable servers without logging in. PHP released security fixes on October 21, 2026.

Why does this matter?

PHP powers many websites and web applications. A vulnerability in the PHP runtime can put a website at risk even when its application code appears secure.

What should developers do?

Check which PHP version their servers are running.
Apply the appropriate security updates immediately.
Restart PHP workers and verify that the patches are active.
Review server logs for suspicious activity.
Avoid running untrusted exploit scripts found online.

The key lesson is simple: writing secure code is important, but keeping the underlying technology updated is equally important.

Security is not something we do once. It is part of every developer's responsibility.

Read the full report from The Hacker News:

https://thehackernews.com/2026/10/php2shell-two-unpatched-critical-php.html

What do you think: do developers pay enough attention to server-level security, or do most people focus only on their application code?

CyberSecurity #PHP #InfoSec #WebDevelopment #DevSecOps #DEVCommunity

VoxTerm: the terminal that listens — my side hustle for Hacktoberfest Week 2

Maisam Abbas — Sun, 18 Oct 2026 09:20:22 +0000

I type for a living. So do you, probably. And somewhere along the way we all
started typing more — not to write code, but to explain what we want the code
to do. Long, careful prompts. Paragraphs that are really just me talking to a
machine that only listens through a keyboard.

One night I caught myself: I had a perfect sentence in my head, and I was
hunting for the keys to spell it out one letter at a time. That felt absurd.
I own a microphone. My computer owns a microphone. Why am I still typing?

VoxTerm started as a question — what if the terminal just listened? — and
became a genuine side-hustle-shaped product: a premium desktop workspace for
real operating-system shells where you dictate a prompt, it gets cleaned up by
an open-weight model, and it lands in your shell ready to run. You still press
Enter. That part matters.

What I Built

VoxTerm is a desktop terminal workspace (Electron + React + xterm.js) built
around one honest idea: every button does the thing it says, or it tells you why
it can't.

It is a real terminal first — genuine node-pty sessions running bash, zsh,
fish, anything on your $PATH, with correct input/output, resize, Unicode and
cleanup. On top of that foundation it adds the things a developer actually
wants when they're deep in a session:

🎙 Dictation into the shell. Hold a hotkey, speak, release. Your words are transcribed and typed into the active terminal. Never auto-executed — you review and hit Enter.
🤖 Prompt cleanup with open-weight Gemma. The raw transcript gets rewritten by a fallback chain — local Ollama first, then Google's hosted Gemma — so "make it list the big files in downloads" becomes a crisp shell command.
🔒 A real privacy switch. Local-only mode refuses every cloud request at the service layer. Pair it with Ollama and nothing ever leaves the machine.
🖧 Attach to sessions you already have. Live discovery of tmux/screen sessions running outside the app, with exact $N-id targeting and honest caveats when a session is shared.
🔊 Spoken announcements. ElevenLabs text-to-speech for events the app can actually confirm — a build error, a session exit, an agent milestone.
🧩 Agent-agnostic. OpenCode, Claude Code, Codex CLI, Gemini CLI, Aider — detected by what's genuinely installed, nothing fabricated.

Who would pay for it? This is aimed at the professional who lives in a
terminal and bills by the hour — backend and platform engineers, DevOps and SRE
folks, data engineers, and the fast-growing crowd of developers who now drive
coding agents from the CLI all day. For them, typing is the last slow part of
the loop. A tool that removes friction without removing control is worth
money.

The problem it solves, in one line: it turns the most tedious part of
working with AI — writing the prompt — into the most natural thing a human does:
talking. And it does it without ever taking the wheel away from the driver.

The Terminals view. Real shells, real tabs, and a dictation that just landed as
editable text — not an executed command.

Code

The whole thing is open source under MIT:

maisamabbas0323 / voxterm

VoxTerm 'hacktoberfest week#2 challange' is a cross-platform voice-controlled terminal for developers, enabling natural multilingual voice commands for OpenCode, Claude Code, Codex, and other coding agents with offline speech recognition and intelligent prompt refinement. Built with Electron.js for Linux, Windows, and macOS.

VoxTerm

Type less. Talk more. Ship code.

A premium, voice-ready terminal workspace for developers — real operating-system shells, speech-to-text dictation, agent-agnostic CLI sessions and an explicit honest human-in-the-loop workflow.

Why VoxTerm

Most "AI terminals" are a chat box bolted onto a shell, wrapped in marketing. VoxTerm is the opposite: a genuinely good terminal first, with voice and local models added where they actually help — and every control either does the thing it claims or tells you exactly why it can't.

Concretely:

Real shells,…

View on GitHub

If the embed doesn't render: github.com/maisamabbas0323/voxterm

A quick tour of what's inside:

Layer	What it does
`src/main/terminals`	Owns every `node-pty` process — never the renderer
`src/main/voice`	ElevenLabs speech-to-text + the global push-to-talk hotkey
`src/main/prompts`	The Ollama → Google Gemma fallback chain and its instructions
`src/main/external`	tmux/screen discovery and precise attach targeting
`src/shared`	Zod schemas + the typed IPC contract, shared by both sides

How I Built It

The stack is intentionally boring where it should be, and interesting only where
it earns it.

The shell is sacred. VoxTerm is a real terminal first. Every tab is a
node-pty process owned entirely by the Electron main process; the renderer
just sends keystrokes and receives output over a typed, Zod-validated IPC
bridge. The renderer is sandboxed with context isolation and no Node access, so
a bug (or a malicious page) can't reach your filesystem through the UI. This
isn't paranoia — it's the difference between a tool you trust with your shells
and one you don't.

The AI is open-weight and yours to run. For prompt cleanup I didn't want to
hard-wire one company's API into the core loop. So VoxTerm calls a fallback
chain:

Ollama first — a fully local, open-weight Gemma model on your own machine. This is the default the product is designed around, because it's the one that makes the privacy promise real: nothing leaves your computer.
Google AI Studio's hosted Gemma as the fallback for machines that can't run a local model — reached with your own API key against the official endpoint, with no configurable base URL to get wrong.

That ordering is the whole point. It means the "free and private" path is the
primary path, and the cloud is the convenience path — not the other way
around. Speech-to-text and spoken announcements go through ElevenLabs because
good real-time transcription and natural TTS are genuinely hard to match with a
small local model today, and the app is upfront in the UI that dictation audio is
sent to that service.

The engineering rule I refused to break: no fake buttons, no invented
statistics, no placeholder sessions. If a feature isn't wired up, it's disabled
and labelled. Provider status is a real network probe. "Detected tooling" is a
real filesystem lookup with the resolved path and version. The activity log
stores metadata only — never your terminal output, never env vars, never secrets.
Honesty became an architecture decision, not a marketing line.

Settings shows real provider reachability and a one-switch local-only mode. The
voice controls live here too — no separate "AI panel" pretending to be useful.

A few of the tools that made this buildable: Electron 44, React 19,
xterm.js 6, node-pty, Zod 4, electron-vite / Vite 7,
Vitest 5, and lucide-react for every icon (SVG only — no emoji avatars,
no decorative AI sparkle). It's verified with 105 unit tests, a headless
Chrome-DevTools-Protocol UI smoke test, and real calls against both providers.

Why Does Open Innovation Matter?

VoxTerm would be a worse product if it had been built around a single closed API.
Here's concretely why.

Open weights made the privacy promise possible. The entire premise —
"your voice, your prompts, your machine" — only works because I can run a
capable model like Gemma locally through Ollama. A closed, cloud-only model
would have forced every prompt through someone else's servers, and "local-only
mode" would have been a lie I couldn't tell. Open-weight models turned a privacy
feature into a privacy fact.

Open source let me build a terminal I actually trust. node-pty, xterm.js,
Electron, Zod, Vite — I read the code, patched around edge cases, and shipped
because thousands of people already solved the hard parts in public. That's the
quiet superpower of open innovation: nobody has to rebuild a PTY from scratch to
make something new on top of it.

It keeps the exit door open. Because the provider layer is a chain and not a
contract, you can swap Ollama for a different local runner, add another hosted
model, or run entirely offline — without asking anyone's permission or waiting
for a pricing page to change. That's what open innovation buys you: the ability
to keep building when the ground shifts underneath you.

And honestly? It's just nicer. Building in the open meant every design choice
was a conversation with how real tools behave, not a negotiation with a vendor's
roadmap.

My First User

The first person to actually open VoxTerm wasn't a customer — it was a friend who
lives in tmux and has opinions about everything. I handed them the build, watched
them attach to a session they already had running, dictate one command, and go
quiet for a second.

Then: "Okay, that was faster than typing it. That's annoying. I want it."

They haven't paid me — this is still a side project finding its feet, and I'd
rather say that plainly than invent a fake invoice. But "I want it" from someone
who is not impressed by anything is the signal I actually trust. The next step is
turning that into the boring, unglamorous part of a side hustle: a pricing page,
a signed build, and a handful of real users who'll tell me what's still wrong.

Prize Categories

Given what VoxTerm is built on and how it's verified, I'm entering the categories
that genuinely apply — I'll confirm the exact list from the challenge page before
publishing:

Best Use of Open-Source AI — the core loop runs on open-weight Gemma via a local Ollama first, with a hosted fallback.
Best Use of ElevenLabs — ElevenLabs does real work in two places, not a decorative bow: speech-to-text turns a held hotkey into a transcript that lands straight in the shell, and text-to-speech speaks only the events a developer actually cares about (a crash, a finished agent step) — never your terminal output, never your secrets. Both paths are privacy-gated, clearly labelled in the UI, and wired so the local/open-weight model stays the default.
Best Developer Tool — a real desktop terminal for professional workflows.
Best Side Hustle — built to be something people would actually pay for, not a demo.

What's Next

VoxTerm isn't a weekend sketch that stops at the demo. The roadmap is the same
list a paying user would care about:

Per-agent adapters so the terminal can understand agent events instead of just displaying them.
Word-timestamp highlighting in the dictation flow, so you can see what the model thought you said.
A signed, packaged release and a real pricing model.
macOS and Windows follow behind Linux — I'd rather ship one platform well than three badly.

If you're the kind of person who types Ctrl+R and then apologises to your shell
— give it a try, break it, and tell me where it hurts. That's the only way a side
hustle becomes something worth paying for.

Repo: https://github.com/maisamabbas0323/voxterm
License: MIT
Built with: Electron, React, xterm.js, node-pty, Zod, and open-weight Gemma
via Ollama.

Type less. Talk more. Ship code.

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.

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.