|
| 1 | +### YamlMime:ModuleUnit |
| 2 | +uid: learn.wwl.spec-driven-development-github-spec-kit-greenfield-intro.knowledge-check |
| 3 | +title: Module assessment |
| 4 | +metadata: |
| 5 | + title: Module Assessment |
| 6 | + description: "Module assessment" |
| 7 | + ms.date: 01/26/2026 |
| 8 | + author: chrishowd |
| 9 | + ms.author: cahowd |
| 10 | + ms.topic: unit |
| 11 | +durationInMinutes: 10 |
| 12 | +quiz: |
| 13 | + title: "Check your knowledge" |
| 14 | + questions: |
| 15 | + - content: "What is the primary characteristic that distinguishes spec-driven development (SDD) from traditional development approaches?" |
| 16 | + choices: |
| 17 | + - content: "Code is treated as the ultimate source of truth, and specifications serve as supporting documentation." |
| 18 | + isCorrect: false |
| 19 | + explanation: "Incorrect. This describes traditional development, not spec-driven development. In SDD, the relationship is inverted." |
| 20 | + - content: "Specifications become the primary artifact that drives implementation, and code becomes an expression of those specifications." |
| 21 | + isCorrect: true |
| 22 | + explanation: "Correct. In spec-driven development, specifications are the central source of truth. Code is generated from specifications, eliminating the gap between intent and implementation." |
| 23 | + - content: "Developers write code first and then create specifications to document what was built." |
| 24 | + isCorrect: false |
| 25 | + explanation: "Incorrect. This code-first approach is the opposite of SDD, which emphasizes defining specifications before implementation." |
| 26 | + - content: "What happens to specifications in spec-driven development (SDD) when requirements change?" |
| 27 | + choices: |
| 28 | + - content: "Specifications are treated as static documents that rarely need updates once created." |
| 29 | + isCorrect: false |
| 30 | + explanation: "Incorrect. This describes Waterfall-style documentation. SDD specifications are living documents that evolve with the project." |
| 31 | + - content: "Specifications are discarded and new ones are created from scratch." |
| 32 | + isCorrect: false |
| 33 | + explanation: "Incorrect. SDD doesn't require starting over. Specifications are updated, and changes propagate through plan, tasks, and code." |
| 34 | + - content: "Specifications are updated, and affected implementation plans and code can be regenerated accordingly." |
| 35 | + isCorrect: true |
| 36 | + explanation: "Correct. SDD transforms requirement changes from obstacles into normal workflow. When specifications are updated, implementation plans and code can be systematically regenerated." |
| 37 | + - content: "What are the four phases of the spec-driven development (SDD) workflow?" |
| 38 | + choices: |
| 39 | + - content: "Research, Design, Develop, and Deploy." |
| 40 | + isCorrect: false |
| 41 | + explanation: "Incorrect. These phases don't represent the SDD workflow, which has a specific structure for AI-assisted development." |
| 42 | + - content: "Specify, Plan, Tasks, and Implement." |
| 43 | + isCorrect: true |
| 44 | + explanation: "Correct. The SDD workflow progresses through these four phases: define what to build (Specify), determine how to build it (Plan), break it into actionable items (Tasks), and write the code (Implement)." |
| 45 | + - content: "Requirements, Architecture, Coding, and Testing." |
| 46 | + isCorrect: false |
| 47 | + explanation: "Incorrect. While these are common development activities, they don't match the specific SDD phase terminology." |
| 48 | + - content: "What distinguishes spec-driven development (SDD) outputs as 'living artifacts' compared to traditional documentation?" |
| 49 | + choices: |
| 50 | + - content: "Living artifacts are stored in version control systems." |
| 51 | + isCorrect: false |
| 52 | + explanation: "Incorrect. While living artifacts can be stored in version control, this isn't what makes them 'living.' Traditional docs can also be version-controlled." |
| 53 | + - content: "Living artifacts can evolve as new information emerges, with changes propagating through plan, tasks, and code." |
| 54 | + isCorrect: true |
| 55 | + explanation: "Correct. Living artifacts are continuously used, updated, and refined. When requirements change, the spec updates, and those changes flow through to implementation." |
| 56 | + - content: "Living artifacts are automatically generated without human input." |
| 57 | + isCorrect: false |
| 58 | + explanation: "Incorrect. Living artifacts require human oversight and refinement. The 'living' aspect refers to their ability to evolve, not automation." |
| 59 | + - content: "How does spec-driven development (SDD) complement Agile methodologies?" |
| 60 | + choices: |
| 61 | + - content: "SDD replaces Agile practices entirely with a more structured approach." |
| 62 | + isCorrect: false |
| 63 | + explanation: "Incorrect. SDD doesn't replace Agile. The two approaches share common values and can work together effectively." |
| 64 | + - content: "SDD can operate within Scrum by treating each user story with a micro-cycle of specify, plan, tasks, and implement." |
| 65 | + isCorrect: true |
| 66 | + explanation: "Correct. SDD supports agility by making changes easier - update the spec, regenerate plan and tasks, and continue. An Agile team can adopt SDD within each sprint." |
| 67 | + - content: "SDD requires comprehensive upfront documentation that conflicts with Agile values." |
| 68 | + isCorrect: false |
| 69 | + explanation: "Incorrect. While SDD emphasizes specifications, these are living documents that evolve, aligning with Agile's embrace of change." |
| 70 | + - content: "When comparing spec-driven development (SDD) to Test-Driven Development (TDD), what is a key difference in their approach?" |
| 71 | + choices: |
| 72 | + - content: "TDD operates at the unit test level, while SDD works at a higher requirements level to describe complete features." |
| 73 | + isCorrect: true |
| 74 | + explanation: "Correct. TDD drives design through unit tests for individual functions, while SDD uses specifications that describe complete features to drive design and code generation." |
| 75 | + - content: "TDD and SDD are mutually exclusive approaches that can't be used together." |
| 76 | + isCorrect: false |
| 77 | + explanation: "Incorrect. TDD and SDD can complement each other. You can use SDD for overall direction and still apply TDD within implementation." |
| 78 | + - content: "SDD produces automated tests while TDD produces specifications." |
| 79 | + isCorrect: false |
| 80 | + explanation: "Incorrect. This reverses the primary artifacts. TDD produces tests; SDD produces specifications that drive implementation." |
| 81 | + - content: "In the Specify phase of spec-driven development (SDD), what does a well-structured specification include?" |
| 82 | + choices: |
| 83 | + - content: "Only a high-level summary of the feature with implementation details." |
| 84 | + isCorrect: false |
| 85 | + explanation: "Incorrect. A specification focuses on what the software should do, not implementation details. It includes multiple sections beyond just a summary." |
| 86 | + - content: "Summary, user stories, acceptance criteria, functional requirements, nonfunctional requirements, and edge cases." |
| 87 | + isCorrect: true |
| 88 | + explanation: "Correct. A well-structured specification includes all these sections to comprehensively define what the software should do without specifying how." |
| 89 | + - content: "Architecture diagrams and technology stack decisions." |
| 90 | + isCorrect: false |
| 91 | + explanation: "Incorrect. Architecture and technology decisions belong in the Plan phase, not the Specify phase." |
| 92 | + - content: "What is the purpose of the Plan phase in the spec-driven development (SDD) workflow?" |
| 93 | + choices: |
| 94 | + - content: "To define what the software should do and capture user needs." |
| 95 | + isCorrect: false |
| 96 | + explanation: "Incorrect. Defining what the software should do is the purpose of the Specify phase, not the Plan phase." |
| 97 | + - content: "To determine how to build what the spec describes, including architecture decisions and technology choices." |
| 98 | + isCorrect: true |
| 99 | + explanation: "Correct. The Plan phase transforms requirements into architecture decisions, technology stack choices, and implementation sequence." |
| 100 | + - content: "To break down work into actionable development tasks." |
| 101 | + isCorrect: false |
| 102 | + explanation: "Incorrect. Breaking down work into actionable tasks is the purpose of the Tasks phase, not the Plan phase." |
| 103 | + - content: "What is GitHub Spec Kit?" |
| 104 | + choices: |
| 105 | + - content: "A proprietary AI model developed by GitHub for code generation." |
| 106 | + isCorrect: false |
| 107 | + explanation: "Incorrect. GitHub Spec Kit isn't an AI model. It's a framework and CLI that works with your chosen AI agent." |
| 108 | + - content: "An open-source toolkit that facilitates spec-driven development by integrating with AI coding assistants." |
| 109 | + isCorrect: true |
| 110 | + explanation: "Correct. GitHub Spec Kit is an open-source toolkit developed by GitHub that orchestrates the spec-driven development workflow through structured commands, templates, and persistent artifacts." |
| 111 | + - content: "A Visual Studio Code extension that replaces GitHub Copilot." |
| 112 | + isCorrect: false |
| 113 | + explanation: "Incorrect. GitHub Spec Kit works alongside AI assistants like GitHub Copilot, not as a replacement." |
| 114 | + - content: "How does GitHub Spec Kit address the challenge of maintaining context across AI chat sessions?" |
| 115 | + choices: |
| 116 | + - content: "By storing specifications, plans, and tasks as Markdown files in your repository." |
| 117 | + isCorrect: true |
| 118 | + explanation: "Correct. GitHub Spec Kit creates persistent artifacts that maintain context across sessions. The AI can reference these files to understand previous decisions and project requirements." |
| 119 | + - content: "By replacing the AI's memory with a cloud-based storage system." |
| 120 | + isCorrect: false |
| 121 | + explanation: "Incorrect. GitHub Spec Kit uses local Markdown files in your repository, not cloud-based memory replacement." |
| 122 | + - content: "By limiting AI interactions to a single continuous session." |
| 123 | + isCorrect: false |
| 124 | + explanation: "Incorrect. GitHub Spec Kit enables multiple sessions by persisting context in files, not by restricting to single sessions." |
| 125 | + - content: "What is required to install GitHub Spec Kit's specify CLI tool?" |
| 126 | + choices: |
| 127 | + - content: "Only Visual Studio Code with the GitHub Copilot extension." |
| 128 | + isCorrect: false |
| 129 | + explanation: "Incorrect. While Visual Studio Code with GitHub Copilot is one supported environment, you also need Python 3.11+, Git, and the uv tool for installation." |
| 130 | + - content: "Python 3.11 or later, Git, and the uv tool for package management." |
| 131 | + isCorrect: true |
| 132 | + explanation: "Correct. These are the core prerequisites. On Windows, you should also use WSL2 since GitHub Spec Kit expects a Unix-like environment." |
| 133 | + - content: "A paid enterprise license from GitHub." |
| 134 | + isCorrect: false |
| 135 | + explanation: "Incorrect. GitHub Spec Kit is open source and doesn't require an enterprise license." |
| 136 | + - content: "Which AI coding assistants does GitHub Spec Kit support?" |
| 137 | + choices: |
| 138 | + - content: "Only GitHub Copilot in Visual Studio Code." |
| 139 | + isCorrect: false |
| 140 | + explanation: "Incorrect. GitHub Spec Kit supports multiple AI assistants, not just GitHub Copilot." |
| 141 | + - content: "Multiple agents including GitHub Copilot, Claude Code, Cursor, Windsurf, and Amazon Q Developer." |
| 142 | + isCorrect: true |
| 143 | + explanation: "Correct. GitHub Spec Kit's agent-agnostic approach supports multiple AI coding assistants. The underlying specification artifacts remain identical regardless of which assistant you use." |
| 144 | + - content: "Only command-line AI tools, not IDE-integrated assistants." |
| 145 | + isCorrect: false |
| 146 | + explanation: "Incorrect. GitHub Spec Kit supports both CLI and IDE-integrated AI assistants." |
| 147 | + - content: "What is the purpose of the constitution.md file generated by the /speckit.constitution command?" |
| 148 | + choices: |
| 149 | + - content: "To store the source code for the application's core functionality." |
| 150 | + isCorrect: false |
| 151 | + explanation: "Incorrect. The constitution contains project principles and constraints, not source code." |
| 152 | + - content: "To define project-wide principles, constraints, and non-negotiable requirements that ensure consistency." |
| 153 | + isCorrect: true |
| 154 | + explanation: "Correct. The constitution captures technology standards, security requirements, coding conventions, and other principles that the AI uses when generating plans and code." |
| 155 | + - content: "To list all the tasks required for implementing a feature." |
| 156 | + isCorrect: false |
| 157 | + explanation: "Incorrect. Tasks are stored in tasks.md, not constitution.md. The constitution contains guiding principles, not task lists." |
| 158 | + - content: "What is the recommended sequence for using GitHub Spec Kit commands in a greenfield project?" |
| 159 | + choices: |
| 160 | + - content: "Run commands in any order since they're independent of each other." |
| 161 | + isCorrect: false |
| 162 | + explanation: "Incorrect. The commands follow a specific sequence where each builds on the outputs of the previous one." |
| 163 | + - content: "specify init, then /speckit.constitution, /speckit.specify, /speckit.plan, /speckit.tasks, and finally /speckit.implement." |
| 164 | + isCorrect: true |
| 165 | + explanation: "Correct. This sequence ensures each phase has the necessary inputs from previous phases. Project initialization comes first, followed by constitution, specification, plan, tasks, and implementation." |
| 166 | + - content: "Start with /speckit.implement and work backward to /speckit.specify." |
| 167 | + isCorrect: false |
| 168 | + explanation: "Incorrect. Implementation comes last, not first. You need specifications, plans, and tasks before you can implement." |
0 commit comments