AgentSkillsCN

spectr-proposal

根据差异规范与任务清单，创建全新的变更提案。

SKILL.md
--- frontmatter
name: spectr-proposal
description: Create a new change proposal with delta specs and tasks

Proposal Creation Guide

Guardrails

  • •Favor straightforward, minimal implementations first and add complexity only when it is requested or clearly required.
  • •Keep changes tightly scoped to the requested outcome.
  • •Refer to spectr/AGENTS.md and spectr/project.md (located inside the spectr/ directory—run ls spectr) if you need additional Spectr conventions or clarifications.
  • •Identify any vague or ambiguous details and ask the necessary follow-up questions before editing files.

Note: You are not implementing yet, you are fully planning and creating the change proposal using spectr.

Steps

  1. •Review spectr/project.md, read spectr/specs/ and spectr/changes/ directories, and inspect related code or docs (e.g., via rg/ls) to ground the proposal in current behaviour; note any gaps that require clarification.
  2. •Choose a unique verb-led change-id and scaffold proposal.md, tasks.md, and design.md (when needed) under spectr/changes/<id>/.
  3. •Map the change into concrete capabilities or requirements, breaking multi-scope efforts into distinct spec deltas with clear relationships and sequencing.
  4. •Capture architectural reasoning in design.md when the solution spans multiple systems, introduces new patterns, or demands trade-off discussion before committing to specs.
  5. •Draft spec deltas in spectr/changes/<id>/specs/<capability>/spec.md (one folder per capability) using ## ADDED|MODIFIED|REMOVED Requirements with at least one #### Scenario: per requirement and cross-reference related capabilities when relevant.
  6. •Draft tasks.md as an ordered list of small, verifiable work items that deliver user-visible progress, include validation (tests, tooling), and highlight dependencies or parallelizable work. Note: After running spectr accept, both tasks.md (human-readable) and tasks.jsonc (machine-readable) will coexist—the former preserves formatting and context, while the latter becomes the runtime source of truth.
  7. •Validate with spectr validate <id> and resolve every issue before sharing the proposal.

Reference

  • •Read delta specs directly at spectr/changes/<id>/specs/<capability>/spec.md when validation fails.
  • •Read existing specs at spectr/specs/<capability>/spec.md to understand current state.
  • •Search existing requirements with rg -n "Requirement:|Scenario:" spectr/specs before writing new ones.
  • •Explore the codebase with rg <keyword>, ls, or direct file reads so proposals align with current implementation realities.