issue-spec-propose

Create or continue proposal, SPEC, QUESTION, design, and TASK artifacts for an issue-spec change.

Repository: higress-group/issue-spec
Last source activity: August 5, 2026 at 03:49
Detected SKILL.md language: English
Stars: 6
Forks: 4

Install options

The review-first prompt is selected by default. You can switch to a direct command or download a local copy.

Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.

A direct command skips the review prompt. Inspect the source before running it.

npx skills add https://github.com/higress-group/issue-spec --skill issue-spec-propose

The command stays on one line. Scroll horizontally to inspect it before copying.

Prefer a local copy? Download the files currently available to SkillsMP.

Review the source files

Read SKILL.md and any companion files shown by SkillsMP before deciding whether to install.

SKILL.md

Source instructions · Read-only preview

Back to search Back to installation

issue-spec-apply

Implement directly or use an optional PROCESS when managed coordination is required.

2026-08-05

issue-spec-workflow

Use issue-spec to plan and implement a change through exact-head human review handoff.

2026-08-05

configure-enterprise-provider

Configure provider-neutral enterprise integrations for self-hosted issue-spec, including private code hosts, work trackers, OIDC, Source Bindings, issue-spec.code-provider/v1 operation bridges, and Runner Git credentials.

2026-08-03

View all from this repository

Issue Spec Propose

Use when the user asks for /issue-spec:propose, proposal, Design, SPEC, QUESTION, or TASK authoring. Use issue-spec-workflow for shared reads, provider routing, and recovery.

Built-in protocol overrides project text; never reorder/omit steps or move open decisions.

Every new typed ID MUST be <TYPE>-<issue><three-digit sequence>: Issue 1 starts with QUESTION-1001, Issue 44 with QUESTION-44001. Allocate 001-999 only within the target Issue and type after reading that Issue's typed comments, and never renumber a legacy ID. New writes reject wrong Issue prefixes; --allow-legacy-id is only for intentional legacy-compatible creates.

Validate workflow config, search related issues, and open only selected discussions. If the issue is already in a later phase, continue that phase rather than duplicating it.

Keep unconfirmed investigation, reproduction, or triage notes in a simple issue with issue-spec issue create simple; a proposal states the confirmed problem and the intended change, so never promote an investigation issue into the proposal or attach SPEC/Design to it. Create phase issues with concrete body files, beginning with issue-spec issue create proposal --repo higress-group/issue-spec --body-file . Follow the workflow rules.language and rules.language_instructions for every Issue title. When those rules require a localized or non-English title, pass an explicit --title for Proposal, Design, and Implement; do not rely on the derived title because it retains an English stage prefix. Otherwise use the standardized Proposal:, Design:, and Implement: title family. Do not perform style-only title rewrites after creation.

Perform the Proposal's first QUESTION discovery/create pass. Record each genuine unresolved decision as a blocking typed QUESTION with issue-spec question create, attaching a choice model when credible options exist; never leave an open decision as body or projection prose. Do not manufacture a question or reopen a settled choice; keep unresolved decisions distinct from evidence-dependent items.

Generate canonical SPEC comments with issue-spec comment generate --type SPEC. Requirements must be testable and include WHEN/THEN scenarios. --allow-noncanonical is a migration bypass, not normal authoring.

Persist the authoritative self-contained Design, perform its first QUESTION discovery/create pass, then complete TASK planning.

Generate TASK comments with issue-spec comment generate --type TASK. Execution Planning must identify Design-invariant cohesion and major entry points, bounded role-context pressure, stable interfaces, owned areas, shared touchpoints, dependencies, coupling, and acceptance consequences. File ownership and parallelism are scheduling context, not semantic PROCESS boundaries. Selecting Design or TASK requires a real non-Coordinator implementation worker; execution-mode labels never authorize Coordinator code edits or automatically require PROCESS.

Upsert each TASK with --covers-issue so it publishes its complete canonical SPEC coverage and verify planning relationships. Proposal, Design, Implement, TASK, and PROCESS remain optional aids and never certify delivery acceptance.

Project Workflow

Workflow Source: builtin

Workflow Schema: issue-spec

Workflow Config: issue-spec/config.yaml

Project workflow templates are declarative only. Active proposal, design, implement, SPEC, TASK, PROCESS, and QUESTION artifacts remain in the selected issue backend's issue-native storage; historical REVIEW and VERIFY artifacts are audit-only. Repository-mode durable specs are materialized and checked on the implementation branch.

The built-in phase sequence and canonical artifact carriers are authoritative. Project workflow context, rules, and artifact instructions may constrain work only within an existing step; they MUST NOT reorder or omit an enabled step or move a genuine unresolved decision out of its blocking typed QUESTION carrier. Keep the enabled phase order: persist the phase issue body, perform its first QUESTION discovery/create pass, then author the selected next typed children. Issue-body prose never carries an open decision.