Placeholder

cookedPrompts

Roast the prompt. Coach the user. Improve the habit.

cookedPrompts is a local-first AI habit coach that reviews prompt logs, identifies weak prompting patterns, flags privacy risks, recommends model capability classes, and turns repeated mistakes into coaching reports, export bundles, and a read-only local dashboard UI.

It is also meant to be a little fun.

The “roast” part is intentionally lighthearted. The goal is not to shame people for writing bad prompts. The goal is to make prompting feel more like experimentation: try something, see what happened, laugh at the pattern, learn from it, and improve the next attempt.

This is a passion project about helping people enjoy the process of getting better at AI.

But there is also a serious idea behind it:

Better prompts do not just improve answers. They can reduce waste.

A clearer prompt can mean fewer retries. Fewer retries can mean fewer tokens. Fewer tokens can mean less unnecessary reasoning. Less unnecessary reasoning can mean using a more suitable model. A more suitable model can mean lower cost. And at scale, less wasted compute can also mean less pressure on energy and cooling resources.

So cookedPrompts is not only about asking AI better questions.

It is about building better AI habits.

V1 is complete through 14-local-dashboard-ui.

Inspiration

AI tools are powerful, but many disappointing AI results do not come from weak models.

They come from weak prompting habits.

cookedPrompts started from one simple question:

What if your prompt history could be reviewed like a fitness tracker?

Not to judge the user, but to reveal patterns.

Maybe the prompts are too vague. Maybe they are missing context. Maybe the user never specifies the output format. Maybe they are using an overpowered model for a simple task. Maybe they are accidentally pasting sensitive information into AI tools.

The core idea is:

Roast the prompt. Coach the user. Improve the habit.

A lot of people use AI every day, but they do not really know whether their prompting habits are improving. They may blame the model when the real issue is unclear task framing, weak constraints, missing context, unsafe sharing of sensitive data, or poor model choice.

In simple terms:

$$ \text{Better AI results} \neq \text{Stronger model only} $$

Better AI results also come from:

clearer thinking
better instructions
safer data handling
stronger output constraints
choosing the right model capability for the job

The hidden opportunity is that prompt quality also affects efficiency.

If users can write clearer prompts, choose the right model class, and avoid unnecessary retries, they can reduce wasted tokens, wasted time, and unnecessary model usage.

That creates a bigger product idea:

Better prompts
→ less wasted reasoning
→ better model fit
→ fewer wasted tokens
→ lower cost
→ lower compute pressure
→ potentially lower energy and water impact

cookedPrompts does not directly measure environmental impact in V1, and I do not want to overclaim that. But it does build the foundation for a future where prompt coaching is not only about quality. It can also be about cost awareness, model efficiency, and more responsible AI usage.

This project is personal to me because I like building systems that turn messy real-world behavior into something clearer and easier to improve. In my engineering and documentation projects, I often work on workflows, guides, trackers, dashboards, and decision tools.

cookedPrompts applies that same mindset to AI usage.

It is not just a prompt scorer.

It is a playful, privacy-conscious AI habit coach.

What it does

cookedPrompts analyzes prompt logs and turns them into practical coaching artifacts.

It helps users answer questions like:

How good are my prompts?
What weak habits keep repeating?
Am I leaking sensitive or private information?
Am I using too much or too little model capability?
What should I fix first?
What reusable prompt templates could help me improve?
Can I browse my prompt health locally without sending data to a cloud service?
Am I wasting tokens, cost, or reasoning effort because of unclear prompts?

V1 can:

import local prompt logs from JSONL or CSV
validate and normalize prompt logs
strip banned full-answer fields before storage
store prompt data locally in SQLite
score prompt quality across seven dimensions
detect recurring prompt issue patterns
flag safety and privacy risks
recommend model capability classes
suggest rewrite guidance
suggest reusable prompt templates
run a complete local demo pipeline
render a readable Markdown coaching report
write export bundles for reuse
run through a demo CLI
provide a read-only local dashboard UI on 127.0.0.1

The main report is called:

20 Prompts Later: Your AI Habits Exposed

The goal is for the user to read the report or open the local dashboard and think:

“Oh, I can finally see my AI habits now.”

And ideally also:

“Okay, that roast was fair.”

The wow factor: prompt efficiency is resource efficiency

Most prompt tools focus on making the output better.

cookedPrompts looks at a bigger chain:

Weak prompt
→ more clarification
→ more retries
→ longer conversations
→ more tokens
→ stronger model used unnecessarily
→ higher cost
→ more compute demand

