Agent skill

Openspec Linearized

by intent-driven-dev in intent-driven-dev/openspec-schemas

A skill your agent uses whenever Codex operates on an OpenSpec change lifecycle or artifact, including propose/new change, apply/implement tasks, archive/finalize, sync specs, continue/update…

MITAuto-check passed

Install Openspec Linearized

skills CLI
$ npx skills add intent-driven-dev/openspec-schemas --skill openspec-linearized -a claude-code

Project install by default; add -g for ~/.claude/skills/.

GitHub CLI
$ gh skill install intent-driven-dev/openspec-schemas openspec-linearized --agent claude-code

Project scope by default; add --scope user for a personal install. Needs GitHub CLI 2.90.0 or later (public preview).

Manual copy
$ git clone --depth 1 https://github.com/intent-driven-dev/openspec-schemas.git skills-src && mkdir -p .claude/skills && cp -r skills-src/.codex/skills/openspec-linearized .claude/skills/openspec-linearized && rm -rf skills-src

Use ~/.claude/skills/ instead of .claude/skills for a personal install. The folder must contain SKILL.md.

Claude Code skills documentation · loads skills from .claude/skills/

Facts

Skill name
openspec-linearized
GitHub stars
105
Token cost
~1.8k tokens
SKILL.md length
869 words
Files
3 (incl. references)
Skills in repo
3
Repo updated
First seen
Licence
MIT

At a glance

A skill your agent uses whenever Codex operates on an OpenSpec change lifecycle or artifact, including propose/new change, apply/implement tasks, archive/finalize, sync specs, continue/update…

  • Codex operates on an OpenSpec change lifecycle
  • SKILL.md covers Invocation Contract, Start, Linear Rules and Phase Hooks, plus 1 more section
  • Instructions only: no scripts, shell commands, URLs or credentials in SKILL.md
  • Including propose/new change

What it does

Openspec Linearized is an agent skill from intent-driven-dev/openspec-schemas. Use whenever Codex operates on an OpenSpec change lifecycle or artifact, including propose/new change, apply/implement tasks, archive/finalize, sync specs, continue/update artifacts, validate/status checks, or work under openspec/changes/. This is the Linear lifecycle overlay for OpenSpec work: bind Linear issues, maintain openspec/linear.yaml, update Linear issue business context/status, keep technical design/tasks in the repo, and mirror canonical specs into Linear Project Documents after archive.

Its SKILL.md is about 1.8k tokens, which your agent loads only when the skill is triggered. The skill folder holds 4 other files, including reference files (for example `agents/openai.yaml` and `references/lifecycle.md`).

It works with Linear. The repository describes itself as: Collection of OpenSpec Custom Schema for Workflows other than standard spec-driven schema that is included in OpenSpec. The licence is MIT.

When your agent uses it

  • Codex operates on an OpenSpec change lifecycle
  • Including propose/new change
  • Apply/implement tasks
  • Archive/finalize

Example prompts

  • “/openspec-linearized”

What it can do on your machine

Read from SKILL.md and the folder at commit 4bb6de2. It shows what the files ask for, not the result of running them.

  • Tool permissions

    Pre-approves nothing: there is no allowed-tools line, so your agent's usual permission prompts apply.

    From allowed-tools in the SKILL.md frontmatter.

  • Runs code

    No scripts in the folder and no shell commands in SKILL.md.

    From the folder's file list and the shell code blocks in SKILL.md.

  • Network

    No URLs in SKILL.md.

    From URLs in SKILL.md, links to its own repository left out.

  • Credentials

    Names no API keys, tokens, secrets or passwords.

    From names ending in _API_KEY, _TOKEN, _SECRET, _KEY or _PASSWORD in SKILL.md.

Context cost

Openspec Linearized loads about 1.8k tokens when it runs, and up to ~4.6k if it reads all its reference files. Until then it costs about 131 tokens; SKILL.md has 869 words of instructions outside code blocks.

Always · name and description, kept in context so the agent knows when to use it
~131
When it runs · the whole SKILL.md, loaded when a task matches
~1.8k
With references · SKILL.md plus every file in references/, read only if the agent opens them
~4.6k

Estimates: characters ÷ 4, the usual rule of thumb; real counts depend on the model's tokenizer. Scripts and assets cost tokens only if the agent reads them.

Safety

Auto-check passed

The automated check found no risky patterns in SKILL.md.

Automated static check — not a guarantee. Review scripts before installing. It scans the text of SKILL.md for risky patterns (piping downloads into a shell, reading credential files, hidden Unicode, destructive commands); files beside SKILL.md are not scanned.

