Source profileQuality 88/100

javded-itres/Holix/core/skills/bundled/holix-sdd-propose/SKILL.md

holix-sdd-propose

Create Spec-Driven Development changes (OpenSpec-style) — multi-project openspec, understanding gate, assigned tasks before coding

Source repository stars
12
Declared platforms
0
Static risk flags
1
Last source update
2026-08-04
Source checked
2026-08-04

Decision brief

What it does—and where it fits

User wants a non-trivial feature, API, schema, or product change. Work starts with a specification, not code.

Best for

  • User wants a non-trivial feature, API, schema, or product change. Work starts with a specification, not code.

Not for

  • Tasks that require unconfirmed production actions or broad system permissions.
  • Environments where the pinned source and install steps cannot be inspected.

Compatibility matrix

Platform support, with evidence labels

PlatformStatusEvidenceWhat to check
CodexNot declaredNo explicit evidencePortability before use
Claude CodeNot declaredNo explicit evidencePortability before use
CursorNot declaredNo explicit evidencePortability before use
Gemini CLINot declaredNo explicit evidencePortability before use
Open the compatibility checker

Installation

Inspect first. Install second.

The source command is displayed only when detected. A safe inspection prompt is always available so your agent can explain every action before execution.

Source-detected install commandSource
npx skills add https://github.com/javded-itres/Holix --skill "core/skills/bundled/holix-sdd-propose"
Safe inspection promptEditorial

Inspect the Agent Skill "holix-sdd-propose" from https://github.com/javded-itres/Holix/blob/2b0735f8a5e86be092e4918f1ff2e305bcea693a/core/skills/bundled/holix-sdd-propose/SKILL.md at commit 2b0735f8a5e86be092e4918f1ff2e305bcea693a. List every install step, command, network request, credential, file read/write, external action, and rollback step. Explain whether it fits my task. Do not install or execute anything until I approve.

Workflow

What the source asks the agent to do

  1. 01

    Workflow (propose)

    1. sddstatus with project= — if not initialized → sddinit with the same project= 2. sddlistspecs + sddreadspec for relevant domains 3. sddlistchanges — avoid duplicate open changes 4. sddcreatechange with slug id and request= (user request text) 5. Understanding gate (if enabled…

    sddstatus with project= — if not initialized → sddinit with the same project=sddlistspecs + sddreadspec for relevant domainssddlistchanges — avoid duplicate open changes
  2. 02

    When to use

    User wants a non-trivial feature, API, schema, or product change. Work starts with a specification, not code.

    User wants a non-trivial feature, API, schema, or product change. Work starts with a specification, not code.
  3. 03

    Language (Studio locale)

    Match the user's Studio UI language (ru or en only):

    Chat (questions, summaries, progress) — that language onlyAll SDD artifacts via sddwriteartifact (proposal, design, specs, tasks) — that language onlysddupdateunderstanding summary / questions — that language only
  4. 04

    Multi-project workspaces

    A workspace may contain several projects, each with its own openspec/.

    sddlistprojects — pick the project path (empty string = workspace root)Pass project= to every subsequent sdd tool for that workA workspace may contain several projects, each with its own openspec/.
  5. 05

    Assignees (you choose who does the work)

    1. Call listsubagenttypes first. 2. Custom types (user-created Agents tab): prefer matching custom agents by role. 3. No custom types: pick a built-in (coder, reviewer, researcher, analyst, writer, webresearcher) that fits each task. 4. main: shared / risky / merge-conflict work…

    Call listsubagenttypes first.Custom types (user-created Agents tab): prefer matching custom agents by role.No custom types: pick a built-in (coder, reviewer, researcher, analyst, writer, webresearcher) that fits each task.

Permission review

Static risk signals and limitations

Writes files

medium · line 45

The documentation asks the agent to create, modify, or delete local files.

to run `/init <path>` if you cannot write). Do not skip when the codebase

Evidence record

Why each signal appears

EvidenceSourceComputedTestedEditorial
SignalValueEvidence typeMeaning
Quality score88/100ComputedDocumentation, specificity, maintenance, and trust rules
Repository stars12SourceRepository attention, not individual Skill quality
Compatibility0 platformsSourceDeclared in the catalog source record
Usage guideautomated source guideEditorialGenerated or reviewed according to the visible evidence level

Pinned source

Provenance and original SKILL.md

Repository
javded-itres/Holix
Skill path
core/skills/bundled/holix-sdd-propose/SKILL.md
Commit
2b0735f8a5e86be092e4918f1ff2e305bcea693a
License
MIT
Collected
2026-08-04
Default branch
main
View the original SKILL.md

