顧客アカウントの評判監視

---
name: customer-account-sentiment-monitoring
description: Build, approve, and run recurring Xiaohongshu account sentiment monitoring with Google Drive reports and a simple Google Sheets run log.
---

# Customer Account Sentiment Monitoring

## Loadout capabilities

Use <action-tag>api:tikhub_api:xiaohongshu_app_v2</action-tag> for Xiaohongshu user search, account information, posted-note lists, note details, top-level comments, and selected sub-comments. It is read-only but billable, so inspect its live schema and preflight the bounded call set before every baseline or recurring scan.

Use <action-tag>composio:googledrive_tools:googledrive_list_children_v2</action-tag> to verify access to the user-selected folder, detect existing child IDs, and read back the created artifact references. Use <action-tag>composio:googledrive_tools:googledrive_create_folder</action-tag> to create one run folder under the selected folder. Use <action-tag>composio:googledrive_tools:googledrive_create_file_from_text</action-tag> to create the monitoring-plan Google Doc and each run-report Google Doc in the correct folder.

Use <action-tag>composio:googlesheets_tools:googlesheets_create_google_sheet1</action-tag> to create the account's monitoring log in the selected folder. Use <action-tag>composio:googlesheets_tools:googlesheets_batch_get</action-tag> to inspect headers, locate the next empty row, and prevent duplicate run entries. Use <action-tag>composio:googlesheets_tools:googlesheets_update_values_batch</action-tag> to initialize or append the reviewed log fields and then read the written cells back.

Do not replace these exact Action references with generic web search, scraping, browser automation, or direct provider APIs while they remain available. Never request raw provider credentials. Use Aident Vault for Google OAuth and the active Aident-managed or user-connected TikHub access.

## Operating boundary

- Read only public Xiaohongshu account, post, and comment data. Do not log in to Xiaohongshu, bypass access controls, publish, comment, message, follow, or modify an account.
- The initial account scan is a bounded read-only operation. Google Drive writes and recurring automation require approval of the complete monitoring plan.
- Recommendations are not authorization to apply changes to a profile, post, customer-support workflow, or any other system.
- Treat sentiment as an evidence-based operational signal, not a claim about a person's private intent or protected traits.
- Keep short evidence excerpts only when needed to explain a finding. Prefer summaries, counts, timestamps, and source links. Do not copy entire posts or comment threads.
- Follow current Action authorization, acknowledgement, billing, connection, and risk checks even when this Skill says to continue.

## 1. Ask for the account

At the start of a new setup, ask one required question:

> 请提供需要监测的小红书账户链接或账户名称。

Accept a public profile URL, share text containing a profile URL, or an account name. Do not ask for Google Drive access or a schedule yet.

If the user supplied a link, resolve the account directly and record the stable user ID, current display name, canonical profile link when returned, bio, and retrieval time. If the user supplied a name, use the Xiaohongshu user-search operation, show only the plausible candidates with their distinguishing public fields, and ask the user to select when more than one candidate remains plausible. Never silently choose an ambiguous namesake.

If the link or selected result cannot be resolved, stop before sampling and ask for a public profile link. Do not broaden to a general web search.

## 2. Run the bounded baseline scan

After identity is resolved, inspect the live Xiaohongshu Action schema and pricing, preflight the bounded call set, and satisfy any required acknowledgement. The request to use this Skill authorizes only the default read-only baseline; it does not authorize Google writes or automation.

Use this default baseline unless the user requested a smaller scope:

1. Fetch the account's posted-note list and sort returned items by their observed publication timestamp.
2. Select up to five latest posts from the last 30 days. If fewer than five exist, use all returned posts in the window and state the gap. Do not substitute unrelated search results.
3. Fetch the matching image-note or video-note detail for each selected post.
4. Fetch up to 20 newest available top-level comments per selected post. Sample sub-comments only for threads that contain a complaint, factual dispute, safety issue, service failure, rumor, or rapidly repeated question, with a default maximum of ten sub-comment calls across the baseline.
5. Record actual posts, comments, sub-comments, pages, calls, time range, and missing or truncated data. Never describe the sample as complete coverage.

For every sampled post, retain the source ID or link, publication time, short content summary, public engagement counts returned by the Action, comment count sampled, and observed themes. Classify each sampled comment as positive, neutral, question, complaint/negative, misinformation or factual dispute, safety/compliance, or other. Preserve the source's language and mark uncertainty rather than forcing a label.

Summarize the baseline with:

- overall observed sentiment and the count behind each label;
- recurring praise, questions, objections, and unmet expectations;
- issue candidates with evidence links, severity, confidence, and whether they are isolated or repeated;
- changes that can be detected only on later runs, explicitly marked as awaiting a comparison baseline;
- data gaps, platform limits, and the settled Action-call cost when available.

## 3. Draft the monitoring plan

Write a simple plan using the [artifact templates](references/artifact-templates.md). Ground detected risks in the sampled evidence. Separate them from plausible future risks, which must be labeled as hypotheses.

Recommend a cadence from the observed activity and risk:

- **Daily:** default for low or moderate activity without a current high-severity issue.
- **Every 12 hours:** use when posts or material comments appear most days, an active campaign is running, or medium-risk complaints are repeating.
- **Every 4 hours for 72 hours, then daily:** use only for a launch, incident, viral thread, safety concern, or fast-growing high-severity issue.
- **Weekly:** use only when the account is inactive and the user accepts slower detection.

Do not recommend a cadence more frequent than every four hours by default. State the timezone, kickoff minute, estimated Xiaohongshu call volume per run, current unit price, estimated cost per run, and the condition that returns a temporary high-frequency monitor to its normal cadence.

