Run any Skill in Manus with one click

openspec

Stars14

Forks1

UpdatedMay 12, 2026 at 12:01

Spec-driven development with OpenSpec. Use when the user mentions OpenSpec, OPSX, spec-driven development, SDD, change proposals, delta specs, /opsx commands, or wants structured planning for features, migrations, refactors, or bug fixes.

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

saski

saski/augmentedcode-configuration

View GitHub Repository View Creator Repositories

Download

Run Skill in Manus

Related occupationsSOC

Based on SOC occupation classification

Software DevelopersComputer and Mathematical Occupations·SOC 15-1252

File Explorer

2 files

SKILL.md

readonly

name	openspec
description	Spec-driven development with OpenSpec. Use when the user mentions OpenSpec, OPSX, spec-driven development, SDD, change proposals, delta specs, /opsx commands, or wants structured planning for features, migrations, refactors, or bug fixes.
metadata	{"category":"workflow-automation","pattern":"pipeline","owner":"engineering","status":"active","review_cycle_days":90,"benchmark_after_model_update":true,"outputs":["change-proposal","delta-spec","design","task-list","implementation-verification"]}
compatibility	Portable Agent Skills core; OpenSpec CLI is optional but preferred when installed.

OpenSpec

Use OpenSpec as the planning layer when work needs durable requirements, reviewable intent, or a multi-session implementation trail. Keep the repository's normal engineering rules active: start implementation with tests where applicable, work in small steps, and run the project's canonical checks.

Before You Start

