WHAT IS THIS RUBBER DUCK FOR?

This is a submission for the DEV April Fools Challenge

What I Built

The starting point was a brief moment in Harry Potter and the Chamber of Secrets, when Arthur Weasley asks Harry: "what exactly is the function of a rubber duck?"

I took that very essential question as the basis for the project and turned it into a ministerial interface for the formal examination of a yellow plastic duck.
So I built What Is This Duck For?, a web app that treats a rubber duck as a matter of public administration, emotional uncertainty, procedural concern, and possible domestic surveillance.

The app lets visitors submit the duck to five official interpretive modes:

• Analyze the Duck — a mock-expert technical reading
• Request Deeper Interpretation — overthinking, philosophical drift
• Escalate to Ministry — paperwork, forms, bureaucratic misery
• Trust the Duck — calm reassurance and quiet faith
• Do Not Trust the Duck — bathroom paranoia and suspicious side-eye

Each mode generates a formal “ministerial report” with a hypothesis, classification, threat level, confidence score, and conclusion. The result is mildly concerning, far more official than necessary, and hopefully funny.

Demo

You can try the live demo here:

Live Demo

The interface is designed to feel strangely official for something that should never have required official attention in the first place.

A typical session looks like this:

• choose a mode
• trigger the inquiry
• watch the report compile itself
• leave with fewer answers than you started with

Code

Source code is available here:

GitHub Repository

The project includes:

• a FastAPI backend
• Gemini 2.5 Flash
• a custom frontend with a ministry-style interface
• prompt-based persona logic
• an About page explaining the investigation as if it were a real institutional service
• custom duck persona assets for each official mode

How I Built It

I built the app with FastAPI, server-rendered templates, custom CSS, and JavaScript for the interactive report flow.

The biggest part of the work was not _“building a useful product,” _but overbuilding a completely useless one with as much conviction as possible.

A few highlights:

• I designed the homepage as a fake bureaucratic dashboard
• I created five distinct duck-analysis personas with different tones and behaviors
• I refined the generated writing so each mode felt readable, funny, and specific
• I added custom duck visuals for each persona on the About page
• I deployed the demo on Hugging Face Spaces

For the AI side, I worked with Gemini CLI from the beginning, using it throughout the project to build, refine, and steer the experience. On the generation side, I used Google Gemini to produce structured, persona-driven reports that stayed coherent, readable, and funny.

One of the most interesting challenges was building the five analysis personas so they produced outputs that felt distinct, coherent, and consistently funny without becoming repetitive. That required a lot of prompt iteration — especially around the relationship between hypothesis and conclusion — and a gradual shift away from pure absurdity toward a more structured comic logic, all with Gemini 2.5 Flash.

Agents Sessions

1 - This initial prompt defined the joke, the scope, and the rules of the project from the start.

what_is_the_duck_for - initial prompt initial prompt

You

You are my coding assistant. I am building a deliberately silly challenge project called "What Is This Duck For?".

Context:
- This project is for a challenge whose spirit is: build something intentionally useless, funny, light, absurd, and simple.
- The concept: a very serious interface uses Google Gemini to analyze a yellow rubber duck, but never reaches a useful conclusion.
- This is NOT a serious product, NOT an MVP, NOT a scalable app.
- It must stay small, clean, readable, and fun.
- No overengineering.

Your role for this step:
Bootstrap the project environment from scratch inside the current workspace.

Current state:
- Workspace already exists.
- A Python virtual environment .venv already exists.
- Nothing else is installed yet.

Technical direction:
- Python backend with FastAPI
- Simple frontend with HTML/CSS/vanilla JS
- Gemini API integration later
- No database
- No authentication
- No React
- No Docker for now
- No testing setup yet unless strictly necessary
- Keep the architecture minimal

What I want you to do now:
1. Inspect the current workspace first.
2. Activate/use the existing .venv.
3. Install only the minimal dependencies needed for the initial project skeleton:
- fastapi
- uvicorn
- jinja2
- python-dotenv
- google-genai
4. Create a clean minimal project structure for this app.
5. Add a .gitignore.
6. Add a .env.example.
7. Add a minimal README.md that presents the project in the spirit of the challenge.
8. Add the minimal FastAPI app skeleton and the basic template/static folders, but do NOT build the full app yet.
9. Make sure the structure is simple and easy to continue step by step.

