Operate

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

Spec-driven AI development lifecycle for Claude Code — spec-kit + AI-DLC fused, with hook-enforced human-approval gates. Installable plugin + marketplace.

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.

2 things to look at

13 days oldThe repository was created 13 days ago. New is not bad, but a brand new repository carrying a familiar-sounding name is the shape a typosquat arrives in, and there has been no time for anyone else to find a problem with it.
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.

What its author says it does

Copied from the file, not written here

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.

SKILL.md

3.2 KB, 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.