Check whether the current repository already has an openspec/ directory or docs/openspec/.
Check whether the CLI is available with openspec --version.
If OpenSpec is missing and the user asked to adopt it, initialize it with the shared installer after confirming the target repository.
If OpenSpec is present, read the relevant openspec/specs/*/spec.md and active openspec/changes/<change>/ artifacts before proposing edits. If openspec/ is a symlink to docs/openspec/, keep using openspec/... paths for CLI compatibility while recognizing that the physical files live under docs/openspec/.
Treat OpenSpec artifacts as source files: update them with the same care as code, keep language precise, and include them in validation.

Shared Installer

This tooling repo exposes a portable installer through the shared ~/.agents symlink:

~/.agents/skills/openspec/scripts/install-openspec
~/.agents/skills/openspec/scripts/install-openspec /path/to/repo

The installer uses this placement policy:

If the target repository already has docs/, create docs/openspec/ and a root openspec -> docs/openspec symlink so openspec CLI commands work from the repo root.
If the target repository has thoughts/ but no docs/, create thoughts/openspec/ and a root openspec -> thoughts/openspec symlink.
If the target repository does not have docs/ or thoughts/, create the normal root openspec/ directory.
Do not move an existing real root openspec/ directory automatically; treat it as an existing installation.

Default Workflow

Use the core OPSX path for most changes:

Explore unclear requirements before creating artifacts.
Propose the change and generate planning artifacts.
Review and refine proposal.md, delta specs, design.md, and tasks.md.
Apply tasks one at a time, checking off completed items in tasks.md.
Verify implementation against the proposal, specs, design, and tasks.
Sync and archive the change when the implementation is complete.

If slash commands are available in the active tool, prefer:

/opsx:explore for investigation before committing to a change.
/opsx:propose <change> for the default proposal-to-tasks path.
/opsx:apply <change> for implementation.
/opsx:verify <change> when the expanded workflow is enabled.
/opsx:sync <change> to merge delta specs into canonical specs when needed.
/opsx:archive <change> to finalize completed work.

If the tool does not expose slash commands, perform the same workflow directly in files under openspec/changes/<change>/. In docs-first repositories, that path may resolve through the root symlink to docs/openspec/changes/<change>/.

CLI Use

Prefer CLI commands for repository state and validation when available:

openspec list
openspec list --specs
openspec show <change-or-spec>
openspec status <change>
openspec validate --all

Use --json for agent-readable output when the command supports it. Do not build long-lived automation on beta workspace commands unless the user explicitly asks for experimental workspace setup.

Artifact Standards

Name change folders in kebab-case and avoid generic names like update or wip.
Write requirements with SHALL statements and concrete scenarios.
Keep scenarios in GIVEN, WHEN, THEN, and optional AND form.
Keep tasks small enough to implement and verify independently.
Update the design when implementation decisions change.
Run OpenSpec validation and the repository's canonical validation before claiming completion.

Brownfield Repositories

OpenSpec works incrementally. Do not try to generate a full specification library upfront unless the user asks for a documentation pass. For mature codebases, create or update specs around the change being made, then let the spec library grow through real work.

Setup Guidance

When initializing OpenSpec, choose the smallest tool scope that matches the user's request:

~/.agents/skills/openspec/scripts/install-openspec
openspec update

After upgrading the CLI, run openspec update in initialized repositories so generated tool instructions stay current.

More from this repository

same repository

personal-knowledge-routing

saski/augmentedcode-configuration

Route durable personal context and reusable knowledge between augmentedcode-configuration and the personal knowledge vault. Use when the user asks to remember, persist, capture, retrieve, or organize personal knowledge; when deciding whether information belongs in rules, skills, portfolio, notes, maps, or inbox; or when using personal-knowledge-vault as a low-context reference layer.

2026-06-1714

github-host-alias

saski/augmentedcode-configuration

Use when running git clone, git remote add, git remote set-url, or suggesting GitHub SSH commands to ensure all GitHub access uses the saski SSH host alias.

2026-06-1714

building-data-apps

saski/augmentedcode-configuration

Build modern data apps, dashboards, and interactive reports using either React + Vite or Streamlit. Includes optional Gemini Data Analytics chat integration for an AI powered "chat with your data" experience. Relevant when any of the following conditions are true: 1. User explicitly requests to build a data dashboard, data application, or visualization UI, and the UI pulls data from a GCP database (defaulting to BigQuery unless otherwise specified). 2. You need to generate a frontend web application to interact with, query, and visualize data from GCP data sources. 3. User wants to build a "chat with your data" experience or integrate the Gemini Data Analytics chat API into a web interface. Do NOT use when any of the following conditions are true: 1. The request is for building backend-only services. 2. The request is for simple CLI scripts or command-line applications. 3. The web application is not data-centric or does not involve visualizing/querying data from GCP sources.

2026-06-0314

gcp-spark

saski/augmentedcode-configuration

Develops and executes Spark code on Dataproc Clusters and Serverless. Reads and writes data using BigLake Iceberg catalogs, BigQuery and Spanner. Debugs execution failures. Use when: - Writing Spark ETL pipelines on GCP. - Training or running inference with ML models with spark on GCP. - Managing Spark clusters, jobs, batches, and interactive sessions. Don't use when: - Writing generic Python scripts that don't use Spark. - Performing simple SQL queries that can be done directly in BigQuery.

2026-06-0314

lustra

saski/augmentedcode-configuration

Use when the user wants to clean up AI slop, harden a codebase, or run technical due diligence: review code for security flaws and vulnerable or wrongly-licensed dependencies, find and remove dead code, audit dependency health, run and triage linters, type checkers, test suites and formatters, evaluate design principles (SOLID and the cohesion/coupling equivalents for non-OO stacks), audit logging and observability, find performance smells, check documentation and CI health, scaffold baseline configs for the detected stack, do a structured code review, guide a one-major-at-a-time dependency migration, fix project structure, or produce one aggregated health report across all of these. Triggers on phrases like clean this up, find security issues, remove dead code, check dependencies, lint, typecheck, run the tests, format, review my code, check the design, check logging, is this slow, migrate a dependency, fix the project structure, set up the project, audit everything, due diligence, or this looks like AI slop

2026-06-0314

llm-council

saski/augmentedcode-configuration

Run any question, idea, or decision through a council of 5 AI advisors who independently analyze it, peer-review each other anonymously, and synthesize a final verdict. Based on Karpathy's LLM Council methodology. MANDATORY TRIGGERS: 'council this', 'run the council', 'war room this', 'pressure-test this', 'stress-test this', 'debate this'. STRONG TRIGGERS (use when combined with a real decision or tradeoff): 'should I X or Y', 'which option', 'what would you do', 'is this the right move', 'validate this', 'get multiple perspectives', 'I can't decide', 'I'm torn between'. Do NOT trigger on simple yes/no questions, factual lookups, or casual 'should I' without a meaningful tradeoff (e.g. 'should I use markdown' is not a council question). DO trigger when the user presents a genuine decision with stakes, multiple options, and context that suggests they want it pressure-tested from multiple angles.

2026-05-2714

name	openspec
description	Spec-driven development with OpenSpec. Use when the user mentions OpenSpec, OPSX, spec-driven development, SDD, change proposals, delta specs, /opsx commands, or wants structured planning for features, migrations, refactors, or bug fixes.
metadata	{"category":"workflow-automation","pattern":"pipeline","owner":"engineering","status":"active","review_cycle_days":90,"benchmark_after_model_update":true,"outputs":["change-proposal","delta-spec","design","task-list","implementation-verification"]}
compatibility	Portable Agent Skills core; OpenSpec CLI is optional but preferred when installed.

OpenSpec

Before You Start

Check whether the current repository already has an openspec/ directory or docs/openspec/.
Check whether the CLI is available with openspec --version.
If OpenSpec is missing and the user asked to adopt it, initialize it with the shared installer after confirming the target repository.
If OpenSpec is present, read the relevant openspec/specs/*/spec.md and active openspec/changes/<change>/ artifacts before proposing edits. If openspec/ is a symlink to docs/openspec/, keep using openspec/... paths for CLI compatibility while recognizing that the physical files live under docs/openspec/.
Treat OpenSpec artifacts as source files: update them with the same care as code, keep language precise, and include them in validation.

