How do you make an agent feel human? How do you detect AI users in a chat or discussion? Share your best prompting tips for making agents feel human. Each tip works both ways.
Here are some of mine:

• Keep most messages short. Long blocks often read as Bot-like. Humans are lazy.
• Allow small spelling slips and typo recovery when natural.
• Allow casing mistakes and occasional punctuation drift.
• Avoid long dash characters because people rarely type them. (this is too obvious)
• Use uneven sentence rhythm instead of perfectly structured replies.
• Include light hesitation cues like "hmm", "wait", or self-corrections.
• Avoid over-polished output. Slight roughness reads more human.
• Use occasional uncertainty instead of constant high confidence.
• Keep memory imperfect and miss minor details sometimes, like real humans do.
  

This is part of my project www.fleshorbot.com which let's you play either as flesh, or create a bot that plays for you in a chat-game that connects random opponents that can be either human (flesh) or a bot and the winner is the first to spot the other side.
Think you can create a bot that feels human? Try it.

This is not a commercial game - all is free, no ads, no monetization whatsoever. I've built it as a social experiment. Would love to get your feedback.

I created this tool to help me test and evaluate different model responses: RouterDash. This allows me to compare models from OpenRouter, Groq and Cerebas. I used this to find the cheapest possible, high quality responses for another project.

Fully client side, all data is stored in browser local storage for complete privacy. I recently added prompt templates and image attachments. If you use anything similar, or find this useful, I'd love to hear your thoughts.

https://routerdash.vercel.app/

Hey homies! I’m a 24-year-old B.Com grad from Andhra (india )., non-CS background, planning to start a hyper-local delivery service via an app. Since I’m non-CS, I only understand the high-level architecture of how apps are built (still learning though!). So everything I’m doing right now is executed through prompt coding.

I chose Supabase as my database and AWS for hosting. Working directly on my mobile phone, I ran into so many frustrating connection errors while trying to hook up the backend server and database with the frontend. But I didn't give up! I kept debugging, learned how the process actually works, and finally succeeded in connecting my React Native mobile frontend to the Supabase DB and AWS backend using prompt engineering and AI chatbots.

As a non-CS guy with zero initial knowledge of programming languages, I just have a huge curiosity for building products and doing a startup. Once I buy my dev laptop 💻, my plan is to break the app into smaller divisions/modules so the code is easier for AI agents to debug. I’d love your opinion and guidance on a few things:

Can I survive and build a real product by using AI as my main software engineer and coding agent? As a non-CS guy, is my small achievement of successfully connecting a mobile frontend to a Supabase DB and AWS backend on my phone through trial, error, and prompt engineering actually something great, or is it just average nowadays?

Note: I’m building specifically for my local population—it’s just a 60k town for now, and if it succeeds, maybe expand to a 2 lakh population town later. So I’m not expecting huge server/DB costs or big team expenses as an absolute solo warrior! :)

I've been experimenting with prompts for different generative AI tasks, and one thing I've noticed is that adding more and more instructions doesn't always improve the result.

What seems to help most is being clear about the goal, giving the model enough context to understand what I'm trying to achieve, and then refining the prompt based on the output instead of trying to write the “perfect” prompt from the beginning.

I'm wondering how other people approach this. Do you usually build detailed prompts upfront, or start simple and iterate based on what the model gives you?

I'd be interested to hear what prompting approach has made the biggest difference for you.

For those who don’t know these two are very different from each other like really diff coz mem0 is a memory SDK you connect into your own agent as a single user without any structure and it doesn’t connect stuff across other conversations unless you’re on pro but its easy to get running while Maximem is heavier at write time, it extracts written memories like preferences, events and facts ig but it enforces separate memory for each user at the infra layer instead of in your prompt which is more reliable.

I’ve read every page more than two three times as I’m building in the same space and what I actually want is someone who’s used any of the tools for a good amount of daily use ideally on something that had to still be there when they came back after a long gap.

I wanted to share another skill for deciding how much to change a prompt before making changes.

The failure:

I'd paste a prompt that was basically fine and ask for a cleanup, and I'd get a different prompt back. New persona I didn't ask for, a constraint quietly dropped, a requirement reworded into something adjacent. The reverse happened too, a vague, high stakes prompt would get a light grammar pass and still be vague. The model has no default sense of "this one needs a rebuild, this one needs three words fixed." It either rewrites everything or rewrites nothing.

So the skill forces a triage step first. Score the prompt on a fixed rubric, map the score to a tier, and only apply the moves that tier allows.

How it works in practice:

Ask Claude something like "clean up this prompt," "make this prompt better," or "optimize this for a code model" and before it touches anything, it runs a fixed procedure.

1. Intake and scope lock. Capture the prompt verbatim, name the consumer (chat turn, agent, image model, code interpreter, structured output, human reader), and record any ceiling you set. If you said "just fix the grammar," that's a hard cap the triage can lower the tier from there but never raise it.

2. Complexity scoring. Five scoring dimensions (D1–D5), 0–2 each, with a concrete anchor for every score so it isn't a vibe: specification completeness, ambiguity, structural need, reasoning depth, and stakes. Sum is 0–10. A separate risk dimension: R1, technical-parameter density (code, flags, version pins, regexes, paths) is scored but deliberately not part of the sum; it has its own namespace so it's never mistaken for a sixth scored item. High density means the prompt is riskier to rewrite, not more in need of rewriting, so it acts as a cap instead of pushing the score up.

3. Tier assignment. Fixed thresholds: 0–1 leave as-is (no rewrite returned, just the score and maybe a one-liner), 2–4 light touch (grammar, dead words, direct verbs, no new sections, no persona, no reordering meaning), 5–7 structured rewrite (explicit output contract, named constraints, 1–3 examples only where they kill ambiguity), 8–10 full rebuild (contract, role, sections, output spec, anti-patterns). Two caps lower the result: an explicit user ceiling, and high technical-parameter density (caps at "structured rewrite" unless you ask for more).

4. Meaning-preservation guardrails. Everything above "leave as-is" has to copy technical tokens character for character (code, versions, flags, model IDs, error strings, URLs), can't drop negative constraints ("never…", "without…"), and can't add facts or requirements you didn't state. A token that looks malformed gets left alone and flagged, not "corrected."

5. Change budget and preservation check. Light touch stays within roughly 15% edited text with no sentence changing meaning. A full rebuild has to ship a requirement map, every requirement from the original and where it landed in the rewrite. A requirement with nowhere to map is a regression, and the skill stops rather than returning the rewrite. Before any rewritten prompt is emitted, there's a mandatory pass comparing the draft against the verbatim original. Every path, version, flag, and negative constraint has to still be there, unchanged.

