agentleFS
merllinsbeardmerllinsbeard/merlin-skills/skills/speckit-taskstoissues/SKILL.md

speckit-taskstoissues

Skill1 starsChanged 6 months agoMITView on GitHub

Convert existing tasks into actionable, dependency-ordered GitHub issues for the feature based on available design artifacts.

125 other projects use a version of this, 124 of them edited.

Adopted by

Most recently taken up by

Used with

Projects with it also use speckit-agent-context-update, speckit-git-commit and 10 more.

Other files people use alongside this one.

Files found in the same public projects as a version of this one, more often than they turn up anywhere else. Each project counts once, large collections count for less, and this file's own repository is left out.
  • Microsoft AzureSkill

    speckit-agent-context-update

    Refresh the managed Spec Kit section in coding agent context file(s)

    Also in 13 projects that use this

  • Sorcha-PlatformSkill

    speckit-git-commit

    Auto-commit changes after a Spec Kit command completes

    Also in 35 projects that use this

  • Sorcha-PlatformSkill

    speckit-git-feature

    Create a feature branch with sequential or timestamp numbering

    Also in 35 projects that use this

  • patterson-agentsSkill

    speckit-baseline

    Generate feature specifications by analyzing existing source code.

    Also in 3 projects that use this

  • patterson-agentsSkill

    claude-command-converter

    Convert Claude Code commands (.claude/commands/*.md) to standard Agent Skills (skills/*/SKILL.md). Use when migrating slash commands to portable skill format, creating skills from existing commands, or standardizing command definitions across AI runtimes.

    Also in 3 projects that use this

  • Microsoft AzureSkill

    agentic-workflows

    Route gh-aw workflow design/create/debug/upgrade requests to the right prompts.

    Also in 3 projects that use this

  • +3 more from Sorcha-Platform

The file

We split this skill into the rules it gives an agent

8 rules. 1 is common, 0 are distinctive, and 7 are very specific to this project.

  • 1

    Common

    Most of the 123 edited versions we read keep these.

  • 0

    Distinctive

    This author's own choices. Worth a look.

  • 7

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Very specific:

    Check if .specify/extensions.yml exists in the project root.

    line 22
  2. Very specific:

    If it exists, read it and look for entries under the hooks.before_taskstoissues key

    line 23
  3. Common:

    If the YAML cannot be parsed or is invalid, skip hook checking silently and continue normally

    line 24
  4. Very specific:

    If the hook has no condition field, or it is null/empty, treat the hook as executable

    line 27
  5. Very specific:

    If the hook defines a non-empty condition, skip the hook and leave condition evaluation to the HookExecutor implementation

    line 28
  6. Very specific:

    When constructing slash commands from hook command names, replace dots (.) with hyphens (-).

    line 29
  7. Very specific:

    If no hooks are registered or .specify/extensions.yml does not exist, skip silently

    line 52
  8. Very specific:

    Run .specify/scripts/bash/check-prerequisites.sh --json --require-tasks --include-tasks from repo root and parse FEATURE_DIR and …

    line 56

“Common” is measured: kept by at least 6 in 10 of the 123 edited versions of this file we could read. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

User Input

$ARGUMENTS

You MUST consider the user input before proceeding (if not empty).

Pre-Execution Checks

Check for extension hooks (before tasks-to-issues conversion):

  • Check if .specify/extensions.yml exists in the project root.
  • If it exists, read it and look for entries under the hooks.before_taskstoissues key
  • If the YAML cannot be parsed or is invalid, skip hook checking silently and continue normally
  • Filter out hooks where enabled is explicitly false. Treat hooks without an enabled field as enabled by default.
  • For each remaining hook, do not attempt to interpret or evaluate hook condition expressions:
    • If the hook has no condition field, or it is null/empty, treat the hook as executable
    • If the hook defines a non-empty condition, skip the hook and leave condition evaluation to the HookExecutor implementation
  • When constructing slash commands from hook command names, replace dots (.) with hyphens (-). For example, speckit.git.commit → /speckit-git-commit.
  • For each executable hook, output the following based on its optional flag:
    • Optional hook (optional: true):
      ## Extension Hooks
      
      **Optional Pre-Hook**: {extension}
      Command: `/{command}`
      Description: {description}
      
      Prompt: {prompt}
      To execute: `/{command}`
    • Mandatory hook (optional: false):
      ## Extension Hooks
      
      **Automatic Pre-Hook**: {extension}
      Executing: `/{command}`
      EXECUTE_COMMAND: {command}
      
      Wait for the result of the hook command before proceeding to the Outline.
  • If no hooks are registered or .specify/extensions.yml does not exist, skip silently

Outline

  1. Run .specify/scripts/bash/check-prerequisites.sh --json --require-tasks --include-tasks from repo root and parse FEATURE_DIR and AVAILABLE_DOCS list. All paths must be absolute. For single quotes in args like "I'm Groot", use escape syntax: e.g 'I'''m Groot' (or double-quote if possible: "I'm Groot").
  2. From the executed script, extract the path to tasks.
  3. Get the Git remote by running:
git config --get remote.origin.url

[!CAUTION] ONLY PROCEED TO NEXT STEPS IF THE REMOTE IS A GITHUB URL

  1. For each task in the list, use the GitHub MCP server to create a new issue in the repository that is representative of the Git remote.

[!CAUTION] UNDER NO CIRCUMSTANCES EVER CREATE ISSUES IN REPOSITORIES THAT DO NOT MATCH THE REMOTE URL

Post-Execution Checks

Check for extension hooks (after tasks-to-issues conversion): Check if .specify/extensions.yml exists in the project root.

  • If it exists, read it and look for entries under the hooks.after_taskstoissues key
  • If the YAML cannot be parsed or is invalid, skip hook checking silently and continue normally
  • Filter out hooks where enabled is explicitly false. Treat hooks without an enabled field as enabled by default.
  • For each remaining hook, do not attempt to interpret or evaluate hook condition expressions:
    • If the hook has no condition field, or it is null/empty, treat the hook as executable
    • If the hook defines a non-empty condition, skip the hook and leave condition evaluation to the HookExecutor implementation
  • When constructing slash commands from hook command names, replace dots (.) with hyphens (-). For example, speckit.git.commit → /speckit-git-commit.
  • For each executable hook, output the following based on its optional flag:
    • Optional hook (optional: true):
      ## Extension Hooks
      
      **Optional Hook**: {extension}
      Command: `/{command}`
      Description: {description}
      
      Prompt: {prompt}
      To execute: `/{command}`
    • Mandatory hook (optional: false):
      ## Extension Hooks
      
      **Automatic Hook**: {extension}
      Executing: `/{command}`
      EXECUTE_COMMAND: {command}
  • If no hooks are registered or .specify/extensions.yml does not exist, skip silently

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.