From 33a07969c3f1bf881147313b85d5d8d89bc287cf Mon Sep 17 00:00:00 2001 From: Benjamin Pahl <8275915+DasBen@users.noreply.github.com> Date: Mon, 20 Oct 2025 00:49:15 +0200 Subject: [PATCH] feat(ci): add markdownlint-cli2 for consistent markdown formatting Add automated markdown linting to ensure consistent formatting across all markdown files in the repository. Changes: - Add .markdownlint-cli2.jsonc configuration - Create .github/workflows/lint.yml for CI/CD integration - Fix all 908 existing markdown errors across 27 files - Enforce ATX-style headings and asterisk emphasis - Set consistent 2-space list indentation This prevents markdown errors after project initialization and maintains high documentation quality standards. --- .github/workflows/lint.yml | 18 ++++++++ .markdownlint-cli2.jsonc | 24 ++++++++++ AGENTS.md | 27 +++++++++--- CHANGELOG.md | 4 +- CODE_OF_CONDUCT.md | 20 ++++----- CONTRIBUTING.md | 3 +- README.md | 55 +++++++++++------------ SECURITY.md | 20 ++++----- SUPPORT.md | 3 +- docs/README.md | 3 +- docs/index.md | 7 ++- docs/installation.md | 4 +- docs/local-development.md | 10 ++++- docs/quickstart.md | 2 +- spec-driven.md | 1 - templates/agent-file-template.md | 7 ++- templates/checklist-template.md | 1 - templates/commands/analyze.md | 1 - templates/commands/checklist.md | 38 +++++++++------- templates/commands/clarify.md | 70 +++++++++++++++--------------- templates/commands/constitution.md | 10 ++--- templates/commands/implement.md | 44 ++++++++++--------- templates/commands/plan.md | 4 +- templates/commands/specify.md | 21 +++++---- templates/commands/tasks.md | 8 ++-- templates/plan-template.md | 7 ++- templates/spec-template.md | 1 - templates/tasks-template.md | 8 ++-- 28 files changed, 247 insertions(+), 174 deletions(-) create mode 100644 .github/workflows/lint.yml create mode 100644 .markdownlint-cli2.jsonc diff --git a/.github/workflows/lint.yml b/.github/workflows/lint.yml new file mode 100644 index 00000000..fa20c809 --- /dev/null +++ b/.github/workflows/lint.yml @@ -0,0 +1,18 @@ +name: Lint + +on: + push: + branches: ["main"] + pull_request: + +jobs: + markdownlint: + runs-on: ubuntu-latest + steps: + - name: Checkout + uses: actions/checkout@v4 + + - name: Run markdownlint-cli2 + uses: DavidAnson/markdownlint-cli2-action@v19 + with: + globs: '**/*.md' diff --git a/.markdownlint-cli2.jsonc b/.markdownlint-cli2.jsonc new file mode 100644 index 00000000..a96fd3e6 --- /dev/null +++ b/.markdownlint-cli2.jsonc @@ -0,0 +1,24 @@ +{ + // https://github.com/DavidAnson/markdownlint/blob/main/doc/Rules.md + "config": { + "default": true, + "MD003": { + "style": "atx" + }, + "MD007": { + "indent": 2 + }, + "MD013": false, + "MD024": { + "siblings_only": true + }, + "MD033": false, + "MD041": false, + "MD049": { + "style": "asterisk" + }, + "MD050": { + "style": "asterisk" + } + } +} \ No newline at end of file diff --git a/AGENTS.md b/AGENTS.md index 492603cd..b8d75013 100644 --- a/AGENTS.md +++ b/AGENTS.md @@ -68,12 +68,14 @@ AGENT_CONFIG = { ``` **Key Design Principle**: The dictionary key should match the actual executable name that users install. For example: + - ✅ Use `"cursor-agent"` because the CLI tool is literally called `cursor-agent` - ❌ Don't use `"cursor"` as a shortcut if the tool is `cursor-agent` This eliminates the need for special-case mappings throughout the codebase. **Field Explanations**: + - `name`: Human-readable display name shown to users - `folder`: Directory where agent-specific files are stored (relative to project root) - `install_url`: Installation documentation URL (set to `None` for IDE-based agents) @@ -102,12 +104,14 @@ Update the **Supported AI Agents** section in `README.md` to include the new age Modify `.github/workflows/scripts/create-release-packages.sh`: -##### Add to ALL_AGENTS array: +##### Add to ALL_AGENTS array + ```bash ALL_AGENTS=(claude gemini copilot cursor-agent qwen opencode windsurf q) ``` -##### Add case statement for directory structure: +##### Add case statement for directory structure + ```bash case $agent in # ... existing cases ... @@ -131,14 +135,16 @@ gh release create "$VERSION" \ #### 5. Update Agent Context Scripts -##### Bash script (`scripts/bash/update-agent-context.sh`): +##### Bash script (`scripts/bash/update-agent-context.sh`) Add file variable: + ```bash WINDSURF_FILE="$REPO_ROOT/.windsurf/rules/specify-rules.md" ``` Add to case statement: + ```bash case "$AGENT_TYPE" in # ... existing cases ... @@ -151,14 +157,16 @@ case "$AGENT_TYPE" in esac ``` -##### PowerShell script (`scripts/powershell/update-agent-context.ps1`): +##### PowerShell script (`scripts/powershell/update-agent-context.ps1`) Add file variable: + ```powershell $windsurfFile = Join-Path $repoRoot '.windsurf/rules/specify-rules.md' ``` Add to switch statement: + ```powershell switch ($AgentType) { # ... existing cases ... @@ -200,6 +208,7 @@ elif selected_ai == "windsurf": **CRITICAL**: When adding a new agent to AGENT_CONFIG, always use the **actual executable name** as the dictionary key, not a shortened or convenient version. **Why this matters:** + - The `check_tool()` function uses `shutil.which(tool)` to find executables in the system PATH - If the key doesn't match the actual CLI tool name, you'll need special-case mappings throughout the codebase - This creates unnecessary complexity and maintenance burden @@ -207,6 +216,7 @@ elif selected_ai == "windsurf": **Example - The Cursor Lesson:** ❌ **Wrong approach** (requires special-case mapping): + ```python AGENT_CONFIG = { "cursor": { # Shorthand that doesn't match the actual tool @@ -222,6 +232,7 @@ if agent_key == "cursor": ``` ✅ **Correct approach** (no mapping needed): + ```python AGENT_CONFIG = { "cursor-agent": { # Matches the actual executable name @@ -234,6 +245,7 @@ AGENT_CONFIG = { ``` **Benefits of this approach:** + - Eliminates special-case logic scattered throughout the codebase - Makes the code more maintainable and easier to understand - Reduces the chance of bugs when adding new agents @@ -289,6 +301,7 @@ echo "✅ Done" ### CLI-Based Agents Require a command-line tool to be installed: + - **Claude Code**: `claude` CLI - **Gemini CLI**: `gemini` CLI - **Cursor**: `cursor-agent` CLI @@ -298,13 +311,16 @@ Require a command-line tool to be installed: - **CodeBuddy CLI**: `codebuddy` CLI ### IDE-Based Agents + Work within integrated development environments: + - **GitHub Copilot**: Built into VS Code/compatible editors - **Windsurf**: Built into Windsurf IDE ## Command File Formats ### Markdown Format + Used by: Claude, Cursor, opencode, Windsurf, Amazon Q Developer ```markdown @@ -316,6 +332,7 @@ Command content with {SCRIPT} and $ARGUMENTS placeholders. ``` ### TOML Format + Used by: Gemini, Qwen ```toml @@ -337,6 +354,7 @@ Command content with {SCRIPT} and {{args}} placeholders. ## Argument Patterns Different agents use different argument placeholders: + - **Markdown/prompt-based**: `$ARGUMENTS` - **TOML-based**: `{{args}}` - **Script placeholders**: `{SCRIPT}` (replaced with actual script path) @@ -372,4 +390,3 @@ When adding new agents: --- *This documentation should be updated whenever new agents are added to maintain accuracy and completeness.* - diff --git a/CHANGELOG.md b/CHANGELOG.md index 3ca2ee00..ea672914 100644 --- a/CHANGELOG.md +++ b/CHANGELOG.md @@ -63,7 +63,7 @@ and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0 - New `/clarify` command template to surface up to 5 targeted clarification questions for an existing spec and persist answers into a Clarifications section in the spec. - New `/analyze` command template providing a non-destructive cross-artifact discrepancy and alignment report (spec, clarifications, plan, tasks, constitution) inserted after `/tasks` and before `/implement`. - - Note: Constitution rules are explicitly treated as non-negotiable; any conflict is a CRITICAL finding requiring artifact remediation, not weakening of principles. + - Note: Constitution rules are explicitly treated as non-negotiable; any conflict is a CRITICAL finding requiring artifact remediation, not weakening of principles. ## [0.0.16] - 2025-09-22 @@ -140,7 +140,6 @@ and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0 - Updated command instructions in the CLI. - Cleaned up the code to not render agent-specific information when it's generic. - ## [0.0.6] - 2025-09-17 ### Added @@ -166,4 +165,3 @@ N/A ### Changed N/A - diff --git a/CODE_OF_CONDUCT.md b/CODE_OF_CONDUCT.md index 6dc4b121..73a27ec9 100644 --- a/CODE_OF_CONDUCT.md +++ b/CODE_OF_CONDUCT.md @@ -14,21 +14,21 @@ orientation. Examples of behavior that contributes to creating a positive environment include: -* Using welcoming and inclusive language -* Being respectful of differing viewpoints and experiences -* Gracefully accepting constructive criticism -* Focusing on what is best for the community -* Showing empathy towards other community members +- Using welcoming and inclusive language +- Being respectful of differing viewpoints and experiences +- Gracefully accepting constructive criticism +- Focusing on what is best for the community +- Showing empathy towards other community members Examples of unacceptable behavior by participants include: -* The use of sexualized language or imagery and unwelcome sexual attention or +- The use of sexualized language or imagery and unwelcome sexual attention or advances -* Trolling, insulting/derogatory comments, and personal or political attacks -* Public or private harassment -* Publishing others' private information, such as a physical or electronic +- Trolling, insulting/derogatory comments, and personal or political attacks +- Public or private harassment +- Publishing others' private information, such as a physical or electronic address, without explicit permission -* Other conduct which could reasonably be considered inappropriate in a +- Other conduct which could reasonably be considered inappropriate in a professional setting ## Our Responsibilities diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md index 92894915..3e6e24aa 100644 --- a/CONTRIBUTING.md +++ b/CONTRIBUTING.md @@ -1,4 +1,4 @@ -## Contributing to Spec Kit +# Contributing to Spec Kit Hi there! We're thrilled that you'd like to contribute to Spec Kit. Contributions to this project are [released](https://help.github.com/articles/github-terms-of-service/#6-contributions-under-repository-license) to the public under the [project's open source license](LICENSE). @@ -125,4 +125,3 @@ Please be respectful to maintainers and disclose AI assistance. - [How to Contribute to Open Source](https://opensource.guide/how-to-contribute/) - [Using Pull Requests](https://help.github.com/articles/about-pull-requests/) - [GitHub Help](https://help.github.com) - diff --git a/README.md b/README.md index cb20ad6c..fed79325 100644 --- a/README.md +++ b/README.md @@ -1,5 +1,5 @@
- + Spec Kit Logo

🌱 Spec Kit

Build high-quality software faster.

@@ -253,7 +253,7 @@ Additional commands for enhanced quality and validation: Spec-Driven Development is a structured process that emphasizes: -- **Intent-driven development** where specifications define the "_what_" before the "_how_" +- **Intent-driven development** where specifications define the "*what*" before the "*how*" - **Rich specification creation** using guardrails and organizational principles - **Multi-step refinement** rather than one-shot code generation from prompts - **Heavy reliance** on advanced AI model capabilities for specification interpretation @@ -383,7 +383,7 @@ This step creates or updates the `.specify/memory/constitution.md` file with you With your project principles established, you can now create the functional specifications. Use the `/speckit.specify` command and then provide the concrete requirements for the project you want to develop. >[!IMPORTANT] ->Be as explicit as possible about _what_ you are trying to build and _why_. **Do not focus on the tech stack at this point**. +>Be as explicit as possible about *what* you are trying to build and *why*. **Do not focus on the tech stack at this point**. An example prompt: @@ -417,16 +417,16 @@ At this stage, your project folder contents should resemble the following: ```text └── .specify ├── memory - │ └── constitution.md + │ └── constitution.md ├── scripts - │ ├── check-prerequisites.sh - │ ├── common.sh - │ ├── create-new-feature.sh - │ ├── setup-plan.sh - │ └── update-claude-md.sh + │ ├── check-prerequisites.sh + │ ├── common.sh + │ ├── create-new-feature.sh + │ ├── setup-plan.sh + │ └── update-claude-md.sh ├── specs - │ └── 001-create-taskify - │ └── spec.md + │ └── 001-create-taskify + │ └── spec.md └── templates ├── plan-template.md ├── spec-template.md @@ -440,6 +440,7 @@ With the baseline specification created, you can go ahead and clarify any of the You should run the structured clarification workflow **before** creating a technical plan to reduce rework downstream. Preferred order: + 1. Use `/speckit.clarify` (structured) – sequential, coverage-based questioning that records answers in a Clarifications section. 2. Optionally follow up with ad-hoc free-form refinement if something still feels vague. @@ -477,23 +478,23 @@ The output of this step will include a number of implementation detail documents . ├── CLAUDE.md ├── memory -│ └── constitution.md +│ └── constitution.md ├── scripts -│ ├── check-prerequisites.sh -│ ├── common.sh -│ ├── create-new-feature.sh -│ ├── setup-plan.sh -│ └── update-claude-md.sh +│ ├── check-prerequisites.sh +│ ├── common.sh +│ ├── create-new-feature.sh +│ ├── setup-plan.sh +│ └── update-claude-md.sh ├── specs -│ └── 001-create-taskify -│ ├── contracts -│ │ ├── api-spec.json -│ │ └── signalr-spec.md -│ ├── data-model.md -│ ├── plan.md -│ ├── quickstart.md -│ ├── research.md -│ └── spec.md +│ └── 001-create-taskify +│ ├── contracts +│ │ ├── api-spec.json +│ │ └── signalr-spec.md +│ ├── data-model.md +│ ├── plan.md +│ ├── quickstart.md +│ ├── research.md +│ └── spec.md └── templates ├── CLAUDE-template.md ├── plan-template.md @@ -575,6 +576,7 @@ Once ready, use the `/speckit.implement` command to execute your implementation ``` The `/speckit.implement` command will: + - Validate that all prerequisites are in place (constitution, spec, plan, and tasks) - Parse the task breakdown from `tasks.md` - Execute tasks in the correct order, respecting dependencies and parallel execution markers @@ -625,4 +627,3 @@ This project is heavily influenced by and based on the work and research of [Joh ## 📄 License This project is licensed under the terms of the MIT open source license. Please refer to the [LICENSE](./LICENSE) file for the full terms. - diff --git a/SECURITY.md b/SECURITY.md index 67a9cbf2..4c1e92da 100644 --- a/SECURITY.md +++ b/SECURITY.md @@ -1,10 +1,10 @@ -Thanks for helping make GitHub safe for everyone. +# Security Policy -# Security +Thanks for helping make GitHub safe for everyone. GitHub takes the security of our software products and services seriously, including all of the open source code repositories managed through our GitHub organizations, such as [GitHub](https://github.com/GitHub). -Even though [open source repositories are outside of the scope of our bug bounty program](https://bounty.github.com/index.html#scope) and therefore not eligible for bounty rewards, we will ensure that your finding gets passed along to the appropriate maintainers for remediation. +Even though [open source repositories are outside of the scope of our bug bounty program](https://bounty.github.com/index.html#scope) and therefore not eligible for bounty rewards, we will ensure that your finding gets passed along to the appropriate maintainers for remediation. ## Reporting Security Issues @@ -16,13 +16,13 @@ Instead, please send an email to opensource-security[@]github.com. Please include as much of the information listed below as you can to help us better understand and resolve the issue: - * The type of issue (e.g., buffer overflow, SQL injection, or cross-site scripting) - * Full paths of source file(s) related to the manifestation of the issue - * The location of the affected source code (tag/branch/commit or direct URL) - * Any special configuration required to reproduce the issue - * Step-by-step instructions to reproduce the issue - * Proof-of-concept or exploit code (if possible) - * Impact of the issue, including how an attacker might exploit the issue +- The type of issue (e.g., buffer overflow, SQL injection, or cross-site scripting) +- Full paths of source file(s) related to the manifestation of the issue +- The location of the affected source code (tag/branch/commit or direct URL) +- Any special configuration required to reproduce the issue +- Step-by-step instructions to reproduce the issue +- Proof-of-concept or exploit code (if possible) +- Impact of the issue, including how an attacker might exploit the issue This information will help us triage your report more quickly. diff --git a/SUPPORT.md b/SUPPORT.md index c75ce9bd..c6acf76e 100644 --- a/SUPPORT.md +++ b/SUPPORT.md @@ -1,4 +1,4 @@ -# Support +# Support ## How to file issues and get help @@ -17,4 +17,3 @@ For help or questions about using this project, please: ## GitHub Support Policy Support for this project is limited to the resources listed above. - diff --git a/docs/README.md b/docs/README.md index 7a155cfa..a9edc81d 100644 --- a/docs/README.md +++ b/docs/README.md @@ -7,11 +7,13 @@ This folder contains the documentation source files for Spec Kit, built using [D To build the documentation locally: 1. Install DocFX: + ```bash dotnet tool install -g docfx ``` 2. Build the documentation: + ```bash cd docs docfx docfx.json --serve @@ -31,4 +33,3 @@ To build the documentation locally: ## Deployment Documentation is automatically built and deployed to GitHub Pages when changes are pushed to the `main` branch. The workflow is defined in `.github/workflows/docs.yml`. - diff --git a/docs/index.md b/docs/index.md index e134404e..38a6de34 100644 --- a/docs/index.md +++ b/docs/index.md @@ -18,7 +18,7 @@ Spec-Driven Development **flips the script** on traditional software development Spec-Driven Development is a structured process that emphasizes: -- **Intent-driven development** where specifications define the "_what_" before the "_how_" +- **Intent-driven development** where specifications define the "*what*" before the "*how*" - **Rich specification creation** using guardrails and organizational principles - **Multi-step refinement** rather than one-shot code generation from prompts - **Heavy reliance** on advanced AI model capabilities for specification interpretation @@ -36,19 +36,23 @@ Spec-Driven Development is a structured process that emphasizes: Our research and experimentation focus on: ### Technology Independence + - Create applications using diverse technology stacks - Validate the hypothesis that Spec-Driven Development is a process not tied to specific technologies, programming languages, or frameworks ### Enterprise Constraints + - Demonstrate mission-critical application development - Incorporate organizational constraints (cloud providers, tech stacks, engineering practices) - Support enterprise design systems and compliance requirements ### User-Centric Development + - Build applications for different user cohorts and preferences - Support various development approaches (from vibe-coding to AI-native development) ### Creative & Iterative Processes + - Validate the concept of parallel implementation exploration - Provide robust iterative feature development workflows - Extend processes to handle upgrades and modernization tasks @@ -60,4 +64,3 @@ Please see our [Contributing Guide](https://github.com/github/spec-kit/blob/main ## Support For support, please check our [Support Guide](https://github.com/github/spec-kit/blob/main/SUPPORT.md) or open an issue on GitHub. - diff --git a/docs/installation.md b/docs/installation.md index d4dfaa3d..6daff243 100644 --- a/docs/installation.md +++ b/docs/installation.md @@ -42,11 +42,13 @@ uvx --from git+https://github.com/github/spec-kit.git specify init --script sh uvx --from git+https://github.com/github/spec-kit.git specify init --script ps @@ -63,6 +65,7 @@ uvx --from git+https://github.com/github/spec-kit.git specify init --script ps # Force PowerShell uvx --from git+https://github.com/github/spec-kit.git specify init --script sh # Force POSIX shell @@ -120,4 +121,3 @@ implement specs/002-create-taskify/plan.md - Read the complete methodology for in-depth guidance - Check out more examples in the repository - Explore the source code on GitHub - diff --git a/spec-driven.md b/spec-driven.md index 13edc9e3..0e546ff3 100644 --- a/spec-driven.md +++ b/spec-driven.md @@ -401,4 +401,3 @@ By embedding these principles into the specification and planning process, SDD e This isn't about replacing developers or automating creativity. It's about amplifying human capability by automating mechanical translation. It's about creating a tight feedback loop where specifications, research, and code evolve together, each iteration bringing deeper understanding and better alignment between intent and implementation. Software development needs better tools for maintaining alignment between intent and implementation. SDD provides the methodology for achieving this alignment through executable specifications that generate code rather than merely guiding it. - diff --git a/templates/agent-file-template.md b/templates/agent-file-template.md index f7349979..4cc7fd66 100644 --- a/templates/agent-file-template.md +++ b/templates/agent-file-template.md @@ -3,20 +3,25 @@ Auto-generated from all feature plans. Last updated: [DATE] ## Active Technologies + [EXTRACTED FROM ALL PLAN.MD FILES] ## Project Structure -``` + +```text [ACTUAL STRUCTURE FROM PLANS] ``` ## Commands + [ONLY COMMANDS FOR ACTIVE TECHNOLOGIES] ## Code Style + [LANGUAGE-SPECIFIC, ONLY FOR LANGUAGES IN USE] ## Recent Changes + [LAST 3 FEATURES AND WHAT THEY ADDED] diff --git a/templates/checklist-template.md b/templates/checklist-template.md index 1c8b11a1..806657da 100644 --- a/templates/checklist-template.md +++ b/templates/checklist-template.md @@ -38,4 +38,3 @@ - Add comments or findings inline - Link to relevant resources or documentation - Items are numbered sequentially for easy reference - diff --git a/templates/commands/analyze.md b/templates/commands/analyze.md index 82957e5e..473339fc 100644 --- a/templates/commands/analyze.md +++ b/templates/commands/analyze.md @@ -185,4 +185,3 @@ Ask the user: "Would you like me to suggest concrete remediation edits for the t ## Context {ARGS} - diff --git a/templates/commands/checklist.md b/templates/commands/checklist.md index 0900e33a..e32a2c84 100644 --- a/templates/commands/checklist.md +++ b/templates/commands/checklist.md @@ -10,12 +10,14 @@ scripts: **CRITICAL CONCEPT**: Checklists are **UNIT TESTS FOR REQUIREMENTS WRITING** - they validate the quality, clarity, and completeness of requirements in a given domain. **NOT for verification/testing**: + - ❌ NOT "Verify the button clicks correctly" - ❌ NOT "Test error handling works" - ❌ NOT "Confirm the API returns 200" - ❌ NOT checking if code/implementation matches the spec **FOR requirements quality validation**: + - ✅ "Are visual hierarchy requirements defined for all card types?" (completeness) - ✅ "Is 'prominent display' quantified with specific sizing/positioning?" (clarity) - ✅ "Are hover state requirements consistent across all interactive elements?" (consistency) @@ -80,7 +82,7 @@ You **MUST** consider the user input before proceeding (if not empty). - spec.md: Feature requirements and scope - plan.md (if exists): Technical details, dependencies - tasks.md (if exists): Implementation tasks - + **Context Loading Strategy**: - Load only necessary portions relevant to active focus areas (avoid full-file dumping) - Prefer summarizing long sections into concise scenario/requirement bullets @@ -91,7 +93,7 @@ You **MUST** consider the user input before proceeding (if not empty). - Create `FEATURE_DIR/checklists/` directory if it doesn't exist - Generate unique checklist filename: - Use short, descriptive name based on domain (e.g., `ux.md`, `api.md`, `security.md`) - - Format: `[domain].md` + - Format: `[domain].md` - If file exists, append to existing file - Number items sequentially starting from CHK001 - Each `/speckit.checklist` run creates a NEW file (never overwrites existing checklists) @@ -103,7 +105,7 @@ You **MUST** consider the user input before proceeding (if not empty). - **Consistency**: Do requirements align with each other? - **Measurability**: Can requirements be objectively verified? - **Coverage**: Are all scenarios/edge cases addressed? - + **Category Structure** - Group items by requirement quality dimensions: - **Requirement Completeness** (Are all necessary requirements documented?) - **Requirement Clarity** (Are requirements specific and unambiguous?) @@ -114,14 +116,14 @@ You **MUST** consider the user input before proceeding (if not empty). - **Non-Functional Requirements** (Performance, Security, Accessibility, etc. - are they specified?) - **Dependencies & Assumptions** (Are they documented and validated?) - **Ambiguities & Conflicts** (What needs clarification?) - + **HOW TO WRITE CHECKLIST ITEMS - "Unit Tests for English"**: - + ❌ **WRONG** (Testing implementation): - "Verify landing page displays 3 episode cards" - "Test hover states work on desktop" - "Confirm logo click navigates home" - + ✅ **CORRECT** (Testing requirements quality): - "Are the exact number and layout of featured episodes specified?" [Completeness] - "Is 'prominent display' quantified with specific sizing/positioning?" [Clarity] @@ -130,7 +132,7 @@ You **MUST** consider the user input before proceeding (if not empty). - "Is the fallback behavior specified when logo image fails to load?" [Edge Cases] - "Are loading states defined for asynchronous episode data?" [Completeness] - "Does the spec define visual hierarchy for competing UI elements?" [Clarity] - + **ITEM STRUCTURE**: Each item should follow this pattern: - Question format asking about requirement quality @@ -138,28 +140,28 @@ You **MUST** consider the user input before proceeding (if not empty). - Include quality dimension in brackets [Completeness/Clarity/Consistency/etc.] - Reference spec section `[Spec §X.Y]` when checking existing requirements - Use `[Gap]` marker when checking for missing requirements - + **EXAMPLES BY QUALITY DIMENSION**: - + Completeness: - "Are error handling requirements defined for all API failure modes? [Gap]" - "Are accessibility requirements specified for all interactive elements? [Completeness]" - "Are mobile breakpoint requirements defined for responsive layouts? [Gap]" - + Clarity: - "Is 'fast loading' quantified with specific timing thresholds? [Clarity, Spec §NFR-2]" - "Are 'related episodes' selection criteria explicitly defined? [Clarity, Spec §FR-5]" - "Is 'prominent' defined with measurable visual properties? [Ambiguity, Spec §FR-4]" - + Consistency: - "Do navigation requirements align across all pages? [Consistency, Spec §FR-10]" - "Are card component requirements consistent between landing and detail pages? [Consistency]" - + Coverage: - "Are requirements defined for zero-state scenarios (no episodes)? [Coverage, Edge Case]" - "Are concurrent user interaction scenarios addressed? [Coverage, Gap]" - "Are requirements specified for partial data loading failures? [Coverage, Exception Flow]" - + Measurability: - "Are visual hierarchy requirements measurable/testable? [Acceptance Criteria, Spec §FR-1]" - "Can 'balanced visual weight' be objectively verified? [Measurability, Spec §FR-2]" @@ -195,7 +197,7 @@ You **MUST** consider the user input before proceeding (if not empty). - ❌ "Click", "navigate", "render", "load", "execute" - ❌ Test cases, test plans, QA procedures - ❌ Implementation details (frameworks, APIs, algorithms) - + **✅ REQUIRED PATTERNS** - These test requirements quality: - ✅ "Are [requirement type] defined/specified/documented for [scenario]?" - ✅ "Is [vague term] quantified/clarified with specific criteria?" @@ -225,6 +227,7 @@ To avoid clutter, use descriptive types and clean up obsolete checklists when do **UX Requirements Quality:** `ux.md` Sample items (testing the requirements, NOT the implementation): + - "Are visual hierarchy requirements defined with measurable criteria? [Clarity, Spec §FR-1]" - "Is the number and positioning of UI elements explicitly specified? [Completeness, Spec §FR-1]" - "Are interaction state requirements (hover, focus, active) consistently defined? [Consistency]" @@ -235,6 +238,7 @@ Sample items (testing the requirements, NOT the implementation): **API Requirements Quality:** `api.md` Sample items: + - "Are error response formats specified for all failure scenarios? [Completeness]" - "Are rate limiting requirements quantified with specific thresholds? [Clarity]" - "Are authentication requirements consistent across all endpoints? [Consistency]" @@ -244,6 +248,7 @@ Sample items: **Performance Requirements Quality:** `performance.md` Sample items: + - "Are performance requirements quantified with specific metrics? [Clarity]" - "Are performance targets defined for all critical user journeys? [Coverage]" - "Are performance requirements under different load conditions specified? [Completeness]" @@ -253,6 +258,7 @@ Sample items: **Security Requirements Quality:** `security.md` Sample items: + - "Are authentication requirements specified for all protected resources? [Coverage]" - "Are data protection requirements defined for sensitive information? [Completeness]" - "Is the threat model documented and requirements aligned to it? [Traceability]" @@ -282,10 +288,10 @@ Sample items: ``` **Key Differences:** + - Wrong: Tests if the system works correctly - Correct: Tests if the requirements are written correctly - Wrong: Verification of behavior - Correct: Validation of requirement quality -- Wrong: "Does it do X?" +- Wrong: "Does it do X?" - Correct: "Is X clearly specified?" - diff --git a/templates/commands/clarify.md b/templates/commands/clarify.md index 65f2536f..9a62dfa7 100644 --- a/templates/commands/clarify.md +++ b/templates/commands/clarify.md @@ -87,63 +87,63 @@ Execution steps: 3. Generate (internally) a prioritized queue of candidate clarification questions (maximum 5). Do NOT output them all at once. Apply these constraints: - Maximum of 10 total questions across the whole session. - Each question must be answerable with EITHER: - * A short multiple‑choice selection (2–5 distinct, mutually exclusive options), OR - * A one-word / short‑phrase answer (explicitly constrain: "Answer in <=5 words"). - - Only include questions whose answers materially impact architecture, data modeling, task decomposition, test design, UX behavior, operational readiness, or compliance validation. - - Ensure category coverage balance: attempt to cover the highest impact unresolved categories first; avoid asking two low-impact questions when a single high-impact area (e.g., security posture) is unresolved. - - Exclude questions already answered, trivial stylistic preferences, or plan-level execution details (unless blocking correctness). - - Favor clarifications that reduce downstream rework risk or prevent misaligned acceptance tests. - - If more than 5 categories remain unresolved, select the top 5 by (Impact * Uncertainty) heuristic. + - A short multiple‑choice selection (2–5 distinct, mutually exclusive options), OR + - A one-word / short‑phrase answer (explicitly constrain: "Answer in <=5 words"). + - Only include questions whose answers materially impact architecture, data modeling, task decomposition, test design, UX behavior, operational readiness, or compliance validation. + - Ensure category coverage balance: attempt to cover the highest impact unresolved categories first; avoid asking two low-impact questions when a single high-impact area (e.g., security posture) is unresolved. + - Exclude questions already answered, trivial stylistic preferences, or plan-level execution details (unless blocking correctness). + - Favor clarifications that reduce downstream rework risk or prevent misaligned acceptance tests. + - If more than 5 categories remain unresolved, select the top 5 by (Impact * Uncertainty) heuristic. 4. Sequential questioning loop (interactive): - Present EXACTLY ONE question at a time. - For multiple‑choice questions: - * **Analyze all options** and determine the **most suitable option** based on: + - **Analyze all options** and determine the **most suitable option** based on: - Best practices for the project type - Common patterns in similar implementations - Risk reduction (security, performance, maintainability) - Alignment with any explicit project goals or constraints visible in the spec - * Present your **recommended option prominently** at the top with clear reasoning (1-2 sentences explaining why this is the best choice). - * Format as: `**Recommended:** Option [X] - ` - * Then render all options as a Markdown table: + - Present your **recommended option prominently** at the top with clear reasoning (1-2 sentences explaining why this is the best choice). + - Format as: `**Recommended:** Option [X] - ` + - Then render all options as a Markdown table: | Option | Description | |--------|-------------| | A |