Openspec Context Loading
Discover existing OpenSpec capabilities, active changes, and requirements before editing or proposing new work.
Overview
openspec-context-loading is an agent skill most often used in Build (also Validate scope, Operate iterate) that discovers and summarizes OpenSpec specs, active changes, and requirements from the repo.
Install
npx skills add https://github.com/forztf/open-skilled-sdd --skill openspec-context-loadingWhat is this skill?
- Search → Read → Summarize workflow for specification context
- Lists all capability dirs and spec.md files under spec/specs
- Surfaces active changes under spec/changes with discovery shell patterns
- Answers what requirements and capabilities exist and where features are specified
- Trigger phrases: openspec context, list capabilities, show changes, what's in the spec
Adoption & trust: 722 installs on skills.sh; 9 GitHub stars; 3/3 security scanners passed (skills.sh audits).
What problem does it solve?
You need to change or implement something but do not know which specs already exist, what changes are in progress, or where requirements live in the tree.
Who is it for?
OpenSpec or spec/ tree workflows where agents must read before write.
Skip if: Greenfield repos with no spec/specs layout or when you only need generic codebase grep without spec semantics.
When should I use this skill?
User asks about project state, existing specs, active changes, available capabilities, or needs context discovery (e.g. "openspec context", "what specs exist", "list capabilities").
What do I get? / Deliverables
You get a structured inventory of capabilities, active changes, and requirement locations so the next edit or proposal aligns with documented intent.
- Summary of existing specs and capabilities
- List of active changes
- Pointers to relevant spec.md paths
Recommended Skills
Journey fit
Spans multiple journey phases - primary shelf plus alternate fits below.
Spec and change discovery sits in the build PM shelf because it maps the living contract tree agents follow during implementation. PM subphase is where solo builders reconcile what is already specified versus what is in flight under spec/changes.
Where it fits
Before committing to a feature, list capabilities to see if it is already specified.
Load active changes so your agent does not duplicate an in-flight proposal.
Summarize spec/requirements for a handoff comment or PR description.
Cross-check implementation claims against the canonical spec.md for a capability.
How it compares
Use instead of ad-hoc find/grep in chat when your project standardizes specs under spec/specs and changes under spec/changes.
Common Questions / FAQ
Who is openspec-context-loading for?
Solo and indie builders (and small teams) shipping with agentic workflows that keep specifications in-repo under OpenSpec-style paths.
When should I use openspec-context-loading?
At the start of implementation, before proposing a change, during validate-style scope checks, or when you ask what specs exist, list capabilities, or show active changes.
Is openspec-context-loading safe to install?
Review the Security Audits panel on this Prism page for install risk and file hash; the skill suggests read-only discovery commands but agents may still run shell find/list on your filesystem.
SKILL.md
READMESKILL.md - Openspec Context Loading
# Specification Context Loading Discovers and loads project specifications, active changes, and requirements to provide context. ## Quick Start Context loading helps answer: - What specs exist in this project? - What changes are currently active? - What requirements are defined? - What capabilities does the system have? - Where is a specific feature specified? **Basic pattern**: Search → Read → Summarize ## Discovery Commands ### List All Specifications ```bash # Find all spec files find spec/specs -name "spec.md" -type f # Find all capability directories find spec/specs -mindepth 1 -maxdepth 1 -type d # Show spec tree tree spec/specs/ # if tree is installed # or ls -R spec/specs/ ``` **Output format**: ``` spec/specs/ ├── authentication/ │ └── spec.md ├── billing/ │ └── spec.md └── notifications/ └── spec.md ``` ### List Active Changes ```bash # Show all active changes find spec/changes -maxdepth 1 -type d -not -path "spec/changes" -not -path "*/archive" | sort # Show with modification dates find spec/changes -maxdepth 1 -type d -not -path "spec/changes" -not -path "*/archive" -exec ls -ld {} \; # Count active changes find spec/changes -maxdepth 1 -type d -not -path "spec/changes" -not -path "*/archive" | wc -l ``` ### List Archived Changes ```bash # Show all archived changes ls -1 spec/archive/ # Show with dates ls -la spec/archive/ # Find recently archived (last 7 days) find spec/archive/ -maxdepth 1 -type d -mtime -7 ``` ### Search for Requirements ```bash # Find all requirements grep -r "### Requirement:" spec/specs/ # Find requirements in specific capability grep "### Requirement:" spec/specs/authentication/spec.md # List unique requirement names grep -h "### Requirement:" spec/specs/**/*.md | sed 's/### Requirement: //' | sort ``` ### Search for Scenarios ```bash # Find all scenarios grep -r "#### Scenario:" spec/specs/ # Count scenarios per spec for spec in spec/specs/**/spec.md; do count=$(grep -c "#### Scenario:" "$spec") echo "$spec: $count scenarios" done ``` ### Search by Keyword ```bash # Find specs mentioning "authentication" grep -r -i "authentication" spec/specs/ # Find requirements about "password" grep -B 1 -A 5 -i "password" spec/specs/**/*.md | grep -A 5 "### Requirement:" # Find scenarios about "error" grep -B 1 -A 10 -i "error" spec/specs/**/*.md | grep -A 10 "#### Scenario:" ``` ## Common Queries ### Query 1: "What specs exist?" ```bash # List all capabilities find spec/specs -mindepth 1 -maxdepth 1 -type d -exec basename {} \; # Count requirements per capability for cap in spec/specs/*/; do name=$(basename "$cap") count=$(grep -c "### Requirement:" "$cap/spec.md" 2>/dev/null || echo "0") echo "$name: $count requirements" done ``` **Response format**: ```markdown ## Existing Specifications The project has specifications for the following capabilities: - **authentication**: 8 requirements - **billing**: 12 requirements - **notifications**: 5 requirements Total: 3 capabilities, 25 requirements ``` ### Query 2: "What changes are active?" ```bash # List with proposal summaries for change in spec/changes/*/; do if [ "$change" != "spec/changes/archive/" ]; then id=$(basename "$change") echo "=== $id ===" head -n 20 "$change/proposal.md" | grep -A 3 "## Why" fi done ``` **Response format**: ```markdown ## Active Changes Currently active changes: ### add-user-auth **Why**: Users need secure authentication... ### update-billing-api **Why**: Payment processing requires v2 API...