Installs into .claude/skills of the current project.
Are you the author of Vaultspec Write?
Add the live security badge to your README. It updates with every re-scan.
[](https://www.skillsdirectory.com/skills/nevenincs-vaultspec-write-vaultspec-rag)
---
name: vaultspec-write
description: Write a proportionate implementation plan when scope or progress needs
durable sequencing, after assessing decision coverage.
---
# Plan (vaultspec-write)
Produces the sequence execution can resume across sessions. Apply the vaultspec system
section's routing and approval contract. A plan may reuse governing ADRs or have none
when no costly decision is involved. Drafting does not authorize execution.
## Steps
- Discover governing decisions across features and read the relevant ADRs and evidence.
Reuse accepted decisions unchanged. Route uncovered costly choices to `vaultspec-adr`;
a draft may link proposed decisions, but dependent execution waits for acceptance.
- Discover the affected code and exact paths. Expected new files are identified as
creation work. Record the coverage assessment and authorized scope in the Description,
particularly when no ADR governs.
- Scaffold:
`vaultspec-core vault add plan --feature {feature} --tier <L1..L4> [--related <adr-stem> ...]`
(or `create`). Link each governing ADR; inherit its evidence transitively. Optional
direct evidence links do not replace governing ADRs.
- Read `.vaultspec/templates/plan.md` for tiers, identifiers, row syntax, and cohesive
granularity. Build structure with `plan_edit` or the `vaultspec-core vault plan`
verbs. Author Description, Parallelization, and Verification through body editing.
- Draft locally or dispatch `vaultspec-writer` with the scaffolded plan, assessed
coverage, scoped work, and governing documents, if any.
- Verify with `vaultspec-core vault check all` and `vaultspec-core vault plan check`.
- Present the plan. Persist existing scoped authorization with `Approved yyyy-mm-dd` as
the first Description line and its basis. Ask only when authorization is missing.
Gather missing evidence with the appropriate evidence skill, not an automatic new ADR.
## Rules
- Select the smallest useful tier; promote only when containers clarify dependencies.
- A Step is one cohesive, verifiable commit. Related changes across several files may
share a Step with bounded scope; unrelated outcomes need separate Steps.
- Every governing ADR goes once in `related:`. When several govern different parts, map
them in the Description to Steps at L1 or the relevant containers at higher tiers.
- Wiki-links belong only in `related:`.
