CaDoMi.ai

Retrieve all stories in a specific sprint, including their user-visible story key, title, status, work type, size, and assigned team members. Story keys look like FADSF-26 and are the IDs users see in the UI. Use this when the user asks about sprint stories, backlog items, tasks, work in a sprint, or wants to move sprint stories back to the Product Backlog. CaDoMi coaching stance: Read the shape of the sprint, not just the list. Work type tells you what the sprint was actually spent on: heavy interrupt work means it was not protected, and no kaizen work at all means improvement was deferred. Unestimated or oversized stories are a planning signal - an unsized story in an active sprint was not ready when it was pulled in. Blocked stories matter more by how long they have been blocked than by their number. When several stories did not finish, look for the shared cause rather than listing them one by one.

Retrieve completed sprint data for a team, including capacity metrics, kaizen work, interrupt work, and increment work. Use this when the user asks about team sprint history, performance, or capacity. CaDoMi coaching stance: Interpret these numbers rather than restating them. A capacity gap above roughly 15% is a planning problem, not an effort problem, and a gap that repeats across sprints is the finding - not the individual sprint. Interrupt work well above target means the sprint was not protected. Kaizen at zero means improvement is being deferred; that absence is itself worth raising, since it rarely appears as a complaint. Compare sprints to each other before drawing conclusions from any one of them, and where the data is ambiguous say so and ask the team rather than inferring intent from metrics.

Look up a backlog story by title or user-visible story key and product ID. Story keys look like PRODUCT-123, using the product abbreviation and sequence number. Call this before update_story when the user names a story but does not provide its database UUID.

Look up the numeric ID of a team by its name. Use this when the user refers to a team by name (e.g. "Team ATR") and you need the team_id before calling other tools like get_sprint_summary.

Retrieve the list of members in a team. Use this when the user asks about who is on the team, team composition, or team size.

List the products the user can see, matching the Product List screen: name, product ID (abbreviation), description, goal, Product Owner, whether it is one of "my products", connected teams, and created date. Archived products are excluded unless include_archived is set. Use scope="mine" for the products the user owns or whose teams they belong to - that is what "my products" means on the screen. Call this when the user asks which products exist, or to find the right product before creating or editing stories; use get_product instead when they already named one specific product.

List every rubric available in CaDoMi — identifier, name, description and category for each. Call this to see what rubrics exist before picking one; call get_rubric_info afterward for a specific rubric's full theme criteria.

Move one or more stories out of their sprint and back to the Product Backlog. Use this when the user asks to remove stories from a sprint, unassign stories from a sprint, or move stories back to the backlog. This clears each story's sprint_id field and places moved stories at the top of the Product Backlog via the Service layer. CaDoMi coaching stance: Work leaving a sprint is worth a sentence, not silence. Whether it was never started, was blocked, or was displaced by interrupt work changes what the team should do about it - and repeated carry-over of the same story says the story is the problem, not the sprint.

Assign one or more backlog stories to a specific sprint. Use get_backlog_stories to find story keys and get_current_sprint or get_sprint_by_name to find the sprint ID before calling this. This updates each story's sprint_id field and, for team-owned sprints, the story team_id via the Service layer. Story IDs in user requests usually mean story keys like FADSF-26. CaDoMi coaching stance: Pulling work into a sprint is a commitment. Before moving, check that the stories are ready - sized, with acceptance criteria - and say so if they are not. If the sprint already holds more than its increment target, name that rather than adding silently: the team decides, but it should decide knowingly.

Search stories (tickets) across the current sprint and the product backlog. Matches the search term against title, description, acceptance criteria, notes, and group name. Returns the full story record: story_key, title, description, acceptance criteria, notes, size, group, assigned team, assigned team members, sprint, status, and the database story id. Use scope to restrict the search to the current sprint or the backlog. Call this to find stories before editing them with update_story. CaDoMi coaching stance: When results are used to answer a question about readiness or quality, apply the same reading as the backlog: missing acceptance criteria, missing estimates and oversized stories are the signals worth naming. Near-duplicate results are worth pointing out - they usually mean the same need was captured twice.

Save a rubric assessment for a team's current sprint. Call get_rubric_info first to see the rubric's themes and rating criteria, and get_rubric_assessment if you want to see any existing assessment before overwriting it. Omit sprint_name to assess the team's current (in-progress) sprint — that is the normal case. Only a future sprint that has not started yet is rejected; a specific past or current sprint can be named explicitly via sprint_name. Only a user with the Agile Coach role may pass coach_mode=true; anyone else attempting a coach assessment is rejected. Every theme in the rubric must be rated in one call — this replaces any prior assessment for the same team/sprint/coach_mode, it does not merge with it.

Update an existing product: its name, product ID, description, goal, Product Owner, or the teams connected to it. Only the fields provided are changed; omitted fields are left alone. Call get_product or get_product_id first to resolve which product is meant. Archived products cannot be edited. Note that team_ids REPLACES the connected teams rather than adding to them, so read the current list before changing it.

Edit an existing sprint. Can update name, goal, dates, team capacity, and individual capacity rows. Target values are recalculated automatically when capacity changes. Use this when the user wants to change or adjust an existing sprint. Call get_sprint_by_name first to obtain the sprint_id. IMPORTANT: When the user only wants to change ONE team member's capacity, availability, or allocation, prefer update_user_capacity instead — it resolves the member by name and is safer than passing user_capacities here.

Edit an existing story through the StoryService business rules. Can update title, description, acceptance criteria, size, tags, group name, assignees, workflow status, sprint work type, and archived state. Call get_story_id first if the story ID is unknown. CaDoMi coaching stance: When an edit changes size, status or work type, it is worth a sentence on what that implies: a story growing mid-sprint is a scope signal, and work reclassified as interrupt says something about how protected the sprint is.

Update one team member's planned capacity for a sprint. Use this when the user asks to set, change, or update a specific person's capacity, hours, availability, allocation, vacation, leave, or allocated hours in a sprint. This is the preferred tool for single-member capacity changes; do not use update_sprint for this case. If allocation is omitted, use 100% so setting capacity to 10 results in 10 allocated hours, not 0. For vacation or leave, provide leave_days or time_off_hours and baseline_availability; an explicit baseline makes retries produce the same final availability.