Run any Skill in Manus with one click

sprint-planner

Stars2

Forks0

UpdatedJune 29, 2026 at 10:07

Plan a sprint by selecting tracker tickets from one or more feature epics, ordering them into dependency-aware execution waves, matching capacity against estimates, and producing a sprint kickoff document modelled on the tech-lead delegation pattern. Use when: preparing the next sprint, replanning mid-sprint, or turning a prioritised backlog into an executable plan. Phase 3 of the ol-sdd-workflow orchestrator. Tracker-agnostic (jira | linear | ado | local). Output is a committed sprint-kickoff.md and a tracker sprint/cycle/iteration (or local `sprint:` tag) populated with the selected tickets.

Installation

Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.

Run Skill in Manus

Source

OntoLedgy

OntoLedgy/ol_ai_context_library

View GitHub Repository View Creator Repositories

Download

Run Skill in Manus

Related occupationsSOC

Based on SOC occupation classification

Project Management SpecialistsBusiness and Financial Operations Occupations·SOC 13-1082

SKILL.md

readonly

More from this repository

same repository

linear-backlog-manager

OntoLedgy/ol_ai_context_library

Publish an approved feature spec (tasks.md) to a Linear project as a structured tree of labeled, nested issues (feature → story → task), each with a spec back-link, requirements traceability, skill-routing label, and point estimate. Use when: the project tracker is Linear and a feature spec has been approved and needs to become a tracked backlog, or when a new requirement needs to be added to an existing Linear feature-issue. Phase 2 of the ol-sdd-workflow orchestrator when the project's tracker is Linear. The Linear parallel of backlog-manager (JIRA), ado-backlog-manager (ADO), and local-backlog-manager (filesystem). Requires Linear MCP — if the MCP is unavailable, fall back to `local-backlog-manager`.

2026-07-112

skill-updater

OntoLedgy/ol_ai_context_library

Check installed agent skills for available updates and bring them up to date. Covers the global install (~/.agents/skills + ~/.claude/skills), the current project's install, and — fleet mode — every repo under a user-supplied root folder. Detects three things: lock-tracked skills whose GitHub source moved on (updated via `npx skills update`), installs that drifted from a local library checkout or were never lock-tracked (updated via a deterministic local sync script), and broken .claude/skills symlinks. Use when: the user asks to update their skills, check whether installed skills are stale, roll a library change out to every machine-local install, or audit which repos have skills installed. Cross-cutting infrastructure skill — applies to all skills in the library.

2026-07-112

confluence-space-manager

OntoLedgy/ol_ai_context_library

Bootstrap, audit, and align solution-specific Confluence spaces against the canonical Ontoledgy space structure. The Confluence parallel of notion-workspace-manager, selected when the docs backend is Confluence. Operates in three modes: Create, Audit, and Align. Use when: the docs backend is Confluence (not Notion — use notion-workspace-manager for Notion) and a new solution repo needs a Confluence home, an existing space has drifted from convention, or a team wants to align multiple spaces before a release. Companion to `product-vision-steering` (Phase 0) and `release-planner` (Phase 0.5) — provides the *Confluence-side* container they publish into.

2026-07-102

impl-logger

OntoLedgy/ol_ai_context_library

Post a structured implementation log as a comment on a tracker work item (or, for `tracker: local`, an Activity Log entry) after a task is completed. Captures files created/modified, code statistics, and structured artifacts (API endpoints, components, functions, classes, integrations) so future engineers and AI agents can discover existing code and avoid duplication. Adapted from the spec-workflow-mcp log-implementation schema. Tracker-agnostic: works against JIRA, Linear, Azure DevOps, or a local filesystem tracker via the task-executor tracker adapter (`skills/task-executor/references/tracker-{jira,linear,ado,local}.md`), selected by the `tracker:` input. Use when: a task has been committed and the implementation needs to be recorded, or when a user asks to backfill a missing implementation log for an already-closed item. Phase 5 of the ol-sdd-workflow orchestrator: normally invoked once per completed task by the executor, but can also be run directly.

2026-07-102

ol-sdd-workflow

OntoLedgy/ol_ai_context_library

Ontoledgy end-to-end Spec-Driven Development (SDD) workflow orchestrator. Drives a team through six phases — Steering → Release Plan → Feature Spec → Backlog → Sprint Plan → Execution — with explicit user approval gates between each phase and structured implementation logs published to the tracker as issue comments. Use when: starting a new product or project from goals, scoping an MVP or release, taking a feature from concept to shipped code, setting up a sprint, or running a sprint with delegated task execution. Backend-agnostic: runs in `tracker: jira|linear|ado|local` and `docs: confluence|notion|ado-wiki|local` mode, routing each phase to the matching backend skill. `tracker: ado` + `docs: ado-wiki` runs the whole workflow on Azure DevOps Boards + Wiki; `tracker: local` + `docs: local` is the fully offline fallback — markdown files in the repo, no MCP — for when JIRA/Confluence/Notion/Linear/ADO are unavailable. Orchestrates product-vision-steering, release-planner, feature-spec-author, the tracker's bac

