agentsclimarketplace

Grace spec

Skill osovv/grace-marketplace/plugins/grace/skills/grace/grace-spec

GRACE (Graph-RAG Anchored Code Engineering): open Agent Skills for contract-driven AI code generation with semantic markup, knowledge graphs, and support for Claude Code, Codex CLI, and Kilo Code.

Install
npx -y skills add osovv/grace-marketplace --skill grace-spec

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

What its author says it does

Copied from the file, not written here

Interview the user and create an approved GRACE 4 GraceChangeSpec plus optional design-context.xml inside .grace/changes/active/C-*/.

SKILL.md

2.0 KB, 433 tokens by cl100k_base, as published. Nobody here has run it

<skill> <change_bundle_contract> `.grace/changes/active/C-CHANGE-ID/`
  • spec.xml — normative GraceChangeSpec
  • design-context.xml — optional, explanatory only
  • plan.xml — created later by grace-plan </change_bundle_contract>

<status_rules> Create spec.xml as status="draft". Set status="approved" only after explicit user approval. Rejected or cancelled specs move to archive with terminal status. Do not create or edit plan.xml in this skill. </status_rules>

<strict_contract> The direct C-* wrapper must contain exactly one meaningful Summary, Goals, Constraints, NonGoals, AcceptanceCriteria, AffectedAreas, and VerificationIntent section. Empty containers are not approval-ready. Semantic anchors are canonical attribute-free XML tags, never attributes or attribute values. </strict_contract>

<workflow> 1. Ask one focused question at a time until goal, scope, constraints, non-goals, acceptance criteria, affected areas, and verification expectations are clear. 2. Propose a concise design summary and explicit assumptions. Ask for approval before writing an approved spec. 3. Create a deterministic uppercase-kebab `C-*` change id. 4. Write `spec.xml` from `references/change-spec-template.xml` with exactly one direct `C-*` wrapper and no empty required section. 5. If rationale, alternatives, scenarios, or external constraints would otherwise bloat the spec, write non-normative `design-context.xml` from its template. 6. If approval is not explicit, leave `spec.xml` as `status="draft"` and report the approval step needed. </workflow>

<hard_rules>

  • spec.xml is the source of truth for grace-plan; design context never adds requirements.
  • Do not implement code, mutate current graph/verification state, or create retroactive change bundles.
  • Recommend grace lint --path <project-root> --assertions current after writing the bundle. </hard_rules> </skill>

Gives 0 of the 12 instructions most plan spec skills give in 433 tokens

Counted across 1,100 of the 1,860 authors here whose files we hold, read 2026-08-06

  • ask one question at a timein 46 of 1100, across 38 files
  • Break plans into vertical slicesin 28 of 1100, across 10 files
  • Publish issues in dependency orderin 27 of 1100, across 9 files
  • Iterate until user approves the breakdownin 24 of 1100, across 6 files
  • Explore the repository to understand the codebase statein 24 of 1100, across 7 files
  • Use domain glossary vocabularyin 23 of 1100, across 5 files
  • Apply correct triage labels to published issuesin 23 of 1100, across 5 files
  • Write failing tests before implementation codein 23 of 1100, across 18 files
  • Prefer AFK slices over HITLin 22 of 1100, across 7 files
  • ask clarifying questions until requirements are concretein 21 of 1100, across 13 files
  • Respect existing architecture decision recordsin 20 of 1100, across 5 files
  • write a specification before writing any codein 20 of 1100, across 12 files

Said here and by no other author read

  • propose design summary and assumptions
  • create deterministic uppercase change id
  • copy spec template
  • create design context for extra rationale
  • keep draft status without explicit approval
  • recommend running grace lint

Grouped from the skills themselves: near-identical wordings counted once, and counted by distinct author, so one author publishing three of these counts once. Length counted with cl100k_base; the agent that loads this file may tokenize it differently.

Keep looking

Skills are one crate of 328,083. Ordering is by how many stacks a row turns up in, so the top of any crate is what has actually been picked rather than what has the most stars.