Recommended structure:
- app/
- main.py
- gemini_service.py
- prompts.py
- templates/
- index.html
- static/
- css/
- style.css
- js/
- app.js
- img/
- .gitignore
- .env.example
- README.md
- requirements.txt

Important constraints:
- Do not invent extra features.
- Do not add database, auth, admin panel, API complexity, or unnecessary abstractions.
- Do not implement the real Gemini logic yet beyond placeholder structure.
- Do not generate a complex UI yet.
- Keep names explicit and readable.
- Keep the codebase lightweight and hackathon-friendly.
- Prefer clarity over cleverness.

After you make the changes:
1. Show me the final file tree.
2. Explain briefly what you installed and created.
3. Tell me exactly what command I should run next to start the app locally.
4. Mention any point that still needs my manual input, especially the Gemini API key.

If something is ambiguous, make a reasonable minimal choice and state it clearly.

Show more

24 messages not shown

Agent

Providing the Final Response

The project "What Is This Duck For?" is now bootstrapped with a minimal FastAPI skeleton and a clean directory structure.

Final File Tree

.
├── app/
│   ├── static/
│   │   ├── css/
│   │   │   └── style.css
│   │   ├── img/
│   │   └── js/
│   │       └── app.js
│   ├── templates/
│   │   └── index.html
│   ├── gemini_service.py
│   ├── main.py
│   └── prompts.py
├── .env.example
├── .gitignore
├── README.md
└── requirements.txt

What was installed and created:

1. Dependencies: fastapi, uvicorn, jinja2, python-dotenv, and google-genai were installed into your existing .venv. A requirements.txt was generated.
2. Backend Skeleton: Created app/main.py with basic routing and static file serving.
3. Gemini Service: Added app/gemini_service.py and app/prompts.py as placeholders for the AI logic.
4. Frontend: Built a minimalist "Advanced Rubber Duck Analytics" interface using vanilla HTML, CSS, and JS.
5. Project Docs: Added a README.md in the spirit of the challenge and a .env.example for configuration.

How to start the app locally:

1. Prepare Environment: bash cp .env.example .env
2. Run the Server: bash .venv/bin/uvicorn app.main:app --reload
3. View the App: Open your browser at http://localhost:8000.

Manual Input Needed:

• Gemini API Key: You need to edit the .env file and provide a valid GEMINI_API_KEY.
• Duck Image: I've created the app/static/img/ folder. You might want to drop a picture of a rubber duck there later to replace the CSS placeholder.

Show more

36 messages not shown

You

You are my coding assistant.

We are continuing the project:
WHAT IS THIS DUCK FOR?

Important:
Do not implement the Gemini engine yet.
Do not redesign the UI.
Do not add backend complexity.
This step is about documentation, planning, and locking the behavior of the 5 buttons.

PROJECT STATE

The interface now includes the 5 final action buttons:
1. ANALYZE THE DUCK
2. REQUEST DEEPER INTERPRETATION
3. ESCALATE TO MINISTRY
4. TRUST THE DUCK
5. DO NOT TRUST THE DUCK

We want to keep the project simple and organized.
So before implementing the engine, we want:
- a small docs folder
- a clear planning document
- a task checklist we can follow and update
- a mini-spec for the 5 button modes

YOUR TASK

1. Create a docs/ folder at the project root.

2. Inside docs/, create these files:

• project_plan.md
• task_checklist.md
• button_modes.md

1. Fill them with simple, practical, readable content.

CONTENT REQUIREMENTS

A) docs/project_plan.md
Create a short project plan that reflects the real order of work:

• current state
• what is already done
• what comes next
• what should come later

The order should be:

1. Environment bootstrap
2. Basic app skeleton
3. UI base
4. Final button set in the interface
5. Lock the behavior of each button
6. Implement Gemini interaction
7. Polish the UI and visual identity
8. Final cleanup / submission preparation

Keep it concise.
Do not write corporate/project-management jargon.
Write it like a practical internal roadmap.

B) docs/task_checklist.md
Create a checklist with markdown checkboxes.

