Agent skill

Prd V08 Monitoring Setup

by mattgierhart in mattgierhart/PRD-driven-context-engineering

Define monitoring strategy, metrics collection, and alerting thresholds during PRD v0.8 Deployment & Ops.

MITAuto-check: notesDevOps & Cloud

Install Prd V08 Monitoring Setup

skills CLI
$ npx skills add mattgierhart/PRD-driven-context-engineering --skill prd-v08-monitoring-setup -a claude-code

Project install by default; add -g for ~/.claude/skills/.

GitHub CLI
$ gh skill install mattgierhart/PRD-driven-context-engineering prd-v08-monitoring-setup --agent claude-code

Project scope by default; add --scope user for a personal install. Needs GitHub CLI 2.90.0 or later (public preview).

Manual copy
$ git clone --depth 1 https://github.com/mattgierhart/PRD-driven-context-engineering.git skills-src && mkdir -p .claude/skills && cp -r skills-src/.claude/skills/prd-v08-monitoring-setup .claude/skills/prd-v08-monitoring-setup && rm -rf skills-src

Use ~/.claude/skills/ instead of .claude/skills for a personal install. The folder must contain SKILL.md.

Claude Code skills documentation · loads skills from .claude/skills/

Facts

Skill name
prd-v08-monitoring-setup
GitHub stars
180
Token cost
~3.8k tokens
SKILL.md length
888 words
Files
5 (incl. references, assets)
Skills in repo
45
Repo updated
First seen
Licence
MIT

At a glance

Define monitoring strategy, metrics collection, and alerting thresholds during PRD v0.8 Deployment & Ops.

  • Works in 6 steps: Define SLOs (Service Level Objectives) → Identify key metrics per layer → Set alert thresholds → …
  • Requests to set up monitoring
  • SKILL.md covers Execution Mode, Consumes, Produces and Core Concept: Monitoring as…, plus 12 more sections
  • Instructions only: no scripts, shell commands, URLs or credentials in SKILL.md

What it does

Prd V08 Monitoring Setup is an agent skill from mattgierhart/PRD-driven-context-engineering. Define monitoring strategy, metrics collection, and alerting thresholds during PRD v0.8 Deployment & Ops. Triggers on requests to set up monitoring, define alerts, or when user asks "what should we monitor?", "alerting strategy", "observability", "metrics", "SLOs", "dashboards", "monitoring setup". Outputs MON- entries with monitoring rules and alert configurations.

Its SKILL.md is about 3.8k tokens, which your agent loads only when the skill is triggered. The skill folder holds 6 other files, including reference files and assets (for example `assets/mon-template.md`, `references/dashboard-guide.md` and `references/monitoring-stack.md`).

It sits in DevOps & Cloud, covering PRD writing, Site reliability engineering and Monitoring and alerting. The repository describes itself as: PRD-Led Context Engineering — Memory as Infrastructure. An ontology layer for product teams building products that solve real problems — with AI agents that remember. Gated PRD… The licence is MIT.

When your agent uses it

  • Requests to set up monitoring
  • User asks what should we monitor?
  • Alerting strategy
  • Monitoring setup

Example prompts

  • “what should we monitor?”
  • “alerting strategy”
  • “observability”
  • “/prd-v08-monitoring-setup”

Requirements

  • Pre-approved tools (allowed-tools): Read, Write, Edit, Glob, Grep, Bash

Workflow steps

6 steps, taken from the first numbered list in SKILL.md.

  1. Define SLOs (Service Level Objectives)
  2. Identify key metrics per layer
  3. Set alert thresholds
  4. Map alerts to runbooks
  5. Design dashboards
  6. Create MON- entries with full traceability

What it can do on your machine

Read from SKILL.md and the folder at commit 30ed1b0. It shows what the files ask for, not the result of running them.

  • Tool permissions

    Pre-approves these tools, so the agent can use them without asking each time:

    • Read
    • Write
    • Edit
    • Glob
    • Grep
    • Bash

    From allowed-tools in the SKILL.md frontmatter.

  • Runs code

    No scripts in the folder and no shell commands in SKILL.md (its code samples are markdown).

    From the folder's file list and the shell code blocks in SKILL.md.

  • Network

    No URLs in SKILL.md.

    From URLs in SKILL.md, links to its own repository left out.

  • Credentials

    Names no API keys, tokens, secrets or passwords.

    From names ending in _API_KEY, _TOKEN, _SECRET, _KEY or _PASSWORD in SKILL.md.

