Operate

Skill pooyagolchian/specforge/plugins/specforge/skills/operate

Produce the Operations plan for a completed feature — deploy steps, runbook, observability, rollback, and handoff. Use when a feature is implemented and the user wants to ship it, hand it off, operationalize it, write a runbook, or plan deployment/rollback/monitoring. Writes operations.md; it plans operations, it does not run deploys.From its SKILL.md

Install

npx -y skills add pooyagolchian/specforge --skill operate

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

One thing to look at

0 stars0 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.

SKILL.md

3.2 KB, 711 tokens by cl100k_base, as published. Nobody here has run it

/specforge:operate — the Operations phase (ship & own it)

Close the lifecycle. After a feature is built, turn it into something that can be shipped and owned: a concrete deploy plan, a runbook, observability, a rollback plan, and a handoff. This is AI-DLC's Operations phase. It plans operations — it does not execute deployments.

When to use

A feature's implement stage is done and the user wants to ship / hand off / operationalize it.
Trigger words: "ship", "deploy plan", "runbook", "handoff", "operationalize", "on-call", "rollback".

Preconditions

An active feature exists and is implemented. If implement isn't done, say so and offer to finish it (or note the user is planning operations ahead of time — that's fine, just flag it).

Steps

Read the active feature's spec.md, plan.md, and quickstart.md for context (how it runs, what it depends on).
Write specforge/specs/NNN-slug/operations.md from ${CLAUDE_SKILL_DIR}/../_shared/operations-template.md (or the skeleton below), filling:
- Deployment — ordered steps, migrations, flags/config/secrets, post-deploy verification.
- Runbook — symptoms → cause → action for likely failures; common ops commands; escalation.
- Observability — metrics to watch, alert thresholds, where logs/traces live.
- Rollback — how to revert safely, data/back-compat considerations, roll-back-vs-forward criteria.
- Handoff & Ownership — owner/on-call, dependencies, known limitations/follow-ups.
If operations.md already exists, update it in place — don't clobber prior notes.
Update specforge/state.md: add/ensure | NNN-slug | operate | done | <date> |.
Audit: append | <today ISO-8601> | NNN-slug | operate | Operations plan written; owner: <who> |.
Report that the feature is ready to ship, and surface any follow-ups (each of which may deserve a new /specforge:specify).

Operations skeleton (if the shared template is unavailable)

# Operations Plan: <name>
## Deployment      (steps, migrations, flags, post-deploy verification)
## Runbook         (symptoms → cause → action; common ops; escalation)
## Observability   (metrics, alerts, logs/traces)
## Rollback        (safe revert, data/back-compat, roll-back-vs-forward)
## Handoff & Ownership  (owner/on-call, dependencies, follow-ups)
## Sign-off

Guardrails

Plan, don't deploy. This skill writes the operations plan; it must not run deploy/infra commands. If the user wants to actually deploy, that's their action (or a separate, explicitly-approved step).
Keep it concrete and runnable — real commands and thresholds beat vague prose.
New operational scope (a monitoring feature, an infra change) is a new /specforge:specify cycle, not something to smuggle in here.

What ships with it

Read from the repository

Just SKILL.md. No reference files, no scripts.