When to use

User wants a non-trivial feature, API, schema, or product change. Work starts with a specification, not code.

Language (Studio locale)

Match the user's Studio UI language (ru or en only):

  • Chat (questions, summaries, progress) — that language only
  • All SDD artifacts via sdd_write_artifact (proposal, design, specs, tasks) — that language only
  • sdd_update_understanding summary / questions — that language only
  • Do not mix languages; do not write specs in the other language
  • Structural OpenSpec markers may stay English (## ADDED Requirements, GIVEN/WHEN/THEN), but narrative text, requirement titles, scenarios, and task descriptions must be in the selected locale

If the Studio prompt states locale=ru or locale=en, treat that as authoritative.

Multi-project workspaces

A workspace may contain several projects, each with its own openspec/.

  1. sdd_list_projects — pick the project path (empty string = workspace root)
  2. Pass project=<path> to every subsequent sdd_* tool for that work

Workflow (propose)

  1. sdd_status with project= — if not initialized → sdd_init with the same project=

  2. sdd_list_specs + sdd_read_spec for relevant domains

  3. sdd_list_changes — avoid duplicate open changes

  4. sdd_create_change with slug id and request= (user request text)

  5. Understanding gate (if enabled in user prefs — see create_change response).

    Before any clarifying questions to the user, complete this order:

    1. Existing SDD knowledge
      • sdd_list_specs + sdd_read_spec for relevant domains (openspec/specs/)
      • sdd_list_changes with include_archive=true
      • Read related archived change artifacts under openspec/changes/archive/ (proposal, specs, design, tasks) and any overlapping open changes
    2. Project context / /init if needed
      • Read .holix/HOLIX.md (and project-local notes if any)
      • If missing, empty, or insufficient for this request/domain: run project onboarding equivalent to /init for the project path (scan layout + key files; update HOLIX.md via update_holix_section, or ask the user once to run /init <path> if you cannot write). Do not skip when the codebase is unknown.
    3. Assess understanding
      • Call sdd_update_understanding with honest score (0–100) and summary of what you learned from main specs, archives, and HOLIX — before dumping questions at the user
    4. Only then ask residual clarifying questions in chat
      • After each answer: sdd_update_understanding again with user_answer and updated score / questions
      • If score < threshold → keep clarifying (status clarifying)
      • If score ≥ threshold → status ready: offer proceed or more questions
      • If later answers drop score below threshold → new clarifying cycle
    5. Only after user agrees to proceed: sdd_confirm_understanding
    • Do not fill full proposal/specs/tasks until confirmed (or gate disabled/skipped)
    • Do not open with a long questionnaire before steps 1–3
  6. Fill artifacts via sdd_write_artifact only (not write_file / inventing paths):

    • proposalopenspec/changes/<id>/proposal.md
    • designopenspec/changes/<id>/design.md
    • tasksopenspec/changes/<id>/tasks.md
    • specsopenspec/changes/<id>/specs/<domain>/spec.md (pass domain= or omit)
    • There is no openspec/changes/<id>/specs.md — do not read_file that path
    • Prefer sdd_status(change_id=…)artifact_paths before reading anything
    • proposal content — Why / What / Impact
    • specs content — delta with ## ADDED|MODIFIED|REMOVED Requirements and GIVEN/WHEN/THEN
    • design content — approach + task→assignee table
    • tasks content — checklist with assignees (see below)

Assignees (you choose who does the work)

  1. Call list_subagent_types first.
  2. Custom types (user-created Agents tab): prefer matching custom agents by role.
  3. No custom types: pick a built-in (coder, reviewer, researcher, analyst, writer, web_researcher) that fits each task.
  4. main: shared / risky / merge-conflict work that must stay on the main agent.
  5. Apply mode is chosen later by the user:
    • self — assignees are ignored; main does everything (no need to over-optimize assignees).
    • subagents / hybrid — assignees drive dispatch; task graph controls order: only ready tasks spawn (deps done); later waves auto-dispatch after completion. Same type on many ready tasks → parallel jobs type-1, type-2, …

tasks.md format (required — OpenSpec Holix checklist only)

Studio and sdd_* tools parse only checkbox lines. Free-form sections are rejected.

Size & decomposition (required for subagents)

Before writing tasks.md, estimate volume and split large work.

sizeMeaningTypical sub-agent steps
xsOne file / one function / stub~40
sOne slice, 1–3 files, one deliverable~60
mFocused module feature~90
l / xlToo bigsdd_write_artifact rejects for subagent assignees

Rules for volume:

  1. Prefer 5–15 small tasks over 1–3 mega-tasks.
  2. One sub-agent task = one deliverable (one endpoint or one UI screen or one test file — not all).
  3. Put - **size:** \s`(orxs/m`) on every task. Holix also estimates missing sizes.
  4. If a task would be L/XL (full feature, frontend+backend, "entire module") → split with depends_on before write.
  5. Parallelize independent slices (same depends_on) so waves stay short.

