Run any Skill in Manus with one click

specflow-ops

Stars2

Forks0

UpdatedJuly 10, 2026 at 04:07

Live-operations workflow for the ops pack (RUN + MONITOR). Use when the user deploys or runs something live, monitors a live system's health/metrics, captures ephemeral/live data that won't be reproducible, or investigates drift. Creates a RUN (deployment frozen at deploy-time) and appends MONITOR observations (timestamped metric/signal journal). Triggers on "deploy", "go live", "monitor this run", "capture live odds/data", "is it drifting", "check LIVE health / is the deployed run drifting". NOT for offline experiments (use /specflow-autoresearch EXPT), writing app code (use /specflow-execute STORY), requirements authoring (use /specflow-discover), or a project-wide spec/health audit (use /specflow-audit — "health check" means project health there, not live-system health here).

Installation

Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.

Run Skill in Manus

Source

Longhuiberkeley

Longhuiberkeley/specflow

View GitHub Repository View Creator Repositories

Download

Run Skill in Manus

Related occupationsSOC

Based on SOC occupation classification

Network and Computer Systems AdministratorsComputer and Mathematical Occupations·SOC 15-1244

SKILL.md

readonly

name

specflow-ops

description

SpecFlow Ops

Track what is live and how it is doing over time. Two artifact types, both in _specflow/ops/:

RUN — a deployment frozen at deploy-time. What is deployed (deployed_ref: path/version/fingerprint), where (environment), when (deployed_at), and what it satisfies (links derives_from the REQ/ARCH, optionally the EXPT/STORY output it promoted). Like a baseline, but for a live system. Status: deployed → live → paused → retired.
MONITOR — an append-only, timestamped observation of a RUN. A metrics snapshot, free-form signals (drift for quant, latency/error-rate for web, sensor values for embedded — domain-neutral), health (ok/degraded/breached), and captures (ephemeral-data refs + freshness for live/short-lived data). Over time, MONITORs are the observation/metric ledger. Status: logged → flagged → resolved.

Domain-neutral by design. Quant specifics (drift, oos_decay) belong in the quant concept→artifact map, not in these fields.

Workflow

Flow A — Deploy (something goes live)

Identify what is being deployed and the artifact it satisfies/promotes from:
- A promoted experiment → links: [{target: EXPT-NNN, role: derives_from}].
- A requirement/architecture it realizes → links: [{target: REQ-NNN|ARCH-NNN, role: derives_from}] (or implements).

Freeze the deployment record — create the RUN with the exact deployed_ref (path or version + fingerprint) and environment. This is immutable intent: a later change to what's live is a new RUN, not an edit.

specflow create --type run --title "<system> — <env>" --status live \
  --set environment=<env> \
  --set deployed_ref=<path/version, fingerprint if known> \
  --set deployed_at=<date> \
  --links <REQ-NNN|ARCH-NNN|EXPT-NNN>:derives_from \
  --skip-dedup-check

Confirm specflow artifact-lint RUN-NNN passes, then present: TLDR (what went live, from what, satisfying what), one next step.

Flow B — Observe (record a snapshot / capture ephemeral data)

Identify the RUN this observation belongs to.

Record the MONITOR — append one entry per observation. Use metrics for numbers, signals for trend/qualitative notes, health for the verdict, captures for any ephemeral data you grabbed (refs + how fresh).

specflow create --type monitor --title "RUN-NNN obs <date>" --status logged \
  --set run=RUN-NNN \
  --set observed_at=<date> \
  --set 'metrics={"<key>": <value>, ...}' \
  --set 'signals={"<key>": "<note>"}' \
  --set health=<ok|degraded|breached> \
  --set 'captures={"<source>": <count>, "freshest_age_min": <n>}' \
  --links RUN-NNN:belongs_to \
  --skip-dedup-check

On a breach (health: breached or a signal crosses a threshold defined in a REQ):
- Set the MONITOR status: flagged (specflow update MON-NNN --status flagged).
- Propose the domain's next action and link it back to the MONITOR: a retrain → create a new LOOP linked --links MON-NNN:informs; a rollback/fix → a DEC or DEF. Do not auto-trigger — surface it for the human.

