Wicked Ticket (wiki-ticket): Graph Engineering for your current SLDC tools

Use Wicked Ticket to map plans from Claude Code and Grok Build to your existing SLDC tools, keeping stakeholders, project managers, and product managers in the loop while you employ agentic harness,..

I started working on a project called Wicked Ticket (wiki-ticket-sdd). This is a Claude Code and Grok Build plugin to do graph engineering using your current SLDC tools. The tools your stakeholders are already using.

Here I am sitting at my desk working on a graph engineering project and not knowing it’s a graph engineering project. For the past few months, I’ve been managing projects a certain way. And it sort of evolved into, well, initially it was take a to-do list and keep track of that to-do list and keep adding to the to-do list and then just sync those to Jira tickets, subtask, task, whatever. And it was a little bit haphazard.

Use Wicked Ticket to map plans from Claude Code and Grok Build to your existing SLDC tools, keeping stakeholders, project managers, and product managers in the loop while you employ agentic harness and loop engineering

This todo-list idea came from several of the Anthropic harness engineering papers and blogs, which in my mind led to a lot of ideas in both the Harness Engineering and Loop Engineering space.

The issue I ran into when I was working with multiple coding agents on multiple branches and/or with multiple other developers was when I was trying to sync everything together. Right? Essentially, how to work with multiple agents working in multiple feature branches, worktrees, plus multiple developers without stepping on each other's toes. I spent some time doing that and figuring it out. Then I had this system that works with PRs and tickets. The tickets are your standard Agile SLDC-type tickets and can be epics, stories, tasks, or subtasks. There are tags and flags to adapt the tickets to your special process. For example, you can also support features, which is basically just a story with a flag that says it’s a feature. And then the task can be tagged as a bug or as just basically different ways. And the tickets have dependencies. A story could depend on an epic, an epic could depend on another epic, an epic could depend on stories in another epic. It was already a hierarchy. It was already a graph. The idea was to map a standard ontology and taxonomy to the todo.jsonl file.

And the reason I was doing this to begin with is to support my loop engineering efforts, where I have a list of tasks. Unlike some of the hanress engineering papers, or loop engineering papers, I have other developers to sync with as well as stakeholders, project managers, and product managers, not to mention a QA team.

Also, while agents were working, I could work on plans for other stores and epics. I had maybe multiple plans at any time. The next trick is that when the plan is done, a hook turns that plan into this hierarchy of tasks or hierarchy of tickets, as I described earlier. Then a background subagent turns the entries in the todo.jsonl to JIRA tickets or Github issues or Azure DevOps, etc. This way we have visible work. And while that is happening, we are executing the tasks in todo.json, but it knows their relationships, and I can add different tasks, different stories, different pieces, different dependencies, and I can add, or the agent can add, a task to do an ops piece and so on and so forth.

The rule is that all work be trackable via epics, stories, tasks, or subtasks.

It has that in there, and it has these dependencies kind of built out. And it knows to add tasks. And then it will sync those tasks to Jira, Azure DevOps, GitHub, GitLab, et cetera. And it works with PRs, releases, et cetera. It doesn’t try to tie itself to a specific system. Rather, it ties itself to the concepts of all of those systems, and then it does the final mapping when you install the plug-in. It can adapt to your existing system quite easily as long as you already have the tools to talk to your existing system. And then there are some hints in the wiki on how to cover common systems, which the skill can reference. Or the plug-in knows how to reference.

The whole idea behind it was to support graph engineering before I knew the term graph engineering. And then as I’m kind of releasing this, the term " graph engineering starts making headlines; I look, I go, that’s great. That’s what I’m doing. I’m also building a UI. The part that works really well is the mapping to the existing system. I’ve mostly tried it with GitHub, but also Azure DevOps quite a bit. In the past, I’ve done similar things with Confluence and Jira, and Git, GitHub. And there’s no reason why this couldn’t work with GitLab or any tool like that or the Amazon or Google equivalent. That’s what this is. It’s graph engineering, but it maps it to your current SDLC tools.

It does not try to replace your existing SDLC tools. Because those are the tools that your stakeholders are already using. Your product managers, your program managers, et cetera. are tracking visible work through these tools. And they can help guide that work, but only if it is visible.

Now maybe in some startups, you don’t have those roles, but in existing companies, you do. And there’s a whole sort of infrastructure around that. To be able to report and fishbowl what you’re working on to your stakeholders, your product managers, your project managers, the ones that are paying the bills and keeping things on track and keeping groups kind of delivering together, not just your team but the larger team. It’s a good thing. And that’s what this is. It’s graph engineering for the SDLC tools that you already use. You could have visible work in progress (WIP). And that’s what Wicket Ticket is. Graph Engineering to support Harness and Loop Engineering but still have manageable visible work.

