Reuse
Borrowing it
Nothing to install: this file belongs to zarfld/presonus-studiolive-mcp. Take a copy, put it at the same path in your own repository, and replace the rules that are about this project with yours.
curl -O https://raw.githubusercontent.com/zarfld/presonus-studiolive-mcp/master/.github/prompts/reliability-plan-create.prompt.mdgit clone --depth 1 https://github.com/zarfld/presonus-studiolive-mcpWrote this? Show the measurements
A badge with what this costs and how it scanned, read live from this page, so it follows the numbers instead of freezing them. Markdown for a README, HTML for a documentation site or a project page.
[](https://agentmods.dev/commands/zarfld/presonus-studiolive-mcp/reliability-plan-create)<a href="https://agentmods.dev/commands/zarfld/presonus-studiolive-mcp/reliability-plan-create"><img src="https://agentmods.dev/badge/commands/zarfld/presonus-studiolive-mcp/reliability-plan-create/github.svg" alt="Measured on agentmods" height="20"></a>Or the 80×15 button, for a site that already has a row of RSS and ATOM ones. Only the verdict fits; the numbers stay here.
<a href="https://agentmods.dev/commands/zarfld/presonus-studiolive-mcp/reliability-plan-create"><img src="https://agentmods.dev/badge/commands/zarfld/presonus-studiolive-mcp/reliability-plan-create.svg" alt="Reviewed on agentmods" width="80" height="20"></a> Per session 23 Only the description is in the session, so the agent can decide to use it. The body loads when it is invoked.
When invoked 6,003 The whole file, excluding the scripts and references it only reads on demand.
Security scan A 0 findings. A grade says what 26 rules found in the file — not that it is safe.
Origin original No closer match found in the catalogue.
Token cost
What it costs to keep this loaded
Counted locally with the o200k_base tokenizer, which is exact for GPT models; Claude uses its own tokenizer and its counts differ. Treat this as one consistent yardstick across the catalogue rather than a bill. Prices are per million input tokens.
| Model | Per session | Once invoked |
|---|---|---|
| Fable 5.1 | $0.00023 | $0.06003 |
| Opus 5 | $0.00012 | $0.03002 |
| Sonnet 5 | $0.00005 | $0.01201 |
| Haiku 4.5 | $0.00002 | $0.00600 |
Security
Grade A, and why
reliability-plan-create scanned grade A with 0 findings against 26 rules in 11 categories — prompt injection, anti-refusal, data exfiltration, privilege escalation, supply chain, agent snooping, system-prompt leakage, SSRF and excessive agency — measured yesterday.
A static scan of the body, not an audit. Every finding is printed with the line that produced it so you can judge whether it matters here. A mod is markdown that instructs an agent; that is exactly why what it instructs is worth reading.
Nothing flagged
None of the 26 patterns this scan looks for appear in this file: no shell pipes, no recursive deletes, no credential paths, no hidden text, no instruction-override or anti-refusal phrasing, no agent-config snooping. That is not a guarantee, it is the absence of the things that are checkable.
.github/prompts/reliability-plan-create.prompt.md · 691 lines
How it starts
The opening of the file, as written. The whole thing — 691 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Software Reliability Program Plan (SRPP) Creation Prompt
You are a Software Reliability Engineering (SRE) Expert following IEEE 1633-2016 standards.
📤 EXPECTED OUTPUT (ALWAYS DELIVER)
When user requests SRPP creation, you MUST produce a complete Software Reliability Program Plan document following the template structure.
Complete SRPP Document Structure
# Software Reliability Program Plan (SRPP)
**Project**: [Project Name]
**Version**: [X.Y.Z]
**Date**: [YYYY-MM-DD]
**Document ID**: SRPP-[Project]-[Version]
**Status**: [Draft/Review/Approved]
**IEEE 1633-2016 Compliant**
---
## Document Control
| Version | Date | Author | Changes | Approved By |
|---------|------|--------|---------|-------------|
| [X.Y] | [Date] | [Name] | [Summary] | [Name] |
## Table of Contents
1. Introduction
2. Software Reliability Objectives
3. Software Reliability Engineering Roles and Responsibilities
4. Software Reliability Engineering Activities Throughout Lifecycle
5. Software Failure Modes and Effects Analysis (SFMEA)
6. Software Reliability Predictions
7. Software Reliability Growth Testing and Estimation
8. Tools, Techniques, and Standards
9. Schedule and Milestones
10. Appendices
---
## 1. Introduction
### 1.1 Purpose
[Describe the purpose of this SRPP and how it supports system reliability]
### 1.2 Scope
**In Scope:**
- [Software components covered]
- [Lifecycle phases covered]
- [Reliability metrics tracked]
**Out of Scope:**
- [Excluded items]
### 1.3 System Overview
**System Description**: [Brief system description]
**Software Components**:
| Component ID | Name | Description | Criticality | EKSLOC |
|--------------|------|-------------|-------------|---------|
| SW-[XXX] | [Name] | [Description] | [Critical/High/Medium/Low] | [Size] |
### 1.4 Definitions and Acronyms
- **MTBF**: Mean Time Between Failures
- **MTBCF**: Mean Time Between Critical Failures
- **SRG**: Software Reliability Growth
- **OP**: Operational Profile
- **SFMEA**: Software Failure Modes Effects Analysis
- **EKSLOC**: Effective 1000 Source Lines of Code (normalized)
---
## 2. Software Reliability Objectives
### 2.1 System-Level Reliability Requirements
**System MTBF Requirement**: [X hours]
**System Availability Requirement**: [Y%]
**Mission Time**: [Z hours]
**Source**: [System Requirements Document ID]
### 2.2 Software Reliability Allocation
Following IEEE 1633 Section 5.3.8, reliability allocated to software components:
| Component | Allocated MTBF | Allocated Failure Rate | Basis |
|-----------|----------------|------------------------|-------|
| SW-[XXX] | [X hours] | [Y failures/hour] | [Prediction/Historical] |
| **Total** | [System] | [Sum] | |
### 2.3 Critical Operations
Operations where failures would result in critical consequences:
| Operation ID | Description | Severity | MTBCF Target |
|--------------|-------------|----------|--------------|
| OP-CRIT-[NNN] | [Description] | Critical | [X hours] |
### 2.4 Reliability Quality Gates
| Lifecycle Phase | Gate Criteria | Target Value | Verification Method |
|-----------------|---------------|--------------|---------------------|
| Requirements | Completeness | 100% traced | Traceability Matrix |
| Design | SFMEA Complete | All RPN ≥ [X] mitigated | SFMEA Review |
| Implementation | Unit Test Coverage | ≥ [Y%] | Coverage Analysis |
| Integration | Defect Discovery Rate | Decreasing trend | SRG Model |
| V&V | Estimated MTBF | ≥ [Z hours] | SRG Model |
| Release | Residual Defects | ≤ [N] | Capture-Recapture |
---
## 3. Software Reliability Engineering Roles and Responsibilities
### 3.1 SRE Organization
| Role | Name | Responsibilities | IEEE 1633 Reference |
|------|------|------------------|---------------------|
| **SRE Lead** | [Name] | Overall SRE program execution | Clause 4.2 |
| **Reliability Engineer** | [Name] | Predictions, modeling, analysis | Clause 5.3, 6.2 |
| **Software Manager** | [Name] | Resource allocation, schedule | Clause 5.1 |
| **Quality Assurance** | [Name] | Testing, defect tracking | Clause 5.4 |
| **Requirements Engineer** | [Name] | OP definition, traceability | Clause 5.1.1.3 |
| **Design Engineer** | [Name] | SFMEA execution | Clause 5.2 |
| **Test Engineer** | [Name] | OP-driven testing | Clause 5.4 |
### 3.2 Responsibilities Matrix
| Activity | Lead | Support | Review | Approve |
|----------|------|---------|--------|---------|
| SRPP Creation | SRE Lead | Reliability Eng | SW Mgr | [Role] |
| Operational Profile | Requirements Eng | SRE Lead | QA | SW Mgr |
| SFMEA | Design Eng | SRE Lead | QA | SW Mgr |
| Reliability Predictions | Reliability Eng | SRE Lead | SW Mgr | [Role] |
| SRG Testing | Test Eng | QA | SRE Lead | SW Mgr |
| Release Decision | SW Mgr | SRE Lead, QA | Reliability Eng | [Role] |
---
## 4. Software Reliability Engineering Activities Throughout Lifecycle
### 4.1 Phase 01-02: Requirements Definition (IEEE 1633 Clause 5.1)
#### Activities:
1. **Characterize Software System**
- Identify all software/firmware LRUs
- Define Bill of Materials (BOM)
- Estimate effective size (EKSLOC)
2. **Define Failures and Criticality** (IEEE 1633 Clause 5.1.2)
- Define Failure Definition and Scoring Criteria (FDSC)
- Establish severity categories
- Define critical operations
3. **Perform Reliability Risk Assessment** (IEEE 1633 Clause 4.3)
- Identify technical risks
- Identify schedule/resource risks
- Document risk mitigation
4. **Develop Initial Operational Profile** (IEEE 1633 Clause 5.1.1.3)
- Identify user classes
- Define operations and mission profiles
- Assign usage frequencies
#### Deliverables:
- [ ] Software Characterization Document
- [ ] Failure Definition and Scoring Criteria (FDSC)
- [ ] Reliability Risk Assessment
- [ ] Initial Operational Profile (draft)
#### Tools/Prompts:
- `reliability-plan-create.prompt.md` (this prompt)
- `operational-profile-create.prompt.md`
---
### 4.2 Phase 03-04: Architecture and Design (IEEE 1633 Clause 5.2)
#### Activities:
1. **Perform Software Failure Modes Effects Analysis (SFMEA)**
- Identify failure modes for each component
- Identify root causes
- Assess consequences (RPN)
- Define mitigation actions
2. **Update Operational Profile**
- Refine based on architecture
- Develop Markov Chain Usage Model (MCUM)
- Define state transitions
3. **Perform Reliability Predictions** (IEEE 1633 Clause 6.2)
- Predict defect density
- Predict operational defects
- Predict MTBF/failure rate
#### Deliverables:
- [ ] SFMEA Report with Critical Items List (CIL)
- [ ] Detailed Operational Profile with MCUM
- [ ] Reliability Predictions Report
#### Tools/Prompts:
- `sfmea-create.prompt.md`
- `operational-profile-create.prompt.md`
---
### 4.3 Phase 05: Implementation (IEEE 1633 Clause 5.3)
#### Activities:
1. **Allocate Reliability to Components** (IEEE 1633 Clause 5.3.8)
- Bottom-up prediction per component
- Top-down allocation
2. **Implement SFMEA Mitigations**
- Track mitigation actions
- Verify implementation
3. **Develop Reliability Test Suite**
- Design OP-driven tests
- Develop test adapters
- Prepare test execution environment
#### Deliverables:
- [ ] Component Reliability Allocations
- [ ] SFMEA Mitigation Verification
- [ ] Reliability Test Plan
#### Quality Gates:
- All Critical SFMEA items mitigated (RPN reduced)
- Unit test coverage ≥ [X%]
- Static analysis defects resolved
---
### 4.4 Phase 06: Integration (IEEE 1633 Clause 5.4)
#### Activities:
1. **Execute OP-Driven Reliability Testing**
- Run tests according to operational profile
- Collect failure data
- Track test execution time
2. **Collect Defect Data** (IEEE 1633 Clause 5.4.4)
- Record all failures with timestamps
- Classify by severity (FDSC)
- Track defect correction
3. **Perform Preliminary SRG Modeling**
- Apply trend tests (Laplace, arithmetic mean)
- Select appropriate SRG models
- Generate preliminary estimates
#### Deliverables:
- [ ] Test Execution Log
- [ ] Failure Data Collection Spreadsheet
- [ ] Preliminary SRG Analysis
#### Tools/Prompts:
- `reliability-test-design.prompt.md`
- `srg-model-fit.prompt.md`
---
### 4.5 Phase 07: Verification & Validation (IEEE 1633 Clause 5.4, 5.5)
#### Activities:
1. **Continue SRG Testing and Modeling**
- Execute extended test campaigns
- Fit multiple SRG models
- Validate model accuracy
2. **Estimate Reliability Metrics** (IEEE 1633 Clause 6.3)
- Current MTBF / MTBCF
- Residual defects
- Confidence intervals
3. **Support Release Decision** (IEEE 1633 Clause 5.5)
- Assess against quality gates
- Evaluate release stability
- Perform Reliability Demonstration Test (RDT) if required
#### Deliverables:
- [ ] SRG Model Fitting Report
- [ ] Reliability Estimation Report
- [ ] Release Readiness Assessment
#### Quality Gates:
- Failure discovery rate decreasing
- Estimated MTBF ≥ requirement
- Test coverage (structural + OP) ≥ [Y%]
- Estimated residual defects acceptable
#### Tools/Prompts:
- `srg-model-fit.prompt.md`
- `reliability-release-decision.prompt.md`
---
### 4.6 Phase 08-09: Transition and Operations (IEEE 1633 Clause 5.6)
#### Activities:
1. **Monitor Field Reliability**
- Track trouble reports
- Calculate actual MTBF
- Validate predictions
2. **Update Historical Data**
- Document actual defect density
- Update prediction models
- Lessons learned
#### Deliverables:
- [ ] Field Reliability Monitoring Report
- [ ] Prediction Accuracy Report
- [ ] Lessons Learned Document
---
## 5. Software Failure Modes and Effects Analysis (SFMEA)
### 5.1 SFMEA Scope
**Components Analyzed**:
- [List all components subject to SFMEA]
**Failure Mode Categories** (per IEEE 1633 Annex A):
- Faulty data
- Faulty timing
- Faulty sequencing
- Faulty error handling
- Faulty logic
### 5.2 SFMEA Process (IEEE 1633 Clause 5.2.2)
1. Identify potential failure modes
2. Identify root causes
3. Identify consequences (local & system)
4. Assess Risk Priority Number (RPN = Severity × Likelihood × Detectability)
5. Define mitigation actions
6. Generate Critical Items List (CIL)
### 5.3 RPN Thresholds
| RPN Range | Action Required |
|-----------|-----------------|
| ≥ [X] | **Must** mitigate before release |
| [Y] - [X-1] | **Should** mitigate before release |
| < [Y] | Monitor, mitigate if resources allow |
### 5.4 SFMEA Schedule
| Milestone | Date | Status |
|-----------|------|--------|
| Requirements SFMEA | [Date] | [Status] |
| Design SFMEA | [Date] | [Status] |
| Code SFMEA | [Date] | [Status] |
| Integration SFMEA | [Date] | [Status] |
**SFMEA Document Location**: `04-design/sfmea/`
---
## 6. Software Reliability Predictions
### 6.1 Prediction Methodology (IEEE 1633 Clause 6.2)
**Models Used**:
- **Defect Density Prediction**: [Shortcut Model / Historical Data / Other]
- **Size Estimation**: [Function Points / COCOMO / Historical]
- **Growth Model**: [Exponential / Rayleigh] (before testing)
### 6.2 Prediction Inputs
| Parameter | Value | Source | Date |
|-----------|-------|--------|------|
| Total EKSLOC (normalized) | [X] | [Tool/Estimate] | [Date] |
| Predicted Defect Density | [Y defects/KESLOC] | [Model] | [Date] |
| Predicted Total Defects | [Z] | [Calculation] | [Date] |
| Growth Rate (Q) | [6-12] | [Deployment model] | [Date] |
| Growth Period (months) | [T] | [Schedule] | [Date] |
| Duty Cycle (hours/month) | [H] | [Operational] | [Date] |
### 6.3 Predicted Reliability Metrics
| Metric | Predicted Value | Confidence | Target | Status |
|--------|-----------------|------------|--------|--------|
| Initial MTBF (month 1) | [X hours] | [Low/Med/High] | [Y hours] | [🔴/🟡/🟢] |
| MTBF at 12 months | [X hours] | [Low/Med/High] | [Y hours] | [🔴/🟡/🟢] |
| MTBCF at 12 months | [X hours] | [Low/Med/High] | [Y hours] | [🔴/🟡/🟢] |
| Availability (99.X%) | [%] | [Low/Med/High] | [%] | [🔴/🟡/🟢] |
### 6.4 Sensitivity Analysis
Factors most sensitive to reliability:
1. [Factor 1 - e.g., "Team size > 8 people"]
2. [Factor 2 - e.g., "Testing starts after all code complete"]
3. [Factor 3 - e.g., "New technology/language"]
**Mitigation Actions**: [Actions to improve prediction]
**Predictions Document Location**: `05-implementation/docs/reliability-predictions.md`
---
## 7. Software Reliability Growth Testing and Estimation
### 7.1 Test Approach (IEEE 1633 Clause 5.4)
**OP-Driven Testing**: Tests are generated and executed according to the Operational Profile to ensure representative sampling of field usage.
**Test Phases**:
1. **Component Integration Testing**: Initial SRG data collection
2. **System Testing**: Primary SRG data collection
3. **Acceptance Testing**: Release readiness validation
### 7.2 Failure Data Collection (IEEE 1633 Clause 5.4.4)
**Data Elements Collected**:
- Failure timestamp
- Test execution time at failure
- Failure severity (per FDSC)
- Failure description
- Root cause (after analysis)
- Correction action
**Data Collection Tool**: [Spreadsheet / JIRA / Other]
### 7.3 SRG Models (IEEE 1633 Clause 6.3)
**Models to be Applied**:
- **Musa-Okumoto** (logarithmic Poisson, decreasing failure rate)
- **Goel-Okumoto** (exponential, decreasing failure rate)
- **Jelinski-Moranda** (decreasing failure rate)
- **Crow/AMSAA** (time-based, power law)
**Model Selection Criteria** (IEEE 1633 Clause 5.4.5):
1. Laplace trend test result (U-shaped, decreasing, etc.)
2. Failure rate trend (increasing/decreasing)
3. Model goodness-of-fit
4. Prediction accuracy (historical validation)
### 7.4 Reliability Estimation Outputs
| Metric | Definition | Update Frequency |
|--------|------------|------------------|
| Current Failure Intensity | Failures/hour (current) | Weekly |
| Current MTBF | 1/failure intensity | Weekly |
| Estimated Remaining Defects | From SRG model | Weekly |
| Defect Removal % | Found/(Found+Remaining) × 100% | Weekly |
| Predicted MTBF at Release | Extrapolated from model | Bi-weekly |
### 7.5 Test Coverage Requirements
| Coverage Type | Target | Verification Method |
|---------------|--------|---------------------|
| Requirements Coverage | 100% | Traceability Matrix |
| Code Coverage (Branch/Decision) | ≥ [X%] | Coverage Tool |
| MCUM State Coverage | ≥ [Y%] | OP Test Generator |
| MCUM Transition Coverage | ≥ [Z%] | OP Test Generator |
---
## 8. Tools, Techniques, and Standards
### 8.1 Applicable Standards
| Standard | Title | Applicable Clauses |
|----------|-------|-------------------|
| **IEEE 1633-2016** | Software Reliability Recommended Practice | All |
| IEEE 1012-2016 | Verification and Validation | Testing procedures |
| IEEE 29148-2018 | Requirements Engineering | OP definition |
| IEEE 42010-2011 | Architecture Description | SFMEA inputs |
### 8.2 Tools
| Tool | Purpose | Version | License |
|------|---------|---------|---------|
| [Static Analysis Tool] | Code quality, size estimation | [X.Y] | [License] |
| [Coverage Tool] | Test coverage measurement | [X.Y] | [License] |
| [Test Management Tool] | Defect tracking, test execution | [X.Y] | [License] |
| [SRG Tool] | Reliability growth modeling | [X.Y] | [License] |
| [SFMEA Tool] | FMEA analysis | [X.Y] | [License] |
### 8.3 Copilot Prompts (Custom)
| Prompt File | Purpose | Phase |
|-------------|---------|-------|
| `reliability-plan-create.prompt.md` | Create/update SRPP | 01-02 |
| `operational-profile-create.prompt.md` | Generate OP from requirements | 04-05 |
| `sfmea-create.prompt.md` | Guide SFMEA execution | 04 |
| `reliability-test-design.prompt.md` | Design OP-driven tests | 06-07 |
| `srg-model-fit.prompt.md` | Fit and interpret SRG models | 06-07 |
| `reliability-release-decision.prompt.md` | Assess release readiness | 07-08 |
---
## 9. Schedule and Milestones
### 9.1 SRE Milestones
| Milestone | Planned Date | Actual Date | Status | Deliverable |
|-----------|--------------|-------------|--------|-------------|
| SRPP Approved | [Date] | [Date] | [Status] | This document |
| OP Complete | [Date] | [Date] | [Status] | OP Document |
| SFMEA Complete | [Date] | [Date] | [Status] | SFMEA Report + CIL |
| Predictions Complete | [Date] | [Date] | [Status] | Predictions Report |
| SRG Testing Start | [Date] | [Date] | [Status] | Test Plan |
| SRG Testing End | [Date] | [Date] | [Status] | Test Results |
| Release Decision | [Date] | [Date] | [Status] | Release Assessment |
| First Deployment | [Date] | [Date] | [Status] | Deployed Software |
### 9.2 Dependencies
| SRE Activity | Depends On | Blocks |
|--------------|------------|--------|
| OP Creation | Requirements 90% complete | SFMEA, Test Design |
| SFMEA | Architecture/Design 80% complete | Predictions |
| Predictions | SFMEA, Size estimate | Test planning |
| SRG Testing | Integration complete | Release decision |
| Release Decision | SRG data collection ≥ [X weeks] | Deployment |
---
## 10. Appendices
### Appendix A: Failure Definition and Scoring Criteria (FDSC)
| Severity | Definition | System Impact | MTBCF Target |
|----------|------------|---------------|--------------|
| **Critical** | Loss of critical function, safety hazard | System abort, data loss | [X hours] |
| **High** | Major function degraded | Reduced capability | [Y hours] |
| **Medium** | Minor function impacted | Workaround available | [Z hours] |
| **Low** | Cosmetic, no functional impact | Minimal impact | N/A |
### Appendix B: Operational Profile Summary
- **Location**: `02-requirements/operational-profile.md`
- **User Classes**: [List]
- **Mission Profiles**: [List]
- **Top 10 Operations**: [List with frequencies]
### Appendix C: Historical Data
| Previous Release | EKSLOC | Actual Defect Density | Actual MTBF (12 mo) |
|------------------|--------|----------------------|---------------------|
| [Version] | [X] | [Y defects/KESLOC] | [Z hours] |
### Appendix D: Risk Register
| Risk ID | Description | Probability | Impact | Mitigation | Owner |
|---------|-------------|-------------|--------|------------|-------|
| RISK-[NNN] | [Description] | [L/M/H] | [L/M/H] | [Action] | [Name] |
### Appendix E: Glossary
[Additional project-specific terms]
### Appendix F: References
1. IEEE Std 1633-2016, IEEE Recommended Practice on Software Reliability
2. [Project System Requirements Specification]
3. [Project Software Requirements Specification]
4. [Project Software Design Document]
---
## Document Approval
| Role | Name | Signature | Date |
|------|------|-----------|------|
| SRE Lead | [Name] | | |
| Software Manager | [Name] | | |
| Quality Assurance | [Name] | | |
| Program Manager | [Name] | | |
---
**END OF SOFTWARE RELIABILITY PROGRAM PLAN**
Changes
What this file has done since we first saw it
Hashed on every crawl. A supply-chain change to an agent config is a question of when, not whether, so the history is kept rather than the latest state alone.
- yesterday First seen · 691 lines · 23 tokens per session scan A 14070b23fb27
reliability-plan-create is a command published in the GitHub repository zarfld/presonus-studiolive-mcp (1 stars, last pushed 2d ago), licensed MIT. It adds 23 tokens to every session and 6,003 once invoked, about $0.0001 per session on Opus 5. A static security scan graded it A with 0 findings. No closer match exists in the catalogue, so it is treated as the original; first seen 2026-09-08.
Related
Other commands, from other repositories
prototype
You are building a proof-of-concept for the current Grainulator sprint. Read CLAUDE.md for sprint context and claims.json for existing research claims.
verify
Run repository verification using the verification-loop skill.
qa-changes
This skill should be used when the user asks to "QA a pull request", "test PR changes", "verify a PR works", "functionally test changes", or when an automated workflow triggers QA validation of code changes. Provides a structured methodology for setting up the environment, exercising changed behavior, and reporting…
test-coverage
Analyze test coverage and identify the highest-value gaps to fill.
tdd
A command that follows test-driven development (TDD), a method where you write tests before the code they check. It moves through writing a failing test, adding the smallest implementation, and then improving the code.
check-dev
Type-check a Z specification with fuzz.