# Lerianstudio Ring Using Pm Team

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

- Skill: `tomevault-io/lerianstudio-ring-using-pm-team` (Agent Skill, multi-file: 2 files)
- Install (CLI): `npx skillmds@latest add tomevault-io/lerianstudio-ring-using-pm-team`
- Raw SKILL.md: https://api.skillmd.com/api/skills/tomevault-io/lerianstudio-ring-using-pm-team/raw
- Safety review: pending (external: skill-scanner PASS, skillspector CAUTION)
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Productivity
- Author: tomevault-io (https://skillmd.com/u/tomevault-io)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/tomevault-io/lerianstudio-ring-using-pm-team

---


# 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, .json |

**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, .json |

**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."

---

## Standards Loading (MANDATORY)

This skill is an orchestration/navigation skill for the pm-team plugin. It does NOT require WebFetch of language-specific standards.

**However**, when dispatching implementation agents (e.g., `ring:backend-engineer-golang`), those agents MUST load their respective standards via WebFetch before proceeding.

---

## Blocker Criteria - STOP and Report

| Condition | Action | Severity |
|-----------|--------|----------|
| No project scope or feature defined | STOP and report to user | CRITICAL |
| User requests to skip all planning | STOP and report - planning is mandatory | CRITICAL |
| PRD/TRD already exists but user wants to start over | STOP and confirm user intent | HIGH |
| Unclear whether Small or Large Track applies | STOP and ask clarifying questions | MEDIUM |
| Missing prerequisite gate artifacts | STOP and complete previous gate first | HIGH |

---

## Cannot Be Overridden

These requirements are NON-NEGOTIABLE:

- MUST use ORCHESTRATOR principle - dispatch skills, don't plan manually
- MUST complete gates in sequence - CANNOT skip gates
- MUST validate gate outputs before proceeding to next gate
- MUST create planning artifacts before implementation
- MUST use Large Track when feature exceeds Small Track criteria
- CANNOT proceed to implementation without completing mandatory gates

---

## Severity Calibration

| Severity | Definition | Example |
|----------|------------|---------|
| **CRITICAL** | Blocks all progress, fundamental violation | Attempting to code without any planning artifacts |
| **HIGH** | Significant risk, must address before continuing | Skipping a mandatory gate in the workflow |
| **MEDIUM** | Quality impact, should address soon | Choosing wrong track (Small vs Large) |
| **LOW** | Minor issue, track for improvement | Incomplete gate documentation |

---

## Pressure Resistance

| User Says | Your Response |
|-----------|---------------|
| "Skip planning, just start coding" | "Cannot proceed. Planning prevents 10x rework cost. I'll start with ring:pre-dev-research to gather context first." |
| "We don't need PRD, requirements are obvious" | "Cannot skip PRD. 'Obvious' requirements cause scope creep. I'll create a focused PRD documenting what we're building and why." |
| "Use Small Track, we're in a hurry" | "Cannot compromise on track selection. If feature meets Large Track criteria, I MUST use Large Track. Shortcuts now = rework later." |
| "Skip research, we know the codebase" | "Cannot skip Gate 0. Research validates assumptions and finds existing patterns. Takes 30 mins, saves hours of reinvention." |
| "Just give me tasks, skip the architecture" | "Cannot skip TRD. Architecture decisions affect all tasks. I'll create TRD first to ensure tasks are correctly scoped." |

---

## Anti-Rationalization

| Rationalization | Why It's WRONG | Required Action |
|-----------------|----------------|-----------------|
| "This feature is simple, skip planning" | Simple features still have requirements and architecture | **Use at minimum Small Track (5 gates)** |
| "We already know what to build" | Knowing ≠ documenting. Documentation prevents drift | **Create PRD regardless of certainty** |
| "Planning slows us down" | Unplanned work slows down 10x more during implementation | **Complete all gates in sequence** |
| "I can plan in my head while coding" | Mental planning isn't verifiable or shareable | **Create written artifacts for each gate** |
| "Previous similar feature didn't need this" | Each feature is independent. Past shortcuts don't justify current ones | **Evaluate each feature independently** |
| "User is experienced, they know what they want" | Experience doesn't replace systematic planning | **Follow the workflow regardless** |

---

## When This Skill Is Not Needed

- Quick exploratory work where `ring:brainstorming` suffices
- Bug fix with known solution requiring no design changes
- Trivial changes that take less than 1 hour
- Documentation-only updates
- Configuration changes with no code impact
- Direct implementation after planning is already complete (use `ring:executing-plans` or `ring:dev-cycle` instead)

---
> Converted and distributed by [TomeVault](https://tomevault.io/claim/lerianstudio) — claim your Tome and manage your conversions.
<!-- tomevault:4.0:skill_md:2026-04-11 -->