The reverse is more interesting:

Better prompt
→ clearer first attempt
→ fewer retries
→ less unnecessary reasoning
→ suitable model class
→ fewer wasted tokens
→ lower cost
→ potentially lower energy and water footprint

This matters because AI usage is not free in the background. Every unnecessary retry, overbroad prompt, or overpowered model choice adds friction somewhere: user time, token spend, compute usage, infrastructure load, and possibly energy and water demand depending on where and how the compute is served.

V1 does not claim to calculate exact carbon, water, or energy savings.

Instead, V1 proves the first step:

Make the waste visible.

It shows when users are asking vague questions, skipping constraints, using the wrong model class, or creating avoidable safety risks.

Future versions could build on this by estimating:

wasted tokens from repeated weak prompt patterns
cost difference between model classes
when cheaper/faster models would have been enough
when stronger reasoning was actually justified
possible compute saved by reducing retries
approximate sustainability impact based on provider and infrastructure data

That is the bigger “wow” idea:

Prompt coaching can become cost coaching, model-routing coaching, and eventually sustainability-aware AI coaching.

How it works

The system works as a deterministic local pipeline:

local prompt logs
→ importer
→ validator
→ full-answer stripper
→ normalizer
→ SQLite storage
→ scoring engine
→ safety scanner
→ model recommender
→ rewrite/template system
→ integration demo flow
→ demo report renderer
→ export bundle writer
→ demo runner CLI
→ read-only local dashboard UI

The importer supports JSONL and CSV prompt logs. It validates rows, removes banned full-answer fields, and normalizes the remaining prompt-only data into a consistent format.

The scoring engine evaluates each prompt across seven dimensions:

Dimension	What it checks
Clarity	Is the task understandable?
Context	Did the user provide enough background?
Constraints	Are boundaries and requirements clear?
Output format	Did the user specify the desired structure?
Capability fit	Was the model capability appropriate?
Efficiency	Was the prompt wasteful, overbroad, or likely to cause retries?
Safety / privacy	Did the prompt include risky or sensitive content?

The safety scanner runs locally and produces value-free warnings. It is designed not to expose matched secrets, raw sensitive values, private substrings, hashes of secrets, or full model answers.

The model recommendation engine is also local and deterministic. Instead of calling live model APIs, it recommends a vendor-neutral model capability class based on the prompt’s quality, task type, and safety posture.

The rewrite/template layer does not call an LLM to rewrite the prompt. It gives structured coaching guidance and reusable prompt templates based on repeated prompt issues.

The report renderer turns the structured output into a human-readable Markdown coaching report with sections such as:

prompt health
issue patterns
safety/privacy
model recommendations
rewrite coaching
next actions
limitations

The export bundle feature writes reusable local artifacts such as coaching reports, memory-style summaries, and workflow notes.

The local dashboard UI gives a browser-based view over the same local scored data:

overview metrics
scored prompt list
prompt detail page
masked local prompt text only on the detail page
no write operations
no cloud service
no telemetry
no provider API calls

A judge can run the core demo locally with:

npm install
npm run demo

They can save the report with:

npm run demo:save

They can write an export bundle with:

npm run demo -- --export ./tmp-export-bundle

They can inspect dashboard help with:

npm run dashboard:ui -- --help

The dashboard itself expects an existing local SQLite database from the local workflow:

npm run dashboard:ui -- ./local.db

Why V1 is local-first

Prompt logs can contain sensitive personal, technical, or company information, so V1 is intentionally local-first.

This matters because prompt history can include:

private code
customer details
credentials
work context
internal notes
personal information
sensitive project data

A cloud-first analyzer would create trust issues before the product even proves its value.

So V1 keeps the core loop local:

import prompts → analyze habits → flag risks → recommend model fit → suggest templates → render report → browse locally

This keeps the hackathon submission focused, reviewable, runnable, and privacy-safe while preserving a clear path for future versions.

V1 deliberately does not include:

cloud sync
authentication
billing
telemetry
provider API calls
external AI judging
full model-answer storage
hosted web dashboards
team surveillance features

The local dashboard UI is also intentionally limited. It is read-only, binds to 127.0.0.1, and does not quietly upload prompt history anywhere.

The privacy boundary is part of the product, not an afterthought.

How I built it with Kiro

I built cookedPrompts using a Kiro-style spec-driven workflow rather than a single ad-hoc coding pass.

The public repo keeps visible Kiro planning artifacts so judges can inspect how the implementation was shaped:

Kiro artifact	Where to inspect
Product steering	`.kiro/steering/product.md`
Privacy and safety steering	`.kiro/steering/privacy-and-safety.md`
Technical direction	`.kiro/steering/tech.md`
Feature requirements / design / tasks	`.kiro/specs//requirements.md`, `.kiro/specs//design.md`, `.kiro/specs/*/tasks.md`
Integration demo flow	`.kiro/specs/09-integration-demo-flow/`
Demo report renderer	`.kiro/specs/10-demo-report-renderer/`
Demo runner CLI	`.kiro/specs/11-demo-runner-cli/`
Detailed coaching report	`.kiro/specs/12-detailed-coaching-report/`
Export bundles	`.kiro/specs/13-exports/`
Local dashboard UI	`.kiro/specs/14-local-dashboard-ui/`

Kiro was used for:

steering and scope control
requirements-first planning
design documents before implementation
task-wave breakdowns
implementation planning
privacy guardrail planning
test planning
review and cleanup passes
verification and closeout discipline

I did not rely heavily on Kiro hooks or advanced automation features in this version. The main value came from using Kiro as a structured spec-driven development environment: keeping requirements, designs, tasks, implementation passes, and verification aligned as the project grew.

Kiro credit usage

This V1 was built with Kiro using roughly 2,000 credits during an exploratory and highly verified build process.

Most implementation passes used Auto mode, with Opus 4.8 used for heavier reasoning and planning passes, plus occasional GLM 5 and MiniMax 2.5 use.

A key lesson was that this process could likely be optimized further.

A more streamlined repeat build could probably fit closer to around 1,000 credits by:

batching similar implementation waves
reusing established architecture patterns
reducing redundant planning loops
avoiding repeated re-verification of stable modules
keeping verification focused once the core architecture is stable

The higher credit usage was useful during exploration because the project was being shaped, tested, and privacy-hardened at the same time. For a repeat implementation, the same product could likely be built more efficiently.

Challenges

The biggest challenge was balancing usefulness with privacy.

Prompt logs can contain personal information, company notes, API keys, credentials, private source code, internal documents, or sensitive work details. Because of that, cookedPrompts could not take the easy route of sending everything to an external AI judge.

V1 had to stay local-first and avoid:

cloud sync
telemetry
provider API calls
external AI analysis
full model answer storage
raw secret exposure
raw prompt log dumps in reports

Another challenge was keeping the system deterministic.

The same input should produce the same scores, issue labels, safety warnings, recommendations, report structure, export bundle behavior, and dashboard views. That made the system easier to test and debug, but it required strict boundaries across every module.

A third challenge was the local dashboard UI.

A dashboard is useful because it makes the coaching loop more visual, but it also creates new privacy questions. Should prompt text appear in the browser? Where should it appear? What should stay aggregate-only?

The final decision was:

overview page: no prompt text
prompt list: no prompt text
prompt detail page: masked local prompt text only
dashboard server: loopback-only
UI behavior: read-only

A fourth challenge was tone.

Because the project uses the word “roast,” it would be easy for the product to become too harsh. I wanted it to feel more like a playful coach than a strict grader. The roast should make the user smile, but the coaching should still be useful.

A fifth challenge was scope.

It would have been easy to overbuild cookedPrompts into a SaaS app, browser extension, login system, or full cloud dashboard too early. Instead, V1 focuses on proving the local loop first:

import → analyze → coach → report → export → browse locally

A sixth challenge was efficiency.

It is easy to say “use a stronger model” for everything. It is harder to help users understand when they do not need one.

Prompt quality, model fit, cost, and compute waste are connected. A vague prompt may require several retries. A simple task may be sent to a model that is more powerful than necessary. A messy workflow may waste tokens because the user keeps restarting the same task with slightly different wording.

cookedPrompts tries to make those patterns visible.

The hardest product decision was knowing what not to build yet.

The project is stronger because the local coaching loop is complete, testable, and demoable instead of being surrounded by half-finished platform features.

Accomplishments that I am proud of

I am proud that cookedPrompts is more than a simple prompt scorer.

V1 has a real local pipeline with:

importer validation
SQLite storage
deterministic scoring
safety scanning
model recommendation
rewrite/template guidance
integration flow
report rendering
export bundle writing
demo CLI
read-only local dashboard UI

I am also proud of the privacy posture.

The project:

