How do I install the Openspec Authoring skill?

Run npx skillmds add majiayu000/openspec-authoring in your terminal (requires Node.js), paste this page's agent-chat prompt into Claude, Cursor, or any MCP-connected agent, or download the SKILL.md file and copy it into your agent's skills directory.

Is Openspec Authoring safe to use?

This skill has not completed SkillMD's automated safety review yet. Capability flags: docs only. SkillMD never runs a skill's scripts for you; review the SKILL.md before installing.

Which AI agents work with Openspec Authoring?

This skill is tagged as working with Claude Code, Claude.ai, OpenAI Codex. SKILL.md is an open format, so most agents that read a skills directory can load it too.

Is Openspec Authoring free to use?

Yes. Installing skills from SkillMD is free, and the skill stays under its author's original license.

Who published Openspec Authoring?

majiayu000 (@majiayu000) published this skill. Their other Agent Skills are listed on their SkillMD profile.

Openspec Authoring by majiayu000 — Agent Skill

Name: Openspec Authoring
Rating: 4.2 (5 reviews)
Author: majiayu000

File contents

OpenSpec Authoring Patterns

Trigger Keywords: openspec, proposal, change-id, tasks.md, spec delta, requirement, scenario, validation, archive

Agent Integration: Used by spec-writer and planning agents when creating or updating OpenSpec proposals, tasks, and spec files.

Metadata & Frontmatter

Proposals/Tasks: include Change ID, Status, Date, and Author near the top.
Specs: start with # Spec: <Title> plus capability/status/related lines.
Use verb-led, kebab-case change-id (e.g., add-doc-spec-writer-agent).
Keep managed instruction blocks intact when present.

Required Section Ordering

proposal.md: Executive Summary → Background → Goals → Scope/Non-Goals → Approach → Risks & Mitigations → Validation → Open Questions.
tasks.md: Overview → Phase/Task grouping with checklists; include validation notes where possible.
spec.md (delta): Overview → ## ADDED|MODIFIED|REMOVED Requirements → Scenarios per requirement with Given/When/Then.

Requirement & Scenario Patterns

Each requirement MUST have at least one #### Scenario: block.
Scenario steps use bolded Given/When/Then lines on their own lines.
Keep requirements testable and behavior-focused; avoid solutions in "Then".
Use backticks for capability or file references when helpful.

Validation Checklist

✅ Run openspec validate <change-id> --strict when available.
✅ Ensure every referenced skill/agent/capability exists or is added in the change.
✅ Confirm paths use workspace-relative notation (openspec/specs/...).
✅ Keep documentation generic and reusable across Python projects.

Archiving Notes

Archive changes only after deployment, using date-prefixed folder under openspec/archive/.
Use openspec archive <id> --skip-specs --yes only for tooling-only changes.

---name: openspec-authoringdescription: Enforces OpenSpec authoring conventions including metadata blocks, section ordering, requirement/scenario structure, and validation steps.--- # OpenSpec Authoring Patterns **Trigger Keywords**: openspec, proposal, change-id, tasks.md, spec delta, requirement, scenario, validation, archive **Agent Integration**: Used by `spec-writer` and planning agents when creating or updating OpenSpec proposals, tasks, and spec files. ## Metadata & Frontmatter - Proposals/Tasks: include `Change ID`, `Status`, `Date`, and `Author` near the top. - Specs: start with `# Spec: <Title>` plus capability/status/related lines. - Use verb-led, kebab-case `change-id` (e.g., `add-doc-spec-writer-agent`). - Keep managed instruction blocks intact when present. ## Required Section Ordering - **proposal.md**: Executive Summary → Background → Goals → Scope/Non-Goals → Approach → Risks & Mitigations → Validation → Open Questions. - **tasks.md**: Overview → Phase/Task grouping with checklists; include validation notes where possible. - **spec.md (delta)**: Overview → `## ADDED|MODIFIED|REMOVED Requirements` → Scenarios per requirement with Given/When/Then. ## Requirement & Scenario Patterns - Each requirement MUST have at least one `#### Scenario:` block. - Scenario steps use bolded **Given/When/Then** lines on their own lines. - Keep requirements testable and behavior-focused; avoid solutions in "Then". - Use backticks for capability or file references when helpful. ## Validation Checklist - ✅ Run `openspec validate <change-id> --strict` when available. - ✅ Ensure every referenced skill/agent/capability exists or is added in the change. - ✅ Confirm paths use workspace-relative notation (`openspec/specs/...`). - ✅ Keep documentation generic and reusable across Python projects. ## Archiving Notes - Archive changes only after deployment, using date-prefixed folder under `openspec/archive/`. - Use `openspec archive <id> --skip-specs --yes` only for tooling-only changes.

Frequently asked questions