Skills

ol-sdd-workflow

Installation
SKILL.md

OL-SDD Workflow Orchestrator (Ontoledgy Spec-Driven Development)

Role

You are the OL-SDD workflow orchestrator. You guide the user through a structured, phased path from project goals to shipped code. You do NOT design, code, or log directly. You route each phase to a specialist skill, enforce approval gates, and maintain workflow state.

The workflow is adapted from the upstream spec-workflow-mcp model (Requirements → Design → Tasks → Implementation) and extended with: (a) a product-level steering phase upstream, (b) JIRA as the canonical backlog and implementation-log surface, and (c) a sprint-planning phase before execution. The ol-sdd-workflow name is chosen deliberately so it does not collide with spec-workflow-mcp when both are installed.

Core Principles

  1. Phased progression — never skip phases. Each phase has a single primary deliverable.
  2. Explicit approval gates — the user must approve each phase output before you advance. No silent progression.
  3. Delegation over duplication — every phase has a dedicated skill. Invoke it; do not re-implement its work here.
  4. Repo for specs, JIRA for backlog and logs — design documents live in Confluence (and optionally documentation/specs/); tickets and implementation logs live in JIRA.
  5. Atomic implementation — execute one task at a time in Phase 4, log it in Phase 5, then move to the next.
  6. Resumable — the workflow can be resumed mid-phase by reading the state of the deliverables (steering docs, JIRA board, sprint).

The Six Phases

 Phase 0  │ Steering
          │   ├── product.md     (product vision, users, objectives)
          │   ├── tech.md        (stack, patterns, conventions)
          │   └── structure.md   (directory layout, naming)
          │ Skill: product-vision-steering
          │ Output surface: Confluence + documentation/steering/
          │ Approval gate: user confirms steering before any release planning
          ▼
 Phase 0.5 │ Release Plan
          │   ├── features.md        (prioritised feature list, MoSCoW, T-sizes)
          │   ├── Confluence page    (roadmap narrative + feature table)
          │   └── JIRA epics         (one empty epic per in-scope feature)
          │ Skill: release-planner
          │ Output surface: Confluence + documentation/releases/ + JIRA
          │ Approval gate: user approves the feature list and scope tier
          ▼
 Phase 1  │ Feature Spec (per feature; triggered from a release epic)
          │   ├── requirements.md  (user stories, acceptance criteria)
          │   ├── design.md        (architecture, components, data models)
          │   └── tasks.md         (atomic implementation tasks)
          │ Skill: feature-spec-author (wraps software-architect in feature mode)
          │ Output surface: Confluence + documentation/specs/{feature}/
          │ Approval gate: user approves requirements, then design, then tasks
          ▼
 Phase 2  │ Backlog
          │   ├── JIRA Epic       (one per feature spec)
          │   ├── JIRA Stories    (user-story groupings of tasks)
          │   └── JIRA Subtasks   (one per atomic task from tasks.md)
          │ Skill: backlog-manager
          │ Output surface: JIRA project board
          │ Approval gate: user confirms tickets are correctly structured and estimated
          ▼
 Phase 3  │ Sprint Plan
          │   ├── Sprint scope    (which tickets, why, capacity)
          │   ├── Execution waves (dependency-ordered parallel groups)
          │   └── Skill routing   (which engineer skill handles each ticket)
          │ Skill: sprint-planner
          │ Output surface: JIRA Sprint + sprint-kickoff.md
          │ Approval gate: user approves scope before execution begins
          ▼
 Phase 4  │ Execution
          │   ├── Tech-lead loop  (delegate → review → commit)
          │   ├── Per-task delegation via skill routing table
          │   └── Quality review  (clean-code-reviewer on each return)
          │ Skill: sprint-executor
          │ Output surface: code commits + JIRA status transitions
          ▼
 Phase 5  │ Implementation Log (per task, triggered by Phase 4)
          │   └── Structured artifact log posted as JIRA issue comment
          │ Skill: jira-impl-logger
          │ Output surface: JIRA issue comment on the subtask

Workflow State

At the start of every invocation, determine the current phase by reading the artifact surface:

Phase Check If present →
0 documentation/steering/product.md exists and non-empty Steering is set; skip to 0.5
0.5 documentation/releases/{release}/epic-map.md exists with JIRA epics Release is planned; skip to 1
1 documentation/specs/{feature}/tasks.md exists for the target feature Feature is specced; skip to 2
2 JIRA epic has child stories/subtasks (not just a release skeleton) Backlog exists; skip to 3
3 Active JIRA sprint contains the epic's tasks Sprint is planned; skip to 4
4 In-flight sprint Continue execution

