AI-native GitHub issue planning from the command line.

git-tasks wraps the GitHub CLI (gh) so humans and coding agents can manage epics, sprints, and user stories without leaving the terminal.

• Node.js >= 24
• GitHub CLI authenticated via gh auth login

npm install -g @atena-reply/git-tasks
npx @atena-reply/git-tasks --help

The npm package is published as @atena-reply/git-tasks, while the installed command remains git-tasks. The GitHub repository URL remains Atena-IT/git-tasks.

npx @atena-reply/git-tasks skill install --target all

Available targets: claude, copilot, codex, gemini, cline, all.

The repository ships a .claude-plugin/marketplace.json that registers git-tasks in the Claude Code plugin marketplace. Claude Code will pick up the skill automatically from skills/git-tasks/SKILL.md when the plugin is installed.

npx @favelasquez/agentskills
# choose: Install from custom repository
# repository URL: https://github.com/Atena-IT/git-tasks/tree/main/skills
# select: git-tasks
# choose your target agent(s)

# Claude Code
mkdir -p .claude/commands
curl -fsSL https://raw.githubusercontent.com/Atena-IT/git-tasks/main/skills/git-tasks/SKILL.md \
  -o .claude/commands/git-tasks.md

# GitHub Copilot
mkdir -p .github/skills/git-tasks
curl -fsSL https://raw.githubusercontent.com/Atena-IT/git-tasks/main/skills/git-tasks/SKILL.md \
  -o .github/skills/git-tasks/SKILL.md

# Codex / Gemini CLI / Cline
mkdir -p .codex/skills .gemini/skills .clinerules
curl -fsSL https://raw.githubusercontent.com/Atena-IT/git-tasks/main/skills/git-tasks/SKILL.md \
  -o .codex/skills/git-tasks.md
cp .codex/skills/git-tasks.md .gemini/skills/git-tasks.md
cp .codex/skills/git-tasks.md .clinerules/git-tasks.md

The canonical skill source in this repository is skills/git-tasks/SKILL.md.

Labels created automatically: epic, sprint, user-story

git-tasks epic create "Title" -d <desc> -p <points> --start <date> --end <date> [-k <.git-tasks/wiki/knowledge/file.md>] [-a <user>]
git-tasks epic list [--state open|closed|all] [--short]
git-tasks epic show <number> [--comments]
git-tasks epic update <number> [--title <text>] [--points <n>] [--status open|closed]

git-tasks sprint create "Title" -e <epic> -d <desc> -p <points> --start <date> --end <date> [-k <.git-tasks/wiki/knowledge/file.md>] [-a <user>]
git-tasks sprint list [--epic <n>] [--state open|closed|all] [--short]
git-tasks sprint show <number> [--comments]
git-tasks sprint update <number> [--title <text>] [--status open|closed]

git-tasks story create "Title" -s <sprint> -e <epic> -d <desc> -p <points> --priority low|medium|high [-k <.git-tasks/wiki/knowledge/file.md>] [-a <user>]
git-tasks story list [--sprint <n>] [--epic <n>] [--assignee <user>] [--state open|closed|all] [--short]
git-tasks story show <number> [--comments]
git-tasks story update <number> [--status open|in-progress|ready-for-review|closed] [--reviewer <user>]

git-tasks overview [--depth 1|2|3] [--state open|closed|all]
# depth 1=epics only, 2=+sprints, 3=+stories (default: 1)

git-tasks init
git-tasks wiki list
git-tasks wiki show inbox/<file>
git-tasks wiki show knowledge/index

git-tasks init creates a dedicated .git-tasks/ workspace in the repository, including .git-tasks/config.json and .git-tasks/wiki/.

git-tasks init --owner octocat --reviewer octocat
git-tasks overview --depth 2
git-tasks epic list --short
git-tasks story list --short --sprint 5
git-tasks story update 42 --status in-progress --knowledge .git-tasks/wiki/knowledge/auth-plan.md
git-tasks story update 42 --status ready-for-review --reviewer octocat

