customer-db

Maintain a persistent SQLite customer database within the sales-cs workspace. The system hook injects peer (DB primary key) and the Sender block provides user_id_external (raw awada user ID). Use peer for all DB operations.

Quality

57%

Does it follow best practices?

Run evals on this skill

Adds up to 20 points to the overall score

View guide

Securityby

Passed

No findings from the security scan

Fix and improve this skill with Tessl

tessl review fix ./crews/sales-cs/skills/customer-db/SKILL.md

Quality

Content

80%

Reviews the quality of instructions and guidance provided to agents. Good implementation is clear, handles edge cases, and produces reliable results.

The body is highly actionable and concise, with executable commands and domain-specific field knowledge that earns its tokens. Its weaknesses are the absence of validation/verification feedback loops around database writes and a dangling HEARTBEAT.md reference that breaks navigation.

Suggestions

Add an explicit verification step after write/create operations (e.g. re-query via follow-up-due.sh or a read-back check) so the workflow includes a validate->fix->retry loop and can reach workflow_clarity 3.

Either provide the missing HEARTBEAT.md file referenced in section four or remove the dangling reference so navigation is fully resolvable.

Add a brief error-handling note for the scripts (what to do on SQL errors or peer/sessionKey mismatch) to complete the feedback loop for database operations.

Dimension	Reasoning	Score
Conciseness	The body is lean and assumes competence: it documents only domain-specific facts Claude would not know (field enums like business_status, purpose/prompt_source value lists, the two identifier semantics) and never explains basic concepts such as what SQLite is, matching the 'lean and efficient; every token earns its place' anchor.	3 / 3
Actionability	Every operation is given as a complete, copy-paste-ready bash command with all flags and concrete example values (e.g. cs-update.sh --peer --purpose --prompt-source, follow-up-create.sh with --user-id-external --follow-up-at --reason --context-summary), matching the 'fully executable code/commands; copy-paste ready' anchor.	3 / 3
Workflow Clarity	Sequences are present (cancel old pending task then create new; status flow pending -> sent_once -> completed), but there are no explicit validation or verification checkpoints after database writes, and the rubric caps database-operation workflows without feedback loops at 2.	2 / 3
Progressive Disclosure	Structure is good with five clear sections and one-level-deep script references that resolve to real files in ./scripts/, but the body references HEARTBEAT.md ('heartbeat 完整执行流程见 HEARTBEAT.md') which is not present in the bundle, a broken navigation link that keeps it below the well-signaled level 3.	2 / 3
	Total	10 / 12 Passed

Description

35%

Based on the skill's description, can an agent find and select it at the right time? Clear, specific descriptions lead to better discovery.

The description conveys a clear niche (a sales-cs SQLite customer database) and a single concrete action, but it is written as internal mechanics rather than user-facing guidance. It lacks natural trigger terms and any 'Use when...' clause, capping completeness and trigger quality.

Suggestions

Add an explicit 'Use when ...' clause naming situations a user would voice, e.g. 'Use when saving or updating a customer's business status, follow-up tasks, or acquisition channel in the sales-cs customer database.'

Replace internal jargon (peer, Sender block, user_id_external) in the description with user-facing capability language; move the identifier mechanics into the body where they are already documented.

List the concrete operations the skill performs (create/update records, schedule follow-ups, query due tasks) so specificity reaches the multi-action level.

Dimension	Reasoning	Score
Specificity	The description names a concrete domain and a single action ("Maintain a persistent SQLite customer database within the sales-cs workspace") but does not enumerate multiple specific operations, matching the 'names domain and some actions, but not comprehensive' anchor rather than the multi-action level 3.	2 / 3
Completeness	It states what the skill does (maintain a persistent SQLite customer database) but provides no 'when to use it' guidance, so per the rubric's 'Use when...' cap rule it cannot exceed 2.	2 / 3
Trigger Term Quality	It is dominated by internal jargon ("system hook injects peer", "DB primary key", "Sender block provides user_id_external", "raw awada user ID") rather than natural terms a user would actually say, matching the 'no natural keywords; technical jargon' anchor.	1 / 3
Distinctiveness Conflict Risk	Scoping to the "sales-cs workspace" gives it a narrow niche, but the absence of distinct trigger terms means it could still overlap with similar data-handling skills, matching the 'somewhat specific but could still overlap' anchor.	2 / 3
	Total	7 / 12 Passed

Validation

100%

Warnings & errors only

Checks the skill against the spec for correct structure and formatting. All validation checks must pass before discovery and implementation can be scored.

Validation — 16 / 16 Passed

Validation for skill structure

No warnings or errors.

Repository: TeamWiseFlow/xiaobei
Path: crews/sales-cs/skills/customer-db/SKILL.md
Commit: bcef823

Reviewed: 3 days ago

Table of Contents

Discovery Implementation Validation

Is this your skill?

If you maintain this skill, you can claim it as your own. Once claimed, you can manage eval scenarios, bundle related skills, attach documentation or rules, and ensure cross-agent compatibility.