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.
インストールする前に、エージェントに与えられる指示の中身を確認できます。
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.
日本語の概要は準備中です。原文の説明を表示しています。