CtrlK
BlogDocsLog inGet started
Tessl Logo

frontdesk-intake

Convert user conversation into macro workflow requests and present curated clarification or final artifacts.

54

Quality

60%

Does it follow best practices?

Run evals on this skill

Adds up to 20 points to the overall score

View guide

SecuritybySnyk

Passed

No findings from the security scan

Fix and improve this skill with Tessl

tessl review fix ./docs/plantree/plans/agentic-loop-workflow/drafts/agentroles.ccb_frontdesk/skills/frontdesk-intake/SKILL.md
SKILL.md
Quality
Evals
Security

Quality

Content

67%Weight 40%Scale 1-5

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

The body is a dense, highly concrete protocol: strict classification rules, exact artifact templates, a single fully-specified submission command, and explicit prohibitions with a validation checkpoint for final reports. Its main weaknesses are redundant restatement of the final-report and intake rules across sections, a couple of underspecified details (request-id format, Codex call shape), and no post-submission error-recovery path.

Suggestions

Consolidate the duplicated final-report rules (lines 32-43) into a single statement; both paragraphs say 'do not forward' and 'render only user_report_body'.

Prune Rules entries that restate inline guidance (e.g. 'Convert implementation requests into the **Intake Evidence** artifact' repeats the classification section) and keep the Rules list to genuinely new prohibitions.

Specify the request-id format (what 'bounded id' means concretely) and give a full example invocation of ccb_frontdesk_ask_planner for the Codex path.

DimensionReasoningScore

Conciseness

The body is mostly efficient — no padding or explanation of known concepts — but it could be tightened: the final-report rules appear twice ('Do not forward this status back to Planner' and 'render only user_report_body' are each stated in both the paragraph at lines 32-38 and again at lines 40-43), and the Rules section restates guidance already given inline (e.g. 'Convert implementation requests into the **Intake Evidence** artifact'). This is more than minor trimming, so it fits the 'could be tightened' anchor rather than the efficient anchor.

3 / 5

Actionability

The guidance is largely executable: exact markdown reply templates, the exact one allowed shell command with all flags, exact labels, and a strict four-way classification. It falls short of fully copy-paste ready because the request-id format is unspecified ('a fresh bounded id'), and the Codex path only names the tool and parameters without a full example. Minor gaps, matching the mostly-executable anchor.

4 / 5

Workflow Clarity

The multi-step process is clearly sequenced: classify every message (a four-way checklist), produce the exact evidence artifact, submit exactly once with the single allowed command, then stop — with an explicit validation checkpoint ('If the schema or validation marker is absent, report a blocker instead of rendering'). Not a 5 because there is no error-recovery loop after submission or after a rejected ask, and some sequencing rules are scattered between the narrative and the Rules section.

4 / 5

Progressive Disclosure

No bundle files exist (references/, scripts/, assets/ are absent), so the skill is a single self-contained protocol; it has good structure with clear sections (Inputs, Outputs, classification, two templates, Rules) and no buried or nested references. Not a 5 because the ~145-line body inlines content (the full rule catalog and both templates) that could arguably live in reference files, and organization of the long Rules list could be tighter.

4 / 5

Total

15

/

20

Passed

Description

53%Weight 40%Scale 1-5

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 gives a clear, concrete 'what' in third person, but lacks any explicit 'when to use' trigger clause and relies on pipeline-specific jargon rather than natural trigger terms. It is functional but below the standard of the good examples, which pair capabilities with concrete 'Use when...' phrasing.

Suggestions

Append an explicit trigger clause, e.g. 'Use when the user submits a request that requires implementation, testing, or verification work, or when a final workflow report or blocked prerequisite needs to be surfaced.'

Add natural trigger terms users would actually say (e.g. 'intake', 'build/fix/verify request', 'blocked on credentials') alongside the internal 'macro workflow' vocabulary.

Briefly enumerate the three concrete outcomes (clarification reply, intake evidence handoff, final/escalation report) to raise specificity coverage.

DimensionReasoningScore

Specificity

The description names two concrete actions — 'Convert user conversation into macro workflow requests' and 'present curated clarification or final artifacts' — matching the anchor for 1-2 concrete actions without comprehensive coverage. It is not a 4 because it does not list several specific actions, and not a 2 because the actions are concrete rather than generic.

3 / 5

Completeness

The 'what' is stated clearly ('Convert user conversation into macro workflow requests and present curated clarification or final artifacts') but there is no 'Use when...' clause or equivalent explicit trigger guidance, which caps completeness at 3 per the judging guidelines.

3 / 5

Trigger Term Quality

Phrases like 'workflow requests', 'clarification', and 'final artifacts' are somewhat relevant but are internal jargon rather than natural user phrasing, and common variations or synonyms are missing. It sits between the generic-keyword anchor (2) and good natural keyword coverage (4).

3 / 5

Distinctiveness Conflict Risk

The niche (macro workflow intake and routing to a planner) is fairly distinct and unlikely to trigger for unrelated skills, though 'workflow requests' and 'clarification' could minorly overlap with general orchestration or Q&A skills. Not a 5 because the trigger surface is not sharply differentiated.

4 / 5

Total

13

/

20

Passed

Validation

100%

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
SeemSeam/claude_codex_bridge
Reviewed

Table of Contents

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.