Tessl • The package manager for agent skills

Blog Docs Log inGet started

SkillPublic

build-in-public

Best practices for sharing engineering work publicly — what to post, what to withhold, and channel-specific guidance

Quality

70%

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 ./skills/build-in-public/SKILL.md

Quality

Content

75%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 content is well-structured, actionable, and sequenced, giving Claude concrete specs, examples, and a triggered posting workflow without padding. It is held at 4 rather than 5 by minor trimmable phrasing, the absence of error-recovery feedback loops, and inline channel deep-dives that could be externalized.

Suggestions

Trim editorial asides ("No hype sludge", "You're not accepting an award") to push conciseness toward anchor 5.

Add a short validation/retry note for the plugin flow (e.g., what to do when a post is flagged by anonymize.yaml) to strengthen workflow feedback loops.

Consider moving the LinkedIn and X channel deep-dives into references/linkedin.md and references/x.md to improve progressive disclosure toward anchor 5.

Dimension	Reasoning	Score
Conciseness	The body is efficient and avoids re-explaining concepts Claude already knows, instead delivering domain-specific social-media strategy; only minor phrases ("No hype sludge. No 'I'm excited to announce.'") could be trimmed, fitting anchor 4 rather than the fully lean anchor 5.	4 / 5
Actionability	Provides concrete, executable guidance — character limits (800-2000, 280 max), posting windows (Tue-Thu 8-10 AM), metric thresholds (3-5% engagement, 8%+ great), example posts, and plugin YAML — matching anchor 4 with only minor gaps versus the copy-paste-ready anchor 5.	4 / 5
Workflow Clarity	The Content Calendar Rhythm and plugin integration lay out a clear triggered sequence (PR merged -> LinkedIn within 24h, X same day; feature shipped -> LinkedIn first, X 90m later), fitting anchor 4; this is not a destructive/batch skill so the validation cap does not apply, but it lacks explicit error-recovery feedback loops.	4 / 5
Progressive Disclosure	No bundle files exist and the body is organized into clear, well-labeled sections (Philosophy, What to Share, Channel-Specific, Calendar, Anti-Patterns, Measuring, Plugin, Anonymous); the channel-specific deep dives are reasonably inline, fitting anchor 4, though they are long enough that splitting LinkedIn/X into reference files could reach anchor 5.	4 / 5
	Total	16 / 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 clearly conveys the skill's purpose and niche but relies on abstract categories rather than concrete actions and lacks an inline trigger clause, with the actual "when" guidance split into a separate frontmatter field. Adding a "Use when..." clause and the natural term "build in public" would lift specificity, trigger quality, and completeness.

Suggestions

Append an explicit trigger clause to the description, e.g. "Use when drafting build-in-public posts, changelogs, or launch content for social channels," so completeness is not capped at 3.

Include the natural phrase "build in public" and synonyms (social posts, ship logs, dev updates) in the description to improve trigger-term quality.

Replace abstract categories ("what to post, what to withhold") with concrete verbs such as "draft, redact, and schedule engineering posts for LinkedIn and X" to raise specificity.

Dimension	Reasoning	Score
Specificity	Names the domain and a few facets ("what to post, what to withhold, and channel-specific guidance") but these are abstract categories rather than concrete verbs, matching anchor 3 and falling short of the multiple specific actions at anchor 4.	3 / 5
Completeness	Clearly states the "what" (best practices for sharing engineering work, what to post/withhold, channel guidance) but the description field itself lacks a "Use when..." clause — the trigger guidance lives in a separate when-to-use field — so completeness is capped at 3 per the rubric guideline.	3 / 5
Trigger Term Quality	Contains relevant keywords like "sharing engineering work publicly" but omits the natural phrase users would say ("build in public") and common synonyms, matching anchor 3 rather than the comprehensive coverage at anchor 4-5.	3 / 5
Distinctiveness Conflict Risk	Targets a clear niche (engineering build-in-public social content) with low conflict risk against other skills, fitting anchor 4 (mostly distinct, minor overlap) rather than the fully distinct anchor 5 because the description alone lacks the signature "build in public" trigger phrase.	4 / 5
	Total	13 / 20 Passed

Validation

93%

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 — 15 / 16 Passed

Validation for skill structure

Criteria	Description	Result
frontmatter_unknown_keys	Unknown frontmatter key(s) found; consider removing or moving to metadata	Warning

	Total	15 / 16 Passed

Repository: alinaqi/maggy
Path: skills/build-in-public/SKILL.md
Revision: 55aabe2

Reviewed: 20 days ago

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.

build-in-public

Table of Contents

Is this your skill?