Shared Installer

This tooling repo exposes a portable installer through the shared ~/.agents symlink:

~/.agents/skills/openspec/scripts/install-openspec
~/.agents/skills/openspec/scripts/install-openspec /path/to/repo

The installer uses this placement policy:

If the target repository already has docs/, create docs/openspec/ and a root openspec -> docs/openspec symlink so openspec CLI commands work from the repo root.
If the target repository has thoughts/ but no docs/, create thoughts/openspec/ and a root openspec -> thoughts/openspec symlink.
If the target repository does not have docs/ or thoughts/, create the normal root openspec/ directory.
Do not move an existing real root openspec/ directory automatically; treat it as an existing installation.

Default Workflow

Use the core OPSX path for most changes:

Explore unclear requirements before creating artifacts.
Propose the change and generate planning artifacts.
Review and refine proposal.md, delta specs, design.md, and tasks.md.
Apply tasks one at a time, checking off completed items in tasks.md.
Verify implementation against the proposal, specs, design, and tasks.
Sync and archive the change when the implementation is complete.

If slash commands are available in the active tool, prefer:

/opsx:explore for investigation before committing to a change.
/opsx:propose <change> for the default proposal-to-tasks path.
/opsx:apply <change> for implementation.
/opsx:verify <change> when the expanded workflow is enabled.
/opsx:sync <change> to merge delta specs into canonical specs when needed.
/opsx:archive <change> to finalize completed work.

CLI Use

Prefer CLI commands for repository state and validation when available:

openspec list
openspec list --specs
openspec show <change-or-spec>
openspec status <change>
openspec validate --all

Use --json for agent-readable output when the command supports it. Do not build long-lived automation on beta workspace commands unless the user explicitly asks for experimental workspace setup.

Artifact Standards

Name change folders in kebab-case and avoid generic names like update or wip.
Write requirements with SHALL statements and concrete scenarios.
Keep scenarios in GIVEN, WHEN, THEN, and optional AND form.
Keep tasks small enough to implement and verify independently.
Update the design when implementation decisions change.
Run OpenSpec validation and the repository's canonical validation before claiming completion.

Brownfield Repositories

Setup Guidance

When initializing OpenSpec, choose the smallest tool scope that matches the user's request:

~/.agents/skills/openspec/scripts/install-openspec
openspec update

After upgrading the CLI, run openspec update in initialized repositories so generated tool instructions stay current.