For each current or plausible issue, propose one practical preventive Action with an owner and verification test. Examples include clarifying a recurring promise, pinning or preparing an FAQ, fixing an ambiguous profile claim, documenting refund or escalation paths, preserving supporting evidence, or preparing a response template. Recommend only Actions supported by the evidence. Do not execute them as part of monitoring.

The plan must also define:

- the stable account identity and monitored public surfaces;
- post and comment sampling limits;
- sentiment labels, risk levels, and escalation thresholds;
- the default notification rule: write every run to Drive, remain quiet for routine no-change results, and notify the user for medium/high risk, a material trend change, failure, or required action;
- the selected Google Drive folder, plan Doc, log Sheet, run-folder format, and report format, initially marked as awaiting setup;
- recovery behavior for partial Action, Drive, Sheet, or scheduler failures.

## 4. Require plan approval

Show the complete plan in chat before any Google Drive write or automation creation. End with one explicit question asking the user to approve the exact account, scope, sampling limits, schedule, timezone, alert policy, estimated call volume and cost, preventive Actions, and artifact layout.

Treat edits as a new plan revision and ask again. A general request to monitor is not approval of an unstated schedule or cost. Do not create a folder, document, spreadsheet, recurring automation, or preventive external Action before approval.

## 5. Connect Google Drive and create setup artifacts

After approval, check Google Drive and Google Sheets connection status. If either requires user setup, provide the Aident Vault connection flow and wait for the user to complete it. Then ask for the link to one existing Google Drive folder. Extract its folder ID, list its children to verify access, and confirm the intended Google account when more than one active account is available.

Use the linked folder itself as the monitoring root. Sanitize only characters that make names ambiguous; preserve the account's public display name as `XXX`. Create or reuse exactly these root artifacts:

- `XXX舆情监测计划` as a native Google Doc containing the approved plan, approval time, timezone, and plan revision;
- `XXX舆情监测更新表` as a native Google Sheet containing the log headers defined in the artifact templates.

Check for exact-name matches before creating anything. Reuse one verified matching artifact, stop for user selection when duplicates exist, and never overwrite an existing artifact with different content. Capture and retain the root folder ID, plan document ID and link, spreadsheet ID and link, worksheet name, and exact approved plan revision. Read the Sheet headers back after initialization.

## 6. Create the recurring local automation

Read and follow the [automation contract](references/automation-contract.md). Use the active agent host's documented local recurring-automation mechanism. Prefer a task-attached local heartbeat when available; use a standalone local cron only when the user explicitly chose a separate task. Do not hand-write unsupported scheduler directives or claim that a schedule is active without authoritative readback.

The recurring prompt must include the stable account ID and link, approved sampling limits, schedule and timezone, alert thresholds, root folder ID, plan Doc ID, log Sheet ID and worksheet, naming format, and failure behavior. It must re-check live schemas, pricing, and connection state on every run instead of embedding credentials or transient URLs.

Create the automation only for the approved schedule. Read it back and report its exact name, status, next run when available, timezone, destination, and artifact links. If the host cannot create recurring local automations, stop after Drive setup, provide a manual run prompt, and report monitoring as **not scheduled**.

Do not trigger a test run unless the user separately asks to test. Approval of the monitoring plan authorizes setup, not an immediate extra scan.

## 7. Execute each scheduled run

At the start of every run, capture one immutable kickoff timestamp in the approved timezone. Name the run folder:

`YYYY-MM-DD HH-mm IANA_Time_Zone UTC±HH-mm`

Replace `/` in the IANA timezone with `_`; for example, `2026-09-21 09-30 America_New_York UTC-04-00`. Use this kickoff value everywhere even if the scan finishes later. Before creating a retry folder, list the monitoring root and reuse the exact folder ID already recorded for that kickoff. Never rely on names alone when duplicate Google Drive folder names exist.

Then:

1. Create or recover the run folder under the monitoring root.
2. Fetch the latest account posts, select the approved sample, fetch note details, and sample comments using the approved bounds.
3. Compare stable post and comment IDs with the prior successful run. Separate new content, changed public counts, recurring themes, resolved issues, and unavailable comparisons.
4. Produce `XXX舆情监测报告 - {kickoff}` as a native Google Doc inside the run folder, using the report template. A partial scan still gets a report with its failure and coverage clearly marked.
5. List the run folder, capture the verified report link, and update exactly one log row. Read the bounded log range first, reuse a row with the same account ID and kickoff timestamp on retry, otherwise write the next empty row. Read the written row back.
6. Notify according to the approved alert policy. Include the verified report link in any notification.

If Xiaohongshu fails, create the failure report and log the run as `partial` or `failed` when Drive remains available. If report creation fails, do not write a false report link. If the Sheet update fails after the report is created, retain the report and return its link with `log update pending`; the next retry must update the same kickoff row rather than create another scan. If credits are insufficient, stop without retrying and return the billing URL supplied by Loadout.

## 8. Handoff states

Use precise status language:

- **Plan drafted:** baseline sampled and plan proposed; no Google artifacts or automation exist.
- **Plan approved:** the user approved the exact revision; setup may proceed.
- **Drive configured:** the plan Doc and update Sheet were created or verified and read back.
- **Scheduled:** the local automation was created and read back as active.
- **Run completed:** the report exists, its link was verified, and the Sheet row was read back.
- **Monitoring live:** use only after setup is scheduled and at least one dynamic run has completed successfully.

Return the account identity, baseline coverage, plan revision and approval state, schedule, timezone, connection state, artifact links, automation readback, last run status, cost evidence, and any limitation. Never conflate a locally validated Skill package with a scheduled or live monitor.