Install
$ agentstack add skill-lbk-open-super-spec-ss-write-spec ✓ scanned · ✓ verified, works with Claude Code, Cursor, and more.
Security review
✓ PassedNo 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.
Verified badge
Passed review? Show it. Paste this badge into your README, it links to the public security report.
Reliability & compatibility
Declared compatibility
Compatibility is declared by the source manifest. End-to-end runtime verification is coming, see below.
We're building live execution health for every listing: tool-call success rate, median latency, uptime, and last-checked timestamps, measured, not self-reported. It isn't live yet, so we don't show numbers we can't stand behind.
How agent discovery & health will work →About
Write OpenSpec Delta
Generate OpenSpec-compatible delta specs under openspec/changes//. This is a plumbing skill: day-to-day development normally goes through the ss-plan skill, whose Phase 0 runs this same logic automatically.
When To Use
- You need to align capability specs with reviewers before writing a full execution plan.
- You need to adjust delta specs without regenerating the plan.
- The
ss-codingorss-create-prskill reported missing or invalid delta
specs.
Inputs
| Input | Handling | |-------|----------| | A URL to a hosted doc (wiki, Confluence, Google Docs, etc.) | Fetch it with your document-reading tool, or an available doc-integration skill, and convert it to markdown | | A local markdown file | Read the file directly | | Plain text | Treat it as the requirement source |
If none of these is available, ask the user for the proposal, PRD, or requirement text before continuing.
Language of the deltas: write requirement and scenario prose in the same language as the input document (or the project's existing docs, if that's a clearer signal); default to English when neither gives a signal. SHALL/MUST keywords, code identifiers, and file paths always stay in English.
Step 0: Ensure the OpenSpec Skeleton Exists
Check whether openspec/specs/ and openspec/changes/ already exist. If this repository has no OpenSpec structure yet, create it first by following ../ss-references/openspec-skeleton.md, then continue with Step 1 below.
Process
Step 1: Read Context
Read:
openspec/config.yaml, if present- all existing
openspec/specs/*/spec.md - active deltas under
openspec/changes/*/specs/*/spec.md, excludingarchive/ - relevant OpenAPI definitions, if API paths are mentioned
- project guidance files (e.g.,
AGENTS.md/CLAUDE.md), if present
Step 2: Derive Change ID
Use an explicit --change-id if provided. Otherwise derive a kebab-case id from, in order:
- the current branch name, stripped of its type prefix, or
- the proposal title, or
- the first meaningful requirement sentence.
The id must contain only lowercase letters, digits, and hyphens.
Step 3: Decide Capability Ownership
For each requirement:
- Prefer an existing capability under
openspec/specs/. - Create a new capability only when no existing capability owns the behavior.
- Capability names are kebab-case business noun phrases.
- If ownership is ambiguous, stop and ask the user to confirm. Do not guess.
Step 4: Generate Delta Files
Write one file per capability:
openspec/changes//
├── proposal.md
└── specs/
└── /
└── spec.md
Allowed section headings are exactly:
## ADDED Requirements## MODIFIED Requirements## REMOVED Requirements## RENAMED Requirements
Requirement format:
### Requirement:
The system SHALL ...
#### Scenario:
- **WHEN** ...
- **THEN** ...
- **AND** ...
Rules:
- Every Requirement MUST have at least one Scenario.
- Scenario headings MUST be
#### Scenario:. MODIFIEDMUST copy the original Requirement in full, then edit it — don't write a
partial diff.
REMOVEDMUST include a Reason and a Migration note.RENAMEDusesFROM: → TO:.- Do not write implementation details. Specs describe observable behavior only.
Step 5: Self-Review
Verify:
- every source requirement is represented
- existing capabilities were reused where appropriate
- no placeholder text remains
- every
MODIFIEDentry is complete - every
REMOVEDentry has a Migration note - OpenAPI paths mentioned in specs match available OpenAPI definitions, when present
Output
Report:
- the
change-id - files written
- capabilities touched
- ADDED / MODIFIED / REMOVED / RENAMED counts
- any user decisions still pending
Suggest the next step: run the ss-plan skill with the same input to generate the execution plan.
Source & license
This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code.
- Author: lbk-open
- Source: lbk-open/super-spec
- License: Apache-2.0
- Homepage: https://www.npmjs.com/package/@lbk-open/super-spec
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.