Include:
- completed tasks
- current tasks
- upcoming tasks

Use clear checkboxes like:
- [x] ...
- [ ] ...

Include at least:
- project bootstrapped
- FastAPI skeleton created
- single-page UI created
- 5 final buttons added
- button behavior spec pending
- Gemini backend pending
- report panel dynamic update pending
- rubber duck visual improvement pending
- aesthetic polish pending
- README/submission refinement pending

C) docs/button_modes.md
This is the most important file for this step.

Write a mini-spec for the 5 buttons.

For each button, define clearly:
- button label
- internal mode name suggestion
- role
- tone
- type of absurdity / angle of error
- expected response style
- what kind of conclusion it should tend to produce

Use these 5 buttons exactly:

1. Analyze the Duck

2. base pseudo-scientific analysis

3. Request Deeper Interpretation

4. over-interpretation / intellectual overreach

5. Escalate to Ministry

6. absurd bureaucracy / official classification

7. Trust the Duck

8. confident mystic reading / symbolic authority

9. Do Not Trust the Duck

10. suspicious administrative paranoia

IMPORTANT RULES

• Keep all docs short and useful.
• Do not overengineer.
• Do not add product language.
• Do not implement code logic yet unless absolutely necessary.
• Do not change the backend or Gemini integration in this step.
• If you need to make a very small frontend text adjustment for consistency, keep it minimal and list it explicitly.

OUTPUT REQUIRED

After making the changes, show me:

1. the final file tree for the new docs/ folder
2. the full contents of:
3. docs/project_plan.md
4. docs/task_checklist.md
5. docs/button_modes.md
6. a short explanation of how these docs will help the next implementation step
7. if you changed any file outside docs/, list it explicitly

Show more

Agent

Structuring Project Documentation / Outlining the Button Spec / Formulating Button Mode Details / Executing the Plan's Steps

I will create the docs/ directory and populate it with the project plan, task checklist, and button mode specifications.

7 messages not shown

Agent

I have created the requested documentation and planning folder.

Final File Tree for docs/:

docs/
├── button_modes.md
├── project_plan.md
└── task_checklist.md

Contents Summary:

• project_plan.md: Provides a concise, practical roadmap from project bootstrap to final cleanup, focusing on building a "serious, useless" application.
• task_checklist.md: Lists all completed, current, and upcoming tasks with markdown checkboxes, covering infrastructure, interface, and AI integration phases.
• button_modes.md: A detailed specification for the five analysis buttons, defining their internal mode names, tones, absurdity angles, and expected response styles.

How these docs will help:

• Consistency: button_modes.md ensures that as we implement the AI prompts, each mode remains distinct and follows its intended "absurdity angle" (e.g., dry science vs. mystic prophecy).
• Focus: project_plan.md keeps the project scope narrow, preventing feature creep and maintaining the simple, single-page concept.
• Organization: task_checklist.md allows us to track our progress accurately and ensures we don't skip the crucial "polish" steps at the end.

No files were changed outside of the docs/ folder in this step. We are now ready to implement the backend logic to handle these specific modes.

Show more

Slice: initial prompt · 5 of 102 messages

2 - Persona Refinement | Making “Ministry” Funnier and More Concrete

Persona building | what is duck for persona_building

You

We are doing a targeted correction pass on the "ministry" persona only.

Do not change frontend.
Do not change backend flow.
Do not change logging.
Do not change JSON schema.
Do not modify the other personas unless strictly necessary.

DIAGNOSIS

The other personas are now much closer to the desired result.
The main remaining failure is "ministry".

Current problem:
"ministry" still tends to generate bureaucratic worldbuilding instead of a clear comic theory of function.

It produces:
- too much administrative texture
- too many clauses, sections, and procedural layers
- too much fake-ministry prose
- not enough immediate sense

The result is coherent in tone, but not funny enough and not clear enough.

CORRECTION GOAL

The ministry persona must no longer feel like:
"a generic bureaucratic monologue"

It must feel like:
"a civil servant calmly explaining the duck’s specific administrative function and the ridiculous procedural consequences attached to it"

NEW RULES FOR MINISTRY

