openspec-propose

Name: openspec-propose
Author: comol

388stars86forks

How to install openspec-propose?

comol/ai_rules_1c/openspec-propose

$npx -y skills add comol/ai_rules_1c --skill openspec-propose

Installs into the current project.

Summary

Propose a new change with all artifacts generated in one step. Use when the user wants to quickly describe what they want to build and get a complete proposal with design, specs, and tasks ready for implementation.

Files · 1

View on GitHub

SKILL.md

1	Propose a new change - create the change and generate all artifacts in one step.
2
3	I'll create a change with artifacts:
4	- proposal.md (what & why)
5	- design.md (how)
6	- tasks.md (implementation steps)
7
8	When ready to implement, run /opsx:apply
9
10	## Question-asking discipline (read first)
11
12	The propose phase is where every clarifiable architectural decision must be settled. Apply phase is not the time for clarifications — by the time code is being written, the user must not be paying a clarification tax that should have been paid here.
13
14	- Ask the user now, do not defer to apply. The upstream OpenSpec default "prefer making reasonable decisions to keep momentum" is overridden for this project. If a decision is architecturally meaningful and ambiguous (placement / provider / data scope / settings storage / key handling / transactional boundaries / error-handling pattern / logging strategy / library / БСП subsystem / platform-version target / public common-module signatures), ask the user here, not at apply time.
15	- Do not ask the user about facts an MCP call could close. Names, attributes, tabular sections, БСП subsystem availability, platform-API signatures — resolve via `recall` / `resolve_qualified_name` / `search_metadata` / `ssl_search` / `docinfo` before reaching for `AskUserQuestion`.
16	- Pin defaults the user is unlikely to care about with a one-line rationale in `design.md` and move on. Do not ask about cache-eviction policy, private helper names, internal module splits when no NFR or convention exists.
17	- The full rule lives in `content/rules/sdd-integrations.md → Propose-phase clarification discipline`. Load it before authoring any non-trivial proposal.
18
19	Forbidden in finalized artifacts (each is a propose-phase defect of the same severity as a missing `Context sources` block):
20
21	- "TODO: clarify with the user during apply" / "уточнить при реализации" — every such marker is an admission that this phase failed. Either decide now with the user, or capture as a numbered item in `design.md → ## Open Questions` with the exact future question, the artifact section it will update, and the dependent task ID — and only if the answer genuinely depends on facts that surface later, not on a user decision you skipped asking.
22	- "We'll decide once we see the code" / "будем смотреть по ходу" — almost never legitimate.
23	- Vague verbs in delta `### Requirement:` blocks: "appropriately", "if needed", "as required", "по необходимости", "при необходимости".
24	- Phantom defaults — two equally weighted options listed without a written rationale for the default.
25
26	---
27
28	Input: The user's request should include a change name (kebab-case) OR a description of what they want to build.
29
30	Steps
31
32	1. If no clear input provided, ask what they want to build
33
34	Use the AskUserQuestion tool (open-ended, no preset options) to ask:
35	> "What change do you want to work on? Describe what you want to build or fix."
36
37	From their description, derive a kebab-case name (e.g., "add user authentication" → `add-user-auth`).
38
39	IMPORTANT: Do NOT proceed without understanding what the user wants to build.
40
41	2. Create the change directory
42	```bash
43	openspec new change "<name>"
44	```
45	This creates a scaffolded change at `openspec/changes/<name>/` with `.openspec.yaml`.
46
47	3. Get the artifact build order
48	```bash
49	openspec status --change "<name>" --json
50	```
51	Parse the JSON to get:
52	- `applyRequires`: array of artifact IDs needed before implementation (e.g., `["tasks"]`)
53	- `artifacts`: list of all artifacts with their status and dependencies
54
55	4. Create artifacts in sequence until apply-ready
56
57	Use the TodoWrite tool to track progress through the artifacts.
58
59	Loop through artifacts in dependency order (artifacts with no pending dependencies first):
60
61	a. For each artifact that is `ready` (dependencies satisfied):
62	- Get instructions:
63	```bash
64	openspec instructions <artifact-id> --change "<name>" --json
65	```
66	- The instructions JSON includes:
67	- `context`: Project background (constraints for you - do NOT include in output)
68	- `rules`: Artifact-specific rules (constraints for you - do NOT include in output)
69	- `template`: The structure to use for your output file
70	- `instruction`: Schema-specific guidance for this artifact type
71	- `outputPath`: Where to write the artifact
72	- `dependencies`: Completed artifacts to read for context
73	- Read any completed dependency files for context
74	- Create the artifact file using `temp

People who liked this also viewed

6 picks

Type

openspec-propose

388stars86forks

View on GitHub

How to install openspec-propose?

comol/ai_rules_1c/openspec-propose

$npx -y skills add comol/ai_rules_1c --skill openspec-propose

Installs into the current project.

Summary

Files · 1

View on GitHub

SKILL.md

1	Propose a new change - create the change and generate all artifacts in one step.
2
3	I'll create a change with artifacts:
4	- proposal.md (what & why)
5	- design.md (how)
6	- tasks.md (implementation steps)
7
8	When ready to implement, run /opsx:apply
9
10	## Question-asking discipline (read first)
11
12	The propose phase is where every clarifiable architectural decision must be settled. Apply phase is not the time for clarifications — by the time code is being written, the user must not be paying a clarification tax that should have been paid here.
13
14	- Ask the user now, do not defer to apply. The upstream OpenSpec default "prefer making reasonable decisions to keep momentum" is overridden for this project. If a decision is architecturally meaningful and ambiguous (placement / provider / data scope / settings storage / key handling / transactional boundaries / error-handling pattern / logging strategy / library / БСП subsystem / platform-version target / public common-module signatures), ask the user here, not at apply time.
15	- Do not ask the user about facts an MCP call could close. Names, attributes, tabular sections, БСП subsystem availability, platform-API signatures — resolve via `recall` / `resolve_qualified_name` / `search_metadata` / `ssl_search` / `docinfo` before reaching for `AskUserQuestion`.
16	- Pin defaults the user is unlikely to care about with a one-line rationale in `design.md` and move on. Do not ask about cache-eviction policy, private helper names, internal module splits when no NFR or convention exists.
17	- The full rule lives in `content/rules/sdd-integrations.md → Propose-phase clarification discipline`. Load it before authoring any non-trivial proposal.
18
19	Forbidden in finalized artifacts (each is a propose-phase defect of the same severity as a missing `Context sources` block):
20
21	- "TODO: clarify with the user during apply" / "уточнить при реализации" — every such marker is an admission that this phase failed. Either decide now with the user, or capture as a numbered item in `design.md → ## Open Questions` with the exact future question, the artifact section it will update, and the dependent task ID — and only if the answer genuinely depends on facts that surface later, not on a user decision you skipped asking.
22	- "We'll decide once we see the code" / "будем смотреть по ходу" — almost never legitimate.
23	- Vague verbs in delta `### Requirement:` blocks: "appropriately", "if needed", "as required", "по необходимости", "при необходимости".
24	- Phantom defaults — two equally weighted options listed without a written rationale for the default.
25
26	---
27
28	Input: The user's request should include a change name (kebab-case) OR a description of what they want to build.
29
30	Steps
31
32	1. If no clear input provided, ask what they want to build
33
34	Use the AskUserQuestion tool (open-ended, no preset options) to ask:
35	> "What change do you want to work on? Describe what you want to build or fix."
36
37	From their description, derive a kebab-case name (e.g., "add user authentication" → `add-user-auth`).
38
39	IMPORTANT: Do NOT proceed without understanding what the user wants to build.
40
41	2. Create the change directory
42	```bash
43	openspec new change "<name>"
44	```
45	This creates a scaffolded change at `openspec/changes/<name>/` with `.openspec.yaml`.
46
47	3. Get the artifact build order
48	```bash
49	openspec status --change "<name>" --json
50	```
51	Parse the JSON to get:
52	- `applyRequires`: array of artifact IDs needed before implementation (e.g., `["tasks"]`)
53	- `artifacts`: list of all artifacts with their status and dependencies
54
55	4. Create artifacts in sequence until apply-ready
56
57	Use the TodoWrite tool to track progress through the artifacts.
58
59	Loop through artifacts in dependency order (artifacts with no pending dependencies first):
60
61	a. For each artifact that is `ready` (dependencies satisfied):
62	- Get instructions:
63	```bash
64	openspec instructions <artifact-id> --change "<name>" --json
65	```
66	- The instructions JSON includes:
67	- `context`: Project background (constraints for you - do NOT include in output)
68	- `rules`: Artifact-specific rules (constraints for you - do NOT include in output)
69	- `template`: The structure to use for your output file
70	- `instruction`: Schema-specific guidance for this artifact type
71	- `outputPath`: Where to write the artifact
72	- `dependencies`: Completed artifacts to read for context
73	- Read any completed dependency files for context
74	- Create the artifact file using `temp

People who liked this also viewed

6 picks

Type