Conversation
📝 WalkthroughWalkthroughA new documentation file is introduced that specifies a TuxSEO Landing-Page Social Proof Pack library. It defines eight social-proof snippets with validation variants, an evidence matrix mapping requirements to owners and confidence levels, placement recommendations, and implementation and deliverables checklists. Changes
Estimated code review effort🎯 2 (Simple) | ⏱️ ~12 minutes Poem
🚥 Pre-merge checks | ✅ 3✅ Passed checks (3 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
Greptile SummaryThis PR adds a new internal social-proof planning document ( Key observations:
Confidence Score: 3/5
Important Files Changed
Flowchart%%{init: {'theme': 'neutral'}}%%
flowchart TD
A[Hero Section] --> B["Trust Strip (SP1 + SP2)"]
B --> C[How It Works]
C --> D["Testimonial Block (SP3)"]
D --> E["Mini Case Cards (SP4 + SP5)"]
E --> F["Pricing Section + SP6 Reassurance"]
F --> G["Final CTA + SP7 WordPress Proof"]
G --> H["FAQ Objection Answer (SP8)"]
SP1{SP1 Evidence?} -- Validated --> B_strong["Strong: active_projects_count metric"]
SP1 -- Pending --> B_pending["Pending: early SaaS teams copy"]
SP2{SP2 Evidence?} -- Validated --> B2_strong["Strong: median_minutes metric"]
SP2 -- Pending --> B2_pending["Pending: one focused session copy"]
SP6 -- Always --> F_strong["Strong: editorial control claim"]
SP7 -- QA Pass --> G_strong["Strong: WordPress workflow claim"]
Last reviewed commit: acc5cbe |
![greptile-apps[bot]](https://avatars.githubusercontent.com/in/867647?s=60&v=4){kind=small}
| @@ -0,0 +1,192 @@ | |||
| # TuxSEO Landing-Page Social Proof Pack (ported from TuxSEO Old) | |||
There was a problem hiding this comment.
Missing YAML frontmatter
Every other file in docs/content/features/ includes a YAML frontmatter block with title, description, keywords, and author. This file has none, which will likely cause issues with whichever static-site generator (or docs renderer) processes this directory — pages may fail to build, render without metadata, or appear without a title in navigation.
Compare with the sibling file docs/content/features/blog-post-suggestions.md:
| # TuxSEO Landing-Page Social Proof Pack (ported from TuxSEO Old) | |
| --- | |
| title: Landing-Page Social Proof Pack | |
| description: Production-ready social proof snippets and evidence requirements for the TuxSEO landing page. | |
| keywords: TuxSEO, social proof, landing page, conversion, testimonials | |
| author: Rasul Kireev | |
| --- | |
| # TuxSEO Landing-Page Social Proof Pack (ported from TuxSEO Old) |
| @@ -0,0 +1,192 @@ | |||
| # TuxSEO Landing-Page Social Proof Pack (ported from TuxSEO Old) | |||
There was a problem hiding this comment.
Legacy artifact in filename
The -from-old suffix in landing-page-social-proof-pack-from-old.md appears to be a carry-over label from the porting process rather than an intentional production filename. If this document is meant to live in the repo long-term and potentially be rendered in the docs site, consider renaming it to landing-page-social-proof-pack.md to keep the URL and navigation label clean.
Note: If this suggestion doesn't match your team's coding style, reply to this and let me know. I'll remember it for next time!
| # TuxSEO Landing-Page Social Proof Pack (ported from TuxSEO Old) | ||
|
|
||
| Owner: Scribe | ||
| Date: 2026-03-11 | ||
| Source intent: Rebuild a conversion-ready social-proof layer using verified claims only. | ||
|
|
There was a problem hiding this comment.
Document audience mismatch for this directory
The docs/content/features/ directory is intended for end-user-facing feature documentation, as outlined in docs/AGENTS.md ("Write for Users, Not Developers — Focus on what users can do with the feature"). This file is an internal content-strategy / marketing planning artifact (snippet library, evidence matrix, handoff checklist) aimed at the product/content/ops team — not at TuxSEO end users.
Consider whether this document belongs here, or whether it would be better placed in a dedicated internal planning directory (e.g., docs/internal/ or docs/content/marketing/) to avoid confusion with user-facing docs and to keep the features/ path clean for renderable end-user pages.
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 3
🧹 Nitpick comments (1)
docs/content/features/landing-page-social-proof-pack-from-old.md (1)
151-192: Convert this section into a task-based workflow with outcomes.The placement recommendation and checklist are scannable, but they still read like internal planning notes. If this stays in feature docs, rewrite it as numbered steps such as Choose, Place, Validate, and Review, and say what the reader should see when each step is done successfully. As per coding guidelines,
docs/**/*.{md,mdx}should "provide step-by-step instructions using numbered lists with verbs like Create, Configure, Analyze, including expected outcomes and visual indicators of success."🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@docs/content/features/landing-page-social-proof-pack-from-old.md` around lines 151 - 192, Convert the "Final on-page placement recommendation" and "Implementation notes" into a task-based workflow using four numbered steps: 1) Choose — Create a numbered list of selection tasks (e.g., "Create: select SP1–SP8 candidates") and list the expected outcome (selected list with snippet IDs) and a visual indicator (badge or table row marked "selected"); 2) Place — Configure placement tasks (e.g., "Place: add SP1+SP2 to Hero, SP3 to Mid-page…") with expected outcome (snippet mapped to page regions) and a visual indicator (annotated mock or CSS class applied); 3) Validate — Analyze evidence tasks (e.g., "Validate: add entries to proof_registry for each snippet with evidence URL/file and last verified date") with expected outcome (all snippets have proof_registry entries and pending variants flagged) and a visual indicator (proof_registry status column = verified/pending); 4) Review — Review and approve tasks (e.g., "Review: obtain approval owner signatures and permission records for testimonials/logos") with expected outcome (approval recorded) and visual indicator (approval checkbox or timestamp). Also convert the deliverables checklist into actionable subtasks tied to these steps (ensure each checked item maps to Choose/Place/Validate/Review) and state one clear success criterion for the whole workflow (e.g., "All 8 snippets have placement, proof_registry entry, and approval = ready for production").
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In `@docs/content/features/landing-page-social-proof-pack-from-old.md`:
- Around line 138-149: The evidence matrix and handoff rules are internal ops
details and should be removed from this feature doc; extract the entire table
(rows SP1–SP8) plus any references to Owner, Publish gate, proof_registry,
approval records, and verification rules and move them into an internal
handoff/ops artifact, leaving the feature page with a concise, user-facing
summary of what proofs or social-proof types exist (one-line descriptions per
proof ID if needed) without operational columns or jargon; update any in-doc
references at lines ~174-184 to point to the new internal artifact instead of
embedding the table here.
- Around line 70-73: Replace the awkward bullet text "Baseline vs after period
definition" with a clearer phrase such as "Baseline and after-period definition"
in the list under the Evidence required section; locate the exact string
"Baseline vs after period definition" in
docs/content/features/landing-page-social-proof-pack-from-old.md and update it
to the new wording so the docs are easier to scan and follow.
- Around line 1-10: Reframe the document to lead with user/business value:
replace the current opening lines ("TuxSEO Landing-Page Social Proof Pack
(ported from TuxSEO Old)" and the Owner/Date/Source intent metadata) with a
short, user-facing intro that explains what teams can accomplish with this pack
and how it improves conversions (e.g., increase trust, lift CTA performance,
easy verified claims workflow), then keep the "Social proof snippet library
(with confidence variants)" section and the notes about "Strong proof" and
"Pending validation" but move the provenance metadata (Owner/Date/Source intent)
to the end or a separate "Implementation notes" section; ensure the first
paragraph focuses on business outcomes and actionable team benefits before any
technical or validation rules.
---
Nitpick comments:
In `@docs/content/features/landing-page-social-proof-pack-from-old.md`:
- Around line 151-192: Convert the "Final on-page placement recommendation" and
"Implementation notes" into a task-based workflow using four numbered steps: 1)
Choose — Create a numbered list of selection tasks (e.g., "Create: select
SP1–SP8 candidates") and list the expected outcome (selected list with snippet
IDs) and a visual indicator (badge or table row marked "selected"); 2) Place —
Configure placement tasks (e.g., "Place: add SP1+SP2 to Hero, SP3 to Mid-page…")
with expected outcome (snippet mapped to page regions) and a visual indicator
(annotated mock or CSS class applied); 3) Validate — Analyze evidence tasks
(e.g., "Validate: add entries to proof_registry for each snippet with evidence
URL/file and last verified date") with expected outcome (all snippets have
proof_registry entries and pending variants flagged) and a visual indicator
(proof_registry status column = verified/pending); 4) Review — Review and
approve tasks (e.g., "Review: obtain approval owner signatures and permission
records for testimonials/logos") with expected outcome (approval recorded) and
visual indicator (approval checkbox or timestamp). Also convert the deliverables
checklist into actionable subtasks tied to these steps (ensure each checked item
maps to Choose/Place/Validate/Review) and state one clear success criterion for
the whole workflow (e.g., "All 8 snippets have placement, proof_registry entry,
and approval = ready for production").
ℹ️ Review info
⚙️ Run configuration
Configuration used: defaults
Review profile: CHILL
Plan: Pro
Run ID: 0321462d-ef11-4b40-935b-a2918944ea24
📒 Files selected for processing (1)
docs/content/features/landing-page-social-proof-pack-from-old.md
| # TuxSEO Landing-Page Social Proof Pack (ported from TuxSEO Old) | ||
|
|
||
| Owner: Scribe | ||
| Date: 2026-03-11 | ||
| Source intent: Rebuild a conversion-ready social-proof layer using verified claims only. | ||
|
|
||
| ## 1) Social proof snippet library (with confidence variants) | ||
|
|
||
| Use the **Strong proof** variant only when evidence is confirmed and permission is cleared. | ||
| Use **Pending validation** variant while evidence is being collected. |
There was a problem hiding this comment.
Reframe the opening around user value, not internal provenance.
This starts with internal metadata and a legacy-port note, then immediately drops into validation rules. In docs/content/features/, the page should first explain what teams can accomplish with this pack and why it improves conversions before getting into proof variants or evidence handling. As per coding guidelines, docs/**/*.{md,mdx} should "explain business value before technical details" and "write documentation focused on what users can do with features, not implementation details."
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@docs/content/features/landing-page-social-proof-pack-from-old.md` around
lines 1 - 10, Reframe the document to lead with user/business value: replace the
current opening lines ("TuxSEO Landing-Page Social Proof Pack (ported from
TuxSEO Old)" and the Owner/Date/Source intent metadata) with a short,
user-facing intro that explains what teams can accomplish with this pack and how
it improves conversions (e.g., increase trust, lift CTA performance, easy
verified claims workflow), then keep the "Social proof snippet library (with
confidence variants)" section and the notes about "Strong proof" and "Pending
validation" but move the provenance metadata (Owner/Date/Source intent) to the
end or a separate "Implementation notes" section; ensure the first paragraph
focuses on business outcomes and actionable team benefits before any technical
or validation rules.
| **Evidence required:** | ||
| - Publication logs (CMS timestamps) | ||
| - Baseline vs after period definition | ||
| - Short method note (what changed operationally) |
There was a problem hiding this comment.
Tighten the wording on the baseline/after period bullet.
Baseline vs after period definition is awkward and matches the grammar warning here. A small rewrite like Baseline and after-period definition reads more cleanly. As per coding guidelines, docs/**/*.{md,mdx} should "write documentation that is easy to scan and navigate."
🧰 Tools
🪛 LanguageTool
[grammar] ~72-~72: Use a hyphen to join words.
Context: ...ogs (CMS timestamps) - Baseline vs after period definition - Short method note (w...
(QB_NEW_EN_HYPHEN)
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@docs/content/features/landing-page-social-proof-pack-from-old.md` around
lines 70 - 73, Replace the awkward bullet text "Baseline vs after period
definition" with a clearer phrase such as "Baseline and after-period definition"
in the list under the Evidence required section; locate the exact string
"Baseline vs after period definition" in
docs/content/features/landing-page-social-proof-pack-from-old.md and update it
to the new wording so the docs are easier to scan and follow.
| ## 2) Evidence matrix (what exists vs what must be collected) | ||
|
|
||
| | Proof ID | Claim type | Current confidence | Evidence status | Source requirement | Owner | Publish gate | | ||
| |---|---|---:|---|---|---|---| | ||
| | SP1 | Active projects count | Pending | Needs refreshable metric query | Analytics/DB query + definition of "active" + timestamp | Product/Ops | Must verify before numeric publish | | ||
| | SP2 | Speed-to-draft median | Pending | Not yet calculated | Event logs + median method + sample size | Product/Eng | Must verify before numeric publish | | ||
| | SP3 | Testimonial quote | Pending | Quote exists conceptually, no formal approval attached | Written permission + attribution approval | CS/Founder | Attribution required | | ||
| | SP4 | Publishing consistency improvement | Pending | Needs case-level baseline/after data | CMS export + period comparison | CS/Content | Numeric only after validation | | ||
| | SP5 | Ranking traction | Pending | Needs SEO export and attribution notes | GSC/export + page mapping | SEO/Ops | Numeric only after validation | | ||
| | SP6 | Editorial control claim | Strong | Product workflow supports this | UI screenshots + docs | Product | Safe to publish now | | ||
| | SP7 | WordPress workflow claim | Strong (if current integration passes QA) | Setup guide exists; QA check needed for current release | Setup doc + current QA run | Product/Eng | Publish after quick QA pass | | ||
| | SP8 | Non-generic output claim | Pending | Conceptual evidence only | Prompt/context architecture + editing examples | Product/Content | Avoid over-claiming until examples are documented | |
There was a problem hiding this comment.
Move the evidence matrix and handoff rules out of the feature doc.
Owner, Publish gate, proof_registry, approval records, and verification rules are internal process details. They make sense in an ops/handoff artifact, but they make this page read like an implementation brief instead of feature documentation. As per coding guidelines, docs/**/*.{md,mdx} should "write documentation focused on what users can do with features, not implementation details, using plain language without technical jargon."
Also applies to: 174-184
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@docs/content/features/landing-page-social-proof-pack-from-old.md` around
lines 138 - 149, The evidence matrix and handoff rules are internal ops details
and should be removed from this feature doc; extract the entire table (rows
SP1–SP8) plus any references to Owner, Publish gate, proof_registry, approval
records, and verification rules and move them into an internal handoff/ops
artifact, leaving the feature page with a concise, user-facing summary of what
proofs or social-proof types exist (one-line descriptions per proof ID if
needed) without operational columns or jargon; update any in-doc references at
lines ~174-184 to point to the new internal artifact instead of embedding the
table here.
1 participant
Summary
Why
This ships the requested task as a repo artifact via PR so it can be reviewed/merged and tracked in production workflow.
Files
Summary by CodeRabbit