Agent Skill
2/7/2026

ringusing-pm-team

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.

L
lerianstudio
102GitHub Stars
1Views
npx skills add LerianStudio/ring

SKILL.md

Nameringusing-pm-team
Description12 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.

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
GateSkillOutput
0ring:pre-dev-researchresearch.md
1ring:pre-dev-prd-creationPRD.md
2ring:pre-dev-trd-creationTRD.md
3ring:pre-dev-task-breakdowntasks.md
4ring:pre-dev-delivery-planningdelivery-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
GateSkillOutput
0ring:pre-dev-researchresearch.md
1ring:pre-dev-prd-creationPRD.md
2ring:pre-dev-feature-mapfeature-map.md
3ring:pre-dev-trd-creationTRD.md
4ring:pre-dev-api-designAPI.md
5ring:pre-dev-data-modeldata-model.md
6ring:pre-dev-dependency-mapdependencies.md
7ring:pre-dev-task-breakdowntasks.md
8ring:pre-dev-subtask-creationsubtasks/
9ring:pre-dev-delivery-planningdelivery-roadmap.md

Planning time: 2.5-5 hours

Gate Summaries

GateSkillWhat It Does
0ring:pre-dev-researchParallel research: codebase patterns, best practices, framework docs
1ring:pre-dev-prd-creationBusiness requirements (WHAT/WHY), user stories, success metrics
2ring:pre-dev-feature-mapFeature relationships, dependencies, deployment order (Large only)
3ring:pre-dev-trd-creationTechnical architecture, technology-agnostic patterns
4ring:pre-dev-api-designAPI contracts, operations, error handling (Large only)
5ring:pre-dev-data-modelEntities, relationships, ownership (Large only)
6ring:pre-dev-dependency-mapExplicit tech choices, versions, licenses (Large only)
7ring:pre-dev-task-breakdownValue-driven tasks with success criteria
8ring:pre-dev-subtask-creationZero-context 2-5 min implementation steps (Large only)
9ring:pre-dev-delivery-planningDelivery roadmap with timeline, critical path, resource allocation (MANDATORY for both tracks)

Research Agents (Gate 0)

AgentFocus
ring:repo-research-analystCodebase patterns, docs/solutions/ knowledge base
ring:best-practices-researcherWeb search, Context7 for best practices
ring:framework-docs-researcherTech 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:

SkillCommandPurpose
ring:delivery-status-tracking/ring:delivery-statusEvidence-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

PluginUse For
ring:using-ring (default)ORCHESTRATOR principle for ALL tasks
ring:using-dev-teamDeveloper specialists for reviewing designs
ring:using-finops-teamRegulatory compliance planning
ring:using-tw-teamDocumentation 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

ConditionActionSeverity
No project scope or feature definedSTOP and report to userCRITICAL
User requests to skip all planningSTOP and report - planning is mandatoryCRITICAL
PRD/TRD already exists but user wants to start overSTOP and confirm user intentHIGH
Unclear whether Small or Large Track appliesSTOP and ask clarifying questionsMEDIUM
Missing prerequisite gate artifactsSTOP and complete previous gate firstHIGH

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

SeverityDefinitionExample
CRITICALBlocks all progress, fundamental violationAttempting to code without any planning artifacts
HIGHSignificant risk, must address before continuingSkipping a mandatory gate in the workflow
MEDIUMQuality impact, should address soonChoosing wrong track (Small vs Large)
LOWMinor issue, track for improvementIncomplete gate documentation

Pressure Resistance

User SaysYour 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

RationalizationWhy It's WRONGRequired Action
"This feature is simple, skip planning"Simple features still have requirements and architectureUse at minimum Small Track (5 gates)
"We already know what to build"Knowing ≠ documenting. Documentation prevents driftCreate PRD regardless of certainty
"Planning slows us down"Unplanned work slows down 10x more during implementationComplete all gates in sequence
"I can plan in my head while coding"Mental planning isn't verifiable or shareableCreate written artifacts for each gate
"Previous similar feature didn't need this"Each feature is independent. Past shortcuts don't justify current onesEvaluate each feature independently
"User is experienced, they know what they want"Experience doesn't replace systematic planningFollow 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)
Skills Info
Original Name:ringusing-pm-teamAuthor:lerianstudio