2026-07-102

agent-architect

OntoLedgy/ol_ai_context_library

Agent architecture design and review. Extends ob-architect with agent-specific topology design, tool gap analysis against ol_ai_services agent_dev_kit, context engineering, memory architecture, constraint design, and orchestration graph planning. Designs agents that reuse the ol_ai_services service layer; when tools or components are missing, designs new tools for registration into the service layer via BaseTool or MCP interop. Use when: designing a new AI agent system, reviewing an existing agent architecture, planning multi-agent orchestration, or designing tools for agent use — this skill defines the tool contract (schema, behaviour, interop), then hands off to agent-engineer to implement it from the approved design. Canonical address: architect:design:agent:agnostic.

2026-07-102

portability	ol-coupled
reuse	ol-platform-only
requires	["docs(confluence-mcp\|notion-mcp\|ado-wiki-mcp\|local-filesystem)","tracker(jira-mcp\|linear-mcp\|azure-devops-mcp\|local-filesystem)","codex-cli"]
name	sprint-planner
description	Plan a sprint by selecting tracker tickets from one or more feature epics, ordering them into dependency-aware execution waves, matching capacity against estimates, and producing a sprint kickoff document modelled on the tech-lead delegation pattern. Use when: preparing the next sprint, replanning mid-sprint, or turning a prioritised backlog into an executable plan. Phase 3 of the ol-sdd-workflow orchestrator. Tracker-agnostic (jira \| linear \| ado \| local). Output is a committed sprint-kickoff.md and a tracker sprint/cycle/iteration (or local `sprint:` tag) populated with the selected tickets.

Sprint Planner

Role

You turn a prioritised tracker backlog into an executable sprint plan. You select tickets to fit the sprint's capacity, order them by dependency into parallel waves, annotate each with the engineer skill that will execute it, and write a kickoff document the sprint-executor will follow.

You are invoked by the ol-sdd-workflow orchestrator at Phase 3, or directly when a sprint needs planning.

Inputs

Target feature epic(s) or explicit ticket list
Sprint number and length (default 10 working days)
Sprint capacity — engineer-days or total hours
Sprint goal — one sentence
Known constraints (team unavailability, external deadlines, code freezes)
Optional: explicit priority ordering from the user
Tracker — tracker: jira | linear | ado | local (inferred from documentation/workflow-config.md if absent; defaults to local with no tracker MCP), for reading the backlog and creating the sprint/cycle/iteration via the tracker adapter (skills/task-executor/references/tracker-{jira,linear,ado,local}.md)
Docs backend — docs: confluence | notion | ado-wiki | local (inferred likewise), for the sprint overview page via the docs adapter (skills/feature-spec-author/references/docs-adapter.md)

Outputs

Output	Where
`documentation/sprints/sprint-{N}-kickoff.md`	Committed sprint plan (format below)
Sprint/cycle	JIRA sprint / Linear cycle / ADO iteration created or populated; local: `sprint: N` set on each ticket. Tickets moved in
Docs page (Confluence, Notion, ADO Wiki, or local)	Sprint overview page via the docs adapter

Sprint Kickoff Document

The kickoff document follows prompts/coding/templates/sprint-plan-template.md — the single source of truth for its format (sections: Sprint Goal, Context, Capacity & Timeline, Architecture Spec Links, Skill Routing Table, Task Execution Order / Execution Waves, Review Checklist, Key Codebase Locations, Working Conventions, Cuts & Deferrals, Open Questions, Retrospective). Use the template's Capacity & Timeline table and carry the per-ticket Engine column through the wave tables unchanged.

In addition to the template sections, include an Execution Strategy block — the contract sprint-executor reads in mode: parallel (omit for serial-only sprints):

Mode: parallel | serial
Isolation: worktree
Max concurrency: {min(widest wave, 4)}
Worktree naming: ../.sdd-worktrees/sprint-{N}/{ticket-id} on branch exec/{ticket-id}, off sprint base sprint-{N}
See skills/task-executor/references/parallel-execution.md for the mechanism.

Workflow

Step 1 — Gather Inputs

Ask the user (or pull from workflow-config):

Sprint number, length, start date
Capacity (hours or engineer-days × engineer count)
Sprint goal
Target features / epics / tickets
Constraints

Step 2 — Read Backlog

listBacklog(epicIds, ["To Do","Backlog"]) via the tracker adapter:

All leaf tickets under the target epic(s) in To Do / Backlog
Their estimates, skill labels, exec:{engine} labels, requirement labels
Their descriptions for dependency hints

The exec:{engine} per ticket was assigned by the backlog-manager (Phase 2). Carry it through unchanged into the kickoff's Engine column — the sprint planner does not re-classify or override it (the user already reviewed it at the Phase-2 gate). The agent:{engine} label (agent:claude / agent:codex, from the ol-sdd-workflow multi-engine pattern) is accepted as an alias when no exec: label is present; if both are present and disagree, exec: wins. Only if a ticket has neither label, default it (complex → claude, simple → codex) and flag it back so the backlog stays the source of truth.

Read the corresponding documentation/specs/{feature}/ for:

Upstream→downstream task dependencies (from _Leverage: references and design.md)

Step 3 — Build Dependency Graph

For each ticket, identify which other tickets it depends on:

Explicit dependencies (in tasks.md or the tracker's blocked-by links, via getDependencies)
File-level dependencies (task B modifies a file created by task A)
Data-model dependencies (task B adds API calling a model from task A)

Topologically sort into waves:

Wave 1: no unmet dependencies
Wave N: depends only on waves 1..N-1

Step 4 — Fit to Capacity

Sum estimates per wave. Check:

Total ≤ capacity × (1 - headroom factor, default 15%)
Per-wave parallelism is plausible given engineer count
No single ticket exceeds one engineer's sprint capacity (split if so)

If scope exceeds capacity, propose cuts in order:

Deferrable non-critical tickets (flag non-critical:true or polish:true)
Latest-wave tickets
Smallest-requirement-coverage tickets

Never cut tickets that would leave a partial requirement.

Step 5 — Present Plan for Approval

Show the user:

Sprint goal
Scope (committed tickets, total hours)
Wave breakdown (with the per-ticket Engine column)
Execution strategy: mode (parallel/serial), worktree isolation, max concurrency, and the engine mix (n claude / m codex)
Any cuts or deferrals and their rationale
Risks and open questions

Gate: user approves before any sprint/cycle/iteration is created or tickets are moved.

Step 6 — Publish

On approval:

createSprint(name, dates) via the tracker adapter (JIRA: create or select a future sprint; Linear: pick the current/next cycle via list_cycles — cycles are auto-generated on the team cadence, not created via MCP; ADO: pick an existing iteration via work_list_team_iterations, or create one if your MCP exposes iteration creation else in the ADO UI; local: the sprint is the sprint-{N}-kickoff.md doc)
addToSprint(ids, sprint) — move/assign the selected tickets into the sprint/cycle/iteration (ADO: set System.IterationPath; local: set sprint: N in each ticket's frontmatter)
Write documentation/sprints/sprint-{N}-kickoff.md with the full plan
Publish the sprint overview page via the docs adapter (publishPage): Confluence under the project parent, Notion under 06 Sprints, or — for docs: local — the kickoff file itself is the page
Commit the kickoff file
Return to caller with sprint URL and kickoff file path

Mid-sprint Replanning

If invoked mid-sprint:

Read current sprint state (tickets in-progress, done, remaining)
Identify the trigger: blocker, scope change, capacity change, new priority
Present options: drop tickets, add tickets, re-order remaining waves
Apply approved changes to the tracker and update kickoff doc with a "Replan {date}" addendum — do not rewrite history

What This Skill Does NOT Do

Does not create tickets (that's backlog-manager / linear-backlog-manager / ado-backlog-manager / local-backlog-manager)
Does not execute the sprint (that's sprint-executor)
Does not author specs (that's feature-spec-author)
Does not estimate tickets ab initio — estimates come from tasks.md. If missing, flag them back to feature-spec-author.

References

prompts/coding/templates/sprint-plan-template.md
The kickoff doc follows the tech-lead delegation pattern (a Codex sprint-kickoff.md under the project's .codex/ directory)
skills/feature-spec-author/references/skill-routing.md
skills/feature-spec-author/references/docs-adapter.md — docs publish adapter (confluence | notion | ado-wiki | local)
skills/task-executor/references/tracker-{jira,linear,ado,local}.md — tracker adapter (listBacklog, createSprint, addToSprint)
skills/task-executor/references/parallel-execution.md — the worktree + subagent + engine mechanism the Execution Strategy block configures for sprint-executor

Feedback

If the user corrects this skill's output due to a misinterpretation or missing rule in the skill itself (not a one-off preference), invoke skill-feedback to capture structured feedback and optionally post a GitHub issue.

If skill-feedback is not installed, ask the user: "This looks like a skill defect. Would you like to install the skill-feedback skill to report it?" If the user declines, continue without feedback capture.