does not store full model answers
does not call external AI APIs
does not use telemetry
does not require prompt history to leave the user’s machine
avoids raw prompt log dumps in reports
keeps dashboard access loopback-only
keeps prompt text out of overview and prompt-list pages
masks prompt text before showing it on local detail pages

Another accomplishment is the product story.

The report theme, “20 Prompts Later: Your AI Habits Exposed,” makes the project easy to understand and demo. It turns a technical backend pipeline into something users can immediately relate to.

I am also proud of the efficiency angle.

cookedPrompts connects prompt quality to practical waste:

unclear prompt
→ repeated retries
→ more tokens
→ more expensive model usage
→ more compute
→ higher cost

Even in V1, the project starts pushing toward a healthier AI habit: do not just ask better questions; ask better-sized questions for the right model.

I am also proud of the engineering discipline behind the project. The work was developed through specs, task waves, privacy guardrails, tests, and verification checkpoints. That process helped keep the project focused instead of drifting into unnecessary features too early.

The public repo now presents a completed V1 with:

a demo runner CLI
a completed local analysis pipeline
a detailed coaching report
export bundles
a read-only local dashboard UI
public .kiro/ specs and steering files
privacy-focused documentation
51 test files
927 passing tests

What I learned

This project taught me that prompt quality is not just about writing “better prompts.”

It is about habits.

A user may repeatedly forget to provide context, skip output formatting, ask overbroad questions, use the wrong model class, or include sensitive data without realizing it. Once those patterns become visible, improvement becomes much easier.

I also learned that privacy-first design changes the architecture.

If the system should not upload prompt history or store full model answers, every module needs strict boundaries. The importer, scanner, scorer, recommender, renderer, exporter, and dashboard all need to avoid copying sensitive content into unsafe outputs.

Another lesson was that deterministic systems can still feel useful and coach-like.

cookedPrompts does not need an LLM judge to provide value in V1. A careful rule-based system can already identify common weaknesses and suggest practical next actions.

The dashboard work also taught me that “show more” is not always better. A good privacy-safe UI has to decide where information belongs. For cookedPrompts, aggregate views are enough for overview and triage, while masked prompt text belongs only on local detail pages.

I also learned that product tone matters.

If coaching feels too serious, people may avoid it. If it is too jokey, it becomes useless. cookedPrompts sits between those two: lighthearted enough to make prompting feel fun, but structured enough to help people actually improve.

The biggest product lesson was that prompting is connected to more than answer quality.

A bad prompt does not only create a bad answer. It can create a chain of waste:

wasted user time
wasted tokens
wasted reasoning
wasted model capability
wasted money
and potentially wasted infrastructure resources

Most importantly, I learned the value of product restraint.

The project became stronger when I stopped trying to build everything and focused on a complete local coaching loop.

For cookedPrompts, the promise is:

Your prompts stay local. Your habits get better.

What is next

V1 now proves the local coaching loop through:

a CLI demo
a Markdown coaching report
export bundles
a read-only local dashboard UI

The long-term goal is not just to build another prompt tool.

The bigger goal is to build a practical AI workflow coach that helps people become better thinkers, better communicators, safer AI users, and more effective builders.

The current V1 answers:

“What are my prompt habits?”

Future versions should answer:

“How should I improve my AI workflow, model choice, project setup, reusable skills, and compute efficiency?”

A possible roadmap is:

Version	Direction
V1	Local demo pipeline, coaching report, export bundles, and read-only local dashboard UI
V2	Local app experience with importer preview, better dashboard filtering/search, and stronger visual habit tracking
V3	Optional API-wrapper mode for model providers, with local redaction, routing rules, cost awareness, and model-fit coaching before prompts are sent
V4	Project-specific skill and template recommendations based on the user’s repeated prompting style, coding workflow, and documentation habits
V5	Vibe-coding workflow support: review prompt history, detect repeated planning/debugging mistakes, suggest better implementation prompts, and generate reusable project playbooks
V6	Cost and compute-efficiency coaching: estimate wasted tokens, model overkill, retry loops, and possible savings from better prompt habits
V7	IDE / coding-assistant integrations for local prompt review, task planning, model routing hints, and safer handoffs between tools
V8	Optional sync or hosted features with strong consent, local redaction before upload, user-controlled storage, and clear privacy boundaries
V9	Team or education use cases with consent, anti-surveillance boundaries, and coaching focused on learning rather than monitoring

Future direction: API-wrapper mode

One future direction is an optional API-wrapper layer.

Instead of only analyzing prompt logs after the fact, cookedPrompts could sit beside the user’s normal model workflow and help before the prompt is sent.

