Reference

• 1: Glossary of Terms
• 2: Overview of LLM Coding Tools and Platforms
• 3: Types of Specifications
• 4: Common Prompt Patterns
• 5: Validation Checklists

1 - Glossary of Terms

Key Points:

• Definitions for: LLM, Prompt Engineering, Specification (and brief definition of each type covered), Hallucination, Fine-tuning, Token, Context Window, Temperature (LLM parameter), Few-shot/Zero-shot prompting.
• Definition of llm.txt and llmd.txt: (Proposing standard usage)
  • llm.txt: A project-level file (in the root directory) containing guidelines, constraints, and context for LLMs assisting with the project (e.g., preferred libraries, architectural patterns to follow/avoid, general coding standards).
  • llmd.txt: Directory-specific files containing context, examples, or specific instructions relevant only to the code within that directory (e.g., details about a specific module, examples of patterns used in that area).

2 - Overview of LLM Coding Tools and Platforms

Key Points:

• IDE Extensions (Copilot)
  • GitHub Copilot: Focus (inline completion, chat), Integration (IDE extension), Model (OpenAI/Microsoft), Pros/Cons.
• AI-Native IDEs
  • Cursor: Focus (AI-native editor, chat, code analysis), Integration (Standalone IDE), Model (various, including GPT-4), Pros/Cons.
  • Windsurf: Focus (specific features), Integration, Model, Pros/Cons (based on available information).
• Local Deployment
  • Ollama: Focus (running local models), Integration (API, CLI, IDE extensions), Model (various open-source models), Pros/Cons (privacy vs. setup/resource needs).
• Comparison summary (e.g., table format) highlighting key differences (cloud vs. local, IDE integration vs. native, features).

Assets:

• 📄 LLM Platform Feature Table

3 - Types of Specifications

Key Points:

• Business Requirements Specification (BRS): High-level goals, “Why”. Useful for context.
• Software Requirements Specification (SRS): Functional and non-functional requirements. Detailed “What”. Core input.
• Functional Specification Document (FSD): Detailed behavior, user interaction flows. “How it works”. Core input.
• Technical Specification (TS): Implementation details, data structures, algorithms. “How it’s built”. Useful for guiding LLM implementation choices.
• System Design Specification (SDS): Architecture, component interaction. High-level “How”. Useful for ensuring LLM output fits the design.
• Interface/API Specifications: Endpoints, data models, request/response formats. Precise input for API code.
• Product Requirements Documents (PRDs): Market context, user stories, features. Focus on user value. Useful for context and user stories.
• User Stories and Acceptance Criteria: User perspective, testable conditions. Excellent input for generating features and tests.
• Test Specifications: Detailed test cases, setup, expected results. Input for test automation or verifying generated tests.
• Differences
  • Business vs. Technical vs. Functional Specs
  • User Stories vs. Acceptance Criteria
• What makes a spec “LLM-friendly”?
  • Language modeling ≠ semantic understanding
  • Bias toward plausible completion
  • Clarity, atomicity, consistency
  • Examples of good vs. bad specs

Assets:

• 📄 Example spec snippets
• 📄 Table of Spec Characteristics

4 - Common Prompt Patterns

Key Points:

• Single Component Prompts
• Multi-Step Feature Prompts
• Refactoring Prompts

Assets:

• 📄 Prompt Pattern Library (Markdown)

5 - Validation Checklists

Validation Checklists

Description: Ready-to-use checklists for spec-to-code QA.

Key Points:

• Functionality validation
• Security/Safety checks
• Style and readability reviews

Assets:

• 📄 Downloadable Markdown QA Lists