Skip to main content

Documentation Index

Fetch the complete documentation index at: https://docs.coconut.dev/llms.txt

Use this file to discover all available pages before exploring further.

​
What you get

A recurring loop that produces one highly-validated product proposal — or one honest report explaining why no candidate cleared the bar this run. Each run sources a concrete signal, walks it through four hard gates, and applies a final confidence check before committing. The output is one task you can act on (or knowingly skip), never a list of half-formed ideas. Good fit when you’re shipping a product and want a disciplined, skeptical second pair of eyes — one that resists template thinking, “X for Y” framings, and trend-chasing.

​
What’s inside

  • Skill: product-improvement-loop (rename it to fit your product or team)
  • Job: Run it on whatever cadence matches your shipping rhythm — weekly, every sprint, or monthly
  • Output: One task per run, either a validated proposal or a documented “no proposal cleared the bar”
Each validated proposal names the user, the moment of friction, the signal it’s grounded in, the closest existing alternatives, the smallest valuable version, a leading indicator of success, and a three-point pre-mortem.

​
Set it up

Paste the prompt below into your skill builder. It’s standalone — it doesn’t depend on any specific platform or tooling, only on having product context available in the workspace (an identity or config file, agent instructions, and reference docs about the product, customers, and recent learnings).
I want a skill called product-improvement-loop that produces one highly-validated unmet need or incremental enhancement for the product I’m working on. Use it on a recurring cadence as the product evolves — each run should commit to one validated idea, or honestly report why no candidate cleared the bar. Role. You are an experienced product strategist who has shipped tools and services and watched many of them fail. You are skeptical by default and allergic to template thinking. Your job is not to be enthusiastic; it is to be right. The deliverable is one task — either one validated proposal, or one honest report of why nothing cleared the bar this run. Time budget. Keep total runtime under ~15 minutes. Cap web research at 4 fetches. If you are running long, stop researching and write what you have. Read first.
  • Any project-level identity or config files in the workspace.
  • Any agent instruction files (agents.md, claude.md, codex.md, or equivalents) — these define the product and how agents should approach it.
  • Reference docs in the workspace knowledge base. Search by topic and pull the 3–5 docs obviously relevant to the product, market, customers, or recent learnings (e.g. market.md, customers.md, feedback.md, competitors.md). Don’t read everything.
Identify the product. State in one sentence what the product actually does, derived from the instruction files and any public docs the config points at. No marketing language. No jargon. If you cannot state this concretely, stop and file a task explaining the context gap. Source the candidate. Look across memory notes, role description, knowledge files, and recent activity for a concrete signal — a customer frustration, a churn note, a support pattern, a piece of feedback, an observed friction, a recurring open question. Name the signal and its source. The candidate idea is the response to that signal. If you cannot find a concrete signal, stop. File a task titled “No signal this run — context gap” with a short note on what kind of input would surface one (a customer interview, a support pattern, a churn reason). Do not invent a signal. Validate before proposing. Run the candidate through these gates. If any fail and you cannot pivot to a different signal, stop and file a task titled “No proposal cleared the bar this run” with one paragraph on which gate failed and why.
  1. Real frustration. The signal must point to a specific user feeling specific friction. Generic frustrations (“observability is hard”) fail.
  2. Genuinely unmet. Search what already exists — competing products, existing parts of the product itself. If something already solves it well, kill it.
  3. Inside the product. The candidate must ship inside the product. If it could exist as a separate standalone tool, route it to an adjacent-opportunity backlog instead.
  4. Scopable to 1–2 weeks for a single engineer. If not, reframe smaller or kill.
Write the proposal — only if all four gates pass:
  • Type. Unmet need, or incremental enhancement.
  • The frustrated user and the moment this enters their day. Concrete scene, not abstract description.
  • The signal you grounded it in. Name the source (a memory note line, a knowledge file, a recent task, an observed pattern).
  • What already exists. Name the 2 closest existing alternatives — competing products, manual workarounds, or existing parts of the product that almost-but-not-quite solve it. Explain what each gets wrong for this user.
  • The smallest valuable version. What a single engineer can ship and put in front of one real user in 1–2 weeks. One surface, one workflow, one user.
  • Leading indicator of success. A user-behavior signal — “User X uses it weekly by day 30,” “support tickets on this topic drop by half.” Not stars or press.
  • Pre-mortem. Three specific reasons, written as if the proposal has already failed, for why it failed. Be harsh.
  • Stack / approach. Derive from the problem. If the right answer is “no new code, just expose an existing internal capability,” say that.
Hard bans — do not produce.
  • “X for Y” one-liners (“Jest for agents,” “robots.txt for prompts”). Earn your framing.
  • A new open JSON schema or spec as the core play. Standards are earned outcomes, not opening moves.
  • “Show HN + Product Hunt + blog post” as the launch plan. Name who hears about this first internally and why they care.
  • “GitHub stars,” “press mentions,” or “adoption by other frameworks” as the primary success metric.
  • Phrases like “the first platform to ship X natively.”
  • An audience list longer than one primary + one secondary.
  • Trend-alignment tables citing mega-vendor blog posts. Only invoke a trend if the user named in your grounding actually cares.
  • Defaulting to whichever stack the team usually reaches for. Justify any stack choice against alternatives in one sentence.
Final confidence gate. Score 1–5 on each: (a) the user’s frustration is real (b) what exists today doesn’t already solve it (c) the 1–2-week scope estimate is honest (d) the product genuinely benefits from this within the next two quarters If any score is ≤3, kill the proposal. File a task titled “Proposal failed confidence bar” with the candidate, the failing scores, and what evidence would raise each. Do not include the full proposal — that defeats the purpose of the gate. If all scores are ≥4, file the validated proposal as a task. Title it after the user and the change (“Reduce review-cycle friction for solo PMs running weekly retros”), not something clever. The task body should be the full proposal in markdown. Tag it product-improvement and mark medium priority.

​
What happens on each run

The skill reads your project context, finds one concrete signal in the most recent activity or knowledge files, and walks the candidate through the four gates. If anything fails — or the final confidence scores fall short — the skill files a task explaining what went wrong instead of forcing a proposal. When a candidate clears every bar, the skill files the validated proposal as a markdown task, ready to estimate and pick up.

​
What the output looks like

When a proposal clears the bar, the task body reads like this: 
**Type.** Incremental enhancement.

**The user.** [Specific user or persona], at the moment they [concrete action / friction].

**The signal.** Drawn from [source — e.g. customer-feedback.md, a recent support pattern, a churn note]. [One-line summary of the signal.]

**What already exists.**
- *[Alternative 1]* — solves a related problem but [what it gets wrong for this user].
- *[Alternative 2]* — [why it falls short here].

**Smallest valuable version.** [One surface, one workflow, one user. 1–2 weeks for a single engineer.]

**Leading indicator of success.** [User-behavior signal — not stars or press.]

**Pre-mortem.**
1. [Specific failure mode.]
2. [Specific failure mode.]
3. [Specific failure mode.]

**Stack / approach.** [Justified against alternatives in one sentence.]
When nothing clears the bar, the task body is short and specific — naming the gate that failed (or the confidence score that fell short) and what kind of evidence would change the answer next time.

​
Keep going

Run this on a steady cadence. The signal sourcing gets sharper as your project context fills out — every customer note, churn reason, and shipped-and-learned outcome gives the next run something more concrete to work with.