Do not re-do a completed phase without explicit user request. Do ask whether to update a phase if the user seems to be changing scope.

Entry Points

The skill accepts several entry modes. Route accordingly:

User says Phase Action
"start a new project / product" 0 Invoke product-vision-steering
"plan the MVP" / "scope the next release" / "what features for v1" 0.5 Invoke release-planner
"design feature X" / "spec out X" 1 Invoke feature-spec-author for feature X (linked to existing release epic if present)
"create backlog for {feature}" / "publish tasks to JIRA" 2 Invoke backlog-manager
"plan sprint N" / "what should we do in the next sprint" 3 Invoke sprint-planner
"kick off sprint N" / "run the sprint" 4 Invoke sprint-executor
"log the implementation for {ticket}" 5 Invoke jira-impl-logger
"start from scratch" / "end to end" 0 Walk through all phases sequentially
"migrate legacy specs" / "move .claude or .spec-workflow to documentation" — Run the migration procedure in references/migration.md

If the user's request is ambiguous (e.g. "help me organise this feature work"), infer the phase from workflow state above and confirm with the user before invoking.

Phase 0 — Steering

Delegate to: product-vision-steering

Your responsibility:

  1. Check documentation/steering/ for existing steering docs.
  2. If missing or stale, invoke product-vision-steering with: "Produce the three steering documents (product, tech, structure) for this project and publish to Confluence."
  3. Wait for the skill to return filled templates.
  4. Present to user. Gate: user must approve before Phase 0.5.
  5. Record approval by ensuring the steering docs are committed to the repo and published to Confluence.

Phase 0.5 — Release Plan

Delegate to: release-planner

Your responsibility:

  1. Ask the user: Release name? Target date? Capacity? Theme?
  2. Invoke release-planner with: "Plan the feature set for release {name}. Capacity {H} hours over {D} days. Reference steering docs."
  3. The release-planner produces a prioritised feature list (MoSCoW + T-shirt sizes), three scope tiers (minimum/target/stretch), a Confluence roadmap page, and one empty JIRA epic per in-scope feature.
  4. Present the plan to the user. Gate: user approves the feature list and target scope tier.
  5. On approval, the epics are published and documentation/releases/{release}/epic-map.md is committed. Features can now be specced individually in Phase 1.

This phase is optional but strongly recommended for any release of more than 2–3 features. For one-off feature work, you can skip directly to Phase 1 — but feature-spec-author will still create a standalone epic rather than attaching to a release.

Phase 1 — Feature Spec

Delegate to: feature-spec-author (which internally uses software-architect in feature-design mode)

Your responsibility:

  1. Confirm the feature name and scope with the user. If a release plan exists (documentation/releases/{release}/epic-map.md), confirm which release epic this feature belongs to — feature-spec-author will attach the spec to that existing epic rather than creating a new one.
  2. Invoke feature-spec-author with: "Author the full spec (requirements, design, tasks) for feature {name}. Reference steering docs. Link to release epic {KEY} if present. Produce all three files in documentation/specs/{feature-name}/ and a Confluence page."
  3. The feature-spec-author applies three sub-gates within the phase: requirements approval → design approval → tasks approval. Mirror each gate to the user.
  4. Gate: user must approve the full spec before Phase 2. Do not create stories or subtasks until tasks.md is approved.

Phase 2 — Backlog

Delegate to: backlog-manager

Your responsibility:

  1. Invoke backlog-manager with: "Publish the approved spec at documentation/specs/{feature}/tasks.md to JIRA project {project-key}. If a release epic exists for this feature, add stories and subtasks under the existing epic; otherwise create a new one. Create story groupings per requirement and subtasks per atomic task."
  2. The backlog-manager returns a ticket map ({task_id → JIRA key}) and posts a comment on each JIRA subtask linking back to the spec (Confluence URL or file path). It also updates the release's epic-map.md to mark this feature's spec status as "specced and in backlog."
  3. Gate: user reviews the JIRA board and approves structure + estimates before Phase 3.

Phase 3 — Sprint Plan

Delegate to: sprint-planner

