AgentStack
Sign in Publish
MCP servers Skills Toolkits Why AgentStack Sell Docs
Sign in
SKILL verified MIT Self-run

Spec Workflow

skill-yipxiyi-openarc-spec-workflow · by Yipxiyi

Use when creating or updating OpenArc feature specs with versioning, acceptance criteria, implementation tracking, and technical direction.

↗ Website ↗ Repository
— No reviews yet
0 installs
11 views
0.0% view→install

Install

$ agentstack add skill-yipxiyi-openarc-spec-workflow

✓ scanned · ✓ verified — works with Claude Code, Cursor, and more.

Security review

✓ Passed

No issues found. Passed automated security review. · v0.1.0 How review works →

  • ✓ Prompt-injection patterns
  • ✓ Secret / credential exfiltration
  • ✓ Dangerous shell & filesystem operations
  • ✓ Untrusted network calls
  • ✓ Known-malicious package signatures

What it can access

  • ✓ Network access No
  • ✓ Filesystem access No
  • ✓ Shell / process execution No
  • ✓ Environment & secrets No
  • ✓ Dynamic code execution No

From automated source analysis of v0.1.0. “Used” means the capability is present in the source — more access means more to trust, not that it’s unsafe.

Are you the author of Spec Workflow? Claim this listing to set pricing, connect Stripe payouts, and keep 70% of every sale.
Sign up to claim

About

Spec Workflow

Use this skill when a feature, system change, or product direction needs a structured spec before implementation.

Goal

Create lightweight specs that keep humans and coding agents aligned without adding heavy process overhead.

Use Clarification Gate output when available. If the feature behavior, non-goals, compatibility constraints, or acceptance criteria are not clear, run clarification-gate before drafting the spec.

Location

Use docs/specs/ by default.

Recommended file names:

docs/specs/
  0.1.0-auth-system.md
  0.2.0-editor-upgrade.md
  0.3.0-cloud-sync.md

Status Values

  • Draft
  • Planned
  • In Progress
  • Implemented
  • Verified

Version Selection

Use version-governance before choosing a new spec version when the user asks for a change to an existing feature or governance system.

Default mapping:

  • Patch spec: small clarification, typo, doc-only correction, or non-behavioral refinement.
  • Minor spec: backward-compatible feature, optional workflow, new template, or new section.
  • Major spec: breaking behavior, renamed public workflow, removed capability, or incompatible governance structure.

Propose the exact version and ask the user to confirm before naming the spec file.

Required Spec Sections

Use templates/SPEC.template.md as the baseline:

  • Background
  • Goals
  • Non-Goals
  • User Stories
  • Requirements
  • Existing System Review
  • Technical Approach
  • Implementation Plan
  • Tasks
  • Acceptance Criteria
  • Risks
  • Open Questions
  • Changelog

Rules

  • Keep specs concrete and implementation-facing.
  • Separate goals from non-goals.
  • Include acceptance criteria that can be verified.
  • Preserve Clarification Gate decisions in Background, Goals, Non-Goals, Requirements, Risks, or Open Questions instead of creating a separate intake document by default.
  • Update status and changelog after implementation.
  • Do not use specs as a dumping ground for unrelated product ideas.
  • Record the confirmed version decision in the changelog.

Source & license

This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code.

Install and usage instructions live in the source repository linked above.

Reviews

No reviews yet — be the first.

Write a review

Versions

  • v0.1.0 Imported from the upstream source.

More in Agent Skills