--- title: "HacknPlan Integration" description: "HacknPlan is project management built for game development teams, with milestones, kanban boards, work items and a game design model. Agents turn bug reports into work items, move items across board stages, log work and keep the design model linked to the tasks that implement it." url: https://flowrunner.ai/integrations/hacknplan date_modified: 2026-09-04T14:21:17-07:00 --- # HacknPlan [Project Management](https://flowrunner.ai/integrations/category/project-management-productivity) HacknPlan is project management built for game development teams, with milestones, kanban boards, work items and a game design model. Agents turn bug reports into work items, move items across board stages, log work and keep the design model linked to the tasks that implement it. 87 actions · API key · available [HacknPlan website](https://hacknplan.com/) · [Platform Documentation](https://api.hacknplan.com) · Capability data verified 2026-08-18 1. A crash report crosses the reporting threshold in the error tracker 2. Agent reads the stack trace, the affected build, and how many players hit it 3. List Work Items searches the project for an open item already covering the same crash 4. List Categories, List Importance Levels, and List Design Elements resolve this project's own vocabulary 5. Create Work Item raises the task on the right board with an estimate, an importance level, and a link to the design element it belongs to 6. The discipline lead sees what was raised, against which feature, and with what estimate 7. The lead confirms the estimate and the design element link before the item enters the sprint ## What This Integration Enables HacknPlan is built for game teams, and its structural bet is the design model: a tree of features, systems, characters, and content that work items link back to. That is what separates it from a general purpose tracker. In most tools a burndown answers how far into the sprint you are. Here you can ask how complete a feature is, because the metrics hang off the design element rather than off the calendar, and the same question can be asked at the project, milestone, board, and element level. FlowRunner agents work both halves of that model. They raise work items from crash reports, QA forms, and build failures with the project's own categories and importance levels resolved first, since HacknPlan requires an estimate and an importance on every item. They move items across kanban stages as an external process reaches each step, record work logs in the project's cost metric, maintain subtask checklists and dependencies, keep the design tree in step with the design document, and read the metrics that a status update actually needs. Project membership can be kept in step through workspace teams, so a team joining a project is one call rather than a round of invitations. Where an operation would destroy the record of work already done, the connector's [human-in-the-loop](https://flowrunner.ai/concepts/human-in-the-loop) gate takes over. ### Without FlowRunner **Bugs retyped from tools**: A crash in the tracker becomes a task only when somebody copies it across by hand **Progress measured by sprint**: The board says the sprint is 80 percent done, which says nothing about whether the feature ships **Rollover as a manual sweep**: Closing a sprint means deciding item by item what carries forward, usually in a hurry ### With FlowRunner **Bugs arrive as work items**: The report becomes a task on the right board with the right category and importance, deduplicated first **Progress measured by feature**: Metrics are read against the design element, so the question is how far along the feature is **Rollover proposed, then confirmed**: The agent assembles what should carry forward and a lead rules on what counts as finished ## Use Case Scenarios ### A crash becomes a task on the right board, once An error in [Sentry](https://flowrunner.ai/integrations/sentry) or a failed build in [GitHub](https://flowrunner.ai/integrations/github) crosses the threshold that means somebody has to look at it. The agent searches List Work Items with free text over the title and description to check whether the same crash is already open, and if it is, adds a comment with the new occurrence count instead of raising a duplicate. If it is genuinely new, it resolves the project's own categories, importance levels, and stages, since none of those vocabularies are universal, and calls Create Work Item with the estimate and importance HacknPlan requires. The reproduction steps go in as subtasks. The item lands linked to the design element for the system that broke, which is what makes it show up in that feature's metrics later. ### The sprint that reports itself At the end of a board's cycle the agent calls Get Board Metrics for the closed and open counts and the estimated against logged cost, then reads List Work Logs across the items that moved to build the picture of where the time actually went. It groups the variance by person and by category, calls out the items whose logged cost bore no relationship to the estimate, and posts the summary to the studio channel in [Slack](https://flowrunner.ai/integrations/slack) or [Discord](https://flowrunner.ai/integrations/discord). The producer reads a review that was assembled from the data rather than from memory, and the estimates on the next board are set by people who have seen the last set tested. ### Progress asked of the feature, not the calendar A publisher milestone approaches and the real question is which features are ready. The agent walks List Design Elements, calls Get Design Element Metrics for each, and ranks them by how much estimated work is still open against them. Where an element is far behind, it pulls the linked work items and the recent work logs to explain why, and drafts a short note per feature for the leads to react to. The output goes to a sheet in [Google Sheets](https://flowrunner.ai/integrations/google-sheets) for the milestone review. Nobody has to translate sprint burndown into a claim about whether the game is ready. ## Human-in-Loop Highlight When a feature is cut, somebody has to tidy the design model, and Delete Design Element is where that goes wrong. It removes the element and everything nested beneath it, and it takes a choice about the work items linked to it: delete them along with the element, or leave them in place. That choice is not reversible, and the two outcomes are very different. Deleting the linked items destroys their comments and their logged work, which is the record of what the studio actually spent on a feature it decided not to ship. Keeping them leaves orphaned tasks that no longer roll up to anything. So the design cleanup agent gathers and stops. It calls Get Design Element for the children, Get Design Element Metrics for the cost already sunk, and List Work Items filtered to that element, then puts the whole picture in front of the design lead: "Cutting the Weather System element removes 3 child elements and unlinks 41 work items carrying 214 logged hours. Delete the work items with it, or keep them and leave them unlinked?" The lead decides what happens to the record of the work, and the agent executes exactly that. The same discipline applies to Close Board and Close Milestone, where closing the remaining open items marks unfinished work as finished outright unless a target board is named to carry it forward, and to Transfer Project Ownership, which the current owner cannot reverse from the same connection. Agent processes routinely Detects exception requiring judgment Clear match Continues automatically Ambiguous Routes to human via preferred channel Human decides Agent resumes with decision ## Agent Capabilities 87 actions ### Connection 1 - **Get Current User** Retrieves the account the API key belongs to. Every permission check runs against that user, so a flow confirms who it is acting as before it acts. ### Projects 9 - **List Projects** Retrieves every project the connected user can see across their workspaces. The starting point for almost every other operation. - **Get Project** Retrieves one project with its owner, its cost metric, and which optional modules are switched on. A disabled module makes its operations unusable on that project, so this is read before assuming a capability. - **Create Project** Creates a project in a workspace. The cost metric decides whether work is estimated in hours or story points and is not casually changed later, and template options copy the boards, work items, design model, or members of an existing project. - **Update Project** Updates a project's editable fields. A partial update, so untouched fields are left alone. - **Delete Project** Permanently deletes a project with its boards, work items, design model, and logged work. Reviewed before it runs, since closing is what a finished project usually needs. - **Close Project** Closes a project, marking it finished without deleting anything. The reversible way to retire work. - **Reopen Project** Reopens a closed project, leaving everything inside exactly as it was. - **Get Project Metrics** Retrieves progress for a whole project by category: open and closed items, estimated cost, logged cost, and what remains. The figure a status report actually needs. - **Transfer Project Ownership** Hands ownership to another member. The current owner loses owner rights, which the same connection cannot undo, so this waits for a person. ### Boards 10 - **List Boards** Retrieves the boards in a project, excluding closed ones unless asked for. A board is the kanban surface every work item outside the backlog sits on. - **Get Board** Retrieves one board with its milestone and whether it is the project default. - **Create Board** Creates a board, optionally attached to a milestone. Used to open the next sprint from a template of the last one. - **Update Board** Updates a board's editable fields as a partial update. - **Delete Board** Permanently deletes a board. Closing is preferred when the work is simply finished, because closing lets the remaining items move somewhere. - **Close Board** Closes a board and decides what happens to the work still open on it: finish those items outright, or name a target board and carry them over. This is the sprint rollover, and the choice is a judgment rather than a default. - **Reopen Board** Reopens a closed board. Items that were closed when the board closed stay closed. - **Get Board Metrics** Retrieves progress for one board by category. What a sprint review reads from. - **Set Default Board** Makes a board the project's default, which is where new work items land when no board is named. - **Clear Default Board** Removes the project's default board, so new work items must name one explicitly. ### Milestones 8 - **List Milestones** Retrieves the project's milestones, each with the boards it contains. Milestones sit above boards and represent a release or a phase. - **Get Milestone** Retrieves one milestone with the boards that belong to it. - **Create Milestone** Creates a milestone in a project. - **Update Milestone** Updates a milestone's editable fields as a partial update. - **Delete Milestone** Permanently deletes a milestone. Closing is preferred, because closing can carry the unfinished boards and tasks forward. - **Close Milestone** Closes a milestone and decides what happens to the boards and tasks still open inside it. The operation that ends a release cycle, and it can carry unfinished work into the next milestone in one call. - **Reopen Milestone** Reopens a closed milestone. - **Get Milestone Metrics** Retrieves progress for one milestone by category. ### Work Items 13 - **List Work Items** Searches a project's work items by board, milestone, category, assignee, design element, stage, importance, or parent story, and by free text over title and description. The deduplication read behind every intake flow. - **Get Work Item** Retrieves one work item with its board, stage, category, tags, assignees, and estimated against logged cost. - **Create Work Item** Creates a task or a user story. HacknPlan requires a title, an estimated cost, and an importance level on every item, and subtasks can be created inline as a list of titles. - **Update Work Item** Updates a work item as a partial update. Moving it to a different stage is how progress is recorded on the board. - **Delete Work Item** Permanently deletes a work item along with its subtasks, comments, and logged work. - **Assign User To Work Item** Assigns a project member to a work item. HacknPlan allows several assignees, so this adds rather than replaces. - **Unassign User From Work Item** Removes a member's assignment. Work they already logged against the item is kept. - **List Work Item Tags** Retrieves the tags attached to a work item. - **Add Tag To Work Item** Attaches an existing project tag to a work item. Used to apply a classification an agent produced. - **Remove Tag From Work Item** Detaches a tag from a work item. The tag itself stays defined on the project. - **List Work Item Dependencies** Retrieves what a work item is waiting on, with a resolved flag per dependency. An item with an unresolved dependency shows as blocked. - **Add Work Item Dependency** Records that a work item depends on another, which marks the dependent item blocked until it clears. - **Remove Work Item Dependency** Removes a dependency, unblocking the item if that was the only one outstanding. ### Subtasks 5 - **List Subtasks** Retrieves a work item's checklist with each entry's completed state and position. - **Create Subtask** Adds a checklist entry to a work item. Used to turn reproduction steps or a definition of done into something the assignee works down. - **Get Subtask** Retrieves one checklist entry. - **Update Subtask** Renames a checklist entry, reorders it, or ticks it off, as a partial update. - **Delete Subtask** Permanently deletes a checklist entry from a work item. ### Comments 5 - **List Work Item Comments** Retrieves the comments on a work item, newest first. A comment can carry a work log with it, which is how HacknPlan records both what was done and how long it took. - **Create Work Item Comment** Adds a comment attributed to the account the API key belongs to. Used to add a new occurrence to an existing bug rather than raising a duplicate. - **Get Work Item Comment** Retrieves one comment including any work log attached to it. - **Update Work Item Comment** Rewrites a comment's text, normally only where the connection is the author. - **Delete Work Item Comment** Permanently deletes a comment from a work item. ### Work Logs 5 - **List Work Logs** Retrieves the work logged against an item, each entry in the project's cost metric, which is hours on an hours project and points on a points project. - **Create Work Log** Logs work against an item in the project's cost metric, attributed to the connected account, and moves the item's logged cost immediately. - **Get Work Log** Retrieves one work log entry. - **Update Work Log** Changes the amount recorded or its note, and the item's logged cost moves with it. - **Delete Work Log** Permanently deletes a work log entry. The amount comes off the item's logged cost and off every metric that included it. ### Design Model 6 - **List Design Elements** Retrieves the project's design model, the tree of features, systems, and content that work items are built against. The read behind measuring a feature rather than a sprint. - **Get Design Element** Retrieves one element with its children and how many work items reference it. - **Create Design Element** Adds an element to the design model, nested under a parent to build the tree. - **Update Design Element** Updates an element as a partial update. Changing the parent moves the element and everything beneath it. - **Delete Design Element** Deletes an element and everything nested under it, with a choice about whether the linked work items go too. The choice is not reversible, and it is the operation this page's human gate exists for. - **Get Design Element Metrics** Retrieves progress for one design element, which is how a flow answers how far along a feature is. ### Project Configuration 6 - **List Categories** Retrieves the project's work item categories, such as art, code, or audio. Categories the connected user cannot read are omitted, which is how contractors are scoped to their own discipline. - **List Stages** Retrieves the project's workflow stages, which are the columns of its board. Moving an item between stages is how progress is recorded. - **List Importance Levels** Retrieves the project's importance levels, its equivalent of priority. One is required on every work item. - **List Tags** Retrieves the tags defined on a project, the free form labels that cut across categories and boards. - **List Roles** Retrieves the project's roles and the permissions each grants. - **List Design Element Types** Retrieves the design element types, such as feature, system, or character. One is required when creating an element. ### Members 3 - **List Project Members** Retrieves a project's members with their role, admin and guest flags, and per category permissions. - **Invite Project Member** Invites someone to a project by email address. A guest sees only the categories their permissions allow. - **Remove Project Member** Removes a member from a project. Their work items and logged work stay on the project. ### Files and Storage 3 - **List Project Files** Retrieves the files uploaded to a project with their sizes and download addresses. - **Delete Project File** Permanently deletes a file, freeing its storage, and any attachment pointing at it goes with it. - **Get Project Storage** Retrieves how much file storage a project is using against its quota. Used to raise the alarm before an upload starts failing. ### Webhooks 6 - **List Webhook Events** Retrieves the event names a webhook can subscribe to. Fetched before creating one, since an unrecognized name is rejected. - **List Webhooks** Retrieves the webhooks configured on a project with their targets, events, and enabled state. - **Get Webhook** Retrieves one webhook including who created it and which events it listens for. - **Create Webhook** Registers a webhook on a project. HacknPlan names the event in a request header and does not sign its deliveries, so a custom header carrying a shared secret is the only way for the receiver to authenticate the call. - **Update Webhook** Updates a webhook's address, events, or custom headers as a partial update. - **Delete Webhook** Permanently deletes a webhook, stopping deliveries immediately. ### Workspaces 7 - **List Workspaces** Retrieves the workspaces the connected user belongs to, each with its seat count. A workspace is the billing and team boundary projects live inside. - **Get Workspace** Retrieves one workspace with its projects and how many seats are in use. - **List Workspace Teams** Retrieves the teams inside a workspace. A team is a named group of members that can be added to a project in one go. - **Get Workspace Team** Retrieves one workspace team with its members. - **Add Team To Project** Adds every member of a workspace team to a project at once, which keeps project membership consistent with the team rather than with whoever remembered to invite whom. - **List Workspace Members** Retrieves a workspace's members with their admin, guest, and active flags. This is the seat list the workspace is billed for. - **Get Workspace Member** Retrieves one workspace member by their user identifier. ## Frequently Asked Questions ### What can FlowRunner do with HacknPlan? FlowRunner agents can run Get Current User, List Projects, and Get Project in HacknPlan, plus 84 more actions. ### Does connecting HacknPlan to FlowRunner require OAuth? No. HacknPlan connects to FlowRunner with an API key, no OAuth flow required. ### Can HacknPlan trigger a FlowRunner workflow automatically? HacknPlan doesn't currently expose triggers in FlowRunner. It connects as an action step inside workflows started by another trigger. **Work at HacknPlan?** This integration exposes HacknPlan to AI agents on every FlowRunner plan, including through MCP, at no cost to you. [See what FlowRunner offers integration partners](https://flowrunner.ai/integrations/partners), including how to keep this page current. --- Markdown version of https://flowrunner.ai/integrations/hacknplan. Site index: https://flowrunner.ai/llms.txt