CtrlK
BlogDocsLog inGet started
Tessl Logo

plan-execute

Execute an implementation plan with rigorous checklist-driven verification. Every task is pre-flighted, worked, validated with proof, and checked off. Every phase is validated as a whole. If proof is missing, the agent goes back. Honesty is non-negotiable — broken trust means the plan is not done. Triggers: 'implement this plan', 'execute the plan', 'start working on the plan', 'do the plan', 'carry out the phases', 'run the plan', 'work through the plan', 'carry out this plan', 'begin implementation'. Do NOT use for plans that have not been reviewed — use plan-review first.

72

Quality

88%

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

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 exceptionally clear, rigorously validated workflow with concrete commands, templates, and feedback loops at every stage — near-ideal on actionability and workflow clarity. Its main cost is length: repeated honesty exhortations and inline templates that duplicate the existing reference file push it past an efficient token budget.

Suggestions

State the honesty rule once (e.g., in Core Principle) and reference it elsewhere instead of restating it in the Checklist System, section 2e, the Anti-Patterns, and a separate Honesty Checklist section — this would cut roughly 40-60 lines with no loss of guidance.

Move the full checklist entry templates (baseline block, quick/task validation blocks, and the 2e entry format) into references/checklist-templates.md, keeping only one compact example inline, since the reference file already exists for exactly this purpose.

Trim the repeated per-failure 'Stop. Fix. Re-run. Record' instructions to a single general failure rule stated once, and keep only step-specific failure handling where it adds unique guidance (e.g., diagnosing which task caused a phase-level interaction bug).

DimensionReasoningScore

Conciseness

The body contains no explanations of concepts Claude already knows and is entirely operational, but it is noticeably repetitive: the honesty rule is stated five or more times (Core Principle, the checklist RULE, the 2e RULE, the Honesty Checklist, the Anti-Patterns) and the inline checklist templates (baseline, quick/task validation, 2e entry format) duplicate content already in references/checklist-templates.md. This fits anchor 3 ('could be tightened') better than 4, where over-explanation would be only minor.

3 / 5

Actionability

Guidance is fully executable for a process skill: exact file paths (.context/plans/<slug>/CHECKLIST.md), a gate-discovery block, a copy-paste git commit message template with evidence lines, a concrete audit command (grep -n "\[ \|IN_PROGRESS\|BLOCKED" CHECKLIST.md), and a YAML frontmatter snippet. Placeholders like <typecheck> are justified because gate commands are project-specific, matching the anchor-5 example of copy-paste-ready commands covering common cases.

5 / 5

Workflow Clarity

An eight-step workflow (pre-flight through plan-file update) with explicit validation at every level — baseline before touching code, quick gate after 1-3 file ops, task gate, phase gate, domain invariant, regression diff, final completeness audit — plus feedback loops ('If it fails: Stop. Fix... Re-run') and divergence handling. This is the anchor-5 exemplar: explicit validation steps, error-recovery loops, and a checklist for a complex process; anchor 4 would require missing checkpoints, and none are missing.

5 / 5

Progressive Disclosure

The bundle is verified: references/checklist-templates.md exists, is clearly signaled twice in the body with a description of its contents, and is one level deep with no nested references. It is not a 5 because the split is not clean — large template blocks remain inline in SKILL.md and duplicate what the reference file already provides; it is above a 3 because structure is good and the reference is well signaled rather than buried.

4 / 5

Total

17

/

20

Passed

Description

95%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 is a strong example: third-person voice, concrete capability statements, an explicit trigger list, and a negative boundary clause that disambiguates it from the upstream plan-review skill. The only weakness is a slight amount of abstract emphasis ('Honesty is non-negotiable — broken trust means the plan is not done') that adds no actionable information.

DimensionReasoningScore

Specificity

Lists several concrete actions — 'pre-flighted, worked, validated with proof, and checked off', 'Every phase is validated as a whole', 'If proof is missing, the agent goes back' — but coverage has minor gaps (no mention of commits or checklist creation) and the 'Honesty is non-negotiable — broken trust' line is abstract padding, so it falls just short of the comprehensive anchor 5.

4 / 5

Completeness

Explicitly answers what ('Execute an implementation plan with rigorous checklist-driven verification' plus per-task and per-phase validation) and when ('Triggers: ...' list plus 'Do NOT use for plans that have not been reviewed'), which is the anchor-5 pattern of concrete trigger phrases for both. A 4 would require the 'when' to be less explicit, which it is not.

5 / 5

Trigger Term Quality

Nine natural quoted trigger phrases ('implement this plan', 'execute the plan', 'do the plan', 'carry out the phases', 'run the plan', 'work through the plan', 'begin implementation') give comprehensive coverage of how users would phrase the request, matching the synonym-coverage anchor. It is not a 4 because common variations are already present, not 'a few missing'.

5 / 5

Distinctiveness Conflict Risk

Clear niche — executing already-reviewed implementation plans — with explicit boundary guidance ('use plan-review first'), giving minimal conflict risk. Only 'begin implementation' is mildly generic, which is not enough overlap to drop to anchor 4.

5 / 5

Total

19

/

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.

Validation16 / 16 Passed

Validation for skill structure

No warnings or errors.

Repository
pantheon-org/tekhne
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.