SKILL.md

The full file from intent-driven-dev/openspec-schemas at commit 4bb6de2, republished under its MIT licence (© intent-driven-dev). 869 words, ~1,820 tokens.

Download SKILL.mdSave it as .claude/skills/openspec-linearized/SKILL.md (or your agent's skills folder). This skill also uses 2 other files; get the full folder from GitHub.
name
openspec-linearized
description
Use whenever Codex operates on an OpenSpec change lifecycle or artifact, including propose/new change, apply/implement tasks, archive/finalize, sync specs, continue/update artifacts, validate/status checks, or work under openspec/changes/*. This is the Linear lifecycle overlay for OpenSpec work: bind Linear issues, maintain openspec/linear.yaml, update Linear issue business context/status, keep technical design/tasks in the repo, and mirror canonical specs into Linear Project Documents after archive.

OpenSpec Linearized

Use this skill to run an OpenSpec change lifecycle while preserving a clear handoff boundary:

  • Linear issue/card owns the business "what": business goal, use cases, personas/workflows, scope, acceptance criteria, and stakeholder-facing status. Keep its description synchronized from the business-facing content in proposal.md.
  • The repo owns the technical "how": OpenSpec design decisions, tasks, implementation details, migrations, tests, and code.
  • Canonical specs live under openspec/specs/. After archive succeeds, mirror those specs into Linear Project Documents for stakeholder visibility.

Linear updates are best effort once project setup exists.

Invocation Contract

  • If the user asks to operate on an OpenSpec change, use this skill as the Linear lifecycle overlay.
  • Also use the base OpenSpec skill that matches the request, such as openspec-propose, openspec-apply-change, openspec-archive-change, or openspec-sync-specs.
  • If openspec/linear.yaml exists, run the relevant Linear hook for the current phase when possible.
  • If openspec/linear.yaml is missing during proposal/setup, create it before issue hunting, story selection, or other Linear lifecycle work.
  • If openspec/linear.yaml is missing outside proposal/setup, no-op the Linear hook and continue normal OpenSpec work.
  • For status, validate, sync, continue, and artifact-editing work, preserve Linear binding awareness but do not move a Linear story to Done.

Start

  • Read references/lifecycle.md before doing lifecycle work.
  • Run openspec list --json to understand active changes.
  • Determine the phase from the request:
    • Proposal: create or continue an OpenSpec change and bind a Linear story.
    • Apply: implement tasks.md while updating the bound Linear story.
    • Archive: archive the OpenSpec change, then mirror canonical specs and close the story.
    • Sync/status/validate/continue/artifact work: keep the Linear binding in view, preserve the ownership boundary, and avoid Done transitions.
  • If another OpenSpec skill also applies, use this skill as the Linear lifecycle overlay and follow the base OpenSpec skill for normal artifact generation, task execution, or archive mechanics.

Linear Rules

  • Prefer Linear MCP tools when available: list_teams, list_projects, list_issue_labels, list_issues, list_comments, list_documents, save_issue, save_comment, and save_document.
  • If openspec/linear.yaml is missing during proposal/setup, perform setup before proposal discovery: list only Linear setup data, choose team/project/optional issue label filter, then write the config.
  • During missing-config setup, call only list_teams, list_projects, and list_issue_labels. Do not call list_issues until after openspec/linear.yaml exists and the configured lifecycle flow requires story selection.
  • Ask setup choices one question at a time: first Linear team, then Linear project, then issue label filter. The label question must include an explicit "no label filter" option.
  • Never infer or auto-select team, project, or label from names, ordering, previous results, or seemingly obvious matches.
  • After openspec/linear.yaml exists, Linear unavailability is non-blocking. Continue local OpenSpec work and skip Linear updates silently.
  • Keep Linear comments short, at most two sentences.
  • Do not make Linear the specification source of truth. Canonical specs live under openspec/specs/.
  • Do not transition the bound Linear story to Done before OpenSpec archive succeeds.
  • Keep detailed technical design out of Linear issue descriptions and comments; keep business context out of repo design/tasks except where needed to make technical decisions traceable.
  • When proposal.md is created or materially updated, update the bound Linear issue description with the current business-facing proposal details when possible. Exclude frontmatter, Linear metadata, detailed technical design, task lists, and implementation notes.
Show full SKILL.md (353 more words)Show less

Phase Hooks

Proposal:

  • Load openspec/linear.yaml; if it is missing, create it first using the missing-config setup rules above.
  • After openspec/linear.yaml exists, select a configured-project Backlog issue, applying the optional label filter only to candidate selection.
  • Read the selected issue title, description, labels, comments, links, and related context when available.
  • Treat the Linear issue as the business brief. If proposal discovery produces new or corrected business details, update the Linear issue/card when possible instead of making proposal.md the long-form business record.
  • Ask clarifying questions before writing artifacts.
  • Keep proposal.md lean: record Linear metadata in frontmatter, include capability impact and a concise repo-facing summary, and link back to the Linear issue for business details.
  • After writing or updating proposal.md, refresh the bound Linear issue description from the proposal's business-facing sections when possible.
  • Transition the issue to Todo when possible and add a short comment that proposal discovery started.

Apply:

  • Read linear_story_id from openspec/changes/<change>/proposal.md before implementation.
  • Before implementation, sync useful business/context changes from proposal.md to the Linear issue description when possible, but do not copy technical design details from design.md into Linear.
  • Transition Todo to In Progress when possible and add a short comment that implementation began from the OpenSpec change.
  • Work through tasks.md, marking checkboxes complete as tasks finish.
  • Leave Done transition for archive.

Archive:

  • Complete the normal OpenSpec archive flow first, including delta spec sync when applicable.
  • Only after archive succeeds, mirror canonical openspec/specs/<capability>/spec.md content into Linear Project Documents.
  • Use deterministic titles: OpenSpec: <capability-name>.
  • Persist created or discovered document IDs in openspec/linear.yaml when possible.
  • Transition the bound Linear issue to Done when possible and add a short archive-complete comment.

Guardrails

  • Keep post-archive Linear Project Document sync guidance out of tasks.md; it belongs to archive behavior.
  • Only Linear Project Documents are in scope for spec mirrors. Do not create generic project resources for specs.
  • Linear Project Documents are archive-time mirrors of finalized specs, not a place for draft design notes or implementation tasks.
  • If the active schema is already linearized, honor OpenSpec CLI instructions and avoid duplicating conflicting guidance.
  • If the active schema is local-only, layer this skill's Linear hooks around the normal proposal/apply/archive workflow.

© intent-driven-dev, MIT. Rendered from Markdown: HTML in the file is shown as text, images as links, and headings moved down two levels. Raw file

Files

SKILL.md and 2 other files (references) in .codex/skills/openspec-linearized of intent-driven-dev/openspec-schemas.

  • SKILL.md
  • agents/openai.yaml
  • references/lifecycle.md

Open the folder on GitHubat commit 4bb6de2

Compare with similar skills

Openspec Linearized next to the 5 skills that share the most tags, products or categories with it. Stars are the repository's; “used in” counts other GitHub owners with a copy.

Openspec Linearized compared with similar skills
SkillStarsUsed inTokensAuto-checkLicenceRepo updated
Openspec Linearized this skillintent-driven-dev/openspec-schemas105—~1.8kAutomated safety check: PassMIT
Orca Linear Ticket Workflowstablyai/orca87k1 repos~522Automated safety check: PassMIT
Review Triage Phaseprisma/orm48k—~995Automated safety check: PassApache-2.0
Commitdinerojs/dinero.js6.8k—~667Automated safety check: PassMIT
Draft Pull Request Creatorwordpress-mobile/WordPress-Android3.2k—~881Automated safety check: NotesGPL-2.0
Linear Tickets via Orcastablyai/orca87k—~558Automated safety check: PassMIT

Similar skills

  • Linear ticket work through Orca's CLI. Use when working from a linked Linear issue, finishing work with a PR/MR link and a completion comment, moving a ticket…

    87k GitHub starsUsed in 1 repo~522 tokens
    Productivity & AutomationAuto-check passed
  • Official

    Runs the triage step of the review-framework loop: reads fetched PR review state, builds `review-actions.json`, validates it and renders `review-actions.md`.

    48k GitHub stars~995 tokensUpdated today
    DevelopmentAuto-check passed
  • Commit

    dinerojs/dinero.js

    Create a git commit with optional automatic Linear issue linking.

    6.8k GitHub stars~667 tokensUpdated 2 days ago
    DevelopmentAuto-check passed
  • Draft Pull Request Creator

    wordpress-mobile/WordPress-Android

    Commits and pushes current changes, writes a pull request title and body from the branch history and template, and opens a draft PR on GitHub after you approve it.

    3.2k GitHub stars~881 tokensUpdated today
    DevelopmentAuto-check: notes
  • Linear ticket work through Orca's CLI. Use when working from a linked Linear issue, finishing work with a PR/MR link and a completion comment, moving a ticket…

    87k GitHub stars~558 tokensUpdated today
    Productivity & AutomationAuto-check passed
  • Add Icon Mapping

    lobehub/lobe-icons

    Add or modify icon keyword mappings for providers, models, or agents in lobe-icons.

    2.6k GitHub stars~1.5k tokensUpdated today
    MobileAuto-check: warnings

More from intent-driven-dev/openspec-schemas

  • Openspec Schema Authoring

    intent-driven-dev/openspec-schemas

    Create or customize OpenSpec workflow schemas in this repository using openspec schema init and openspec schema fork.

    105 GitHub stars~674 tokensUpdated 1 mo ago
    Auto-check passed
  • Openspec Schema Authoring

    intent-driven-dev/openspec-schemas

    Create or customize OpenSpec workflow schemas in this repository using openspec schema init and openspec schema fork.

    105 GitHub stars~757 tokensUpdated 1 mo ago
    Auto-check passed

Works with

Questions about Openspec Linearized

What does Openspec Linearized do?

A skill your agent uses whenever Codex operates on an OpenSpec change lifecycle or artifact, including propose/new change, apply/implement tasks, archive/finalize, sync specs, continue/update…. Openspec Linearized is an agent skill from intent-driven-dev/openspec-schemas. Use whenever Codex operates on an OpenSpec change lifecycle or artifact, including propose/new change, apply/implement tasks, archive/finalize, sync specs, continue/update artifacts, validate/status checks, or work under openspec/changes/.

When should I use Openspec Linearized?

Openspec Linearized fits situations like: Codex operates on an OpenSpec change lifecycle; including propose/new change; apply/implement tasks; archive/finalize.

How do I install Openspec Linearized in Claude Code?

Run `npx skills add intent-driven-dev/openspec-schemas --skill openspec-linearized -a claude-code`. Or copy the skill folder (.codex/skills/openspec-linearized in intent-driven-dev/openspec-schemas) into .claude/skills/openspec-linearized in your project. Claude Code loads it when a task matches its description.

How do I install Openspec Linearized in Codex?

Run `npx skills add intent-driven-dev/openspec-schemas --skill openspec-linearized -a codex`. Or copy the skill folder (.codex/skills/openspec-linearized in intent-driven-dev/openspec-schemas) into .agents/skills/openspec-linearized in your project. Codex loads it when a task matches its description.

Can I use Openspec Linearized in Cursor, Gemini CLI or GitHub Copilot?

Cursor, Gemini CLI, GitHub Copilot and OpenCode also load SKILL.md folders. With the skills CLI, run `npx skills add intent-driven-dev/openspec-schemas --skill openspec-linearized -a cursor` (or -a gemini-cli, github-copilot or opencode for the others). To copy it by hand, put the folder in .cursor/skills/openspec-linearized, .gemini/skills/openspec-linearized, .github/skills/openspec-linearized and .opencode/skills/openspec-linearized in your project.

What does Openspec Linearized need to run?

SKILL.md names no scripts, command-line tools or credentials: Openspec Linearized is instructions for the agent only.

Does Openspec Linearized access the network?

SKILL.md contains no URLs. Any network use would come from the scripts or tools the agent runs. This is read from the text; nothing was executed.

Is Openspec Linearized safe to install?

Our automated static check of SKILL.md found no risky patterns, such as piping downloads into a shell, reading credential files or hidden Unicode. It is not a guarantee. Review the folder before installing.

What licence does Openspec Linearized use?

Openspec Linearized is published under the MIT licence (the repository's licence). It allows redistribution, so the full SKILL.md is shown on this page.

How many tokens does Openspec Linearized use?

About 1.8k tokens (SKILL.md is roughly 7.3k characters). Agents keep only the skill's name and description in context until a task matches; then they load SKILL.md in full. Its references folder adds about 2.7k tokens, read only when the agent opens those files.

What are the alternatives to Openspec Linearized?

Skills that share tags, products or a category with Openspec Linearized: Orca Linear Ticket Workflow (stablyai/orca, 87k stars), Review Triage Phase (prisma/orm, 48k stars), Commit (dinerojs/dinero.js, 6.8k stars) and Draft Pull Request Creator (wordpress-mobile/WordPress-Android, 3.2k stars). The comparison table on this page puts their stars, adoption, token cost, safety result and licence side by side.

Who maintains Openspec Linearized?

intent-driven-dev (a GitHub organization) maintains it in intent-driven-dev/openspec-schemas, which has 105 GitHub stars. The repository holds 3 skills in this directory. The repository was last updated on August 16, 2026.

Source: intent-driven-dev/openspec-schemas on GitHub. Facts on this page come from the repository at the commit we read; the author's words are quoted as theirs.