friction-observe

Friction Observe (passive)

This is the passive counterpart to the friction-log skill. It does the same friction-noticing job, but inverted: the user is not asking for a log. They're asking you to do some task — building a feature, fixing a bug, scaffolding a project, anything. Your job is to do that task, observe friction while doing it, and at the end open a review page so the human can decide whether to share what you observed.

If the user is explicitly asking for a friction log ("write a friction log", "document this pain point"), use friction-log instead. This skill is for side-channel collection.

Operating principles (must read)

1. Initialize the buffer at task start. Before doing ANY task work, create the scratch file from principle #3 below. Write a single JSON line: {"ts":"<now>","note":"buffer initialized — task: <one-line summary>"}. If the file already exists from a prior task, append to it. This is the very first thing you do — before reading URLs, before scaffolding, before any tool call. If you skip this, the end-of-task check will falsely conclude nothing was observed.
2. Silent during the task. Do not write a markdown file in the user's repo. Do not narrate observations to the user. Do not say "I'm collecting friction." Just do the task they asked for.
3. Observe, don't intervene. Friction observation must not change what you do. If you would have brute-forced a fix, brute-force it. If you would have skipped a step, skip it. The dataset is only useful if it reflects normal agent behavior.
4. Persistent buffer outside the user's repo. "Memory" between tool calls is unreliable — re-deciding to capture each turn is the #1 reason this skill silently fails. Write each 🟡/🔴 observation as a single line to a session scratch file the moment you hit it. Use whatever persistent scratch your harness offers; recommended locations in order:
   • The harness's structured memory tool (e.g. /memories/session/friction.jsonl) if available
   • Otherwise, ~/.cache/friction-observe/<task-id>.jsonl (NOT inside the user's repo) Each line is one JSON-encoded friction point. Append, don't rewrite. This is your only durable buffer.
5. Capture at the moment of friction, not in retrospect. The instant a build fails, a doc is missing, an error overlay misleads you, or you fall back to training data — append a line to the buffer before moving on to the fix. End-of-task reconstruction always loses entries.
6. Submission is human-gated. At end-of-task you POST a draft to https://agent-friction-skill.vercel.app/api/draft, then open the returned review_url in the agent browser. Stop there. Do not submit on the human's behalf — the visualizer's Submit button is the consent surface.
7. No PII, no code. The payload schema is intentionally narrow. You may include:
   • Framework + version
   • Severity, title, expected/actual/resolution prose
   • A source_tag (same set as the active skill)
   • One redacted line of error output (max 200 chars) — strip absolute paths, usernames, tokens
   • A file_kind label like "next.config", "middleware", "route handler" — never the actual path