Context cost

Prd V08 Monitoring Setup loads about 3.8k tokens when it runs, and up to ~15k if it reads all its reference files. Until then it costs about 98 tokens; SKILL.md has 888 words of instructions outside code blocks.

Always · name and description, kept in context so the agent knows when to use it
~98
When it runs · the whole SKILL.md, loaded when a task matches
~3.8k
With references · SKILL.md plus every file in references/, read only if the agent opens them
~15k

Estimates: characters ÷ 4, the usual rule of thumb; real counts depend on the model's tokenizer. Scripts and assets cost tokens only if the agent reads them.

Safety

Auto-check: notes

The automated check noted patterns worth knowing about, such as sudo or a known installer.

  • NotePre-approves every shell command (allowed-tools: Bash)SKILL.md
    allowed-tools: Read, Write, Edit, Glob, Grep, Bash

Automated static check — not a guarantee. Review scripts before installing. It scans the text of SKILL.md for risky patterns (piping downloads into a shell, reading credential files, hidden Unicode, destructive commands); files beside SKILL.md are not scanned.

SKILL.md

The full file from mattgierhart/PRD-driven-context-engineering at commit 30ed1b0, republished under its MIT licence (© mattgierhart). 888 words, ~3,759 tokens.

Download SKILL.mdSave it as .claude/skills/prd-v08-monitoring-setup/SKILL.md (or your agent's skills folder). This skill also uses 4 other files; get the full folder from GitHub.
name
prd-v08-monitoring-setup
description
Define monitoring strategy, metrics collection, and alerting thresholds during PRD v0.8 Deployment & Ops. Triggers on requests to set up monitoring, define alerts, or when user asks "what should we monitor?", "alerting strategy", "observability", "metrics", "SLOs", "dashboards", "monitoring setup". Outputs MON- entries with monitoring rules and alert configurations.
allowed-tools
Read, Write, Edit, Glob, Grep, Bash
context
fork
execution_modes.default
standard
execution_modes.supports
quick, standard, deep

Monitoring Setup

Position in workflow: v0.8 Runbook Creation → v0.8 Monitoring Setup → v0.9 GTM Strategy

Execution Mode

Default is standard. See .claude/rules/08-skill-execution-modes.md for selection logic.

ModeWhat this skill produces
quickRED metrics on critical path only; 3–5 alerts linked to RUN-; single overview dashboard
standardRED + USE coverage; SLOs for tier-1 services; full alert routing to RUN-; dashboards by audience
deepLayered coverage (RED + USE + business + UX); multi-tier SLOs with error budgets; baseline calibration from staging; escalation routing

Consumes

This skill requires prior work from v0.8 Runbook Creation and earlier stages:

  • RUN-* runbook entries (from v0.8 Runbook Creation) — Incident response runbooks define alerting scenarios; critical alerts must link to RUN- procedures
  • DEP-* deployment entries (from v0.8 Release Planning) — DEP- rollback thresholds and post-deploy validation steps inform MON- alert conditions and SLO targets
  • API-* endpoint contracts (from v0.6 Technical Specification) — Define baseline latency, throughput, and error rates for application-layer metrics
  • KPI-* metrics (from v0.3 Outcome Definition and v0.9 Launch Metrics) — Business metrics (signups, conversions, retention) inform dashboard design and business layer monitoring
  • ARC-* architecture decisions (from v0.6 Architecture Design) — System structure determines which components to monitor (monolith has different metrics than distributed services)
  • TECH-* technology stack (from v0.5 Technical Stack Selection) — Technology choices (database, cloud provider, APM tools) determine available metrics and monitoring tools

This skill assumes DEP- and RUN- entries are complete with thresholds, rollback conditions, and incident procedures defined.

Produces

This skill creates/updates:

  • MON-* entries (monitoring specifications, metric/alert/dashboard/SLO types) — Concrete monitoring rules with thresholds, alert conditions, dashboards, SLO definitions, linked to RUN- procedures
  • Alert routing configuration — Mapping of MON- alerts to notification channels and teams; links alerts to RUN- incident procedures
  • Observability baseline — Metrics gathered from staging/production, establishing normal operating ranges for alert thresholds

All MON- entries are operational monitoring specifications, not confidence-based. They are:

  • Measurable (every metric has a source, unit, and aggregation method)
  • Actionable (every alert has a RUN- procedure; no orphaned alerts)
  • Thresholded (critical/warning severity with specific numeric conditions)
  • Dashboarded (MON- dashboard entries provide visibility to operators and stakeholders)
  • SLO-backed (SLO entries tie monitoring to product commitments)

Example MON- entries:

markdown
MON-001: API Request Latency (p95)
Type: Metric
Layer: Application
Owner: Backend Team

Name: api.request.latency.p95
Description: 95th percentile response time for all API endpoints (from API-001–020)
Unit: ms
Source: Application APM (Datadog custom instrumentation)
Aggregation: p95 over 5-minute window
Retention: 90 days

Linked IDs: API-001 to API-020, DEP-004 (baseline from staging)

---

MON-002: High Latency Alert (Warning)
Type: Alert
Layer: Application
Owner: Backend Team

Metric: MON-001 (api.request.latency.p95)
Condition: >500ms (from DEP-002 baseline)
Window: 5 minutes
Severity: Warning
Runbook: RUN-001 (Performance Degradation Investigation)

Notification:
  - Channel: Slack #backend-alerts
  - Recipients: Backend on-call, team notified during business hours

Silencing: During scheduled maintenance windows (DEP-004 notifications)

Linked IDs: MON-001, RUN-001, DEP-002

---

MON-003: Critical Latency Alert
Type: Alert
Layer: Application
Owner: Backend Team

Metric: MON-001 (api.request.latency.p95)
Condition: >2000ms (SLA breach, from KPI-001 target)
Window: 2 minutes
Severity: Critical
Runbook: RUN-001 (Performance Degradation Investigation)

Notification:
  - Channel: PagerDuty (wake on-call)
  - Recipients: Backend on-call, Tech Lead, escalate if not acknowledged in 5 min

Silencing: None (critical alerts never silenced)

Linked IDs: MON-001, RUN-001, KPI-001

---

MON-004: API Availability SLO
Type: SLO
Layer: Application
Owner: Platform Team

Objective: API endpoints return non-5xx response
Target: 99.9% uptime (from DEP-002 / KPI-001)
Window: Rolling 30 days
Error Budget: 43.2 minutes/month

Alerting:
  - 50% error budget consumed → Warning to engineering (slow-burn alert)
  - 75% error budget consumed → Critical, freeze non-essential deploys
  - 100% error budget consumed → Post-incident review required (RUN-008 procedure)

Linked IDs: API-001–020, DEP-003 (rollback triggers), RUN-008 (incident review)

---

MON-005: System Health Dashboard
Type: Dashboard
Layer: Infrastructure + Application
Owner: Platform Team

Purpose: Quick health check for on-call engineers (run from RUN-002, RUN-001)
Audience: On-call engineers, engineering leadership, ops team
Panels:
  - API Request Rate (last 1h): Should be steady or increasing
  - API Latency (p50, p95, p99): Watch for p95/p99 creeping up
  - Error Rate by Endpoint: Any 5xx > 0 is concerning
  - Active Critical Alerts: Should be none
  - Database Connection Pool (from MON-006): Trending toward threshold
  - CPU/Memory by Service: Identify resource exhaustion
  - Deployment Status: Current version, time of last deploy
Refresh: 30 seconds

Linked IDs: MON-001, MON-002, MON-003, MON-006, DEP-001, RUN-001/002

---

MON-006: Database Connection Pool Utilization
Type: Metric
Layer: Infrastructure
Owner: Database Team

Name: db.connection_pool.utilized_percent
Description: Percentage of available connections in use (from DEP-001 pool size)
Unit: percentage
Source: Database monitoring (RDS Enhanced Monitoring or custom query)
Aggregation: avg over 1-minute window
Retention: 30 days

Linked IDs: DEP-001 (pool config), RUN-001 (incident when >90%)

Core Concept: Monitoring as Early Warning

Monitoring is not about collecting data—it is about detecting problems before users do. Every metric should answer: "Is this working? If not, what's broken?"

Monitoring Layers

LayerWhat to MeasureWhy It Matters
InfrastructureCPU, memory, disk, networkSystem health foundation
ApplicationLatency, errors, throughputUser-facing performance
BusinessSignups, conversions, revenueProduct health
User ExperiencePage load, interaction timeReal user impact

Execution

  1. Define SLOs (Service Level Objectives)

    • What uptime do we promise?
    • What latency is acceptable?
    • What error rate is tolerable?
  2. Identify key metrics per layer

    • Infrastructure: Resource utilization
    • Application: RED metrics (Rate, Errors, Duration)
    • Business: KPI- from v0.3 and v0.9
    • User: Core Web Vitals, journey completion
  3. Set alert thresholds

    • Warning: Investigate soon
    • Critical: Act immediately
    • Base on SLOs and historical data
  4. Map alerts to runbooks

    • Every critical alert → RUN- procedure
    • No alert without action path
  5. Design dashboards

    • Overview: System health at a glance
    • Deep-dive: Per-service details
    • Business: KPI tracking
  6. Create MON- entries with full traceability

MON- Output Template

MON-XXX: [Monitoring Rule Title]
Type: [Metric | Alert | Dashboard | SLO]
Layer: [Infrastructure | Application | Business | User Experience]
Owner: [Team responsible for this metric/alert]

For Metric Type:
  Name: [metric.name.format]
  Description: [What this measures]
  Unit: [count | ms | percentage | bytes]
  Source: [Where this comes from]
  Aggregation: [avg | sum | p50 | p95 | p99]
  Retention: [How long to keep data]

For Alert Type:
  Metric: [MON-YYY or metric name]
  Condition: [Threshold expression]
  Window: [Time window for evaluation]
  Severity: [Critical | Warning | Info]
  Runbook: [RUN-XXX to follow when fired]
  Notification:
    - Channel: [Slack, PagerDuty, Email]
    - Recipients: [Team or individuals]
  Silencing: [When to suppress, e.g., maintenance windows]

For Dashboard Type:
  Purpose: [What questions this answers]
  Audience: [Who uses this dashboard]
  Panels: [List of visualizations]
  Refresh: [How often to update]

For SLO Type:
  Objective: [What we promise]
  Target: [Percentage, e.g., 99.9%]
  Window: [Rolling 30 days]
  Error Budget: [How much downtime allowed]
  Alerting: [When error budget is at risk]

Linked IDs: [API-XXX, UJ-XXX, KPI-XXX, RUN-XXX related]

Example MON- entries:

MON-001: API Request Latency (p95)
Type: Metric
Layer: Application
Owner: Backend Team

Name: api.request.latency.p95
Description: 95th percentile response time for all API endpoints
Unit: ms
Source: Application APM (Datadog/New Relic)
Aggregation: p95
Retention: 90 days

Linked IDs: API-001 to API-020
MON-002: High Latency Alert
Type: Alert
Layer: Application
Owner: Backend Team

Metric: MON-001 (api.request.latency.p95)
Condition: > 500ms
Window: 5 minutes
Severity: Warning
Runbook: RUN-006 (Performance Degradation Investigation)

Notification:
  - Channel: Slack #backend-alerts
  - Recipients: Backend on-call

Silencing: During scheduled deployments (DEP-002 windows)

Linked IDs: MON-001, RUN-006, DEP-002
MON-003: Critical Latency Alert
Type: Alert
Layer: Application
Owner: Backend Team

Metric: MON-001 (api.request.latency.p95)
Condition: > 2000ms
Window: 2 minutes
Severity: Critical
Runbook: RUN-006 (Performance Degradation Investigation)

Notification:
  - Channel: PagerDuty
  - Recipients: Backend on-call, Tech Lead

Silencing: None (always alert on critical)

Linked IDs: MON-001, RUN-006
MON-004: API Availability SLO
Type: SLO
Layer: Application
Owner: Platform Team

Objective: API endpoints return non-5xx response
Target: 99.9%
Window: Rolling 30 days
Error Budget: 43.2 minutes/month

Alerting:
  - 50% budget consumed → Warning to engineering
  - 75% budget consumed → Critical, freeze non-essential deploys
  - 100% budget consumed → Incident review required

Linked IDs: API-001 to API-020, DEP-003
MON-005: System Health Dashboard
Type: Dashboard
Layer: Infrastructure + Application
Owner: Platform Team

Purpose: Quick health check for on-call engineers
Audience: On-call, engineering leadership
Panels:
  - API Request Rate (last 1h)
  - API Latency (p50, p95, p99)
  - Error Rate by Endpoint
  - Active Alerts
  - Database Connection Pool
  - CPU/Memory by Service
Refresh: 30 seconds

Linked IDs: MON-001, MON-002, MON-003
Show full SKILL.md (369 more words)Show less

The RED Method (Application Monitoring)

For each service, measure:

MetricWhat It MeasuresAlert Threshold
RateRequests per secondAnomaly detection
ErrorsFailed requests / total>1% warning, >5% critical
DurationRequest latency (p95, p99)>500ms warning, >2s critical

The USE Method (Infrastructure Monitoring)

For each resource (CPU, memory, disk, network):

MetricWhat It MeasuresAlert Threshold
Utilization% of capacity used>80% warning, >95% critical
SaturationQueue depth, waiting>0 for critical resources
ErrorsError count/rateAny errors = investigate

SLO Framework

TierAvailabilityLatency (p95)Use For
Tier 199.99% (52 min/yr)<100msPayment, auth
Tier 299.9% (8.7 hr/yr)<500msCore features
Tier 399% (3.6 days/yr)<2sBackground jobs

Alert Severity Matrix

SeverityUser ImpactResponse TimeNotification
CriticalService unusable<5 minPagerDuty (wake up)
WarningDegraded experience<30 minSlack (business hours)
InfoNo immediate impactNext dayDashboard/log

Dashboard Design Principles

PrincipleImplementation
Answer questionsEach panel answers "Is X working?"
HierarchyOverview → Service → Component
ContextShow thresholds, comparisons
ActionableLink to runbooks from alerts
FastQuick load, auto-refresh

Anti-Patterns

PatternSignalFix
Alert fatigueToo many alerts, team ignoresTune thresholds, remove noise
No runbook linkAlert fires, no one knows what to doEvery alert → RUN-
Vanity metrics"1 million requests!" without contextFocus on user-impacting metrics
Missing baselinesNo historical comparisonEstablish baselines before launch
Over-monitoring500 metrics, can't find signalFocus on RED/USE fundamentals
Under-monitoring"We'll add monitoring later"Monitoring ships with code

Quality Gates

Before proceeding to v0.9 GTM Strategy:

  • SLOs defined for critical services (MON- SLO type)
  • RED metrics configured for application layer
  • USE metrics configured for infrastructure layer
  • Critical alerts linked to RUN- procedures
  • Overview dashboard created for on-call
  • Alert notification channels configured
  • Baseline metrics established from staging

Downstream Connections

ConsumerWhat It UsesExample
On-Call TeamMON- alerts trigger responseMON-003 → page engineer
v0.9 Launch MetricsMON- provides baseline dataMON-001 baseline → KPI-010 target
Post-MortemsMON- data for incident analysis"MON-005 showed spike at 14:32"
Capacity PlanningMON- trends inform scalingUSE metrics → infrastructure planning
DEP- RollbackMON- thresholds trigger rollbackMON-002 breach → DEP-003 rollback

Detailed References

  • Monitoring stack examples: See references/monitoring-stack.md
  • MON- entry template: See assets/mon-template.md
  • SLO calculation guide: See references/slo-guide.md
  • Dashboard best practices: See references/dashboard-guide.md

© mattgierhart, MIT. Rendered from Markdown: HTML in the file is shown as text, images as links, and headings moved down two levels. Raw file

Files

SKILL.md and 4 other files (references, assets) in .claude/skills/prd-v08-monitoring-setup of mattgierhart/PRD-driven-context-engineering.

  • SKILL.md
  • assets/mon-template.md
  • references/dashboard-guide.md
  • references/monitoring-stack.md
  • references/slo-guide.md

Open the folder on GitHubat commit 30ed1b0

Compare with similar skills

Prd V08 Monitoring Setup next to the 5 skills that share the most tags, products or categories with it. Stars are the repository's; “used in” counts other GitHub owners with a copy.

Prd V08 Monitoring Setup compared with similar skills
SkillStarsUsed inTokensAuto-checkLicenceRepo updated
Prd V08 Monitoring Setup this skillmattgierhart/PRD-driven-context-engineering180—~3.8kAutomated safety check: NotesMIT
Expert TeamReJeCtAll/ExpertTeam-Codex113—~667Automated safety check: PassMIT
Dev Architecture Playbookmajiayu000/spellbook287—~848Automated safety check: PassMIT
Alerting Irmgrafana/skills2821 repos~1.9kAutomated safety check: PassApache-2.0
Promqlgrafana/skills2821 repos~1.1kAutomated safety check: PassApache-2.0
Service Mesh Observabilitywshobson/agents40k9 repos~607Automated safety check: PassMIT

Similar skills

  • Expert Team

    ReJeCtAll/ExpertTeam-Codex

    专家团总路由器。用于 Codex CLI 的 $expert-team 调用. An agent skill from ReJeCtAll/ExpertTeam-Codex.

    113 GitHub stars~667 tokensUpdated 3 mo ago
    DevOps & CloudAuto-check passed
  • Dev Architecture Playbook

    majiayu000/spellbook

    Route full software-development architecture work from product intent through design, implementation, testing, release, and operations.

    287 GitHub stars~848 tokensUpdated 2 days ago
    DevOps & CloudAuto-check passed
  • Alerting Irm

    grafana/skills

    Official

    Configure Grafana Alerting, Incident Response Management (IRM), and SLOs end-to-end — provisions Grafana-managed and data-source-managed alert rules, contact points (Slack/PagerDuty/email/webhook)…

    282 GitHub starsUsed in 1 repo~1.9k tokens
    DevOps & CloudAuto-check passed
  • Promql

    grafana/skills

    Official

    Write, validate, and optimize PromQL for Prometheus / Grafana Mimir / Grafana Cloud Metrics.

    282 GitHub starsUsed in 1 repo~1.1k tokens
    DevOps & CloudAuto-check passed
  • Set up tracing, metrics and dashboards for Istio, Linkerd and other service meshes, with golden-signal alerts, SLOs and guidance on sampling and cardinality.

    40k GitHub starsUsed in 9 repos~607 tokens
    DevOps & CloudAuto-check passed
  • Monitoring Observability

    ahmedasmar/devops-claude-skills

    Monitoring and observability strategy, implementation, and troubleshooting.

    203 GitHub stars~3.9k tokensUpdated 6 mo ago
    DevOps & CloudAuto-check passed

More from mattgierhart/PRD-driven-context-engineering

All 45 skills in this repo
  • Ghm Gate Check

    mattgierhart/PRD-driven-context-engineering

    Validates gate criteria before PRD lifecycle advancement by delegating to the readiness scoring pipeline (scripts/readiness.py).

    180 GitHub stars~1.3k tokensUpdated 1 mo ago
    Auto-check: notes
  • Ghm Harvest

    mattgierhart/PRD-driven-context-engineering

    Extracts durable insights from temp/ files to SoT during EPIC Phase E.

    180 GitHub stars~1.1k tokensUpdated 1 mo ago
    Auto-check passed
  • Ghm Id Register

    mattgierhart/PRD-driven-context-engineering

    Validates and registers new SoT IDs with cross-reference integrity.

    180 GitHub stars~1.5k tokensUpdated 1 mo ago
    Auto-check passed
  • Ghm Sot Builder

    mattgierhart/PRD-driven-context-engineering

    Creates new Source of Truth (SoT) files when existing templates don't fit your needs.

    180 GitHub stars~2k tokensUpdated 1 mo ago
    Auto-check passed
  • Prd V01 Problem Framing

    mattgierhart/PRD-driven-context-engineering

    Transform vague product ideas into evidence-anchored problem statements for PRD v0.1 Spark.

    180 GitHub stars~1.7k tokensUpdated 1 mo ago
    Auto-check passed
  • Prd V01 User Value Articulation

    mattgierhart/PRD-driven-context-engineering

    Transform validated pain points into articulated user value statements for PRD v0.1 Spark.

    180 GitHub stars~1.6k tokensUpdated 1 mo ago
    Auto-check passed

Questions about Prd V08 Monitoring Setup

What does Prd V08 Monitoring Setup do?

Define monitoring strategy, metrics collection, and alerting thresholds during PRD v0.8 Deployment & Ops. Prd V08 Monitoring Setup is an agent skill from mattgierhart/PRD-driven-context-engineering.8 Deployment & Ops.

When should I use Prd V08 Monitoring Setup?

Prd V08 Monitoring Setup fits situations like: requests to set up monitoring; user asks what should we monitor?; alerting strategy; monitoring setup.

How do I install Prd V08 Monitoring Setup in Claude Code?

Run `npx skills add mattgierhart/PRD-driven-context-engineering --skill prd-v08-monitoring-setup -a claude-code`. Or copy the skill folder (.claude/skills/prd-v08-monitoring-setup in mattgierhart/PRD-driven-context-engineering) into .claude/skills/prd-v08-monitoring-setup in your project. Claude Code loads it when a task matches its description.

How do I install Prd V08 Monitoring Setup in Codex?

Run `npx skills add mattgierhart/PRD-driven-context-engineering --skill prd-v08-monitoring-setup -a codex`. Or copy the skill folder (.claude/skills/prd-v08-monitoring-setup in mattgierhart/PRD-driven-context-engineering) into .agents/skills/prd-v08-monitoring-setup in your project. Codex loads it when a task matches its description.

Can I use Prd V08 Monitoring Setup in Cursor, Gemini CLI or GitHub Copilot?

Cursor, Gemini CLI, GitHub Copilot and OpenCode also load SKILL.md folders. With the skills CLI, run `npx skills add mattgierhart/PRD-driven-context-engineering --skill prd-v08-monitoring-setup -a cursor` (or -a gemini-cli, github-copilot or opencode for the others). To copy it by hand, put the folder in .cursor/skills/prd-v08-monitoring-setup, .gemini/skills/prd-v08-monitoring-setup, .github/skills/prd-v08-monitoring-setup and .opencode/skills/prd-v08-monitoring-setup in your project.

What does Prd V08 Monitoring Setup need to run?

SKILL.md names no scripts, command-line tools or credentials: Prd V08 Monitoring Setup is instructions for the agent only. Its frontmatter pre-approves these tools: Read, Write, Edit, Glob, Grep, Bash.

Does Prd V08 Monitoring Setup access the network?

SKILL.md contains no URLs. Any network use would come from the scripts or tools the agent runs. This is read from the text; nothing was executed.

Is Prd V08 Monitoring Setup safe to install?

Our automated static check of SKILL.md found notes only (pre-approves every shell command (allowed-tools: bash)), nothing it rates as a warning. It is not a guarantee. Review the folder before installing.

What licence does Prd V08 Monitoring Setup use?

Prd V08 Monitoring Setup is published under the MIT licence (the repository's licence). It allows redistribution, so the full SKILL.md is shown on this page.

How many tokens does Prd V08 Monitoring Setup use?

About 3.8k tokens (SKILL.md is roughly 15k characters). Agents keep only the skill's name and description in context until a task matches; then they load SKILL.md in full. Its references folder adds about 11k tokens, read only when the agent opens those files.

What are the alternatives to Prd V08 Monitoring Setup?

Skills that share tags, products or a category with Prd V08 Monitoring Setup: Expert Team (ReJeCtAll/ExpertTeam-Codex, 113 stars), Dev Architecture Playbook (majiayu000/spellbook, 287 stars), Alerting Irm (grafana/skills, 282 stars) and Promql (grafana/skills, 282 stars). The comparison table on this page puts their stars, adoption, token cost, safety result and licence side by side.

Who maintains Prd V08 Monitoring Setup?

mattgierhart (a GitHub user) maintains it in mattgierhart/PRD-driven-context-engineering, which has 180 GitHub stars. The repository holds 45 skills in this directory. The repository was last updated on August 31, 2026.

Source: mattgierhart/PRD-driven-context-engineering on GitHub. Facts on this page come from the repository at the commit we read; the author's words are quoted as theirs.