speckit-taskstoissues

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/powershell/check-prerequisites.ps1 -Json -RequireTasks -IncludeTasks 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. IF EXISTS: Load .specify/memory/constitution.md for project principles and governance constraints.
3. From the executed script, extract the path to tasks.
4. Fan the tasks out onto this repository's Forgejo tracker using scripts/backlog.mjs, which derives
   the API base and the owner/repo from git remote get-url origin — the same derivation the backlog
   tooling uses everywhere. There is no GitHub gate and no MCP server involved; both were dead ends on
   this repository (see .claude/skills/forgejo-issues/SKILL.md).

# once per feature — the milestone must exist before it can be referenced
node scripts/backlog.mjs setup-milestone <NNN-slug>

# one item per task; body from a file, never a flag
node scripts/backlog.mjs create --title "T012 — <task title>" --body-file /tmp/t012.md \
  --label type/chore --label priority/p2 --milestone <NNN-slug>

# encode the task ordering as blocking edges, so `ready` answers correctly
node scripts/backlog.mjs dep <item-of-T013> --blocked-by <item-of-T012>

[!CAUTION]
UNDER NO CIRCUMSTANCES EVER CREATE ISSUES IN REPOSITORIES THAT DO NOT MATCH THE REMOTE URL.
This is enforced, not merely asked for: every write in backlog.mjs asserts its target against the
origin remote and refuses a mismatch before issuing the call — checked once against any --repo value
and again at the request boundary. The write credential can reach other repositories by design, so that
guard is the only client-side bound. Do not work around it.

This fan-out is optional. tasks.md remains the authoritative in-feature decomposition; the items are
a mirror of it for coordination, never a replacement. The primary flow runs the other way — backlog items
are inputs to /speckit-specify. Prefer it only for a feature large enough that the ordering is worth
tracking in the open, and be aware that a 70-task feature becomes 70 items in a shared tracker.

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