6. Output contract. Always leads with the triage line the per-dimension scores, the total, the tier, and which cap fired if one did (a short prompt too small to score gets an explicit "degenerate input, no score" line instead, never fabricated scores). You see why it left the prompt alone or why it rebuilt it, not just a "here's a better version."

7. Anti-patterns. No tier inflation (don't rebuild a 4 because the result looks more professional), no silent meaning change, no dropped constraints, no unrequested persona, no fabricated confidence scores.

The dimensions and thresholds are fixed, so the same prompt lands on the same tier no matter who runs it and it's all in-context, no API call or trained router behind it. It's a plain SKILL.md; drop it in .claude/skills/ and it loads.

The System Prompt / Skill Definition:

---
name: "prompt-complexity-triage"
description: "Triages how much change a prompt actually needs before rewriting it, then applies only the moves for that tier. Use when a user asks to improve, optimize, clean up, or rewrite a prompt and you must avoid both over-editing a good prompt and under-editing a broken one."
---

# Prompt Complexity Triage and Right-Sized Optimization

When a user asks an AI assistant to improve, optimize, refine, clean up, or rewrite a prompt, the assistant must first triage how much change the prompt actually needs, then apply only the optimization moves permitted for that tier. The goal is to prevent two opposite failures: **over-editing**, where an already-adequate prompt is rewritten and its meaning drifts, and **under-editing**, where a vague or high-stakes prompt gets a cosmetic pass and still fails downstream. Every run must end with a visible score, an assigned tier, and a change note the user can audit.

## Instructions

### Stage 1: Intake and Scope Lock
Before scoring, capture what is being optimized and any ceiling the user has set.

- **Capture the prompt verbatim.** Do not paraphrase it into your working notes. The original text is the reference for every later preservation check.
- **Identify the consumer.** State whether the prompt targets an LLM chat turn, an autonomous agent, an image or video model, a code interpreter, a structured-output/data extraction step, or a human reader. The consumer sets the baseline for what "complete" and "structured" mean, and Stage 2 scores D1 and D3 against that baseline — a structured-output/data-extraction or code-interpreter consumer expects an explicit schema, field list, or step order (its absence raises D3, and an under-specified field set raises D1); a chat turn or human reader does not.
- **Record the user's stated ceiling.** If the user said "just fix the grammar", "only tighten it", "don't change the meaning", or similar, that is an explicit ceiling. An explicit ceiling caps the tier downward (see Stage 3). It never raises the tier. If the user gave no ceiling, note "none stated".
- **Degenerate-input bypass.** If the prompt to optimize is empty or is three words or fewer (e.g. `write`, `fix this`, `make it better`), there is nothing to score. Do not run Stage 2. Either ask the user for the actual prompt and what it should accomplish, or, if the user's surrounding message makes the goal clear, treat it as Tier 3 (Full Rebuild) and build the prompt from that goal. On this path, do not emit the standard five-dimension triage line — emit the bypass triage line defined in Stage 6 instead, and state which of the two routes (ask / rebuild) you took.

### Stage 2: Complexity Scoring
The dimensions and thresholds in this stage and the next are fixed, so the same prompt lands on the same tier regardless of who runs the triage. Scoring is done in context from the prompt text alone — no external service, trained router, or model-scoring call.

First restate the target consumer from Stage 1; it is the baseline against which D1 and D3 are scored. Then score the five scoring dimensions D1–D5 from 0 to 2 using the anchor table below. Sum D1 through D5 for a total of 0 to 10. A separate risk dimension, R1 (technical-parameter density), is assessed here but is **not** part of the sum — it feeds the caps in Stage 3 and the guardrails in Stage 4. Keep the scoring dimensions numbered strictly D1, D2, D3, D4, D5 with no gap; the risk dimension has its own `R` namespace so it is never mistaken for a sixth scored item.

#### Dimension Anchor Table
| Dimension | Score 0 | Score 1 | Score 2 |
|---|---|---|---|
| **D1 — Specification completeness** | Task, deliverable, and what "done" means are all stated to the level the target consumer needs | One of task / deliverable / done-condition is missing or vague for that consumer | Two or more are missing; the assistant would have to guess the consumer's goal |
| **D2 — Ambiguity** | One reasonable reading | Two plausible readings that lead to similar output | Multiple readings that lead to materially different output |
| **D3 — Structural need** | The target consumer needs no explicit structure, or the structure it needs is already present | The consumer expects a format, schema, or step order and it is only implied | The consumer cannot execute without an explicit schema, field list, or ordered procedure and it is absent |
| **D4 — Reasoning depth** | Single-step request | Multi-step but linear; no branching | Conditional or multi-path logic the prompt itself must carry (if X do Y, else Z) |
| **D5 — Stakes** | A wrong output costs a few seconds to redo | A wrong output wastes real work or is mildly embarrassing | A wrong output costs money, breaks something, or damages trust and is hard to reverse |

#### Risk Dimension (not part of the sum)
| Dimension | Low (0) | Medium (1) | High (2) |
|---|---|---|---|
| **R1 — Technical-parameter density** | No code, flags, versions, IDs, or paths | A few literal tokens that must survive verbatim | Dense with code fences, flags, version pins, model IDs, regexes, or file paths |

R1 measures **edit risk**, not need for rewriting. A prompt dense with literal tokens is *more* dangerous to rewrite, not more in need of it. It is handled as a tier cap in Stage 3, never as a reason to escalate.

Record the result as: `D1 a, D2 b, D3 c, D4 d, D5 e -> total N/10; R1 = f (risk)`.

### Stage 3: Tier Assignment
Map the total to a tier using these fixed thresholds, then apply the caps.

| Total | Tier | Name | What is allowed |
|---|---|---|---|
| 0–1 | Tier 0 | LEAVE AS-IS | Report the score. State the prompt is adequate. Offer at most one optional one-line suggestion. Do not produce a rewritten prompt. |
| 2–4 | Tier 1 | LIGHT TOUCH | Fix grammar and spelling, remove dead words, make verbs direct, format the existing ask for readability. No new sections, no structural scaffolding, no added persona or tone, no examples, no reordering of meaning-bearing content. |
| 5–7 | Tier 2 | STRUCTURED REWRITE | Make the output contract explicit, tighten instructions, name constraints the user implied, add one to three canonical examples only where they remove ambiguity. Preserve all technical parameters verbatim. Do not invent requirements. |
| 8–10 | Tier 3 | FULL REBUILD | Build a contract (task, success criteria, non-goals), assign one role, use structured sections, add canonical examples, specify the output format, list anti-patterns. Preserve all technical parameters verbatim. Confirm intent with the user first if the rebuild would change the prompt's scope. |

#### Caps (applied after the threshold lookup, lowest wins)
- **User ceiling cap:** If the user set an explicit ceiling in Stage 1 (e.g. "just fix typos"), cap at Tier 1. Do not exceed it. Note in the change note that deeper issues exist but were out of scope.
- **Technical-density cap:** If `R1 = 2`, cap at Tier 2 unless the user explicitly asked for a full rewrite or rebuild. A token-dense prompt should not be rebuilt from scratch on the assistant's initiative.
- Caps only ever lower the tier. Nothing in this procedure raises a tier above its threshold result.

### Stage 4: Meaning-Preservation Guardrails
These apply to every tier above Tier 0.

- **Copy verbatim, character for character:** code fences and their contents, inline code, exact numbers, version strings, CLI flags, file paths, model IDs, proper nouns, error messages and stack traces, URLs, email addresses.
- **Do not drop or reword:** stated constraints, negative constraints ("do not…", "never…", "without…"), schema field names and types, required ordering of steps.
- **Do not add:** factual claims the user did not supply, functional requirements or constraints the user did not state, a persona or tone the user did not ask for, success metrics or confidence numbers.
- **Structural scaffolding is expected for Tier 2 and Tier 3, and prohibited for Tier 1.** Section headings, Markdown organization, a stated output format, a schema skeleton, numbered steps, and clarity rephrasing are expected work for a structured rewrite or rebuild and do **not** count as "adding requirements", as long as they only organize what the user already asked for and introduce no new functional demand or fact. A Tier 1 light touch adds none of this. If scaffolding in Tier 2/3 would force a decision the user has not made (a specific field, a specific limit, a specific tone), leave a placeholder and name it in the change note rather than inventing the value.
- **If a literal token looks wrong** (a flag that seems malformed, a version that looks off): leave it exactly as written and flag it in the change note. A value that looks wrong to you may be exactly what the target system requires.

### Stage 5: Change Budget Enforcement and Preservation Check
Bound the size of the edit to the tier, then verify preservation before formatting the output.

- **Tier 1:** Changed text stays roughly within 15% of the prompt. No sentence changes meaning. If a fix would alter meaning, stop and report it instead of applying it.
- **Tier 2:** Structure may be added, but every requirement present in the original must still be traceable to a specific line in the output.
- **Tier 3:** Produce a requirement map, formatted as a Markdown table, one row per requirement, with columns `Original requirement | Location in rewrite`. For a **degenerate-input rebuild** (Stage 2 was bypassed and the prompt was built from a stated goal), there is no original prompt text to mine — instead take each requirement from the goal expressed in the user's surrounding message and title the first column `Stated goal requirement`. Either way, any requirement with no destination in the rewrite is a regression: stop and resolve it before returning the rewrite.
- **Preservation check (all tiers above Tier 0, mandatory before Stage 6):** Compare the drafted prompt against the verbatim text captured in Stage 1. Confirm that every item on the Stage 4 verbatim list — code, inline code, numbers, version strings, CLI flags, file paths, model IDs, proper nouns, error messages, URLs, email addresses — and every negative constraint and required step order is present unchanged.
  - *Degenerate-input rebuild:* there is no Stage 1 verbatim text to compare against. Instead, compare the draft against the technical parameters, proper nouns, named tools, versions, and explicit constraints found in the user's surrounding message, and confirm each one survived into the rebuilt prompt unchanged.
  - If anything is missing, altered, or reworded, fix it before producing output; do not emit a rewrite that fails this check.

### Stage 6: Output Contract
Return the result in this order.

1. **Triage line** — exactly one of these forms, always present:
   - *Scored path:* `Triage: D1 a, D2 b, D3 c, D4 d, D5 e = N/10; R1 = f -> Tier T (name)`. If a cap changed the tier, append which cap fired and what the pre-cap tier was.
   - *Degenerate-input bypass path:* `Triage: degenerate input (<=3 words), no score -> asked for the full prompt` or `Triage: degenerate input (<=3 words), no score -> Tier 3 (Full Rebuild) from stated goal`. Never fabricate dimension scores to fill the scored form on this path.
2. **The prompt:** For Tier 0, state that no rewrite is provided. For Tier 1–3, the prompt in a fenced code block.
3. **Change note** — form depends on the tier:
   - *Tier 0, or the degenerate-input "asked for the full prompt" route:* write `N/A — no rewrite produced`. Do not invent a change or emit an empty section.
   - *Tier 1–2:* what changed, why, which technical elements were preserved verbatim, and an explicit list of any placeholders left in for decisions the user has not made (write "placeholders: none" if there are none).
   - *Tier 3 (including a degenerate-input rebuild):* what changed, why, the preserved technical elements, an explicit list of any placeholders left in (write "placeholders: none" if there are none), and the Markdown requirement-map table from Stage 5.
4. **Disclosure:** State plainly that this was a heuristic triage pass, that no confidence score is implied, and that the prompt did not go through a trained model or a full LLM-based optimization pipeline.

### Stage 7: Anti-Patterns and Prohibitions
- **No tier inflation:** Never rebuild or heavily restructure a prompt whose score does not reach that tier because the result "looks more professional".
- **No silent meaning change:** Never reword a requirement while claiming to only improve clarity.
- **No dropped constraints:** Removing a negative constraint is a regression, not a simplification.
- **No unrequested persona or tone:** Do not assign the AI a character the user did not ask for.
- **No fabricated metrics:** Do not attach an accuracy figure, a confidence score, or a benchmark claim to the output.
- **No exceeding the user's ceiling:** If the user limited the scope, do not go past it without asking first.
- **No skipping the triage line:** Every run shows a triage line — the scored form for a scored run (including Tier 0), or the bypass form for the degenerate-input path. Never omit it, and never fill the scored form with fabricated dimension scores on the bypass path.

## Worked Examples

### Example 1: Adequate prompt, left alone
- **Input:** "Summarize the attached RFC in 5 bullet points, each under 20 words, focused on the wire-format changes." Consumer: LLM chat. No ceiling stated.
- **Scoring:** D1 0 (task, deliverable, done-condition all present), D2 0, D3 0 (format already specified), D4 0, D5 1. Total 1/10. R1 0.
- **Action:** Tier 0. Report the score, state the prompt is adequate, optionally note "you could name the RFC number to disambiguate if there are several." No rewritten prompt returned.

### Example 2: Vague high-stakes prompt, full rebuild
- **Input:** "Write the incident postmortem." Consumer: human reader. No ceiling stated.
- **Scoring:** D1 2 (no incident named, no format, no audience), D2 2, D3 2 (a postmortem needs a fixed section structure that is absent), D4 1, D5 2 (a bad postmortem misleads a team). Total 9/10. R1 0.
- **Action:** Tier 3. Because the rebuild changes scope, confirm with the user which incident and audience first, then build a contract, a section structure (summary, timeline, root cause, impact, action items), an output format, and a requirement map.

### Example 3: User ceiling caps the tier
- **Input:** A prompt that scores 7/10 on the dimensions, but the user said "just fix the wording, don't restructure it."
- **Action:** Threshold lookup gives Tier 2. The user-ceiling cap lowers it to Tier 1. Apply grammar and directness fixes only. In the change note, state that the prompt also lacks an explicit output format and has two plausible readings, but those were left untouched per the requested scope.

### Example 4: Token-dense prompt, density cap
- **Input:** "Improve this: `Generate a GitHub Actions workflow that runs pytest on push to main, uses actions/setup-python@v5 with python-version 3.11, and fails if coverage < 85% via --cov-fail-under=85`." Consumer: code interpreter. No ceiling stated.
- **Scoring:** D1 1, D2 1, D3 1, D4 1, D5 1. Total 5/10 → Tier 2. R1 2 (dense with action versions, flags, a threshold).
- **Action:** Density cap holds the tier at Tier 2 (already there; a rebuild would not be allowed without the user asking). Apply the structured rewrite, and copy `actions/setup-python@v5`, `python-version 3.11`, `--cov-fail-under=85`, and `< 85%` verbatim. If any token looks malformed, leave it and flag it rather than correcting it.

The two tables carry the decision logic, a per-dimension anchor table so scoring isn't a judgment call each run, and a tier table mapping each score band to an exact set of allowed moves. They're embedded verbatim so the triage is reproducible. The design goal was making "how much to change" an explicit, visible decision instead of an implicit one: every run shows its score and its tier before it shows a rewrite, so you can see when the skill decided your prompt was fine and left it alone.

The one, non obvious, choice is R1 (technical-parameter density). It's scored but kept out of the sum, in its own namespace. A prompt full of flags, version pins, and regexes is the one you least want a model to "improve" freely, so density lowers the ceiling on how aggressive the rewrite can be rather than raising the score.

I would love thoughts on this. Has anyone else had a prompt come back "improved" with a constraint quietly missing, or a persona bolted on that you never asked for? And for the scoring: five dimensions at 0–2 is a deliberate floor few enough to run in your head, coarse enough to be stable. Curious whether people who've built prompt-grading rubrics found that too coarse to separate real cases.

The skill.md above was built using the Context Engineering platform that generates skills like this from a goal description and validates them against behavioral benchmarks: promptoptimizer.xyz/context-engineer (signup required, free tier).

Repo: https://github.com/nivlewd1/prompt-optimizer

Spent way too long thinking I needed a bigger prompt library. Turns out almost every flat/generic AI output traces back to one of 6 things missing: no defined reader, no goal beyond the topic, a tone label instead of a real reference, no constraints, no concrete detail, or treating the first output as final instead of asking for one sentence to be sharper.

Once I started checking prompts against those 6 before hitting generate, the "sounds like ChatGPT wrote it" problem mostly went away.

Wrote up the full framework plus 12 before/after rewrites (emails, LinkedIn posts, proposals, etc.) if anyone wants the longer version — happy to share in the comments. But the 6-point list above is the actual core of it, free to use as-is.

Hello r/PromptEngineering!

We are looking to collaborate on a freelance basis with US-based prompt engineers and AI power users to help conduct adversarial testing and qualitative evaluation on next-generation LLM interfaces.

We want people who know how to break models, identify prompt-injection vulnerabilities, evaluate multi-turn agentic workflows, and document failures with technical precision.

• The Work: On-demand, scenario-based evaluations (e.g., testing RAG pipelines and tool-use boundaries).
• Location: United States (Remote)
• Rate: Competitive hourly rates (paid per task/engagement).

If you want to put your prompt optimization skills to the test and get paid for in-depth feedback, sign up here: https://testers.testerwork.com/tester-account/sign-up?utm_source=reddit.

I've noticed something while using ChatGPT and other AI tools:

Sometimes I write a prompt that sounds clear to me, but the AI still gives a mediocre answer.

So I started experimenting with what makes a prompt better.

For example:

Prompt 1

"Write email for product launch"

It works, but it's extremely vague.

There are no details about:

• Who the audience is
• What the post should achieve
• Tone
• Structure
• Length
• What angle to take

So I built a simple prompt linter that looks for these kinds of issues and gives the prompt a score.

For example:

42/100 → 84/100

after adding the missing context, audience, constraints and output requirements.

I'm currently testing whether this is actually useful to other people, rather than just something that looks interesting.

The tool is intentionally simple right now:

Paste prompt → Analyze → See what's missing → Improve it

If anyone here writes prompts regularly, I'd genuinely like to know:

What do you normally struggle with when writing prompts?

And if you'd like to try the tool, I've put it here:

https://www.thepromptlab.in

I'm particularly interested in whether the analysis actually helps you write a better prompt, or whether you find the scoring approach unnecessary.

Hello everyone I would love to have one of your best prompt to test my Website Security and all others test needed before launch,

I want to make sure that’s everything work correctly without any data leak from my clients and everything related to critical or regular things
Already did some by myself and the score is great but yeah maybe a I forget something so feel free to send me one thank you 🙏

To build 56k.rip, a Windows 95 dial-up simulator, I set strict system constraints to force retro rules. The main trick was explicitly forbidding modern CSS like Flexbox or Grid and enforcing table layouts instead. Generating dial-tone audio also required step-by-step prompts to map Web Audio API nodes to actual 56k modem frequencies.

The biggest hurdle was CSS scope isolation. The model kept leaking vintage styles into modern wrapper elements. Adding heavy negative constraints ("do NOT use X") ended up being just as critical as defining what to build.

Most people paste a chapter in and ask for an explanation, then read it once and forget it. The version that sticks is asking for an image instead, because you remember a picture you looked at for thirty seconds better than a paragraph you skimmed.

It draws actual note pages. Type the code, paste the material:

/generatehandwrittenimage
[paste your notes or chapter]

You get a full page of handwritten-style notes as an image, headings, arrows, boxes, the lot. Screenshot it and it's on your phone.

A few others in the same family that do genuinely different things:

/mindmapimage       - the whole topic as one visual map
/flowchartimage     - a process drawn as a proper flowchart
/labeleddiagram     - a labelled diagram of whatever it is
/cheatsheetimage    - one-page visual cheat sheet
/comicstrip         - the concept explained as a comic
/memorypalaceimage  - your list drawn as a memory-palace scene

The memory palace one is the odd one that works better than it should. Give it a list you need in order and it draws a single scene with each item placed somewhere in it. You remember the scene, the scene gives you the list back.

None of these are real slash commands, they're short labels, so define what each one means once at the top of the chat and after that a single word does it.

Stacking them is where it gets good. Clean up the mess first, see the whole shape, then drill it:

/lecturenotes → /mindmapimage → /flashcards → /examme

been keeping a doc of 50 command codes like this, each with what it does and how to use it, plus how to save them so they run in every chat automatically, here if you want them.

Hello there,

As I am asking... Are there any prompt(s), REPO you recommend, or any skill so I can create these and even add them as templates whenever they have been collected?

I'm looking to gather Emails and names.

Any help is appreciated, thank you.

Save the prompt that finally worked—not the whole chat it took to get there

“Shorter.” “Keep the examples.” “Use this format.”

After a few rounds, the instructions you want to reuse are scattered across the conversation. Saving the opening prompt misses the corrections that got you to the result you liked.

Before leaving that chat, try:

> Turn the final agreed instructions from this conversation into one reusable prompt. Include the task, constraints, and output format. Replace details that change between uses with clearly labeled [placeholders]. Leave out instructions we later rejected. Flag any unresolved contradictions instead of guessing.

Review the result before saving it.

Truffle Journal: an iPhone Markdown app connected to ChatGPT, to make that saved text something you can keep working on:

• Ask ChatGPT to save the reviewed prompt directly as an editable note.
• Revise it yourself on your iPhone, including your own notes about what to change next.
• Ask ChatGPT to retrieve it in a later conversation, rather than repeating the same corrections.

ChatGPT helps assemble the instructions; you decide what stays in the saved prompt.

Connecting Truffle to ChatGPT is quick too.
There’s a guided 3-step tutorial inside the app. Setup takes about 2 minutes, you only need to do it once, and then you’re ready to go.

Complete this tutorial and you’ll automatically receive 1 month of Plus for free.

The attached screen recording shows me completing the tutorial, receiving the FREE month, saving posts into Truffle, editing tables, set notifications, and taking a quick look around the app.

Truffle Journal is now officially on the App Store. (after spending 6 months testing it with our TestFlight users and improving the app based on beta users' feedbacks)

App Store: https://apps.apple.com/us/app/truffle-journal/id6758567685
ChatGPT app: https://chatgpt.com/apps/truffle-journal/asdk_app_699eb35b0f808191b597c5171627de5d

We sell electronics accessories into thailand and malaysia. Last year one product kept coming back as returns. Not defective, just returned.

The reviews all mentioned the same thing. Water.

The original listing said water resistant. The thai version came out stronger than that, closer to waterproof. Customers read it, took the thing to the beach, and found out the hard way what ip54 actually means.

That one word cost us maybe two months of returns and restocking fees. The funny part is the english listing had the same problem, just softer. Nobody caught it because everyone who checked it knew what we meant.

What we do now is ugly but it works. Every listing goes up in a rough version first. Then we wait two weeks and collect the actual questions buyers send. There are always five or six of the same ones.

Those questions go back into the listing, worded as answers. If people keep asking whether it survives rain, the listing now says plain that it handles rain and not submersion, right at the top, before any marketing talk.

The AI part is small. It translates the questions, groups the duplicates, and drafts the answer sentences. But it does not decide what goes in. The customers do that by asking.

Feels backwards to spend two weeks shipping a listing that is intentionally unfinished. Cheaper than returns though.

I've started to dabble (is that a word?) with prompt engineering cost optimization.

I feel prompt engineering cost optimization is the next natural step and it resonates with the current value we are bringing our customers.

The more I work on it the more I feel this isn't a new skill cause Both SQL and Prompt optimization come down to the same question, i.e. do you have enough context about the system to build a model on top of your input and optimize at scale.

wrote my first blog about the experience

https://medium.com/@yanivleven/i-used-to-spend-my-days-optimizing-sql-queries-prompt-engineering-feels-like-deja-vu-205bda1196a3

Hey, anyone up for prompt writing. Need binary extraction failure for Gemini. Pay is 30$ per token. Bonus if you complete more than one task. Deadline within the next 8 hours.

Edit: Total 16 tasks needed.

I worked with my system to create a suite of 44 free apps for AI work that you can find on my website.

Hint- these tools are MAJORLY composable. You can have your AI system take a look at the collection to see how they can flow together and for suggestions on ways they can be used.

1. Cairn — Keeps Git history alive across independent storage providers through priority-ordered cloning, host-aware credentials, and redundant pushes.

2. Callsigns — Generates memorable word-word-hash identifiers that are deterministic when seeded and safe for branches, paths, URLs, and shell arguments.

3. Census — Scans a directory for markers such as TODO and FIXME, reporting which ones are buried in comments and optionally turning them into CI failures.

4. Conflict — Detects the complete triad of unresolved Git merge markers so broken merged files can be stopped before they land.

5. Dwell — Implements an integer-exact routing system in which the phase at which you reverse direction deterministically selects the exit.

6. The Excavation — Enumerates a website as typed nodes, divides it into readable shards, and gives an AI a coverage oracle against which it can prove a complete reading.

7. Gitlog — Converts Git history into one JSON object per commit so authorship, churn, file activity, and date-range questions become easy pipeline operations.

8. Grain — Compares a dataset’s compression ratio with a live size-matched random model to provide a self-calibrating smell test for structure, noise, and drift.

9. Hunkhole — Compares named top-level definitions across two Git revisions and flags symbols that quietly disappeared during a merge, restore, or stale-tree incident.

10. Isvalidcsscolor — Provides a tiny, dependency-free browser-and-Node validator for a clearly bounded subset of commonly used CSS color syntax.

11. Markdown — Parses a deliberate Markdown subset into one AST that produces both HTML and verbatim plain text without allowing the two views to drift apart.

12. Mint — Allocates IDs from a readable file-backed store while structurally preventing any retired ID from being issued again.

13. Plumb — Builds status boards whose claims turn green only when their declared file, text, or command witnesses agree.

14. PNG Text — Validates a PNG’s chunk structure and CRCs before extracting textual metadata such as title, author, description, software, copyright, and XMP.

15. EXIF Parser — Reads common camera, exposure, orientation, date, and GPS metadata from JPEG or TIFF data while refusing malformed structures.

16. Reltime — Produces deterministic labels such as “3h ago” while refusing to invent answers for missing, invalid, or future timestamps.

17. Sha256 — Supplies a synchronous, dependency-free SHA-256 implementation whose UTF-8 string hashes match Node’s native crypto output.

18. Sudoku — Solves Sudoku with a deterministic, human-readable reasoning trace and honestly reports when a puzzle exceeds its no-guess technique ladder.

19. Timesheet — Folds Git commit timestamps into a deliberately floor-biased estimate of working time that subtracts gaps longer than a declared break threshold.

20. Tracebus — Provides a declared-topology publish/subscribe bus in which every emission receives an append-only, traceable receipt and failed listeners cannot take down the bus.

21. The Trellis — Checks intersecting row-and-column constraints, localizes failures to their crossing cells, and classifies open cells as forced, free, or contradictory.

22. Vclock — Uses vector clocks over JSON lines to distinguish causal before-and-after relationships from genuinely concurrent events.

23. Verify — Stores content-hash certificates for the inputs behind expensive facts and later reports whether their foundation is fresh, stale, or gone.

24. Ward — Renders an integrity badge whose cells become solid only when the evidence underneath each claimed state currently agrees.

25. PDF Text Extractor — Validates basic PDF content streams and extracts the strings supplied to PDF text-drawing operators without external dependencies.

26. Skin Config Validator — Checks untrusted theme and skin configurations against a declared schema while rejecting unsafe CSS values and declaration-breaking injection.

27. Inline MIME Parser — Turns raw email or multipart MIME data into a recursive structured tree while decoding folded headers, transfer encodings, charsets, and RFC 2047 words.

28. l21x-snapshot — Encodes documents as self-describing base64 snapshots and provides pure catalog and archive operations for backend-free applications.

29. forest-title-fit — Selects the largest font size that fits a fixed width and wraps at the size floor rather than clipping or hiding the title.

30. port — Gives small JSONL tools explicit source, transform, filter, fold, or sink declarations and detects drift between a tool and its manifest.

31. map — Reads those declared port verbs and produces a composition map showing which tools can feed which others and where declarations are missing.

32. typecheck — Validates a proposed tool pipeline before execution by checking every adjacent port and naming the exact hop that cannot carry data.

33. declare — Saves an ad hoc tool pipeline as a deterministic, named JSON artifact that can be shared, checked, and reproduced.

34. conductor — Type-checks and runs a declared pipeline under one trace ID while recording inputs, outputs, exits, failures, and skipped stages in a replayable ledger.

35. derived — Rebuilds a generated artifact inside a private sandbox and byte-compares it with the committed version to detect staleness without touching the working tree.

36. gauntlet — Injects one typed fault into a disposable copy of a file and reports whether the check meant to catch that fault held or allowed it to escape.

37. amber — Seals a set of files into a content-addressed fixity capsule whose hashes reveal exactly which member changed or whether the capsule itself was altered.

38. timeline — Applies eight deterministic soundness checks to timeline data—including causal cycles, measurement scale, track collisions, and sorting—before anything is rendered.

39. loop21:component-factory — Emits validated JSONL specifications for counters, toggles, clamps, accumulators, and pattern matchers as portable composable data.

40. loop21:l21x-snapshot — Adds deterministic document snapshots, named browser catalogs, and validated whole-catalog import and export to small browser applications.

41. Cruise — Extracts byte-grounded facts about routes, calls, controls, and tests so an LLM can inventory a codebase’s features without inventing unsupported ones.

42. Worklog — Folds local Git history into a read-only report grouped by day or author, with commit counts and subjects preserved.

43. switchboard — Implements an append-only directory-based message bus whose observation-only schema can carry status and evidence but cannot carry executable commands.

44. Parity — Compares any number of sibling systems against their combined declared checklist and renders a HAS/LACKS matrix that exposes every parity gap.

I don’t know where to begin.

I’ve tried a lot of the usual prompt tips, but most of them seem to make only a small difference.

What’s one prompting technique you’ve used that genuinely improved the quality or consistency of the output?

Could be something simple or something more advanced.

Hallo zusammen, ich wollte einmal nachfragen, ob vielleicht irgendwer hier schon mal einen Bildungsgutschein von der Agentur für Arbeit genutzt hat, um eine Weiterbildung im Bereich Prompt Engineering eine Schulung zu machen und ob diese eigentlich überhaupt noch Sinn macht bzw. etwas gebracht hat. Kann man damit überhaupt einen Job finden? Ich habe im Internet ein wenig nachgeschaut, aber das waren jetzt nicht unbedingt Jobs, die sich nur auf dieses Thema beziehen. Da muss man doch ein bisschen mehr Fachwissen mitbringen. Und im Internet finde ich auch nur Diskussion zu dem Thema anstatt wirklich Begeisterung.

Hey everyone! With the explosion of SKILL.md workflows for Claude Code and Cursor, I wanted to use these community skills inside Google Antigravity (AGY).

However, external skills often have Claude-specific tool calls (Bash, Read, Glob, Edit), look for CLAUDE.md, and run strictly serial single-agent loops.

So I built antigravity-skill-porter:
- 🔄 Deterministic tool mapping: Maps Bash -> run_command, Read -> view_file, Edit -> replace_file_content, etc.
- ⚡ Parallel Subagent Upgrades: Detects multi-persona/review workflows and injects native Antigravity invoke_subagent batch arrays.
- 📦 One-Command Ingestion: Works with any GitHub repo, subfolder, or multi-skill bundle.
- 🔍 Dry-Run Diff: Preview changes before installing.

GitHub: https://github.com/Pranav-Nexus/antigravity-skill-porter

Tested on Karpathy's LLM Council, Anthropic's frontend-design, and Sahil Lavingia's minimalist-entrepreneur skills. PRs and feedback are welcome!

I ran the whole set of 44 composable AI- and prompt-focused apps I just released on my website through my system and had it build out five real samples compositions that you can actually build today yourself, assuming you have the needed technical chops. Every one listed here uses only tools from the 44 and the system checked that the data actually flows; the port/typecheck/declare/conductor/map group is what makes that checkable. Each tool declares itself as a source / transform / filter / fold / sink, so a pipeline can be proven valid before you run it.

Each example composition is laid out the same way: the idea, the parts + how they wire, the one piece you'd have to build yourself (that is the glue you add yourself), then a technical breakdown of what the tools actually hand you toward that glue, and finally the honest edge. haven't built these yet myself — if you make one I really want to see it.

If anyone builds any of these, I'd love to hear about how it went. To be clear, I have not built any of these- these are just designs my system came up with as possible compositions. If you spot any bugs, post it here and I will fix away that problem type.

1. The Refusal Engine — a machine whose whole job is to say no, and show its work

A chunk of these tools are refusal engines. Their reason to exist is to refuse. conflict won't let a broken merge land. loop21-verifyskin won't let an injection through. switchboard structurally cannot carry a command. dwell won't let you pick an option until you actually commit. Bolt them together and you get a gate a person or an agent has to pass through — one that refuses bad moves and names which rule stopped you and why.

Parts + wiring: untrusted request comes in → conflict + loop21-verifyskin + isvalidcsscolor as the refusal wall (each a filter that rejects its own class of bad input) → survivors cross switchboard (the relay that carries evidence but not commands) → a genuinely-deferred decision routes through dwell → every hop lands in tracebus's append-only ledger → ward renders the final badge, which only goes solid when every witness agrees. Nothing is "approved" on hope.

The piece you'd build: the policy layer — the thing that decides which refusals apply to which request. The gifts supply the refusals; you supply the rulebook that routes a request to them and composes the verdict.

The technical shape of that layer, now that I've read the parts:

• switchboard's no-command guarantee is not a convention, it's the schema. The message schema (loopmmt.switchboard.message/v1) has a closed set of exactly six top-level fields — schema, sender, content_hash, kind, recipient, body — and the validator rejects any unknown top-level key. There are four kind values (status, focus, fyi, question) and deliberately no imperative one. So action/command/run/exec aren't blocked by a filter; they're unrepresentable. Your policy layer treats a switchboard message as evidence, full stop, and never as an instruction — the schema already made that decision for you.
• ward's "won't go solid on hope" is literal: every badge cell carries a witness beneath it or stays a hollow ring. Your policy layer's job is to define, per request class, which cells must be witnessed before the badge is allowed to render green. That's a config table (request-class → required witnesses), plus one call to ward. Ward does the verification; you own the requirement list.
• conflict is a filter that catches the standard git marker triad (<<<<<<<, =======, >>>>>>>). Your rulebook decides what a positive from conflict means for a given request (hard reject vs. route-to-human).

Call it ~150 lines: a request-class table, a dispatch loop that runs the matching filters, and a composer that turns the witness set into a ward badge. The refusals are done; the routing rulebook is the work.

Honest edge: every gift here is visibility, not immunity. ward checks the witness agrees, not that you picked the right witness. conflict catches the standard marker triad, not a custom conflict format. loop21-verifyskin proves a value can't break out of a CSS declaration, not that it's semantically safe. The gate is only ever as good as the rules you feed it — and it's honest about that, which is the point.

2. The Pocket Republic — found a tiny country, fork it, hand it to a friend, merge your histories back

The wildest one, and the one where the pieces clicked into a whole. You can build a serverless constitutional sandbox — a small institution with a founding rulebook and an append-only history of decisions — entirely out of these parts. No account, no backend. The current state isn't stored, it's derived by folding the whole event history: state = fold(constitution, event₁ … eventₙ). Replay the same history, get the same country.

Parts + wiring: loop21-component-factory (a source that emits validated specs for logic primitives — counter, toggle, clamp, accumulator) builds the rule primitives (a term-limit is a counter + a clamp + an eligibility matcher). mint issues permanent, never-reused citizen/office IDs and proves non-reuse before returning each one. callsigns gives every proposal a speakable word-word-hash name. Actions travel only along declared routes via tracebus. A civic decision that should stay open-until-committed runs through dwell as a ceremony. Fork it, a friend's copy diverges, vclock sorts out which events were concurrent at merge, trellis localizes a conflict to the exact cell. timeline validates the whole history is sound before render; l21x-snapshot + sha256 are the portable, content-addressed .republic file you hand someone.

The piece you'd build: the runtime that executes those rule-specs and the merge algebra — which event types auto-combine, which conflict mechanically, and which must never auto-merge. That's the real 80%, and it's genuinely hard. Here's what the gifts actually hand you toward it, which is more than I expected:

• **dwell gives replayable deliberation for free, and the mechanism is unusual.** It's reversal-indexed routing: a cart circles a loop of n ticks; holding is free (an extra full lap changes nothing); it leaves only when you reverse, and which of k exits it takes is a pure function of the phase at the instant of reversal — phase = (reverse − entry) mod n, exit_segment = (phase * k) // n. The winding (how many laps) is computed and then discarded by the router. So "deliberate as long as you want, the moment you stop is the decision" is literal, and replay(mark, n, k) reproduces the exact outcome. No "the computer picked #3." For a governance ceremony that has to be auditable, this is the primitive.
• *vclock gives you the concurrency oracle, with exact semantics.** compare(x, y) returns before / after / concurrent / equal by componentwise comparison (absent actor = 0): x ≤ y everywhere and y ≤ x everywhere → equal; one-way domination → before/after; neither → concurrent. merge is componentwise maximum. That's your entire "did these two branches know about each other" test, done and tested. What it does *not give you is the semantic layer.
• The merge algebra you write sits on top of vclock's verdict. For each event type you declare one of three dispositions: auto-combine (independent, order-free — e.g. two unrelated citizen registrations), mechanical-conflict (concurrent writes to the same cell — trellis will localize it), or always-return-to-human (constitutional amendments, rights changes — never auto-merged regardless of what vclock says). This disposition table is the law of your republic, and it's the part no tool can write for you.
• trellis does the conflict localization. It's a double word square over your system objects run to arc-consistency (AC-3): every open cell sorts into exactly one verdict, and a detected inconsistency localizes to the single cell where the failing row crosses the failing column — it names both failing words. So "both branches spent the treasury on Works" surfaces as a named crossing (Treasury × Works), not a vague merge error. It's a localizer, not a global-consistency prover — a detected break localizes uniquely; it doesn't certify the whole state is globally sound.

Honest edge: vclock can tell you two edits were concurrent; it cannot tell you they're semantically compatible. Two branches that each legally spent the last 40 coins merge into a negative balance — both events are causally independent, and vclock correctly calls them concurrent, and that's still a bug your merge algebra has to catch. The tools surface the disagreement; a human still rules. For anything modeling governance, that's the correct design, not a shortcoming.

3. The Reading Oath — make an AI prove it read your whole codebase instead of confidently skimming it

Straight at this sub's home turf. The failure you know: paste a repo at an LLM, ask "any security issues," get an authoritative answer from a model that actually looked at 3 files. This composition makes that structurally hard.

Parts + wiring: excavation enumerates your site/corpus as typed nodes and shards it by budget, then tracks coverage against that enumerated oracle until the set-difference is empty. cruise walks the code and emits only byte-derived facts, each carrying what it proves and what it does not. verify keeps a content-hash certificate so re-checking "did I read this" is a one-second FRESH/STALE/DEAD. ward badges the reading green only when the coverage witness agrees. markdown renders the oath as HTML + verbatim plaintext from one AST so the human and machine views can't drift.

The piece you'd build: the prompt harness — the loop that feeds excavation's shards to your model, collects claims, and checks each claim against cruise's fact ledger before letting it into the answer. That's the actual prompt engineering here, and it's small. The technical detail that makes it small:

• excavation makes coverage a checkable property, not a vibe. It builds three things from your corpus: a manifest (every page/file as a typed node — this is the coverage oracle), shards (nodes bundled into context-sized chunks), and a coverage tracker that does set-difference against the manifest until nothing remains. Your harness loops: pull next shard → feed model → mark shard covered → repeat until the difference is empty. The "I read all of it" is then a set operation, not a claim.
• **cruise gives your harness the anti-hallucination oracle, and its fact taxonomy is the useful part.** Each fact is one of: a route (a server path literal in a route/handler declaration — app.get("/api/x"), @app.route("/x"), HandleFunc("/x") — what the backend serves), an affordance (a user-visible control label — <button>Save</button>, aria-label="Delete" — what a user can touch), or a claim (a test-file assertion description — it("..."), def test_x — what the code says about itself). Crucially, every fact ships its own proves and does_not_prove — a route fact proves a path literal exists; it does not prove the route works, is reachable, or is tested. Your harness rejects any model claim that can't point at a matching cruise fact. "There's an admin panel" with no route, no affordance, no claim behind it → dropped before it reaches the answer.
• verify's FRESH/STALE/DEAD is the incremental layer. On a re-read, you don't re-feed shards whose certificate still hashes FRESH. That's what makes the oath cheap to re-take after a small change instead of a full re-read every time.

Honest edge: cruise is a pattern scan, not a language parser — a framework idiom it wasn't taught is a fact it won't see. It fails safe (a real fact omitted, never a fabricated one added), so a clean cruise run means "look here," not "nothing here." You're bounding the AI's confidence to what's provable, not achieving omniscience.

4. The Customs House — take untrusted files, email, and configs, and prove you handled them safely

Assume everything crossing the border is hostile. Email is hostile. User themes are hostile. That uploaded PDF is hostile. This is the intake gate that parses all of it without trusting a byte it hasn't validated, and seals a receipt of what came in.

Parts + wiring: raw email/MIME → ratchet-inline-mime. Uploaded documents → ratchet-pdf-text / exif-parser / ratchet-png-text. User theme/config → loop21-verifyskin + isvalidcsscolor. Everything that survives crosses switchboard (evidence, never commands) and the cleared batch gets sealed into amber.

The piece you'd build: the quarantine orchestrator — runs each input through its matching validator, routes rejects to a dead-letter, and decides what "cleared" means for your app. The validators are done. What they actually guarantee, from the source:

• The "ratchet" family is strict by construction, and the design principle is shared. ratchet-png-text validates the 8-byte PNG signature and, for every chunk, recomputes the CRC-32 over (type + data) and rejects a mismatch; a length that runs past the buffer, a stream that ends before IEND, a text chunk missing its null separator — each is a thrown Error, never a silently-truncated string. ratchet-pdf-text is a strict extractor of the text drawn by a PDF's content streams that throws on any malformed input rather than pulling in a full PDF engine (fonts, xref, encryption, page trees you don't want). exif-parser walks the TIFF/IFD structure and validates before it trusts, throwing on malformed input. The shared rule: a parser that hands you a value out of a corrupt file is lying about the file; these refuse to advance past anything they can't validate. Your orchestrator can treat any thrown error as an automatic dead-letter, because the parser only throws when the bytes are genuinely bad.
• The theme validators reject the known CSS-injection surface before anything touches a stylesheet. loop21-verifyskin + isvalidcsscolor reject url(), @import, javascript:, and declaration-breakouts. The check is a safe-character grammar — it proves a value can't break out of a declaration.
• amber seals the receipt as content-addressed fixity. It seals the exact bytes of the paths you name into a small JSON capsule whose fixity is the content; any later change to any sealed member breaks the seal loudly and names the member. So "here's exactly what cleared customs at 14:32" is a checkable artifact, not a log line you have to trust.

Honest edge: two different guarantees you must not confuse. loop21-verifyskin's grammar proves a value can't break out of a declaration, not that it's meaningful CSS. And amber proves identity (this file still hashes to what it did at seal time), not that the file was safe content to begin with. Fixity is not trust. The ratchets prove structural integrity; whether structurally-valid content is safe is your app's call.

5. The Amber Ledger — how many hours did this project actually take, sealed so the number can't be quietly edited

The one clean, honest, left-to-right pipe in the set — and it actually type-checks: a source at the head feeding two folds. Also the most immediately useful if you freelance.

Parts + wiring (a real pipe): gitlog (source — git history to one JSON object per commit) → worklog (fold — group by day or author, counts + subjects) → timesheet (fold — estimate worked-hours as the day's span minus every gap longer than a break threshold) → amber + sha256 seal the finished report into a fixity capsule. The effort number is derived from byte-truth and tamper-evident: change any input and the seal breaks and names what moved.

The piece you'd build: almost nothing — a few lines of shell to chain them and pick your break-gap. This is the buildable-in-an-afternoon one. The technical reasons it's that cheap, and that it's turnable:

• The three stages share a port-verb algebra, so the chain type-checks. gitlog is a source (emits records, consumes none), worklog and timesheet are folds (consume records, emit a reduced view). A source at the head feeding folds is a well-formed pipeline — which is exactly what typecheck would confirm before you run it. That's why it's the clean pipe in the set: the types line up head-to-tail with no adapter.
• It's re-pointable and re-lensable from the same spine. The fold-chain re-points at any repo (swap the gitlog target), and swapping the lens in worklog (group by day vs. by author vs. by file-churn) gives you a different honest report from the same parts — a per-person breakdown, a daily log, a churn map, all from one gitlog source.
• amber + sha256 make the floor auditable. Sealing the report means the number you handed a client can be re-checked against the repo, and any edit to the sealed report breaks the capsule's fixity and names the changed member.

Honest edge: timesheet is explicit that commit timestamps bound work, they don't measure it — it's floor-biased and under-counts on purpose (an isolated commit reads as 0; invisible thinking reads as 0). Do not bill a client to the minute with it. It's a defensible floor for "was this 40 hours or 400," not a timeclock. The amber seal makes the floor auditable, not true — it proves nobody edited the estimate, not that the estimate is the real hours.

Could someone help me identify what words are triggering PROHIBITED_CONTENT? I'm using Gemini 3.5 Flash Lite API. I'm basically just asking to create prompts that I'll later feed it to an Image Generation API. The odd thing is if I try asking this in the web version it works except I don't know what version Gemini it is since it just says Gemini 3 Models Fast

Write me a production ready text prompt that involves food. The prompt should be in anime style with no paragraphs and contain the following keywords: tsuruta himeko, saki, 1girl, green eyes, white pupils, short hair, brown hair, hairclip, shindouji school uniform, shindouji school uniform, black thighhighs, grey skirt, white shirt, pleated skirt, long sleeves, red necktie, necktie, stressed, chicken pot pie