From cyber-mango
Kanban board management protocol — when and how to create, move, and manage cards on the Cyber Mango board.
How this skill is triggered — by the user, by Claude, or both
Slash command
/cyber-mango:board-manageThe summary Claude sees in its skill listing — used to decide when to auto-load this skill
You have access to a Cyber Mango kanban board via MCP tools. This skill defines exactly how and when you use them. Follow these rules without exception.
You have access to a Cyber Mango kanban board via MCP tools. This skill defines exactly how and when you use them. Follow these rules without exception.
At the start of every session, call get_board_summary immediately. This gives you a snapshot of the current board state — how many cards are in each column, their priorities, and any WIP limits in effect. Do not wait for the user to ask. This context is required before you can answer any work-related question accurately.
Every card must be tagged with the current project name. Before creating a card, detect the project name by running:
git remote get-url origin 2>/dev/null
Extract the repository name from the URL (the last path segment, without .git). For example:
https://github.com/juandagalo/cyber-mango.git -> cyber-mango[email protected]:juandagalo/my-app.git -> my-appPass the extracted name as the tags parameter when calling create_card. If additional tags are needed (e.g., bug, feature), combine them: tags: "my-project,bug".
If there is no git remote (not a git repo), omit the project tag.
Create a card whenever:
Do not wait for the user to explicitly ask you to create a card. If the user says "I'm going to fix the login bug", create the card proactively, then confirm it was created.
Before creating any card, call get_board and search the results for an existing card that matches the work item. If one exists, update it instead of creating a duplicate.
Before making any column placement decision, call get_board and read each column's description field. Column descriptions define the intended purpose of each column for THIS board. Do not assume column names map to a fixed meaning — always read the description first.
To understand a column's workflow role:
get_boarddescription field on each column object in the responseIf a column has no description, infer its purpose from:
The DEFAULT board ships with these five columns as examples:
These are the defaults — your board may have different columns with different names and descriptions. Always read descriptions dynamically from get_board.
Never skip columns without a stated reason. If a card jumps from the first column to the last, that is a data quality problem unless the user explicitly confirms it is correct.
Users may refer to cards as "tickets", "tasks", "items", or "work items". These all map to cards on the board. When the user says "move the ticket to Done" or "update the task", they mean a card operation.
Move cards when the work state changes. To determine the correct target column:
get_board and read the description field on each columnFor example, on the DEFAULT board:
blocked tagWhen you detect a state transition, ALWAYS include column_name in your update_card call alongside any other changes. This ensures the card moves to the correct column in the same operation. Use move_card only when repositioning within a column or moving without other changes. Do not assume the card is already in the right column — verify first.
Assign priorities based on urgency and impact:
If the user does not specify a priority, use medium. If the user uses words like "urgent", "blocking", or "ASAP", use high. If they mention production, outages, or security breaches, use critical.
Use tags to classify cards with additional context:
bug: Something is broken and needs fixingfeature: New functionality being addedchore: Maintenance, tooling, dependency updates, refactors with no behavior changeblocked: Work cannot proceed until something else resolvesspike: Time-boxed investigation or proof of concept with no guaranteed deliverableAssign tags via manage_tags. A card can have multiple tags. Tags help filter and prioritize the board — use them consistently.
Before adding a card to a column that has a WIP limit, call get_board and count the current cards in that column. If the column is at capacity:
Never silently exceed a WIP limit.
Every board has workflow phases that track where a card is in the delivery pipeline. The default phases are: Development, Code Review, QA, Client Review, Ready to Deploy.
Assign a phase when creating or updating a card if the work state is clear:
If the work state is ambiguous, do not assign a phase. A card without a phase is valid — it simply means the delivery stage is unknown.
Phases and columns serve DIFFERENT purposes:
A card can be In Progress (column) during Development (phase), then still In Progress during Code Review (phase). Phases change more frequently than columns.
update_card can change both metadata (title, description, priority, phase) AND move to a different column in a single call. When the user mentions a delivery stage change AND a state transition together, use update_card with both phase_name and column_name. Use move_card only when you need to reposition within a column or move without any other changes.
Use manage_phases to list, create, update, delete, or reorder phases on a board:
action: "list" — see all phases on a board (ordered by position)action: "create" — add a new phase (requires name, optional color defaults to #00FFFF)action: "update" — change name or color (requires phase_id)action: "delete" — remove a phase (cards keep their data, phase_id becomes null)action: "reorder" — reorder phases by providing ordered_ids as a JSON arrayWhen you detect a phase change from the conversation, update the card immediately. If the column should also change, include both in the same call:
update_card(card_id: "...", phase_name: "Code Review", column_name: "Review")
If only the phase changes (column stays the same):
update_card(card_id: "...", phase_name: "Code Review")
To remove a phase from a card (e.g., the card is no longer in the delivery pipeline):
update_card(card_id: "...", unset_phase: true)
Do not skip phase transitions without reason. If a card jumps from Development to Ready to Deploy, confirm with the user.
Every card MUST follow this template. No exceptions.
Use the pattern: [type] short imperative description
Valid types:
[feat] — new functionality[bug] — something is broken[chore] — maintenance, tooling, refactors, dependency updates[spike] — investigation or proof of concept[docs] — documentation changesExamples:
[feat] add OAuth2 login flow[bug] fix null pointer on empty board[chore] upgrade mcp-go to v0.45[spike] evaluate Redis vs Memcached for session cacheThe title must be lowercase after the type prefix. Keep it under 60 characters. Use imperative mood ("add", "fix", "update", not "added", "fixing", "updates").
Every description MUST have exactly three sections in this order:
## What
One sentence describing what needs to be done.
## Why
What problem this solves or what motivates the work.
## Context
Relevant files, services, endpoints, or technical details.
Rules:
Do not add extra sections. The current state of each card (status, progress, blockers) is tracked via columns, phases, and tags, not in the description.
Do not write vague descriptions like "fix the bug" or "implement the feature". A card description must stand alone without the surrounding chat history.
When returning to work on an existing item:
get_board to find the card by searching titles and descriptionsupdate_card to update the title, description, or priority as neededIf you are unsure whether a card exists, search before creating. A board cluttered with duplicates is worse than a missing card.
npx claudepluginhub juandagalo/cyber-mango-plugin-go --plugin cyber-mangoGuides creation, editing, and verification of skills for AI coding agents using test-driven development with subagent scenarios. Use when authoring or debugging skills.