There is also a UI being developed, but I think what we spent a lot of time on is making sure that agents can work in different branches and work trees without stepping on each other’s toes by creating a transaction log of changes to tickets that are easier to merge once you merge to main. When they commit things to the main branch, everything gets synchronized basically. If two people happen to touch the same ticket or add details to the same ticket, those things don’t get lost. And where that would come into play, if two agents were working on different stories in the same epic, they might both try to update the same epic. That gets synchronized. There’s a tool to make that happen. There are also tools that have a hook so that whenever you finish a plan, that plan gets turned into this hierarchy of tasks or hierarchy of tickets.

And we spent a lot of time on the information architecture of the wiki to make it human-friendly. You can go to the wiki and find exactly what you’re looking for really quickly. We spent time thinking about that, organizing it, and not just the wiki, but we did that with the PRs, releases, with the tickets, etc. You can see the relationships. You can find the information you’re looking for. And we’re trying to basically use the concepts of information architecture and information engineering to make it super user-friendly.

How does this work in practice? I have actually gone and listed a bunch of tickets that were left, and I just did a “/goal finish those tickets, and verify them,” and the coding agent goes through and finishes the tickets and verifies the tickets. The coding agent runs for quite a while. This is a good tool for loop engineering. Spec-driven development is the fuel for loop engineering.

You know, you've got to know what you’re building, and a lot of times that involves stakeholders, which means you want to update some of these documents so your stakeholders are reading the right documents. The wiki, the Confluence, the pages that matter. This is where the roadmap comes in. A lot of the ideas behind these tools are about keeping these stakeholder docs in sync (design docs, ADRs, decisions, user guides, plans, etc.).

This also keeps a roadmap in sync, so you can see where you are, what’s finished, what hasn’t finished. You know, I’m gonna be honest, the more that you can spin up subagents to finish mass amounts of work, the more important it is to stay in sync with what’s actually done. And the harder it is to keep all that in your head because things are happening a lot faster. Keeping yourself in sync with the system is kind of what the roadmap does, as well as keeping your stakeholders in sync. That’s the whole point of this: to make it all visible so that you can evolve more than just yourself, so that you can get feedback from the people that you’re building software for.

In the past, I’ve worked a lot with GSD, Superpowers, and, for that matter, SpecKit. And I would like to work with other tools like potentially OpenSpec. I spent a lot of time thinking about how the wiki ticket really just works with plans and tasks that come out of the core Grok build, Codex, OpenCode, and Claude Code planning. How would I map this to existing spec-driven development? And I think I can. I think I’ve been doing this already with Superpowers. But I want to keep that up.

That’s an area that I’m looking into: as someone’s using spec-driven development, how do we continue to do this spec-driven development without disrupting what they’re doing? I do use this wiki ticket a lot with Superpowers and a combination of Superpowers and Ponytail. And I don’t seem to have any issues doing that. Currently, I’m mostly using Claude Code and Grok Build. But in the past, I’ve done a lot with Codex, OpenCode, and some other tools. Compatibility is a big deal for me. It should work with Superpowers, PonyTail, GSD, SpecKit, and OpenSpec out of the box, and we added integration guides as part of the skill on how to adapt those, but these are just guides, and you need to decide the final integration.

In conclusion, Wicket Ticket was designed to do spec-driven development, coding agent-based development, while using standard SDLC tools to manage the graph engineering and to make the work visible so that stakeholders, product managers, project managers, QA teams, other developers, and other coding agents can all work together and see where the project is and what the status of the project is and have an idea of what’s happening as a whole, a holistic view of the system to engage with the stakeholders and make the work visible.

---

If you are a paid subscriber, thank you. Your support makes this work possible.

If you are a free subscriber and find these articles useful, please consider upgrading. A paid subscription is $80 per year or $8 per month.

---

About the Author — Claude Certified Architect

Rick Hightower is a former Senior Distinguished Engineer at a Fortune 100 company, focusing on delivering ML / AI insights to front-line applications, and a practitioner building multi-agent production systems. Follow him on SubStack and Medium for more hands-on agent engineering content. You can also book him to speak and train your team: Check out Rick Hightower’s SpeakerHub.

Rick Hightower helps companies become AI-first through practical mentoring, executive and team training, and custom AI solution development. He is a former Senior Distinguished Engineer at a Fortune 100 company, where he focused on bringing ML and AI insights into real front-line business applications.

Subscribe to Rick’s newsletter to see videos and guides.

Rick is a Claude Certified Architect, AI systems practitioner, and builder of production multi-agent systems. He is currently working on authoring a book on Harness Engineering with Manning Publishing. He created Skilz, a universal agent skill installer supporting 30+ coding agents, including Claude Code, Gemini, Copilot, and Cursor, and co-founded one of the largest agentic skill marketplaces.

Today, Rick and the Spillwave team work with leaders and teams who want to move beyond AI experiments and build real AI capability inside their companies. He helps organizations adopt AI safely, train their people, redesign workflows, and build practical AI systems that create measurable business value.

Ready to make your company AI-first? Connect with Rick on LinkedIn, Substack, or Medium, book him to speak or train your team, or visit Spillwave to explore mentoring, training, and custom AI solutions for your organization.