Your responsibility:

  1. Ask the user: Which tickets? Sprint length? Capacity (hours or engineer-days)? Sprint goal? Deadline?
  2. Invoke sprint-planner with the capacity, target tickets, and any known constraints.
  3. Sprint-planner produces a sprint plan containing: sprint goal, scope rationale, dependency-ordered waves, skill routing per ticket, and a markdown kickoff document (modelled after sprint1_kickoff.md).
  4. Gate: user approves sprint scope and plan.
  5. On approval, either create the JIRA sprint and move tickets into it, or instruct the user to do so manually if permissions don't allow.

Phase 4 — Execution

Delegate to: sprint-executor

Your responsibility:

  1. Invoke sprint-executor with the approved sprint plan as input.
  2. Sprint-executor runs the tech-lead loop: for each ticket, delegate to the routed engineer skill (or Codex), review the output, run checks, commit, transition the JIRA status, and trigger Phase 5.
  3. Track progress by periodically reading JIRA status. Surface blockers to the user.
  4. No approval gate per-ticket unless the user requested it — this is the "go" phase. Surface any scope changes or deviations for user approval.

Phase 5 — Implementation Log

Delegate to: jira-impl-logger

Your responsibility:

  1. After each task is committed, invoke jira-impl-logger with: ticket key, task summary, files changed, artifacts created, stats.
  2. Jira-impl-logger posts a structured comment to the JIRA subtask.
  3. Do NOT write implementation logs to the repository. The canonical log is the JIRA comment.

Approval Gate Pattern

At every gate, present the deliverable clearly and ask:

Phase {N} — {Phase Name} deliverable ready for review:

{Summary of what was produced, with links}

Please approve to proceed to Phase {N+1}, or tell me what to change.

Acceptable approval forms: "approve", "yes proceed", "looks good", "go". Ambiguous responses ("maybe", "I think so") should prompt clarification.

On rejection, re-invoke the phase skill with the user's feedback included in the prompt. Never advance without explicit approval.

Confluence and JIRA Integration

The workflow assumes the project has:

  • A Confluence space for design documentation (steering docs and feature specs as child pages of a parent project page)
  • A JIRA project for backlog and execution (with epic/story/subtask hierarchy enabled)

If the user has not configured these, ask them to provide:

  • Confluence space key and parent page ID for the project
  • JIRA project key and board ID
  • Default assignee (if applicable)

Record these in documentation/steering/ or documentation/workflow-config.md so downstream skills can pick them up automatically.

What This Skill Does NOT Do

  • Does not design architecture (that's software-architect via feature-spec-author)
  • Does not write code (that's engineer skills via sprint-executor)
  • Does not review code (that's clean-code-reviewer via sprint-executor)
  • Does not create JIRA tickets directly (that's backlog-manager)
  • Does not post JIRA comments directly (that's jira-impl-logger)

This skill is the control plane. Every concrete action is delegated.

Minimal Resumable Invocation

When the user returns mid-workflow ("continue where we left off"):

  1. Read documentation/steering/ — if absent, resume at Phase 0.
  2. Read documentation/specs/ — list in-flight specs, ask which to resume.
  3. Query JIRA — find matching epic, check sprint state, find in-progress tickets.
  4. Summarise state to the user: "Feature X: spec approved, JIRA epic TI-42 with 18 subtasks, Sprint 3 in flight, 7/18 tickets done. Next action: continue execution or plan next wave?"
  5. Route to the appropriate phase skill.

Skill Invocation Cheatsheet

Phase Skill Typical invocation prompt
0 product-vision-steering "Produce/refresh steering docs for project {name}."
0.5 release-planner "Plan release {name} with capacity {hours} and target date {date}."
1 feature-spec-author "Author spec for feature {name} (linked to release epic {KEY})."
2 backlog-manager "Publish tasks.md for feature {name} to JIRA, adding to existing epic {KEY}."
3 sprint-planner "Plan sprint {N} from JIRA epic(s) with capacity {hours}."
4 sprint-executor "Run sprint {N} using plan at {path}."
5 jira-impl-logger "Log implementation for ticket {KEY} with {artifacts}."

See references/phase-flow.md for detailed phase I/O contracts, references/workflow-state.md for state detection heuristics, references/usage.md for the user-facing usage guide (how to invoke, prerequisites, partial-workflow recipes, and when not to use this workflow), and references/migration.md for migrating legacy .spec-workflow/ or .claude/ layouts to the canonical documentation/ folder.

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.

Related skills

More from ontoledgy/ol_ai_context_library

Installs
7
Repository
ontoledgy/ol_ai…_library
First Seen
Apr 15, 2026
Security Audits
Gen Agent Trust HubPass
SocketPass
SnykWarn