CtrlK
BlogDocsLog inGet started
Tessl Logo
SkillPublic

ask-navigator

Shipyard's navigator — chart a foggy effort (destination unclear, questions not yet stateable) into a map of decision tickets on the repo's issue tracker, then work the frontier one ticket per session until the way is clear, and hand the collapsed decisions to /launch as a mission brief. Wayfinding, not building: it produces decisions, never deliverables.

Quality

79%

Does it follow best practices?

Run evals on this skill

Adds up to 20 points to the overall score

View guide
SecuritybySnyk

Low

Low-risk findings worth noting

Fix and improve this skill with Tessl

tessl review fix ./skills/ask-navigator/SKILL.md
SKILL.md
Quality
Evals
Security

Quality

Content

81%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 an unusually well-engineered process skill: fully actionable numbered workflows with explicit captain-signature validation gates, concrete formats and templates, and clean section structure. Its one real cost is token efficiency — repeated contract statements and metaphor-heavy prose inflate the always-loaded body, and two specialized edge-case blocks (migration, legacy glossary) belong in reference files.

DimensionReasoningScore

Conciseness

The body is dense with substantive, project-specific rules and explains nothing Claude would already know, but it could be meaningfully tightened: the tracker-only-medium rule is restated across 'Map home', the migration paragraph, and 'Scope and non-goals'; 'decisions, never deliverables' and 'one ticket per session' are each repeated several times; and the nautical framing plus long compound sentences add tokens without adding rules. More than the 'minor instances' of anchor 4, but far from the padded filler of anchor 2.

3 / 5

Actionability

For an instruction-only skill the guidance is fully concrete: two numbered procedures with unambiguous steps, a copy-paste-ready map body template, a ticket-type table giving the exact resolution mechanism per type ('Call the Skill tool with "deep-interview"', 'spawn a background subagent', 'Call the Skill tool with "loft"'), an exact index-line format ('[<ticket title>](link): <one-line gist>'), a named command ('node scripts/shipyard-audit.mjs'), and verbatim exit and session-close phrasings. The common charting, working, and exit cases are all covered specifically.

5 / 5

Workflow Clarity

Both multi-step processes are clearly sequenced, and validation checkpoints are explicit: the fog test (Q1/Q2) gates entry, W1 and W2 are captain signatures ('present the destination statement and get explicit confirmation', 'iterate until signed'), the migration path requires 'verify every decision, resolution, and dependency is represented before declaring the import complete', and claiming-before-work plus close-as-not-planned rules handle concurrency and out-of-scope tickets. Feedback loops (re-interview rounds, iterate-until-signed, import verification) are present for the risky tracker operations.

5 / 5

Progressive Disclosure

No bundle files exist (references/, scripts/, assets/ are absent), so all content lives in SKILL.md, and it is well organized: clear section headers, a ticket-type table, and a fenced map-body template make navigation easy, and pointers to companion skills (deep-interview, loft, drydock, launch) are one level deep. It falls short of anchor 5 because two dense inline blocks — the one-time local-map migration paragraph and the legacy-yards (CONTEXT.md) sediment rules — are exactly the kind of specialized, rarely-needed detail that would earn its place in a separate reference file instead of the always-loaded body.

4 / 5

Total

17

/

20

Passed

Description

71%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 communicates what the skill does, its scope boundary (decisions, not deliverables), and when it applies, with strong distinctiveness. Its main weakness is trigger vocabulary: the phrasing is internal-jargon-heavy rather than the words a user would naturally say, and the trigger condition is embedded rather than explicit.

Suggestions

Rewrite the trigger condition as an explicit 'Use when...' clause with natural user phrasing, e.g. 'Use when the user has a loose idea or an effort whose destination or first decisions cannot be stated yet, or hands over residual questions from launch.'

Add common synonyms users would say ('vague idea', 'unclear requirements', 'break down / plan this effort') alongside the shipyard vocabulary so the natural phrases are represented, not just the in-universe terms.

Trim the metaphorical framing ('Shipyard's navigator —', 'Wayfinding, not building') or pair each metaphor with its plain-language equivalent so the concrete actions carry the description.

DimensionReasoningScore

Specificity

The description lists several concrete actions — 'chart a foggy effort... into a map of decision tickets on the repo's issue tracker', 'work the frontier one ticket per session', 'hand the collapsed decisions to /launch as a mission brief' — with a named medium and a clear output contract ('produces decisions, never deliverables'). It falls short of anchor 5 because the metaphorical framing ('Shipyard's navigator', 'wayfinding, not building') substitutes abstraction where a plainer action statement would be more concrete.

4 / 5

Completeness

The 'what' is clearly stated (chart a foggy effort into a map of decision tickets, work the frontier one ticket per session, hand off a mission brief), and the 'when' is present as explicit trigger guidance in the parenthetical '(destination unclear, questions not yet stateable)'. It is not anchor 5 because there is no 'Use when...' phrasing and the trigger condition is embedded in a definition rather than stated as a standalone trigger clause.

4 / 5

Trigger Term Quality

Some concept-level trigger phrases are present — 'destination unclear', 'questions not yet stateable' — but they are phrased in the skill's idiosyncratic vocabulary ('foggy effort', 'the frontier', 'wayfinding') rather than natural user phrasing like 'vague idea', 'unclear requirements', 'break down this project', or 'planning'. It is above anchor 2 (more than one or two keywords, and the conditions are relevant) but below anchor 4 because few terms are ones a user would actually say.

3 / 5

Distinctiveness Conflict Risk

The description carves a clear niche — decision-ticket mapping on an issue tracker, one resolution per session, explicit handoff to /launch, 'produces decisions, never deliverables' — with triggers ('foggy effort', 'residual questions', map continuation) that are unlikely to fire for any other skill.

5 / 5

Total

16

/

20

Passed

Validation

81%

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

Validation — 13 / 16 Passed

Validation for skill structure

CriteriaDescriptionResult

frontmatter_unknown_keys

Unknown frontmatter key(s) found; consider removing or moving to metadata

Warning

relative_links

Relative link issues: 2 missing

Warning

referenced_paths_exist

Referenced path issues: 1 missing

Warning

Total

13

/

16

Passed

Repository

Yeachan-Heo/oh-my-claudecode

Path

skills/ask-navigator/SKILL.md

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.