Recall

What's live right now? specflow trace RUN-NNN — shows the REQ/ARCH/EXPT lineage and all MONITORs.
How is it trending? Read the chain of MONITORs under a RUN (newest last) — that is the metric/drift ledger.
Stale or drifting? specflow brief --next flags a live RUN with no recent MONITOR or a breached MONITOR when the ops pack is active.

Rules

A RUN is frozen at deploy. Changing what's live = a new RUN (derives_from the prior one if it's a successor). Never rewrite a deployed RUN's deployed_ref.
MONITORs are append-only. Correct a bad observation with a new MONITOR (informs/derives_from the wrong one), not an edit.
Every code/script that a RUN executes still traces to a STORY; RUN/MONITOR record the operational reality, they don't replace the spec.

More from this repository

same repository

specflow-audit

Longhuiberkeley/specflow

SCOPE = the whole project. Use for a FULL-PROJECT health review — runs a zero-question deterministic core with optional adversarial wings. Creates AUD and CHL artifacts. Triggers when the user says "audit the project," "health check," "how healthy is the project," "review the whole project," "review overall spec quality," or asks for a comprehensive project-wide assessment. NOT for: single-artifact review (use specflow-artifact-review), reviewing blast radius of recent changes (use specflow-change-impact-review), or quick spot-checks of one file.

2026-07-102

specflow-discover

Longhuiberkeley/specflow

Use to start the SpecFlow requirements discovery workflow — the entry point for any new feature, enhancement, or specification task. Triggers when the user wants to start something NEW — "add a feature," "build a NEW [X]," "I want to create [Z]," "we need [capability]," "capture requirements for," or "what should the system do?" Use this FIRST when the idea is new and no REQ exists yet (if REQs are already approved and stories are queued for coding, use specflow-execute). Also triggers for reverse lifecycle: "rethink the requirements," "revise the requirements," "go back to requirements," or when the user wants to revisit specs after planning or executing. This is step 1 of the core lifecycle — use it FIRST for any new feature or change that needs specification, BEFORE specflow-plan and specflow-execute. NOT for: data exploration, data cleaning, researching technologies, prototyping, running experiments, or technical prep work unrelated to requirements authoring.

2026-07-102

specflow-init

Longhuiberkeley/specflow

Use when setting up SpecFlow in a new or existing project for the FIRST TIME. Triggers when the user says "set up SpecFlow," "initialize the project," or "get started with SpecFlow." Conversational bootstrap that scaffolds directories, installs hooks, generates CI workflows, and recommends next steps. NOT for: re-initializing an already-configured project, adding packs to an existing setup (use specflow-adapter), or routine configuration changes.

2026-07-102

specflow-plan

Longhuiberkeley/specflow

REQUIRED after discover when REQs are approved. Breaks approved requirements into architecture (ARCH), detailed design (DDD), and stories (STORY). Triggers when the user says "design the architecture," "plan the implementation," "break this down," or when REQs are approved and the user is ready to move forward. Also triggers for reverse lifecycle: "rethink the architecture," "revise the plan," "go back to planning," or when the user wants to revisit architecture after executing. This is step 2 of the core lifecycle — use it BEFORE any implementation begins. NOT for: quick bug fixes (use specflow-execute with lean path), research tasks, or infrastructure setup.

2026-07-102

specflow-ship

Longhuiberkeley/specflow

REQUIRED to release a version. Produces a baseline, generates change records (DEC), runs a quick audit, and presents a release summary. Triggers when the user says "release," "ship," "publish v," or asks to tag a version. This is the final step of the core lifecycle — use it when implementation is complete and verified. NOT for: mid-development checkpoints (use specflow-audit or specflow-artifact-review).

2026-07-102

specflow-start

Longhuiberkeley/specflow