1. The hypothesis must clearly state what the duck is administratively FOR.
   It must describe a concrete official or semi-official function.

2. The function must be simple, specific, and readable.

3. The conclusion must comment on the administrative implications of that function.
   It must not spiral into ministry lore.

4. Keep the bureaucracy petty, local, and humiliating.
   Not epic, not sprawling.

5. Prefer:

6. one form

7. one permit

8. one missing signature

9. one wrong classification

10. one absurd office rule
    over:

11. multiple clauses

12. layered subcommittees

13. long directive chains

14. abstract grievance systems

15. The joke should be understandable even on first read.

16. The duck must remain central.
    The bureaucracy must exist because of the duck’s function, not the other way around.

GOOD DIRECTION EXAMPLES

• The duck serves as a floating compliance marker for baths already in progress.
• The duck functions as an informal complaint receiver for minor bath-related grievances.
• The duck is required as a witness object before a splash incident can be officially recorded.
• The duck temporarily certifies that a bather is still emotionally eligible for continued soaking.

BAD DIRECTION EXAMPLES

• abstract grievance manifestation object
• sprawling directive chains
• excessive clause stacking
• vague ministry lore
• classification replacing function

TONE TARGET

The humor should come from:
- procedural seriousness
- ridiculous administrative logic
- calm official language applied to a bath toy

It should be funny because it sounds annoyingly plausible,
not because it sounds huge or overbuilt.

TASK

Update only the ministry persona instructions in app/prompts.py.
Update docs only if needed for consistency.
Do not touch the other persona instructions unless required.

After changes, show:
1. the updated ministry prompt section
2. any doc changes if made
3. a short explanation of how you made ministry clearer, more concrete, and less lore-heavy
4. confirmation that JSON schema, frontend, backend flow, and logging were unchanged

Show more

Agent

Refining the Persona / Prioritizing Functionality

I will update the "ministry" persona in app/prompts.py to ensure it focuses on a clear, concrete administrative function for the duck, followed by a humorous interpretation of its procedural consequences. I'll then review and adjust docs/tone_charter.md and docs/button_modes.md to ensure they remain consistent with this more targeted, petty bureaucratic tone.

1 message not shown

Agent

I have updated the "ministry" persona in app/prompts.py to be more concrete and petty.

1. Updated Ministry Prompt Section

    "ministry": """
    PERSONA: THE PETTY CIVIL SERVANT
    Function Claim: Propose a simple, concrete administrative role for the duck (e.g., a witness for splash-claims, a floating compliance marker, a receiver for bath-grievances).
    Style: Calm, official, and annoyingly procedural. Focus on one specific hurdle: one missing permit, one wrong signature, or an expired bather-eligibility form.
    Avoid: Sprawling lore, multiple clauses, or epic bureaucracy. Keep it local, petty, and understandable.
    Conclusion: Explain the specific administrative consequences or jurisdictional headache caused by the hypothesis.
    """,

2. Documentation Changes

I have verified docs/tone_charter.md and docs/button_modes.md. They already align with this "petty bureaucrat" direction, so no further changes were required there.

3. Explanation of Changes

• Concrete Function: The model is now explicitly told to propose a simple administrative role (e.g., "witness for splash-claims") instead of generating abstract "grievance manifestation" lore.
• Petty Hurdles: I replaced the instruction for "rigid legalistic style" with a focus on specific, relatable administrative failures like "one missing permit" or "one wrong signature."
• Reduced Lore: I banned "sprawling lore" and "epic bureaucracy" to ensure the joke remains grounded in the bathroom context and is immediately understandable.

4. Confirmations

• JSON schema remains unchanged.
• Frontend was not modified.
• Backend flow remains exactly the same.
• Logging is still active and unchanged.

Show more

Slice: persona_building · 3 of 234 messages

Prize Category

I’m primarily submitting this for Best Google AI Usage.

Gemini was a core part of the project, both in the building process and in the app itself. It helped turn a simple joke into a system of distinct personas, structured reports, and consistently readable comic outputs rather than generic AI text.

And if the Ministry happens to win over the public, I would gladly accept the consequences under Community Favorite.

---

Thanks for reading, and please proceed with caution.
In matters involving the yellow rubber duck, certainty remains premature.