This skill should be used when the user says "pick issue", "work on issue", "arness code pick", "arness code pick issue", "arn-code-pick-issue", "grab issue", "pick from backlog", "what should I work on", "show issues", "find issue", "browse issues", "next issue", "select issue", "choose issue", "what's unblocked", "work on next feature", "pick from feature tracker", or wants to browse issues filtered by Arness labels, select one, and route it to the appropriate Arness pipeline skill for implementation. Supports local-first dependency resolution from a greenfield feature backlog when available. Requires an issue tracker (GitHub or Jira) to be configured for remote issue browsing. Do NOT use this for creating new issues — use /arn-code-create-issue for that.
64
76%
Does it follow best practices?
Impact
—
No eval scenarios have been run
Advisory
Suggest reviewing before use
Optimize this skill with Tessl
npx tessl skill review --optimize ./plugins/arn-code/skills/arn-code-pick-issue/SKILL.mdQuality
Discovery
89%Based on the skill's description, can an agent find and select it at the right time? Clear, specific descriptions lead to better discovery.
This description excels at trigger term coverage and completeness, with an exhaustive list of natural phrases and a clear negative boundary distinguishing it from the issue creation skill. The main weakness is that the core capability description could be more specific about what concrete actions are performed beyond browse/select/route. The description is functional and effective for skill selection despite being somewhat verbose.
Suggestions
Add more specific concrete actions beyond 'browse, select, and route' — e.g., describe what filtering options are available, what information is displayed about each issue, or how dependency resolution works in practice.
| Dimension | Reasoning | Score |
|---|---|---|
Specificity | The description mentions browsing issues, selecting one, routing to a pipeline skill, and local-first dependency resolution, but the core actions (browse, select, route) are somewhat generic. It does mention filtering by Arness labels and greenfield feature backlog support, which adds some specificity, but it doesn't list multiple concrete actions as clearly as a score-3 example. | 2 / 3 |
Completeness | The description clearly answers both 'what' (browse issues filtered by Arness labels, select one, route to appropriate pipeline skill, local-first dependency resolution) and 'when' (explicit trigger phrases plus a negative boundary 'Do NOT use this for creating new issues'). The extensive trigger list and explicit exclusion clause make the 'when' guidance very strong. | 3 / 3 |
Trigger Term Quality | The description includes an extensive list of natural trigger phrases users would say: 'pick issue', 'work on issue', 'grab issue', 'what should I work on', 'show issues', 'find issue', 'browse issues', 'next issue', 'select issue', 'choose issue', 'what's unblocked', 'work on next feature', 'pick from backlog', etc. This provides excellent coverage of natural language variations. | 3 / 3 |
Distinctiveness Conflict Risk | The description is highly distinctive with its Arness-specific terminology, explicit trigger phrases, and clear negative boundary ('Do NOT use this for creating new issues — use /arn-code-create-issue'). The niche is clearly defined as issue picking/selection from a backlog, distinct from issue creation or other workflows. | 3 / 3 |
Total | 11 / 12 Passed |
Implementation
62%Reviews the quality of instructions and guidance provided to agents. Good implementation is clear, handles edge cases, and produces reliable results.
This skill is highly actionable with excellent workflow clarity and concrete executable commands for both GitHub and Jira platforms. However, it is significantly over-verbose — the inline content covers every edge case, platform variation, and error scenario in exhaustive detail that would be better served by reference files. The progressive disclosure suffers from trying to keep too much content in a single file rather than splitting platform-specific logic and error handling into separate references.
Suggestions
Move platform-specific logic (GitHub vs Jira sections in Steps 2-4, 6) into separate reference files like `github-workflow.md` and `jira-workflow.md` to reduce the main skill's token footprint by ~40%.
Extract the 15+ error handling cases into a dedicated `error-handling.md` reference file, keeping only a brief 'See error-handling.md for edge cases' note inline.
Condense Step 7 hand-off details — the sub-feature context passing instructions are extremely granular and could be summarized with a reference to a hand-off-context.md file.
Remove explanatory phrases like 'This step is entirely optional — it activates only when...' and 'The greenfield feature backlog provides a local-only alternative to remote issue browsing' — Claude can infer these from the conditional logic.
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | The skill is extremely verbose at ~300+ lines with extensive branching for multiple platforms (GitHub, Jira, Bitbucket), exhaustive error handling enumeration, and detailed sub-feature/greenfield paths. Much of this could be condensed or moved to reference files. The error handling section alone lists 15+ cases inline that Claude could handle with general guidance. | 1 / 3 |
Actionability | The skill provides concrete, executable commands (gh issue list, gh issue view, gh label create), specific CLI flags and JSON field lists, exact JQL query templates, and clear display format examples. Every step has copy-paste ready commands for both GitHub and Jira paths. | 3 / 3 |
Workflow Clarity | The workflow is clearly sequenced across 7 numbered steps with explicit validation checkpoints (prerequisite checks in Step 1, label existence verification in Step 2, drift detection gate in Step 6.5). Error recovery paths are well-defined with feedback loops (e.g., drift severity branching, filter adjustment suggestions). | 3 / 3 |
Progressive Disclosure | The skill references one external file (greenfield-backlog-resolution.md) appropriately, but the vast majority of content is inline — the error handling section, platform-specific branching for GitHub vs Jira, and the detailed Step 6.5/Step 7 hand-off logic could all be split into reference files. The monolithic structure makes it harder to navigate despite good section headers. | 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.
Validation — 10 / 11 Passed
Validation for skill structure
| Criteria | Description | Result |
|---|---|---|
frontmatter_unknown_keys | Unknown frontmatter key(s) found; consider removing or moving to metadata | Warning |
Total | 10 / 11 Passed | |
b9084b6
Table of Contents
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.