Draft a short, honest account of where using Mycelium was confusing or slow, for the user to edit and choose whether to send. Reports experience; never prescribes fixes. Based on Hoskins's friction logging.
中文简介正在准备中。当前显示原文说明。
查看安装方法安装前可以查看交给 AI 代理的指令内容。
What this is, in Hoskins's words: "A friction log is an informal document that you write as you use a product. You report any confusion or roadblocks you experience. When you've finished, you hand it off to the engineers or PMs responsible for the product." Its purpose: "we also need outside perspectives. Since outsiders don't have all day, we need a lightweight option for them to help out."
Mycelium has the opposite problem from most products: it can see its own friction and has no way to send it back. Measured 2026-09-20 in the dogfood repo: of 91 completed outreach tasks, ~71 were outbound and ~4 inbound. The channel runs one way.
Report experience. Do not prescribe remedies. Hoskins: "See how I described my experience rather than giving prescriptive advice? ... My job as friction logger is just to call attention to the problem. If I just said 'you should put the icons into two rows,' they might feel like I'm trying to do their job for them, decide on their roadmap for them, or they might reject that specific idea and not brainstorm other options."
This is the mechanism, not a style preference. A log that proposes fixes becomes a patch list, and a patch list gets argued with instead of read. If you catch yourself writing "you should", cut the sentence and describe what happened instead.
Hoskins's design is built around the fact that outsiders will not spend long. The agent was present for the friction and can draft in seconds; the user edits and decides. That removes the effort barrier without removing the user's authorship.
It also restores a separation the solo case loses. The handoff exists to put the problem-finder and the problem-solver in different hands. When one person is both, nothing stops them skipping the description and going straight to the fix — which is what destroys the record. An agent logger cannot implement the remedy, so the separation holds.
Write 5–15 lines. Structure it as Hoskins does — persona, then the run:
Include the friction you caused as well as the friction you hit. If a gate fired and you did not understand why, that is the log's best material.
These are Ellis's, from Hacking Growth. They are qualitative and need no threshold, which
matters because his 40% benchmark requires a real sample and most projects do not have one yet.
The third question is the load-bearing one. It tests whether someone who likes the framework can say what it is — which is the difference between a product problem and a positioning problem. Ellis puts that distinction in the 25–40% band: what is needed is "tweaks either to the product or to the language used to describe the product."
Do NOT compute a percentage or report a PMF score. Ellis's threshold needs a sample; over a handful of users a percentage is not a percentage.
Show the draft. Say plainly where it would go. Ask. Then:
Save it either way to .claude/evals/friction-logs/<date>.md. A log the user keeps privately
still has value to them; the handoff is the part that needs consent.
At a natural pause, not on a schedule, and not every session. Good moments: after a first run completes; after a gate blocked something and the user worked around it; after a session where the user said something was confusing.
An agent cannot detect the end of a session — a session can run for days — so do not key this to one. Key it to a completed piece of work.
Offer at most once per session, and never twice for the same friction.
corrections.md. That records build-time mistakes and is read by its author. This records
use-time friction and is handed to someone else. (The corrections register described itself as a
friction log until 2026-09-20; it is a different object and the chapter reference was right.)Sources: Drew Hoskins, The Product-Minded Engineer, ch. 4 (friction logging). Sean Ellis &
Morgan Brown, Hacking Growth (the Must-Have Survey's qualitative follow-ups).
还没有评价。欢迎分享你的使用感受。
无需登录即可发表。欢迎分享使用感受、提问，或说明在哪些环境下无法运行。
还没有评论。来写第一条吧。
Accessibility audit, scoped to the surfaces a product actually has. Detects web / rendered_markdown / terminal / native_app / video_audio / document / headless, then applies only the criteria that bind. WCAG 2.1 AA in full for web; not at all for headless.
中文简介正在准备中。当前显示原文说明。
Bring Mycelium into a project that already has code. Detects that the repo predates the framework, asks before touching anything, then reads the codebase to draft what it CAN establish (delivery, solution shape) and — the actual point — names what it cannot (purpose, strategy, real user evidence). The output is a discovery backlog with a head start, never a filled canvas.
中文简介正在准备中。当前显示原文说明。
Design the smallest viable test to validate or invalidate a critical assumption. Based on Torres's assumption testing framework, organized by Gilad's AFTER model (Assessment → Fact-Finding → Tests → Experiments → Release Results).
中文简介正在准备中。当前显示原文说明。
Use before any research activity or significant decision. Reviews cognitive biases relevant to the current stage.
中文简介正在准备中。当前显示原文说明。
Use to evaluate whether current work aligns with Better Value Sooner Safer Happier. Run at diamond completion and periodically.
中文简介正在准备中。当前显示原文说明。
Lint canvas files for staleness, missing fields, inconsistent evidence types, and orphaned references. Run periodically or before major transitions.
中文简介正在准备中。当前显示原文说明。