he-linear-plan
Convert approved HE cognition into small live-ready Linear execution tracking. Use when strategy, reframe, plan, bug, or source-prompt evidence needs scoped issue, milestone, or project routing with explicit confirmation before any live mutation.
50
55%
Does it follow best practices?
Impact
—
No eval scenarios have been run
Passed
No known issues
Optimize this skill with Tessl
npx tessl skill review --optimize ./Plugins/harness-engineering/skills/he-linear-plan/SKILL.mdQuality
Discovery
75%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 has a clear 'when' clause and is distinctive enough to avoid conflicts with other skills, which are strengths. However, it relies heavily on internal jargon ('HE cognition', 'source-prompt evidence', 'live mutation') that reduces clarity and trigger term quality. The specific actions performed (creating issues, setting milestones, etc.) could be stated more concretely and in plainer language.
Suggestions
Replace jargon like 'HE cognition' and 'source-prompt evidence' with plain language that describes what inputs are being converted (e.g., 'approved plans, strategies, or bug reports').
List concrete actions more explicitly, such as 'Creates Linear issues, sets milestones, and routes to projects' instead of the abstract 'execution tracking'.
Add natural trigger terms users would actually say, such as 'Linear ticket', 'create issue in Linear', 'track in Linear', or 'project tracking'.
| Dimension | Reasoning | Score |
|---|---|---|
Specificity | The description mentions some concrete actions like 'scoped issue, milestone, or project routing' and 'explicit confirmation before any live mutation,' but the phrase 'Convert approved HE cognition into small live-ready Linear execution tracking' is jargon-heavy and unclear about what specific actions are performed (e.g., creating issues, setting milestones, linking projects). | 2 / 3 |
Completeness | The description answers both 'what' (convert cognition into Linear execution tracking with issue/milestone/project routing and confirmation) and 'when' (explicitly states 'Use when strategy, reframe, plan, bug, or source-prompt evidence needs scoped issue, milestone, or project routing'). | 3 / 3 |
Trigger Term Quality | It includes some relevant keywords like 'Linear', 'issue', 'milestone', 'project', 'strategy', 'reframe', 'plan', 'bug', but terms like 'HE cognition', 'source-prompt evidence', and 'live mutation' are internal jargon unlikely to match natural user language. Users would more likely say 'create a Linear issue' or 'track this in Linear.' | 2 / 3 |
Distinctiveness Conflict Risk | The description is highly specific to Linear as a project management tool and the particular workflow of converting approved plans into tracked items, making it unlikely to conflict with other skills. The mention of 'explicit confirmation before any live mutation' further narrows its niche. | 3 / 3 |
Total | 10 / 12 Passed |
Implementation
35%Reviews the quality of instructions and guidance provided to agents. Good implementation is clear, handles edge cases, and produces reliable results.
This skill is a dense organizational process document that suffers from significant verbosity and jargon overload. While it demonstrates thorough coverage of edge cases, failure modes, and safety constraints, the content would benefit greatly from concrete output templates, consolidation of overlapping sections, and trimming of repeated concepts. The references section shows good progressive disclosure intent, but the main body retains too much policy-level detail inline.
Suggestions
Add a concrete output template showing an actual `.harness/linear/**-linear-plan.md` artifact with all required fields filled in, rather than listing fields abstractly.
Consolidate overlapping sections (Constraints, Execution Boundaries, Safety Boundaries) into a single 'Boundaries & Constraints' section to reduce redundancy and token usage.
Move detailed field enumerations (schema_version, selected_stage, decision_artifact_status, etc.) to a referenced output contract file rather than listing them inline in the Outputs section.
Replace prose-based examples with actual before/after artifact snippets showing input cognition and the resulting Linear plan markdown file.
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | The skill is extremely verbose with heavy jargon and domain-specific terminology that reads as insider shorthand rather than efficient instruction. Many sections repeat the same concepts (e.g., 'Linear is execution state; .harness is cognition' appears in Philosophy and Gotchas). Extensive enumeration of fields, statuses, and conditions bloats the content well beyond what's needed for actionable guidance. Much of this reads like organizational policy documentation rather than a lean skill. | 1 / 3 |
Actionability | The procedure provides a numbered 12-step workflow with some concrete guidance (specific file paths, script commands, field names), but lacks executable code examples or copy-paste-ready templates. The examples section describes scenarios in prose rather than showing actual artifact content or payload structures. The output format is described abstractly (listing required fields) rather than with a concrete template. | 2 / 3 |
Workflow Clarity | The 12-step procedure provides a clear sequence with some validation checkpoints (step 12 mentions fail-fast, step 4 mentions verification), but the steps are dense and abstract. Validation is mentioned but the feedback loop is vague—step 12 says 'stop at the first failed gate' but the connection between steps and specific validation points is unclear. The failure mode section adds recovery paths but they're separated from the workflow itself. | 2 / 3 |
Progressive Disclosure | The References section provides extensive one-level-deep links to supporting files, which is good structure. However, the main body is monolithic and overloaded—many sections (Constraints, Execution Boundaries, Safety Boundaries) overlap significantly and could be consolidated or moved to references. Without bundle files to verify, the numerous reference paths cannot be validated, and the sheer volume of inline content undermines the disclosure pattern. | 2 / 3 |
Total | 7 / 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.
Validation — 10 / 11 Passed
Validation for skill structure
| Criteria | Description | Result |
|---|---|---|
metadata_version | 'metadata.version' is missing | Warning |
Total | 10 / 11 Passed | |
- Repository
- jscraik/Agent-Skills
- Commit
d00c351
- 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.