home / skills / lerianstudio / ring / using-pm-team

using-pm-team skill

/pm-team/skills/using-pm-team

This skill guides you through structured pre-dev planning using Ring gates to ensure clear requirements, architecture, and delivery planning before coding.

npx playbooks add skill lerianstudio/ring --skill using-pm-team

Review the files below or copy the command above to add this skill to your agents.

Files (1)
SKILL.md
8.2 KB
---
name: ring:using-pm-team
description: |
  12 pre-dev workflow skills + 4 research agents organized into Small Track (4 gates, <2 days) and
  Large Track (9 gates, 2+ days) for systematic feature planning with research-first approach.

trigger: |
  - Starting any feature implementation
  - Need systematic planning before coding
  - User requests "plan a feature"

skip_when: |
  - Quick exploratory work → ring:brainstorming may suffice
  - Bug fix with known solution → direct implementation
  - Trivial change (<1 hour) → skip formal planning
---

# Using Ring Team-Product: Pre-Dev Workflow & Delivery Tracking

The ring-pm-team plugin provides 12 pre-development planning skills and 4 research agents. Use them via `Skill tool: "ring:gate-name"` or via slash commands.

**Remember:** Follow the **ORCHESTRATOR principle** from `ring:using-ring`. Dispatch pre-dev workflow to handle planning; plan thoroughly before coding.

## Pre-Dev Philosophy

**Before you code, you plan. Every time.**

Pre-dev workflow ensures:

- ✅ Requirements are clear (WHAT/WHY)
- ✅ Architecture is sound (HOW)
- ✅ APIs are contracts (boundaries)
- ✅ Data models are explicit (entities)
- ✅ Dependencies are known (tech choices)
- ✅ Tasks are atomic (2-5 min each)
- ✅ Implementation is execution, not design

## Two Tracks: Choose Your Path

### Small Track (5 Gates) – <2 Day Features

**Use when ALL criteria met:**

- ✅ Implementation <2 days
- ✅ No new external dependencies
- ✅ No new data models
- ✅ No multi-service integration
- ✅ Uses existing architecture
- ✅ Single developer

| Gate | Skill                       | Output      |
| ---- | --------------------------- | ----------- |
| 0    | ring:pre-dev-research       | research.md |
| 1    | ring:pre-dev-prd-creation   | PRD.md      |
| 2    | ring:pre-dev-trd-creation   | TRD.md      |
| 3    | ring:pre-dev-task-breakdown | tasks.md    |
| 4    | ring:pre-dev-delivery-planning | delivery-roadmap.md |

**Planning time:** 60-90 minutes

### Large Track (10 Gates) – ≥2 Day Features

**Use when ANY criteria met:**

- ❌ Implementation ≥2 days
- ❌ New external dependencies
- ❌ New data models/entities
- ❌ Multi-service integration
- ❌ New architecture patterns
- ❌ Team collaboration needed

| Gate | Skill                         | Output          |
| ---- | ----------------------------- | --------------- |
| 0    | ring:pre-dev-research         | research.md     |
| 1    | ring:pre-dev-prd-creation     | PRD.md          |
| 2    | ring:pre-dev-feature-map      | feature-map.md  |
| 3    | ring:pre-dev-trd-creation     | TRD.md          |
| 4    | ring:pre-dev-api-design       | API.md          |
| 5    | ring:pre-dev-data-model       | data-model.md   |
| 6    | ring:pre-dev-dependency-map   | dependencies.md |
| 7    | ring:pre-dev-task-breakdown   | tasks.md        |
| 8    | ring:pre-dev-subtask-creation | subtasks/       |
| 9    | ring:pre-dev-delivery-planning | delivery-roadmap.md |

**Planning time:** 2.5-5 hours

## Gate Summaries

| Gate | Skill                         | What It Does                                                         |
| ---- | ----------------------------- | -------------------------------------------------------------------- |
| 0    | ring:pre-dev-research         | Parallel research: codebase patterns, best practices, framework docs |
| 1    | ring:pre-dev-prd-creation     | Business requirements (WHAT/WHY), user stories, success metrics      |
| 2    | ring:pre-dev-feature-map      | Feature relationships, dependencies, deployment order (Large only)   |
| 3    | ring:pre-dev-trd-creation     | Technical architecture, technology-agnostic patterns                 |
| 4    | ring:pre-dev-api-design       | API contracts, operations, error handling (Large only)               |
| 5    | ring:pre-dev-data-model       | Entities, relationships, ownership (Large only)                      |
| 6    | ring:pre-dev-dependency-map   | Explicit tech choices, versions, licenses (Large only)               |
| 7    | ring:pre-dev-task-breakdown   | Value-driven tasks with success criteria                             |
| 8    | ring:pre-dev-subtask-creation | Zero-context 2-5 min implementation steps (Large only)               |
| 9    | ring:pre-dev-delivery-planning | Delivery roadmap with timeline, critical path, resource allocation (MANDATORY for both tracks) |

## Research Agents (Gate 0)

| Agent                            | Focus                                             |
| -------------------------------- | ------------------------------------------------- |
| `ring:repo-research-analyst`     | Codebase patterns, docs/solutions/ knowledge base |
| `ring:best-practices-researcher` | Web search, Context7 for best practices           |
| `ring:framework-docs-researcher` | Tech stack versions, official patterns            |

**Research Modes:**

