Ring Pre Dev Full | Skills Pool
Ring Pre Dev Full Complete 10-gate pre-dev workflow for large features (>=2 days).
Orchestrates topology discovery, research, PRD, feature map, design validation,
TRD, API design, data model, dependency map, task breakdown, subtask creation,
and delivery planning in a sequential gated process with human approval at each gate.
LerianStudio 174 Sterne 06.04.2026 Beruf Kategorien Projektmanagement Full Track Pre-Dev Workflow (10 Gates)
I'm running the Full Track pre-development workflow (10 gates) for your feature.
This track is for features that have ANY of:
Take >=2 days to implement
Add new external dependencies (APIs, databases, libraries)
Create new data models or entities
Require multi-service integration
Use new architecture patterns
Require team collaboration
If feature is simple (<2 days, existing patterns), use /ring:pre-dev-feature instead.
Document Organization
All artifacts will be saved to: docs/pre-dev/<feature-name>/
First, let me ask you about your feature:
Use the AskUserQuestion tool to gather:
Question 1: "What is the name of your feature?"
Header: "Feature Name"
This will be used for the directory name
Schnellinstallation
Ring Pre Dev Full npx skills add LerianStudio/ring
Sterne 174
Aktualisiert 06.04.2026
Beruf
Use kebab-case (e.g., "auth-system", "payment-processing", "file-upload")
Topology Discovery (MANDATORY) This step discovers the project structure (fullstack/backend-only/frontend-only), repository organization (single-repo/monorepo/multi-repo), module paths, and UI configuration. The complete algorithm with all 11 questions and auto-detection logic is in the shared pattern.
Store the result as TopologyConfig for use in all subsequent gates.
After topology discovery, also gather the following feature-specific inputs:
Question 2 (CONDITIONAL): "Does this feature require authentication or authorization?"
Auto-detection: Before asking, check if go.mod contains github.com/LerianStudio/lib-auth
If found → Skip this question. Auth is already integrated at project level.
If not found → Ask this question (new project or project without auth)
Header: "Auth Requirements"
Options:
"None" - No authentication needed
"User authentication only" - Users must log in but no permission checks
"User + permissions" - Full user auth with role-based access control
"Service-to-service auth" - Machine-to-machine authentication only
"Full (user + service-to-service)" - Both user and service auth
Note: For Go services requiring auth, reference golang.md → Access Manager Integration section during TRD creation (Gate 3) and Dependency Map (Gate 6)
Question 3 (CONDITIONAL): "Is this a licensed product/plugin?"
Auto-detection: Before asking, check if go.mod contains github.com/LerianStudio/lib-license-go
If found → Skip this question. Licensing is already integrated at project level.
If not found → Ask this question (new project or project without licensing)
Header: "License Requirements"
Options:
"No" - Not a licensed product (open source, internal tool, etc.)
"Yes" - Licensed product that requires License Manager integration
Note: For Go services requiring license validation, reference golang.md → License Manager Integration section during TRD creation (Gate 3) and Dependency Map (Gate 6)
Why auto-detection? Access Manager and License Manager are project-level infrastructure decisions, not feature-level. Once integrated, all features in the project inherit them.
Question 4 (MANDATORY): "Does this feature include user interface (UI)?"
Header: "Has UI?"
Options:
"Yes" - Feature includes pages, screens, forms, dashboards, or any visual interface
"No" - Backend-only feature (API, service, CLI, etc.)
IMPORTANT: This question MUST always be asked. Do NOT assume based on feature description keywords.
Why mandatory? Keyword detection is unreliable. Explicitly asking prevents skipping UI configuration.
Question 5 (MANDATORY if Q4=Yes): "Which UI component library should be used?"
Trigger: Only ask if Q4 = "Yes"
Auto-detection: Before asking, check package.json for existing UI libraries:
@radix-ui/* packages → shadcn/ui detected
@chakra-ui/* packages → Chakra UI detected
@headlessui/* packages → Headless UI detected
@mui/* or @material-ui/* → Material UI detected
If library found → Still ask, but pre-select detected option and display: "Detected: [library] from package.json"
If not found → Ask without pre-selection
Header: "UI Library"
Options:
"shadcn/ui + Radix (Recommended)" - TailwindCSS-based, highly customizable, copy-paste components
"Chakra UI" - Full component library with built-in theming system
"Headless UI" - Minimal unstyled primitives, Tailwind-native
"Material UI" - Google's Material Design components
"Ant Design" - Enterprise-grade React components
"Custom components only" - Build from scratch, no external UI library
Usage: This choice informs wireframes (component names), TRD (dependencies), and implementation tasks
CANNOT be skipped: Even with auto-detection, user must confirm the choice
Question 6 (MANDATORY if Q4=Yes): "Which styling approach should be used?"
Trigger: Only ask if Q4 = "Yes"
Auto-detection: Before asking, check package.json for existing styling:
tailwindcss → TailwindCSS detected
styled-components → Styled Components detected
@emotion/* → Emotion detected
sass or node-sass → Sass/SCSS detected
If styling found → Still ask, but pre-select detected option and display: "Detected: [styling] from package.json"
If not found → Ask without pre-selection
Header: "Styling"
Options:
"TailwindCSS (Recommended)" - Utility-first CSS, excellent for design systems
"CSS Modules" - Scoped CSS files, traditional approach
"Styled Components" - CSS-in-JS with tagged template literals
"Sass/SCSS" - CSS preprocessor with variables and nesting
"Vanilla CSS" - Plain CSS without preprocessors
Usage: This choice informs wireframes (class naming), component implementation, and code review criteria
CANNOT be skipped: Even with auto-detection, user must confirm the choice
Question 7 (MANDATORY if Q4=Yes AND new project): "What is the target accessibility level?"
Trigger: Only ask if Q4 = "Yes" AND (no existing package.json OR no existing a11y config)
Auto-detection: Check for existing accessibility configuration:
@axe-core/* in package.json → Skip, note "Detected: accessibility testing configured"
pa11y in package.json → Skip, note "Detected: accessibility testing configured"
.lighthouserc.* file exists → Skip, note "Detected: Lighthouse CI configured"
If config found → Skip question, use detected level
If not found → Ask question
Header: "Accessibility"
Options:
"WCAG 2.1 AA (Recommended)" - Standard compliance, 4.5:1 contrast for normal text, 3:1 for large text
"WCAG 2.1 AAA" - Enhanced compliance, 7:1 contrast for normal text, 4.5:1 for large text
"Basic" - Semantic HTML only, no strict contrast requirements
Usage: Informs contrast validation in design-system.md, component requirements, code review criteria
Why this matters: Accessibility requirements affect color choices, component design, and testing requirements
Question 8 (MANDATORY if Q4=Yes AND new project): "Does the application need dark mode support?"
Trigger: Only ask if Q4 = "Yes" AND (no existing package.json OR no dark mode detected)
Auto-detection: Check for existing dark mode:
dark: classes in existing components → Skip, note "Detected: dark mode classes in use"
CSS variables with .dark class in globals.css → Skip, note "Detected: dark mode CSS variables"
Theme provider (next-themes, etc.) in layout → Skip, note "Detected: theme provider configured"
If dark mode found → Skip question, note existing configuration
If not found → Ask question
Header: "Dark Mode"
Options:
"Light + Dark (Recommended)" - Full theme support with system preference detection
"Light only" - Single light theme, no dark mode
"Dark only" - Single dark theme (for specific apps like developer tools)
Usage: Informs design-system.md color tokens, CSS architecture, component variants
Why this matters: Dark mode requires dual color palettes and affects contrast calculations
Question 9 (MANDATORY if Q4=Yes AND new project): "What is the primary brand color?"
Trigger: Only ask if Q4 = "Yes" AND (no existing package.json OR no brand colors detected)
Auto-detection: Check for existing brand colors:
tailwind.config.* with custom primary color → Skip, note "Detected: primary color in Tailwind config"
CSS variable --primary or --color-primary in globals.css → Skip, note "Detected: primary color CSS variable"
If brand color found → Skip question, note existing configuration
If not found → Ask question
Header: "Brand Color"
Options:
"Blue" - Professional, trustworthy (finance, enterprise, healthcare)
"Purple" - Creative, innovative (tech startups, design tools)
"Green" - Growth, sustainability (fintech, eco, wellness)
"Orange" - Energy, action (marketplaces, social, food)
"Custom (specify hex)" - Custom brand color (user provides hex code)
Usage: Informs design-system.md primary palette, derived colors, semantic mappings
Why this matters: Brand color defines the primary visual identity and derived color palette
Question 10 (MANDATORY if Q4=Yes AND new project): "What typography style fits the brand?"
Trigger: Only ask if Q4 = "Yes" AND (no existing package.json OR no custom fonts detected)
Auto-detection: Check for existing typography:
Font imports in layout.tsx or _app.tsx → Skip, note "Detected: [font] configured"
@fontsource/* packages in package.json → Skip, note "Detected: [font] in dependencies"
Google Fonts in next/font/google imports → Skip, note "Detected: [font] from Google Fonts"
If fonts found → Skip question, note existing configuration
If not found → Ask question
Header: "Typography"
Options:
"Modern Tech (Geist) - Recommended" - Clean, technical feel, excellent for SaaS/developer tools
"Contemporary (Satoshi)" - Friendly, approachable, good for consumer apps
"Editorial (Cabinet Grotesk)" - Bold, statement-making, good for marketing/media
"Professional (General Sans)" - Neutral, enterprise-grade, good for B2B
Usage: Informs design-system.md typography scale, font loading strategy, component styles
Why this matters: Typography affects readability, brand perception, and page load performance
Note: Avoid generic fonts (Inter, Roboto, Arial) per frontend standards
UI Configuration Summary: After Q4-Q11 (where Q11 comes from topology discovery's dynamic data question), display:
UI Configuration:
- Has UI: Yes/No
- UI Library: [choice] (confirmed by user)
- Styling: [choice] (confirmed by user)
- Accessibility: [WCAG AA | WCAG AAA | Basic] (for new projects)
- Dark Mode: [Light + Dark | Light only | Dark only] (for new projects)
- Brand Color: [Blue | Purple | Green | Orange | #hex] (for new projects)
- Typography: [Geist | Satoshi | Cabinet Grotesk | General Sans] (for new projects)
- API Pattern: [bff | none] (bff if dynamic data, none if static)
GATE BLOCKER: If Q4 = "Yes" but Q5 or Q6 were not answered, DO NOT proceed to Gate 0. Return and ask the missing questions. For new projects with UI, Q7-Q10 are also required. If scope = "Fullstack" or "Frontend-only" with UI, the dynamic data question (from topology discovery) must be answered.
This configuration is passed to all subsequent gates and used by:
Gate 0 (Research): product-designer searches for patterns in the chosen library
Gate 1 (PRD/UX): criteria reference available components
Gate 2 (Feature Map/UX Design): wireframes use component names from the library
Gate 3 (TRD): architecture considers UI library constraints
Gate 6 (Dependency Map): lists UI library and styling framework as dependencies
Gate 7 (Tasks): implementation tasks reference specific components
After getting the feature name (and auth/license/UI requirements if applicable), create the directory structure and run the 10-gate workflow:
mkdir -p docs/pre-dev/<feature-name>
Gate 0: Research Phase Skill: ring:pre-dev-research
Determine research mode by asking user or inferring from context:
greenfield : New capability, no existing patterns
modification : Extending existing functionality
integration : Connecting external systems
Dispatch 4 research agents in PARALLEL:
ring:repo-research-analyst (codebase patterns, file:line refs)
ring:best-practices-researcher (web search, Context7)
ring:framework-docs-researcher (tech stack, versions)
ring:product-designer (UX research, user problem validation, mode: ux-research)
Aggregate findings into research document
Save to: docs/pre-dev/<feature-name>/research.md
Run Gate 0 validation checklist
Get human approval before proceeding
Gate 1: PRD Creation + UX Validation Skill: ring:pre-dev-prd-creation
Ask user to describe the feature (problem, users, business value)
Create PRD document with:
Problem statement
User stories
Acceptance criteria
Success metrics
Out of scope
Save to: docs/pre-dev/<feature-name>/prd.md
Run Gate 1 validation checklist
Dispatch product-designer for UX validation (mode: ux-validation)
Save to: docs/pre-dev/<feature-name>/ux-criteria.md
Get human approval before proceeding
Gate 2: Feature Map Creation + UX Design Skill: ring:pre-dev-feature-map
Load PRD from docs/pre-dev/<feature-name>/prd.md
Load ux-criteria.md from docs/pre-dev/<feature-name>/ux-criteria.md
Create feature map document with:
Feature relationships and dependencies
Domain boundaries
Integration points
Scope visualization
Save to: docs/pre-dev/<feature-name>/feature-map.md
Run Gate 2 validation checklist
Dispatch product-designer for UX design (mode: ux-design)
Save to: docs/pre-dev/<feature-name>/user-flows.md
Save to: docs/pre-dev/<feature-name>/wireframes/ (directory with YAML specs)
Get human approval before proceeding
Gate 2.5: Design Validation (if feature has UI) Skill: ring:pre-dev-design-validation
Purpose: Verify UX specifications are complete before investing in technical architecture.
HARD GATE: This Gate CANNOT Be Skipped for UI Features If Q4 = "Yes" (feature has UI), this gate is MANDATORY. No exceptions.
Skip condition: ONLY if feature has NO UI (Q4 = "No", backend-only)
Load and validate all design artifacts:
ux-criteria.md
wireframes/*.yaml
wireframes/user-flows.md (or user-flows.md)
Run systematic validation checklist:
Section 1: Wireframe Completeness (CRITICAL)
Section 2: UI States Coverage (CRITICAL)
Section 3: Accessibility Specifications
Section 4: Responsive Specifications
Section 5: User Flow Completeness
Section 6: Content Specifications
Save report to: docs/pre-dev/<feature-name>/design-validation.md
Evaluate verdict:
DESIGN VALIDATED: Proceed to Gate 3
CRITICAL GAPS: STOP. Return to Gate 2 to fix gaps. CANNOT proceed.
MINOR GAPS: Ask user - proceed with documented risk or fix first?
Get human approval before proceeding
BLOCKER: Gate 3 (TRD) Will REFUSE to Start Without This Gate 3 (TRD) checks for design-validation.md before proceeding.
If feature has UI AND design-validation.md is missing → TRD will STOP
If design-validation.md exists but verdict is not VALIDATED → TRD will STOP
Why this gate exists: Incomplete design specs cause 10x implementation rework. Validating now saves time later.
Anti-Rationalization Excuse Reality "We're behind schedule, skip validation" Skipping causes 10x rework. You'll be MORE behind. "Design looks complete to me" "Looks complete" ≠ validated. Run systematic check. "We can validate later" TRD depends on complete design. Cannot proceed without. "Just this once" No exceptions. Every UI feature needs validation.
Gate 3: TRD Creation Skill: ring:pre-dev-trd-creation
Load PRD from docs/pre-dev/<feature-name>/prd.md
Load Feature Map from docs/pre-dev/<feature-name>/feature-map.md
Map Feature Map domains to architectural components
Create TRD document with:
Architecture style (pattern names, not products)
Component design (technology-agnostic)
Data architecture (conceptual)
Integration patterns
Security architecture
NO specific tech products
Save to: docs/pre-dev/<feature-name>/trd.md
Run Gate 3 validation checklist
Get human approval before proceeding
Gate 4: API Design Skill: ring:pre-dev-api-design
Phase 0: Ask user for API naming standards (URL/file/none)
If provided: Load and extract to api-standards-ref.md
Load previous artifacts (PRD, Feature Map, TRD)
Create API design document with:
Component contracts and interfaces
Request/response formats (using standards if available)
Error handling patterns
Integration specifications
Save to: docs/pre-dev/<feature-name>/api-design.md
Run Gate 4 validation checklist
Get human approval before proceeding
Gate 5: Data Model Skill: ring:pre-dev-data-model
Phase 0: Determine database field naming strategy
Check if Gate 4 API standards exist
Ask user: Convert to snake_case? Keep camelCase? Load separate DB dictionary? Define manually?
Generate db-standards-ref.md with automatic conversion and mapping if applicable
Load previous artifacts (API Design, TRD, Feature Map, PRD)
Create data model document with:
Entity relationships and schemas (using field naming strategy from Phase 0)
Data ownership boundaries
Access patterns
Migration strategy
API-to-DB field mapping (automatically generated if conversion applied)
Save to: docs/pre-dev/<feature-name>/data-model.md
Run Gate 5 validation checklist
Get human approval before proceeding
Gate 6: Dependency Map Skill: ring:pre-dev-dependency-map
Load previous artifacts
Create dependency map document with:
NOW we select specific technologies
Concrete versions and packages
Rationale for each choice
Alternative evaluations
Save to: docs/pre-dev/<feature-name>/dependency-map.md
Run Gate 6 validation checklist
Get human approval before proceeding
Gate 7: Task Breakdown Skill: ring:pre-dev-task-breakdown
Load all previous artifacts (PRD, Feature Map, TRD, API Design, Data Model, Dependency Map)
Run AI-assisted time estimation:
Auto-detect tech stack from Dependency Map (if available) OR repository files (go.mod, package.json, etc.)
Dispatch specialized agent based on detected stack:
Go (go.mod detected) → ring:backend-engineer-golang
TypeScript/Node (package.json + backend) → ring:backend-engineer-typescript
React/Next.js (package.json + frontend) → ring:frontend-engineer
Mixed/Unknown → ring:codebase-explorer
Agent analyzes scope and estimates AI-agent-hours per task
Output includes: AI estimate (hours), confidence level (High/Medium/Low), detailed breakdown
AI-agent-hours definition: Time for AI agent to implement via ring:dev-cycle (includes TDD, automated review, SRE validation, DevOps setup)
Create task breakdown document with:
Value-driven decomposition
Each task delivers working software
AI-agent-hours estimates (not story points)
Maximum task size: 16 AI-agent-hours
Dependencies mapped
Testing strategy per task
Save to: docs/pre-dev/<feature-name>/tasks.md
Run Gate 7 validation checklist
Get human approval before proceeding
Confidence Level Definition:
Level Numeric Range Meaning Pass Threshold High 67-100% (0.67-1.0) Clear scope, standard patterns, libs available Pass Medium 34-66% (0.34-0.66) Some custom logic, partial lib support Pass (borderline) Low 0-33% (0.0-0.33) Novel algorithms, vague scope, no lib support Requires review
Gate 7 minimum threshold: Tasks must have confidence >= 67% (High) or >= 34% (Medium with reviewer approval).
Borderline cases (Medium confidence): PM Lead must review and approve before proceeding.
Example conversion (AI-agent-hours → calendar time):
Given:
- ai_estimate = 8 AI-agent-hours (Medium confidence, 55%)
- multiplier = 1.5 (human validation)
- capacity = 0.90 (90% available)
- team_size = 1 developer
Step-by-step calculation:
Step 1: ai_estimate x multiplier = 8h x 1.5 = 12h adjusted
Step 2: adjusted / capacity = 12h / 0.90 = 13.33h calendar
Step 3: calendar / 8h/day = 13.33h / 8 = 1.67 developer-days
Step 4: developer-days / team_size = 1.67 / 1 = 1.67 calendar days ~ 2 days
Formula:
(ai_estimate x multiplier / capacity) / 8 / team_size
= (8 x 1.5 / 0.90) / 8 / 1
= 1.67 calendar days
Gate 8: Subtask Creation Skill: ring:pre-dev-subtask-creation
Load tasks from docs/pre-dev/<feature-name>/tasks.md
Create subtask breakdown document with:
Bite-sized steps (2-5 minutes each)
TDD-based implementation steps
Complete code (no placeholders)
Zero-context executable
Save to: docs/pre-dev/<feature-name>/subtasks.md
Run Gate 8 validation checklist
Get human approval
Gate 9: Delivery Planning (MANDATORY) Skill: ring:pre-dev-delivery-planning
Load tasks from docs/pre-dev/<feature-name>/tasks.md (with AI-agent-hours estimates)
Ask user for delivery inputs:
Start date (when team begins work)
Team composition (how many developers)
Delivery cadence (sprint/cycle/continuous)
Period configuration (if sprint/cycle: duration + start date)
Human validation multiplier (1.2x-2.5x, default 1.5x or custom)
Apply AI-based time calculation:
Formula: (ai_estimate x multiplier / 0.90) / 8 / team_size = calendar_days
Capacity: 90% available capacity (10% overhead for API limits, context loading, tool execution)
Note: 0.90 in formula = available capacity factor, not overhead percentage
Multiplier represents human validation overhead
Analyze dependencies and critical path
Calculate realistic timeline with period boundaries
Identify parallelization opportunities and resource allocation
Create delivery roadmap with Gantt-style timeline
Save to: docs/pre-dev/<feature-name>/delivery-roadmap.md + delivery-roadmap.json
Run Gate 9 validation checklist
Get human approval
After Completion Full Track (10 gates) complete for <feature-name>
Artifacts created (paths depend on topology.structure):
**For single-repo (all in docs/pre-dev/<feature-name>/):**
- research.md (Gate 0) - includes Product/UX Research
- prd.md (Gate 1)
- ux-criteria.md (Gate 1) - UX acceptance criteria
- feature-map.md (Gate 2)
- user-flows.md (Gate 2) - Detailed user flows
- wireframes/ (Gate 2) - Wireframe specs (YAML)
- design-validation.md (Gate 2.5) - Design completeness report (if UI)
- trd.md (Gate 3)
- api-design.md (Gate 4)
- api-standards-ref.md (Gate 4 - if standards provided)
- data-model.md (Gate 5)
- db-standards-ref.md (Gate 5 - always generated)
- dependency-map.md (Gate 6)
- tasks.md (Gate 7)
- subtasks.md (Gate 8)
- delivery-roadmap.md (Gate 9)
- delivery-roadmap.json (Gate 9)
**For monorepo (distributed by module):**
*Root (shared):* research.md, prd.md, feature-map.md, trd.md, tasks.md (index), delivery-roadmap.md, delivery-roadmap.json
*Backend module:* api-design.md, data-model.md, dependency-map.md, tasks.md
*Frontend module:* ux-criteria.md, user-flows.md, wireframes/, design-validation.md, dependency-map.md, tasks.md
**For multi-repo (per-repository):**
*Both repos:* research.md, prd.md, trd.md (synchronized), delivery-roadmap.md, delivery-roadmap.json
*Backend repo:* api-design.md, data-model.md, dependency-map.md, tasks.md
*Frontend repo:* ux-criteria.md, user-flows.md, wireframes/, design-validation.md, dependency-map.md, tasks.md
Planning time: 2.5-4.5 hours (comprehensive with UX design)
Next steps:
1. Review artifacts in docs/pre-dev/<feature-name>/
2. Use delivery-roadmap.md to communicate timelines to stakeholders
3. Use /ring:worktree to create isolated workspace
4. Use /ring:write-plan to create implementation plan
5. Execute the plan (ui-engineer will use user-flows.md and wireframes/)
Remember
This is the Full Track - comprehensive and thorough (10 gates)
All gates provide maximum planning depth
Gate 0 (Research) runs 4 agents in parallel for codebase, best practices, framework docs, and UX research
Gate 1 creates ux-criteria.md with UX acceptance criteria
Gate 2 creates user-flows.md and wireframes/ with detailed UX design
Gate 2.5 (Design Validation) ensures UI specs are complete before technical work
Technology decisions happen at Gate 6 (Dependency Map)
Gate 9 (Delivery Planning) is MANDATORY - creates realistic roadmap with timeline
All documents saved to docs/pre-dev/<feature-name>/
Get human approval at each gate before proceeding
Planning investment (2.5-4.5 hours) pays off during implementation
Delivery roadmap (WHEN/WHO) complements write-plan (HOW)
MANDATORY: Skills Orchestration This skill orchestrates multiple sub-skills in a 10-gate workflow.
Gate Sequence Gate Skill Purpose New Outputs 0 ring:pre-dev-researchDomain, technical, and UX research (4 agents) research.md (includes Product/UX Research) 1 ring:pre-dev-prd-creationProduct requirements + UX validation prd.md, ux-criteria.md 2 ring:pre-dev-feature-mapFeature scope + UX design feature-map.md, user-flows.md, wireframes/ 2.5 ring:pre-dev-design-validationVerify UX specs complete (if UI) design-validation.md 3 ring:pre-dev-trd-creationTechnical requirements trd.md 4 ring:pre-dev-api-designAPI contracts api-design.md 5 ring:pre-dev-data-modelData architecture data-model.md 6 ring:pre-dev-dependency-mapTechnology selection dependency-map.md 7 ring:pre-dev-task-breakdownTask decomposition tasks.md 8 ring:pre-dev-subtask-creationImplementation steps subtasks.md 9 ring:pre-dev-delivery-planningDelivery roadmap delivery-roadmap.md, .json
Execution Pattern For each gate:
Use Skill tool: [gate-skill]
Wait for human approval
Proceed to next gate
Each skill contains its own:
Anti-rationalization tables
Gate pass criteria
Output format requirements
Do NOT skip gates. Each gate builds on the previous gate's output.
02
Document Organization
Projektmanagement
Production Scheduling Codified expertise for production scheduling, job sequencing, line balancing, changeover optimization, and bottleneck resolution in discrete and batch manufacturing. Informed by production schedulers with 15+ years experience. Includes TOC/drum-buffer-rope, SMED, OEE analysis, disruption response frameworks, and ERP/MES interaction patterns. Use when scheduling production, resolving bottlenecks, optimizing changeovers, responding to disruptions, or balancing manufacturing lines.