• Stories are agent-sized atomic slices: independently executable work that should usually take from a few hours up to one day.
• Sprints are short execution windows and should usually stay within three days.
• Epics are the largest planning bucket and should usually stay within two weeks.
• .git-tasks/config.json can override these defaults with repo-specific planningHorizons for agents to read.
• Always keep dependencies explicit: stories belong to a sprint and epic, sprints belong to an epic, and each item should carry enough metadata to be auditable without extra chat context.

• Initialize the repository once with git-tasks init.
• Put inbound human or system inputs in .git-tasks/wiki/inbox/ exactly as they arrive: meeting notes, pasted chats, TODO dumps, transcripts, uploads, or scratch notes.
• Read .git-tasks/wiki/knowledge/index.md before opening individual knowledge files so you reuse existing context instead of creating duplicate nodes.
• Keep .git-tasks/wiki/knowledge/ flat. The semantic kind belongs in frontmatter type, not in subdirectories.
• Use dash-case frontmatter keys for knowledge nodes. A practical minimum is id, type, title, timestamp, status, tags, sources, issue-refs, neighbours, and supersedes.
• Knowledge node bodies should capture the context/source, interpretation, planning changes, rationale, and consequences.
• Update or create knowledge nodes only when durable understanding changes. Then update epics, sprints, and stories from that compiled knowledge when the plan actually changed.
• When backlog items are tied to specific knowledge docs, store repo-relative .git-tasks/wiki/knowledge/... paths in issue Knowledge Links metadata.
• Legacy wiki/raw/ and wiki/processed/ content may still be read for historical context, but new writes should target .git-tasks/wiki/inbox/ and .git-tasks/wiki/knowledge/.

Run git-tasks init --owner <user> --reviewer <user> to create the .git-tasks/ workspace at the repository root, including .git-tasks/config.json and .git-tasks/wiki/. Commit this config so human teammates and AI agents share the same defaults.

{
  "owner": "octocat",
  "defaultReviewers": ["octocat"],
  "planningHorizons": {
    "storyMaxDays": 1,
    "sprintMaxDays": 3,
    "epicMaxWeeks": 2
  }
}

• defaultReviewers is the repo-level fallback when --reviewer is not passed and GIT_TASKS_REVIEWERS is not set.
• owner is the last reviewer fallback when defaultReviewers is empty.
• planningHorizons is for AI guidance, not CLI enforcement. It lets each repo tighten or relax the default story/sprint/epic sizing without editing the shipped skill text.

• New material in .git-tasks/wiki/inbox/ by itself does not create or update issues, branches, or pull requests.
• New or updated knowledge in .git-tasks/wiki/knowledge/ may lead to epic, sprint, or story create/update operations when the planning delta is real.
• story update --status in-progress keeps the story open, updates its workflow status, and ensures a draft PR exists for the current branch.
• Agents should pick up stories in an isolated worktree with a named branch and attached draft PR so execution stays reviewable and self-contained.
• Routine execution should not create new knowledge nodes unless durable understanding or planning changed.
• story update --status ready-for-review promotes the linked draft PR to ready for review and requires reviewers via --reviewer, GIT_TASKS_REVIEWERS=user1,user2, or the repo-level defaults in .git-tasks/config.json.
• When a story is tied to knowledge docs, surface those docs via issue Knowledge Links metadata and in the story PR body for reviewer context.
• story update --status closed closes the story and automatically closes the parent sprint and epic when all of their children are closed.
• sprint update --status closed also cascades closure up to the parent epic when appropriate.
• Branches and draft PRs are execution artifacts for stories, not wiki entities.

Implement the interface in src/backends/ and register it in src/backends/index.js:

export default {
  createIssue({ title, body, labels, assignees }),
  listIssues({ labels, state, limit }),
  viewIssue(number, { comments }),
  editIssue(number, { title, body, addLabels, removeLabels, addAssignees, state }),
}

ISC