CtrlK
BlogDocsLog inGet started
Tessl Logo

he-plan

Plan execution work from specs, brainstorm outputs, bugs, or feature requests into an implementation-ready sequence. Use when the user needs the Harness Engineering planning stage before execution.

55

Quality

62%

Does it follow best practices?

Impact

No eval scenarios have been run

SecuritybySnyk

Passed

No known issues

Optimize this skill with Tessl

npx tessl skill review --optimize ./Plugins/harness-engineering/fixtures/budget-archive/2026-04-21/deferred-store/skills/team_automation/he-plan/SKILL.md
SKILL.md
Quality
Evals
Security

Quality

Content

57%

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

This is a reasonably well-structured planning skill that effectively uses progressive disclosure to keep the overview lean while pointing to detailed references. Its main weaknesses are redundancy across sections (the same constraints repeated 2-3 times) and a lack of concrete examples showing what the actual deliverables look like — a sample plan snippet, traceability matrix, or frontmatter block would significantly improve actionability. The workflow is present but could benefit from tighter integration between procedure steps and validation checkpoints.

Suggestions

Add a concrete example of a plan artifact showing phase IDs, acceptance IDs, traceability matrix format, and Linear Work Item Contract frontmatter — even a minimal skeleton would greatly improve actionability.

Remove redundant statements: 'Keep GitHub PRs as delivery evidence' appears in Core Contract, Constraints, and Gotchas; 'Do not implement code' appears in Constraints and Gotchas. State each constraint once.

Integrate the validation linting command into the Procedure section as an explicit step (e.g., step 5) rather than having it only in a separate Validation section, to make the workflow sequence complete and unambiguous.

DimensionReasoningScore

Conciseness

The content is mostly efficient but has some redundancy — 'Keep GitHub PRs as delivery evidence, not the tracker of record' appears three times (Core Contract, Constraints, Gotchas). The 'Do not implement code' constraint is also repeated. Some sections like Philosophy and When to use add minimal value. However, it generally avoids explaining concepts Claude already knows.

2 / 3

Actionability

The skill provides concrete guidance on what to produce (phase IDs, acceptance IDs, traceability matrices) and includes one specific executable command (the linting script), but most instructions remain at the procedural/conceptual level without concrete examples of what a plan artifact actually looks like — no example plan output, no example traceability matrix format, no example frontmatter block.

2 / 3

Workflow Clarity

The Procedure section provides a clear 4-step sequence and the Validation section includes explicit gates with a 'stop at first failed gate' checkpoint. However, the procedure steps are quite high-level and lack the granularity needed for reliable execution. The validation linting script is a good concrete checkpoint, but the relationship between the procedure and validation sections could be tighter (e.g., when exactly to run the lint script within the procedure).

2 / 3

Progressive Disclosure

The skill is well-structured as an overview with clear, well-signaled one-level-deep references to the full guide, plan artifact contract, verification-first planning, production controls, and routing references. The main SKILL.md stays concise while pointing to detailed materials for deeper context.

3 / 3

Total

9

/

12

Passed

Description

67%

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 provides a reasonable overview of the skill's purpose and includes an explicit 'Use when' clause, which is good for completeness. However, the specific actions are somewhat abstract ('plan execution work') and the trigger terms rely on a proprietary framework name rather than natural user language. The description would benefit from more concrete action verbs and broader natural-language trigger terms.

Suggestions

Add more concrete action descriptions, e.g., 'breaks down specs into ordered tasks, identifies dependencies, estimates complexity, and produces a step-by-step implementation plan'.

Include more natural trigger terms users would say, such as 'task breakdown', 'implementation plan', 'sprint planning', 'work breakdown', 'prioritize tasks', or 'plan development work'.

DimensionReasoningScore

Specificity

It names the domain (planning/execution) and some actions ('plan execution work', 'brainstorm outputs'), but the actions are not very concrete — 'plan execution work from specs' is somewhat vague and doesn't list specific deliverables or steps like 'create task breakdown, estimate effort, identify dependencies'.

2 / 3

Completeness

It answers both 'what' (plan execution work from specs, brainstorm outputs, bugs, or feature requests into an implementation-ready sequence) and 'when' (Use when the user needs the Harness Engineering planning stage before execution) with an explicit 'Use when' clause.

3 / 3

Trigger Term Quality

Includes some relevant terms like 'specs', 'bugs', 'feature requests', 'planning stage', and 'implementation-ready sequence', but relies on the proprietary term 'Harness Engineering' which users may not naturally say. Missing common variations like 'task breakdown', 'roadmap', 'sprint planning', 'work items', or 'backlog'.

2 / 3

Distinctiveness Conflict Risk

The 'Harness Engineering' branding adds some distinctiveness, but 'planning' and 'implementation' are broad terms that could overlap with generic project management or task planning skills. The scope of inputs (specs, bugs, feature requests) is fairly broad and could conflict with bug triage or feature scoping skills.

2 / 3

Total

9

/

12

Passed

Validation

90%

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

Validation10 / 11 Passed

Validation for skill structure

CriteriaDescriptionResult

metadata_version

'metadata.version' is missing

Warning

Total

10

/

11

Passed

Repository
jscraik/Agent-Skills
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.