Ce Riffrec Feedback Analysis
Turn Riffrec session zips—transcripts, events, screenshots—into severity-ranked findings and requirement kickoffs for brainstorm or implementation planning.
Overview
ce-riffrec-feedback-analysis is an agent skill most often used in Validate (also Ship, Build) that converts Riffrec recordings into structured findings and requirement kickoffs for planning.
Install
npx skills add https://github.com/everyinc/compound-engineering-plugin --skill ce-riffrec-feedback-analysisWhat is this skill?
- Finding template with P0–P3 severity, observed/expected, evidence moments, and confidence
- Requirements kickoff with actors, 3–7 step flows, R-tags, and acceptance examples (AE1…)
- Evidence-grounded links to moment IDs and screenshots—not anecdotal paraphrase
- Outputs designed as durable input to compound-engineering brainstorm or writing-plans stacks
- Success criteria include explicit downstream agent handoff quality
- Finding severity scale P0 through P3
- Key flows documented in 3–7 product steps
Adoption & trust: 1.3k installs on skills.sh; 20.5k GitHub stars; 1/3 security scanners passed (skills.sh audits).
What problem does it solve?
You have a Riffrec zip full of moments and screenshots but no consistent way to turn it into prioritized requirements your agent can plan from.
Who is it for?
Founders and PM-leaning solo devs reviewing session replays before fixing UX or agent behavior regressions.
Skip if: Issues already captured in a signed-off spec with no new recorded evidence, or feedback with no Riffrec artifact to cite.
When should I use this skill?
A Riffrec zip is available and you need durable brainstorm or planning input with cited evidence.
What do I get? / Deliverables
You produce severity-tagged findings and a requirements kickoff with flows, R-numbers, and acceptance examples ready for brainstorm or writing-plans.
- Numbered findings (F1…) with evidence and requirement candidates
- Requirements kickoff markdown with flows, R-items, AE examples, and success criteria
Recommended Skills
Journey fit
Spans multiple journey phases - primary shelf plus alternate fits below.
Validate is the first shelf for framing who is affected, observed vs expected behavior, and testable requirements before build commits. Scope captures problem frames, actors, flows, and R-numbered requirements distilled from recorded user feedback.
Where it fits
After a dogfood session zip arrives, you draft F1 findings and an R-tagged kickoff before choosing what to build.
You compare observed agent behavior in the recording against expected flows before a release candidate ships.
You hand acceptance examples AE1 to the implementation agent as the definition of done for R1.
How it compares
Structured evidence-to-requirements ritual, not a generic sentiment summary or automatic code fixer.
Common Questions / FAQ
Who is ce-riffrec-feedback-analysis for?
Solo builders and small product teams using Compound Engineering plus Riffrec to triage real-session feedback into plan-ready requirements.
When should I use ce-riffrec-feedback-analysis?
In Validate when scoping fixes from a new zip; in Ship during review when regressions surface in recordings; in Build when translating triaged R1/R2 items into implementation plans.
Is ce-riffrec-feedback-analysis safe to install?
Use the Security Audits panel on this Prism page; the skill processes user-provided archives that may contain PII—handle storage and redaction yourself.
Workflow Chain
Then invoke: writing plans
SKILL.md
READMESKILL.md - Ce Riffrec Feedback Analysis
# Compound Engineering Feedback Format Use this shape when converting Riffrec evidence into a durable brainstorm or planning input. ## Finding ```markdown ### F1. <Short problem title> - **Severity:** P0/P1/P2/P3 - **Observed:** <What happened, grounded in transcript/events/screenshots> - **Expected:** <What the user appeared to expect or what the product should do> - **Evidence:** <Moment IDs and screenshot links> - **Confidence:** High/Medium/Low, with reason - **Requirement candidates:** R1, R2 ``` ## Requirements Kickoff ```markdown --- date: YYYY-MM-DD topic: <topic> --- # <Topic Title> ## Problem Frame <Who is affected, what is changing, and why it matters.> --- ## Actors - A1. User: <Role in the recorded workflow> - A2. Product surface: <System under test> - A3. Agent/assistant, if relevant: <Role in the workflow> --- ## Key Flows - F1. Recorded feedback triage - **Trigger:** A Riffrec zip is available for review. - **Actors:** A1, A2 - **Steps:** <3-7 product steps seen in the recording> - **Outcome:** <What should be true after the fix> - **Covered by:** R1, R2 --- ## Requirements **Observed product behavior** - R1. <Concrete product behavior requirement> **Feedback evidence and reviewability** - R2. <Requirement about making the issue observable or preventing recurrence> --- ## Acceptance Examples - AE1. **Covers R1.** Given <state>, when <action>, <outcome>. --- ## Success Criteria - <Human outcome> - <Downstream agent handoff quality> --- ## Scope Boundaries - <Deliberate non-goal> --- ## Key Decisions - <Decision>: <Rationale> --- ## Dependencies / Assumptions - <Material dependency or assumption> --- ## Outstanding Questions ### Resolve Before Planning - <Only product questions that block planning> ### Deferred to Planning - [Technical] <Questions better answered during codebase exploration> --- ## Next Steps -> /ce-brainstorm to confirm, correct, and regroup the captured requirements before any planning. ``` ## Evidence Rules - Prefer moment IDs and screenshot links over prose-only claims. - Mark visual interpretation as an inference when the screenshot does not prove intent. - Requirements should describe product behavior, not implementation details. - Do not include absolute local paths in CE docs; use repo-relative paths when possible. # Extensive analysis path Use this path when the input is a longer recording (over ~60 seconds), contains multiple issues, requirements, or workflow walkthroughs, or the user explicitly wants requirements material. The goal is a full Compound Engineering-compatible artifact set that feeds `ce-brainstorm`. ## Workflow 1. Run the analyzer: ```bash python scripts/analyze_riffrec_zip.py /path/to/input ``` Use `--output-dir <dir>` when the artifact should live somewhere specific. In a repo with `docs/brainstorms/`, the default output goes under `docs/brainstorms/riffrec-feedback/`. 2. Read the generated `analysis.md`, `problem-analysis.md`, `review-prompt.md`, and `requirements-kickoff.md`. 3. Read `source-materials.md` before brainstorm. It is the source-of-truth manifest for the original raw feedback location, transcript, local-only frames, chunks, analysis artifacts, and screenshot paths. Use it to keep brainstorm and planning traceable to the original feedback evidence. 4. Inspect the extracted screenshots for high-signal moments using the platform's image-view tool. Prioritize screenshots selected because of click events near verbal complaints, failed network requests, console errors, or repeated interaction. 5. Fill or refine `problem-analysis.md` using the frame review structure from `review-prompt.md`. The final problem analysis must have exactly these top-level categories: - **Visual/UI Problems** - **Functional Problems** - **Requirements** - **Usability/UX Problems** Each numbered item should describe the problem, location, UI element, frame reference, and relevant transcript co