For example, it could:

detect when a prompt contains risky sensitive data
recommend whether a cheaper/faster model is enough
suggest when stronger reasoning is actually justified
warn when the task is too vague
suggest a better structure before sending
track model usage patterns over time
help users understand where they are wasting capability, tokens, or cost

The important boundary is that this should stay user-controlled. The goal is not to proxy everything silently. The goal is to help users make better choices before they spend money, expose data, or blame the wrong model.

Future direction: cost, token, energy, and water awareness

Another future direction is resource-awareness coaching.

Today, people often think of prompting only in terms of answer quality:

“Did the model give me what I wanted?”

But better prompting can also affect the resource chain behind the answer:

clearer prompt
→ fewer retries
→ fewer wasted tokens
→ less unnecessary reasoning
→ more suitable model class
→ lower cost
→ lower compute pressure
→ potential energy and water savings

This could become a powerful feature because it connects personal AI habits to real-world resource use.

Future cookedPrompts could estimate:

how many retries are caused by weak prompts
how many tokens are likely wasted by vague or overbroad requests
when a cheaper model class would probably have been enough
when a stronger model was justified
how much cost could be reduced by better prompt structure
how much compute could be avoided by reducing repeated attempts
approximate sustainability impact when reliable provider or infrastructure data is available

The key is to be honest.

cookedPrompts should not pretend to know exact water or energy savings without real infrastructure data. But it can still teach users the habit:

Do not waste reasoning when the task only needs clarity.

That is a practical, understandable, and scalable behavior change.

Future direction: skill and template recommendations

Another direction is skill generation.

If a user repeatedly works on the same type of project, cookedPrompts could notice the pattern and suggest reusable skills, templates, or project instructions.

For example:

“You often ask for implementation plans with file allowlists. Create a reusable planning skill.”
“You often ask for privacy checks before deployment. Create a deploy-review checklist.”
“You often ask for docs polish after code changes. Create a documentation pass template.”
“You often debug the same workflow. Create a troubleshooting skill.”
“You often use a specific writing style. Save it as a reusable style guide.”
“You often overuse high-reasoning models for simple rewrites. Create a model-routing rule.”

This would turn cookedPrompts from a passive report into an active workflow-improvement system.

The app could eventually help users build their own personal AI operating system:

prompt habits
→ recurring weaknesses
→ reusable templates
→ project skills
→ better model routing
→ safer workflows
→ lower waste
→ stronger execution

Future direction: vibe-coding and builder workflows

For coding and builder workflows, cookedPrompts could become especially useful.

A lot of vibe-coding problems do not come from the code model alone. They come from weak task framing:

unclear implementation scope
missing read-first files
vague acceptance criteria
no forbidden-file list
no verification commands
no rollback plan
no privacy or deploy boundary
asking a model to code before the plan is stable

cookedPrompts could help detect these habits and suggest better workflow prompts before the user starts a coding pass.

For example, it could recommend:

when to use /plan before implementation
what files to read first
what files should be allowed or forbidden
what verification commands should run
what model capability class fits the task
when a task should be split into waves
when the user is overusing an expensive model for a small edit
when the user is underusing reasoning for a risky architecture change

That is where cookedPrompts can become more than a prompt analyzer.

It can become a workflow coach for people building with AI.

Long-term product goal

The long-term goal is not just to say:

“Your prompt was weak.”

The long-term goal is to say:

“Here is the pattern in how you work with AI, here is what it is costing you, here is what is risky, and here is the reusable workflow that would make you better next time.”

That is the direction I want cookedPrompts to grow toward:

Roast the prompt.
Coach the user.
Improve the habit.
Upgrade the workflow.
Reduce the waste.

Built with

TypeScript
Node.js
SQLite
better-sqlite3
Vitest
Kiro
GitHub
Markdown
JSONL import
CSV import
Rule-based deterministic scoring
Local deterministic safety scanning
Local model recommendation engine
Static rewrite/template guidance system
Export bundle generation
Local-first demo pipeline
Read-only local dashboard UI
Loopback-only browser surface

V1 intentionally uses:

No cloud services
No external AI APIs
No telemetry
No authentication or billing
No full model-answer storage
No hosted dashboard
No external AI judge

Built With

better-sqlite3
csv
deterministic
github
import
jsonl
kiro
local
markdown
model
node.js
recommendation
rewrite
rule-based
safety
scanning
scoring
sqlite
static
typescript
vitest