Delivery Planning

Delivery Planning

Runtime Context

Before acting, resolve ` using the runtime bootstrap rules, then read /.workflow/runtime.md and /.workflow/manifest.yml`; do not assume non-default workflow paths or default ids.

Use this skill to propose Kanban changes from project knowledge. This skill produces a dry-run only.

Task items are candidates and context until an approved Kanban card links to them. Use this skill when the user asks to rank loose task items, review backlog candidates, or turn task items into accepted Kanban work.

Workflow

1. Read /.workflow/rules/delivery.md.
2. Read /.workflow/schemas/common.md and /.workflow/schemas/tasks.md.
3. Collect candidate task items and source knowledge.
4. Exclude local workspace notes, archived notes, and localized files.
5. When proposing assignees, reviewers, ownership fit, or handoffs, read only the relevant sections from /members/.md, such as Responsibilities, Focus Areas, Collaboration, or Availability.
6. De-duplicate candidates against /planning/KANBAN.md.
7. Produce a dry-run table and wait for maintainer approval.

Default Inputs

• /product/**
• /user-stories/**
• /discovery/**
• /concepts/**
• /architecture/**
• /decisions/**
• /test-cases/**
• /metrics/**
• /experiments/**
• /releases/**
• /guidelines/**
• /tasks/*.md

Use /guidelines/** as planning context or constraints. Do not create Kanban candidates from guidelines alone unless a guideline explicitly defines executable delivery work.

Use /discovery/** as supporting evidence, assumptions, and opportunity context for product requirements. Do not create Kanban candidates from discovery analysis alone unless it has been accepted as product scope or a task item.

Use /user-stories/** as source intent for user goals, use cases, scenarios, journeys, and acceptance intent. Do not create Kanban candidates from stories alone unless they are linked to accepted product scope or converted into task items.

Use /test-cases/** as validation context for task readiness and acceptance coverage. Do not create Kanban candidates from test cases alone unless the test case explicitly identifies executable delivery work.

Use /metrics/**, /experiments/**, and /releases/** as planning context, evidence, constraints, or follow-up signals. Do not create Kanban candidates directly from raw metric movement, running experiments, or release notes unless a task item or accepted scope exists.

Use /proposals/** only as backlog review context. Do not create Kanban candidates directly from proposals. Accepted task proposals must be converted into task items before delivery planning.

Use type: issue, type: bug, and type: defect task items as delivery candidates only after triage shows they are actionable. Do not plan raw feedback, unverified observations, duplicates, invalid reports, or unresolved non-reproducible defects as Ready work.

When decomposing one requirement into several dependent tasks, propose dependent tasks for Backlog by default. Use blocked_by and readiness: blocked for planned dependency order; propose Ready only when every Ready Checklist source requirement is satisfied and owners resolves to existing member or group documents.

Use /workspace/*/summaries/**, /workspace/*/handoffs/**, or /workspace/*/research/** only when the owner or maintainer explicitly selects it.

Never use /workspace/*/local/** as planning input. Do not read member local workspace instructions for team planning.

Output

• Concise summary of proposed cards.
• Dry-run table.
• Missing metadata or blockers.

References

• For the dry-run table and task metadata examples, read references/dry-run.md.

Source & license

This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code.

• Author: choral-io
• Source: choral-io/choral-skills
• License: MIT
• Homepage: https://github.com/choral-io/choral-skills

Install and usage instructions live in the source repository linked above.