- **greenfield**: Web research primary (new capability)
- **modification**: Codebase research primary (extending existing)
- **integration**: All agents equally weighted (connecting systems)

## Delivery Status Tracking (Post-Planning)

After planning and during execution, track progress:

| Skill                           | Command                 | Purpose                                                   |
| ------------------------------- | ----------------------- | --------------------------------------------------------- |
| `ring:delivery-status-tracking` | `/ring:delivery-status` | Evidence-based progress analysis against delivery roadmap |

**What it does:**

- Scans repository (ALL branches, commits, PRs, releases)
- Matches work to tasks (pattern + semantic analysis)
- Calculates % completion via specialized agents
- Identifies delays, blockers, critical path issues
- Extracts insights (velocity, quality trends, patterns)

**When to use:**

- Weekly checkpoints during execution
- Sprint/cycle end retrospectives
- Before stakeholder status meetings
- When roadmap shows signs of deviation

**Output:** `docs/pre-dev/{feature}/delivery-status-{date}.md`

## Using Pre-Dev Workflow

### Via Slash Commands

```
/ring:pre-dev-feature logout-button    # Small track (5 gates)
/ring:pre-dev-full payment-system      # Large track (10 gates)
```

### Via Skills (Manual)

```
Skill tool: "ring:pre-dev-prd-creation"
(Review output)
Skill tool: "ring:pre-dev-trd-creation"
(Review output)
```

## Output Structure

```
docs/pre-dev/{feature}/
├── research.md        # Gate 0
├── prd.md             # Gate 1
├── feature-map.md     # Gate 2 (large only)
├── trd.md             # Gate 3
├── api-design.md      # Gate 4 (large only)
├── data-model.md      # Gate 5 (large only)
├── dependency-map.md  # Gate 6 (large only)
├── tasks.md           # Gate 7
└── subtasks/          # Gate 8 (large only)
```

## Decision: Small or Large Track?

**When in doubt: Use Large Track.** Better to over-plan than discover mid-implementation that feature is larger.

**You can switch:** If Small Track feature grows, pause and complete Large Track gates.

## Integration with Other Plugins

| Plugin                    | Use For                                     |
| ------------------------- | ------------------------------------------- |
| ring:using-ring (default) | ORCHESTRATOR principle for ALL tasks        |
| ring:using-dev-team       | Developer specialists for reviewing designs |
| ring:using-finops-team    | Regulatory compliance planning              |
| ring:using-tw-team        | Documentation for features                  |

**Combined with:**

- `ring:execute-plan` – Run tasks in batches
- `ring:write-plan` – Generate plan from scratch
- `*-engineer` – Specialist review of design
- `ring:requesting-code-review` – Post-implementation review

## ORCHESTRATOR Principle

- **You're the orchestrator** – Dispatch pre-dev skills, don't plan manually
- **Don't skip gates** – Each gate adds clarity
- **Don't code without planning** – Plan first, code second
- **Use agents for specialist review** – Dispatch engineers to review TRD

### Good (ORCHESTRATOR):

> "I need to plan payment system. Let me run /ring:pre-dev-full, then dispatch ring:backend-engineer-golang to review the architecture."

### Bad (OPERATOR):

> "I'll start coding and plan as I go."

Overview

This skill provides a mandatory, research-first pre-development workflow with 12 planning skills and 4 research agents organized into Small and Large tracks. It enforces engineering quality gates, produces standard artifacts (research, PRD, TRD, APIs, data models, tasks, delivery roadmap), and integrates delivery-status tracking. Use it to guarantee clear requirements, explicit architecture, and evidence-based progress during feature delivery.

How this skill works

Run the skill per-feature either via slash commands or by invoking individual gate skills. Gate 0 runs parallel research agents (repo patterns, best practices, framework docs); subsequent gates generate PRD, TRD, API contracts, data models, task breakdowns, subtasks, and a delivery roadmap. Post-planning, the delivery-status tracker scans repository activity and maps work to tasks to calculate progress, surface blockers, and produce dated delivery-status documents.

When to use it

  • Before writing any production code for a new feature or change
  • For small features (<2 days) that meet all small-track criteria
  • For complex or uncertain work (>=2 days, new deps, new data models, multi-service)
  • When a feature touches architecture, APIs, or cross-team boundaries
  • At sprint checkpoints, pre-release reviews, or stakeholder status meetings

Best practices

  • Default to the Large Track if unsure—over-planning is safer than rework
  • Run Gate 0 research agents in the appropriate mode (greenfield/modification/integration)
  • Stop coding until required gates produce PRD/TRD and delivery roadmap
  • Create zero-context 2–5 minute subtasks for all implementable work in Large Track
  • Use the delivery-status tracker weekly to validate roadmap progress and catch regressions

Example use cases

  • Plan a one-day UI tweak that uses existing APIs (Small Track, 5 gates)
  • Design and coordinate a new payment integration requiring data models and cross-service changes (Large Track, 10 gates)
  • Extend an existing service with a new API and require architect review and subtasks
  • Run weekly delivery-status scans to prepare evidence-based stakeholder reports
  • Convert a growing Small Track feature into the Large Track when scope expands

FAQ

How do I choose Small vs Large Track?

Use Small only when all small-track criteria are met. If any large-track condition applies, use Large. When in doubt, pick Large.

Can I run gates individually?

Yes. You can invoke individual gate skills or run the full track via the slash commands to produce the standard artifacts.