Tessl • The management layer for AI agent skills

SkillPublic

dev-instance

Run the current worktree as a production-shaped local dev instance with web, Slack, or both, on a real LLM + Postgres. Each developer uses their own set of Slack apps from their own machine's pool store, so many worktrees (yours and a teammate's) can run reachable at once without colliding. Use when asked to /dev-instance, "spin this up so I can QA it in Slack", or "let me test your branch end to end".

Quality

82%

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

Quality

Content

71%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.

Highly actionable content with strong validation and error-recovery loops, but it is a long monolithic file with some redundancy and no progressive disclosure — troubleshooting and Slack-pool deep dives belong in separate reference files. Deduplicating the repeated reclaim/exclusivity rules would trim meaningful tokens.

Suggestions

Split the Troubleshooting deep dives (silent-bot diagnosis, Slack app rebuild walkthrough, canary-failed slot recovery) and the pool-store minting/lease internals into one-level-deep reference files (e.g. references/troubleshooting.md, references/slack-pool.md), keeping SKILL.md to the command surface, lifecycle, and pointers.

Deduplicate content stated twice — the not-today/4-hour slot reclaim rule appears in both 'Slack reach' and the 'stale pool recovery' bullet of 'Real by Default', and single-owner Socket Mode exclusivity is explained both in 'Slack reach' and in the 'up' verification paragraph — and trim narrative asides like 'This is the part people get wrong'.

Add a concrete verification command for the after-merge teardown step (e.g. 'bash scripts/dev-instance.sh status --json' and what an exited/released state looks like), and consider a short ordered lifecycle checklist (up → verify → QA → down → verify) so the multi-step workflow is sequenced in one place.

Dimension	Reasoning	Score
Conciseness	The body is dense with genuinely non-obvious project facts, but at ~230 lines it repeats key rules (the not-today/4-hour slot reclaim appears in both 'Slack reach' and 'Real by Default'; socket exclusivity is explained twice) and includes conversational padding like 'This is the part people get wrong, so it's worth stating plainly', so it could be tightened.	3 / 5
Actionability	Fully executable throughout: copy-paste commands ('bash scripts/dev-instance.sh up --surface web', 'DEV_INSTANCE_ALLOW_MEMORY=1 bash scripts/dev-instance.sh up'), concrete recovery procedures, and precise details like token formats ('xoxb-', 'xapp-') and the 'conversations.open' + 'app.slack.com/client/<team-id>/<D-channel-id>' DM-opening recipe.	5 / 5
Workflow Clarity	The lifecycle is clearly sequenced with most validation checkpoints present — 'up' only prints success after proving the bot reachable, 'doctor' gives a ranked diagnosis, and teardown says to verify the supervisor and lease are released — but the after-merge verification lacks a concrete command and there is no consolidated ordered checklist, leaving minor gaps versus the anchor-5 example.	4 / 5
Progressive Disclosure	Section structure is good, but there are no bundle reference files at all: deep-dive material such as the ~35-line Slack app rebuild walkthrough, pool-store minting procedure, and slot-reclaim internals is inlined in a single 230-line file rather than split into one-level-deep references.	3 / 5
	Total	15 / 20 Passed

Description

87%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.

A strong description: concrete, third-person, and explicit about both what the skill does and when to use it, with natural quoted trigger phrases. Minor room to broaden trigger synonyms and enumerate more distinct capabilities.

Dimension	Reasoning	Score
Specificity	The description names several concrete capabilities — 'production-shaped local dev instance with web, Slack, or both, on a real LLM + Postgres' and per-developer Slack app pools — but frames them around a single macro-action rather than the comprehensive multi-action list of the anchor-5 example.	4 / 5
Completeness	It clearly answers both 'what' ('Run the current worktree as a production-shaped local dev instance...') and 'when' with explicit, concrete trigger phrases, matching the anchor-5 example structure exactly.	5 / 5
Trigger Term Quality	'Use when asked to /dev-instance, "spin this up so I can QA it in Slack", or "let me test your branch end to end"' provides natural quoted phrases users would actually say, though common variants like 'run it locally' or 'dev environment' are missing.	4 / 5
Distinctiveness Conflict Risk	It occupies a clear niche — end-to-end local QA of a branch with per-developer Slack app isolation — with distinct triggers ('/dev-instance', 'QA it in Slack', 'test your branch end to end') unlikely to fire for a different skill.	5 / 5
	Total	18 / 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
referenced_paths_exist	Referenced path issues: 14 missing	Warning

	Total	15 / 16 Passed

Repository: yc-software/qm
Path: .codex/skills/dev-instance/SKILL.md
Revision: 88c380f

Reviewed: 6 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.

dev-instance

Table of Contents

Is this your skill?