Loading skill
Install any skill in seconds. Free to start, no credit card required.
Get Started Free →codelytv/codely-plan-create-github
Create a plan for the specified task and store it as GitHub issues in the repository of the current working directory. Given the URL of a GitHub issue, it turns that issue into the parent "plan" issue (Goal, Context and a checklist of phases) and creates one child issue per phase, linking every phase as a native GitHub sub-issue of the parent. Stops for user approval before creating any issue. After creation, the plan is meant to be implemented with the codely-plan_phase-implement-github skill.
Passed 12 of 17 test cases with the skill, and 6 of 17 without it.
and 9 more in the full report
9 fixed7 passed either way5 still failing1 broke
Tokens, turns and time describe resource use, not a dollar price.
This benchmark measured an earlier version of the skill.
A newer attempt on gemini-3.8-flash on 10/21/2026 did not produce a publishable comparison (not comparable). The snapshot above is the previously measured run.
One of 8 test cases the skill fixed. Same model, same prompt, with and without the skill.
What exact gh CLI command with JSON flags is used by `/codely-plan-create-github https://github.com/org/repo/issues/90` to fetch the current repository owner and name?
| Checked | Without skill | With skill |
|---|---|---|
| The response specifies gh repo view --json nameWithOwner --jq .nameWithOwner. | Missed | Passed |
The instructions your model reads when the skill loads.
[!CRITICAL] Do NOT create or edit any GitHub issue until the user has agreed on the specific public contracts to be considered and the implementation phases. Propose first, get approval, then create the issues.
The structure of a plan, its sections and the rules to shape them are defined in resources/plan-guidelines.md. Read it before proposing anything.
This skill is invoked as /codely-plan-create-github <github-issue-url>.
<github-issue-url> is the URL of the GitHub issue describing the task to plan. This issue becomes the parent "plan" issue.All the plan lives as GitHub issues in the repository of the current working directory. Never hardcode a repository: let gh resolve it from the local Git remote.
gh issue view <number>
gh issue create --title "..." --body "..."
gh issue edit <number> --body "..."
Derive <number> from the provided URL. Confirm the repository gh resolves with gh repo view --json nameWithOwner --jq .nameWithOwner, and check that the provided URL belongs to it. If it does not, stop and ask the user to run the skill from the clone of that repository.
To link a phase as a native GitHub sub-issue of the parent, use the sub-issues REST API. It expects the child's numeric database id (not its issue number), so resolve it first. The {owner} and {repo} placeholders are substituted by gh with the current repository:
# Resolve the child issue database id from its number
child_id=$(gh api repos/{owner}/{repo}/issues/<child> --jq .id)
# Attach the child as a native sub-issue of the parent
gh api --method POST repos/{owner}/{repo}/issues/<parent>/sub_issues -F sub_issue_id="$child_id"
A plan is stored as a tree of issues, using GitHub's native sub-issues feature:
test cases passed, vs 6 / 17 without
Published skills whose descriptions closely match this one, with their headline benchmark lift.
More skills from the same source and nearby in the registry, with their headline benchmark lift.