Getting it into your agent
One page per mod, every tool's command on it. A separate URL per tool would split the same page into five that compete with each other.
npx agentmods add skills/darellchua2/opencode-config-template/ticket-plan-workflow-skillnpx skills add darellchua2/opencode-config-template --skill ticket-plan-workflow-skillgit clone --depth 1 https://github.com/darellchua2/opencode-config-templateWrote this? Show the measurements
A badge with what this costs and how it scanned, read live from this page, so it follows the numbers instead of freezing them. Markdown for a README, HTML for a documentation site or a project page.
[](https://agentmods.dev/skills/darellchua2/opencode-config-template/ticket-plan-workflow-skill)<a href="https://agentmods.dev/skills/darellchua2/opencode-config-template/ticket-plan-workflow-skill"><img src="https://agentmods.dev/badge/skills/darellchua2/opencode-config-template/ticket-plan-workflow-skill.svg" alt="Measured on agentmods" height="20"></a>What it costs to keep this loaded
Counted locally with the o200k_base tokenizer, which is exact for GPT models; Claude uses its own tokenizer and its counts differ. Treat this as one consistent yardstick across the catalogue rather than a bill. Prices are per million input tokens.
| Model | Per session | Once invoked |
|---|---|---|
| Fable 5.1 | $0.00052 | $0.06934 |
| Opus 5 | $0.00026 | $0.03467 |
| Sonnet 5 | $0.00010 | $0.01387 |
| Haiku 4.5 | $0.00005 | $0.00693 |
Grade A, and why
ticket-plan-workflow-skill scanned grade A with 1 finding against 26 rules in 11 categories — prompt injection, anti-refusal, data exfiltration, privilege escalation, supply chain, agent snooping, system-prompt leakage, SSRF and excessive agency — measured 2d ago.
A static scan of the body, not an audit. Every finding is printed with the line that produced it so you can judge whether it matters here. A mod is markdown that instructs an agent; that is exactly why what it instructs is worth reading.
Makes network callslowCapability
Not a fault in itself. Listed so you know the mod talks to something, and to what.
2. REST fallback: API token + `curl -u email:token` against `https://<site>.atlassian.net` (discover cloudId: `curl https://<site>.atlassian.net/_edge/tenant_info`). How it starts
The opening of the file, as written. The whole thing — 759 lines — stays where its author put it; the contents beside it link to each section on GitHub.
What I do
I implement a unified ticket/issue creation and planning workflow supporting both GitHub Issues and JIRA:
- Detect Platform: Determine whether to use GitHub Issues or JIRA based on user input and project setup
- Gather Ticket Requirements: Prompt user for structured description following industry best practices
- Determine Ticket Scope: Ask if work should be broken into sub-issues/subtasks
- Create Ticket: Use GitHub CLI or Atlassian MCP tools to create the ticket with appropriate labels/type
- Create Git Branch: Generate branch from ticket identifier (e.g.,
GIT-123orPROJ-456) 5.5. Adopt/Rename PLAN: If an existing draft plan inPLANS/matches this ticket, adopt it (rename to the canonical ticket-scoped filename viagit mv) instead of regenerating from scratch - Generate PLAN file: Create comprehensive plan with atomic steps + rationale (Why / Done when / Consumers affected) and a Dependency & Consumer Map in
PLANS/directory - Commit and Push: Commit PLAN file with semantic formatting and push to remote
- Update Ticket: Post progress comment to GitHub issue or JIRA ticket
- Prompt Execution: Ask user if they want to proceed with plan execution
Framework Skills Used
| Skill | Purpose | Used In |
|---|---|---|
git-issue-labeler |
GitHub label assessment and assignment | Step 4 (GitHub) |
jira-ticket-labeler |
JIRA issue type and priority classification | Step 4 (JIRA) |
git-semantic-commits |
Conventional commit message formatting | Step 7 |
git-issue-updater |
Progress updates to GitHub issues | Step 8 (GitHub) |
When to use me
Use this workflow when:
- Starting a new development task tracked in GitHub Issues or JIRA
- You want a standardized approach to ticket creation and planning
- You need to break down large work into structured phases
- Following the practice of planning before implementation
Prerequisites
GitHub Issues
- GitHub CLI (
gh) installed and authenticated - Git repository initialized with GitHub remote
- Write access to repository
gh auth statusshows valid authentication
What this file has done since we first saw it
Hashed on every crawl. A supply-chain change to an agent config is a question of when, not whether, so the history is kept rather than the latest state alone.
- 2d ago First seen · 759 lines · 52 tokens per session scan A e2070c33dfb4
ticket-plan-workflow-skill is a skill published in the GitHub repository darellchua2/opencode-config-template (6 stars, last pushed 4d ago), licensed Apache-2.0. It adds 52 tokens to every session and 6,934 once invoked, about $0.0003 per session on Opus 5. A static security scan graded it A with 1 finding (makes network calls). No closer match exists in the catalogue, so it is treated as the original; first seen 2026-09-03.
Other skills, from other repositories
jig-github-release
Use when releasing this repository from the CLI by promoting develop to main with a fast-forward push, grading the release as patch/minor/major by what installed projects actually pay, computing the next version from the latest tag, and publishing a GitHub release with agent-written notes. No release PR, no…
jig-version-rubric
Use when creating, reviewing, or re-setting this repository's version grading rubric at .jig/versioning.md: adopt the jig default human-intervention rubric, write a project-specific one, edit one grade, or reset to the default. Owns the rubric file; never runs a release.
ship
Use when ready to ship code to remote — handles direct push to main and PR-based feature branch flows. Do NOT use for partial workflows like just committing or just pushing.
jig-github-sync
Use when synchronizing this repository's GitHub setup: main/develop branches, optional branch protection, and the managed local guards (the git pre-push hook plus the native Codex and Antigravity push hooks), including guard cleanup before uninstalling jig. Do not use for creating a release.
jig-hotfix-flow
Use when a released defect on main must ship before the work already sitting on develop. Branches from main, lands one squashed commit on main through the guard-allowed hotfix push, tags and publishes, then merges main back into develop so the next release still fast-forwards.
git-ship
自动化 Git 工作流一键发布助手，执行完整的「ship」流程： 基于最新 main 切新分支 → commit → 推送 → 创建 PR → squash merge → 回 main。 调用 ship 本身就是对完整流程的授权；自动推断分支名、commit message 和 PR 内容， 并主动解决 Git 冲突、测试、lint、类型检查、构建和 CI 失败，持续修复和重试， 直到改动成功合并。不要因可自行修复的失败暂停，只在认证、权限、仓库保护等 无法由当前环境解决的外部阻塞出现时请求用户介入。 仅在用户明确表达「ship」意图时触发，例如： 直接说「ship」「/ship」「git ship」 明确要求完整走完 git…