Correct (required):

# Tasks: <change-id>

## 1. Backend

- [ ] 1.1 Add OAuth token endpoint only
  - **assignee:** `coder`
  - **size:** `s`
  - **reason:** isolated API surface
  - **depends_on:**

- [ ] 1.2 Persist session store
  - **assignee:** `coder`
  - **size:** `s`
  - **reason:** needs 1.1
  - **depends_on:** `1.1`

## 2. Frontend

- [ ] 2.1 Login button + redirect (UI only)
  - **assignee:** `coder`
  - **size:** `s`
  - **reason:** needs API from 1.1
  - **depends_on:** `1.1`

- [ ] 1.3 Shared auth config
  - **assignee:** `main`
  - **size:** `m`
  - **reason:** conflict-prone shared code
  - **depends_on:** `1.1`

Wrong (rejected — too large / free-form):

- [ ] 1.1 Implement full OAuth (backend, frontend, tests, docs)
  - **assignee:** `coder`

## 1. Add OAuth endpoints
- **Описание:** …
- **Исполнитель:** coder

Rules:

  • Every task is - [ ] <id> <title> (or - [x] when done)
  • Nested - **assignee:** \type` is mandatory structure (main, subagent type, or unassigned`)
  • Nested - **size:** \xs|s|m`` — required for good dispatch budgets
  • Optional - **reason:** …
  • Optional - **depends_on:** \1.1, 1.2`` — execution graph (empty = no explicit deps)
  • Same-section order (1.1 before 1.2) is inferred when depends_on is empty
  • Parallel work: independent sections (1.x vs 2.x) or shared depends_on only
  • Use sdd_write_artifact(artifact=tasks, …) only — never invent another schema
  • If write returns size errors → rewrite tasks.md with smaller checklist items (do not force L/XL)

Assignees: main or a type name from list_subagent_types (custom or built-in).

  1. sdd_status with change_id until apply_ready: true
  2. Stop and let the user review. Do not implement until apply skill / user asks.

Do NOT

  • Do not write product code during propose
  • Prefer real type names for subagents/hybrid; unassigned is OK for mode self (runs on main), but blocks apply-ready for pure subagents
  • Do not skip reading main specs for brownfield work
  • Do not skip understanding gate when it is enabled and status is not confirmed/skipped
  • Do not write SDD artifacts or clarifying questions in a language other than the user's Studio locale (ru or en)

Alternatives

Compare before choosing

Computed 10023,781

alirezarezvani/claude-skills

app-store-optimization

App Store Optimization (ASO) toolkit for researching keywords, analyzing competitor rankings, generating metadata suggestions, and improving app visibility on Apple App Store and Google Play Store. Use when the user asks about ASO, app store rankings, app metadata, app titles and descriptions, app store listings, app visibility, or mobile app marketing on iOS or Android. Supports keyword research and scoring, competitor keyword analysis, metadata optimization, A/B test planning, launch checklist

Computed 1004,922

dotnet/skills

migrate-vstest-to-mtp

Migrates .NET test projects from VSTest to Microsoft.Testing.Platform (MTP). Use when user asks to "migrate to MTP", "switch from VSTest", "enable Microsoft.Testing.Platform", "use MTP runner", set OutputType=Exe only for test projects in Directory.Build.props, or mentions EnableMSTestRunner, EnableNUnitRunner, or UseMicrosoftTestingPlatformRunner. USE FOR: MTP behavioral differences vs VSTest (exit code 8, zero tests discovered, --ignore-exit-code, TESTINGPLATFORM_EXITCODE_IGNORE); centralizing

Computed 9929,558

HKUDS/Vibe-Trading

strategy-generate

Create, modify, and optimize quantitative trading strategies, then backtest and evaluate them.

Computed 9832,606

K-Dense-AI/scientific-agent-skills

dask

Distributed computing for larger-than-RAM pandas/NumPy workflows. Use when you need to scale existing pandas/NumPy code beyond memory or across clusters. Best for parallel file processing, distributed ML, integration with existing pandas code. For out-of-core analytics on single machine use vaex; for in-memory speed use polars.