Use when unsure which SpecFlow step to run next, or for a quick "where am I / what's next" orientation. Runs `specflow brief --next` for a deterministic next-step recommendation, asks ONE disambiguating question only if intent is ambiguous, and points at the right /specflow-* skill. Triggers on "what should I do," "what's next," "what now," "where do I start," "where are we," "what's the status," "continue," "resume," "remind me where we are," "help me get started," "I'm stuck," "point me in the right direction," or any request that doesn't clearly match a specific lifecycle or review skill. This is the safe default when no other skill clearly fits — prefer routing over guessing. NOT a replacement for the lifecycle skills (discover/plan/execute/ship) or the review skills — it only routes you to the correct one. Prefer this over guessing when the user's intent is vague.

2026-07-102

name

specflow-ops

description

SpecFlow Ops

Track what is live and how it is doing over time. Two artifact types, both in _specflow/ops/:

RUN — a deployment frozen at deploy-time. What is deployed (deployed_ref: path/version/fingerprint), where (environment), when (deployed_at), and what it satisfies (links derives_from the REQ/ARCH, optionally the EXPT/STORY output it promoted). Like a baseline, but for a live system. Status: deployed → live → paused → retired.
MONITOR — an append-only, timestamped observation of a RUN. A metrics snapshot, free-form signals (drift for quant, latency/error-rate for web, sensor values for embedded — domain-neutral), health (ok/degraded/breached), and captures (ephemeral-data refs + freshness for live/short-lived data). Over time, MONITORs are the observation/metric ledger. Status: logged → flagged → resolved.

Domain-neutral by design. Quant specifics (drift, oos_decay) belong in the quant concept→artifact map, not in these fields.

Workflow

Flow A — Deploy (something goes live)

Identify what is being deployed and the artifact it satisfies/promotes from:
- A promoted experiment → links: [{target: EXPT-NNN, role: derives_from}].
- A requirement/architecture it realizes → links: [{target: REQ-NNN|ARCH-NNN, role: derives_from}] (or implements).

specflow create --type run --title "<system> — <env>" --status live \
  --set environment=<env> \
  --set deployed_ref=<path/version, fingerprint if known> \
  --set deployed_at=<date> \
  --links <REQ-NNN|ARCH-NNN|EXPT-NNN>:derives_from \
  --skip-dedup-check

Confirm specflow artifact-lint RUN-NNN passes, then present: TLDR (what went live, from what, satisfying what), one next step.

Flow B — Observe (record a snapshot / capture ephemeral data)

Identify the RUN this observation belongs to.

specflow create --type monitor --title "RUN-NNN obs <date>" --status logged \
  --set run=RUN-NNN \
  --set observed_at=<date> \
  --set 'metrics={"<key>": <value>, ...}' \
  --set 'signals={"<key>": "<note>"}' \
  --set health=<ok|degraded|breached> \
  --set 'captures={"<source>": <count>, "freshest_age_min": <n>}' \
  --links RUN-NNN:belongs_to \
  --skip-dedup-check

On a breach (health: breached or a signal crosses a threshold defined in a REQ):
- Set the MONITOR status: flagged (specflow update MON-NNN --status flagged).
- Propose the domain's next action and link it back to the MONITOR: a retrain → create a new LOOP linked --links MON-NNN:informs; a rollback/fix → a DEC or DEF. Do not auto-trigger — surface it for the human.

Recall

What's live right now? specflow trace RUN-NNN — shows the REQ/ARCH/EXPT lineage and all MONITORs.
How is it trending? Read the chain of MONITORs under a RUN (newest last) — that is the metric/drift ledger.
Stale or drifting? specflow brief --next flags a live RUN with no recent MONITOR or a breached MONITOR when the ops pack is active.

Rules

A RUN is frozen at deploy. Changing what's live = a new RUN (derives_from the prior one if it's a successor). Never rewrite a deployed RUN's deployed_ref.
MONITORs are append-only. Correct a bad observation with a new MONITOR (informs/derives_from the wrong one), not an edit.
Every code/script that a RUN executes still traces to a STORY; RUN/MONITOR record the operational reality, they don't replace the spec.