aiwg
Version:
Cognitive architecture for AI-augmented software development with structured memory, ensemble validation, and closed-loop correction. FAIR-aligned artifacts, 84% cost reduction via human-in-the-loop, standards adopted by 100+ organizations.
391 lines (289 loc) • 10.1 kB
Markdown
# Few-Shot Examples Rules
**Enforcement Level**: MEDIUM
**Scope**: Agent system prompts and definitions
**Research Basis**: REF-019 Toolformer
**Issue**: #193
## Overview
These rules require 2-3 concrete examples in every agent system prompt to improve output quality through few-shot learning.
## Research Foundation
From REF-019 Toolformer (Schick et al., 2023):
- Few-shot prompting dramatically improves task performance
- 2-5 examples sufficient for most tasks
- Examples should show both input and desired output
- Diverse examples better than similar ones
## Mandatory Rules
### Rule 1: Every Agent Has Examples
**REQUIRED**:
Every agent definition MUST include 2-3 examples in its system prompt.
```markdown
# Agent: [Name]
## Role
[Agent role description]
## Examples
### Example 1: [Simple Scenario]
**Input:**
[User request]
**Output:**
```[format]
[Complete expected output]
```
### Example 2: [Moderate Scenario]
**Input:**
[More complex request]
**Output:**
```[format]
[Complete expected output]
```
### Example 3: [Complex Scenario]
**Input:**
[Edge case or integration scenario]
**Output:**
```[format]
[Complete expected output]
```
## Your Tasks
[Standard agent instructions]
```
### Rule 2: Example Diversity
**REQUIRED**:
Examples MUST cover different complexity levels:
| Level | Description | Purpose |
|-------|-------------|---------|
| Simple | Minimal complexity, happy path | Baseline understanding |
| Moderate | Realistic production scenario | Standard expectations |
| Complex | Edge cases, error handling, integrations | Robustness |
### Rule 3: Example Completeness
**REQUIRED**:
Each example MUST include:
1. **Input**: Clear description of user request/task
2. **Context**: Any relevant project state (if needed)
3. **Output**: Complete, formatted output (not truncated)
4. **Quality Annotation**: Why this is a good example (optional but encouraged)
**FORBIDDEN**:
- Truncated outputs: `[... rest of document]`
- Placeholders: `[Insert details here]`
- Trivial examples: "User: Hello" → "Hello back"
### Rule 4: Domain-Appropriate Examples
**REQUIRED**:
Examples MUST use realistic domain scenarios:
| Agent | Good Examples | Bad Examples |
|-------|---------------|--------------|
| Requirements Analyst | "Authentication for fintech app" | "Login for app" |
| Test Engineer | "Integration tests for payment processing" | "Test the button" |
| Security Auditor | "OWASP compliance for API endpoints" | "Check security" |
### Rule 5: Output Format Consistency
**REQUIRED**:
Example outputs MUST match the agent's actual deliverable format:
```markdown
### Example: Requirements Analyst
**Output:**
```markdown
# User Story: Secure Password Reset
**As a** registered user who forgot their password
**I want to** reset my password via email verification
**So that** I can regain access to my account securely
## Acceptance Criteria
- [ ] User can request password reset from login page
- [ ] System sends reset link to registered email
- [ ] Reset link expires after 1 hour
- [ ] User must create password meeting security requirements
- [ ] Old sessions are invalidated after password change
## Non-Functional Requirements
- Reset email sent within 30 seconds
- Link is single-use and cryptographically secure
- Failed attempts logged for security monitoring
```
```
## Example Templates by Agent
### Requirements Analyst
```markdown
### Example 1: User Story Creation
**Input:**
Create a user story for login functionality in our healthcare portal.
**Output:**
```markdown
# User Story: Healthcare Portal Login
**As a** healthcare provider
**I want to** log in with my NPI number and password
**So that** I can access patient records securely
## Acceptance Criteria
- [ ] Provider can enter NPI number and password
- [ ] System validates NPI against registry
- [ ] MFA required for all logins
- [ ] Session timeout after 15 minutes of inactivity
- [ ] Failed attempts trigger account lockout after 5 tries
## Non-Functional Requirements
- HIPAA-compliant audit logging
- Login must complete within 3 seconds
- Support for SSO via SAML 2.0
```
**Why This Is Good:**
- Uses domain-specific terminology (NPI, HIPAA)
- Includes security requirements appropriate for healthcare
- Acceptance criteria are testable and specific
```
### Test Engineer
```markdown
### Example 1: Unit Test Generation
**Input:**
Write unit tests for the password validation function.
**Output:**
```typescript
describe('validatePassword', () => {
describe('length requirements', () => {
it('should reject passwords shorter than 8 characters', () => {
expect(validatePassword('Short1!')).toEqual({
valid: false,
errors: ['Password must be at least 8 characters']
});
});
it('should accept passwords of exactly 8 characters', () => {
expect(validatePassword('Valid1!a')).toEqual({
valid: true,
errors: []
});
});
});
describe('complexity requirements', () => {
it('should require at least one uppercase letter', () => {
expect(validatePassword('lowercase1!')).toEqual({
valid: false,
errors: ['Password must contain at least one uppercase letter']
});
});
it('should require at least one special character', () => {
expect(validatePassword('NoSpecial1')).toEqual({
valid: false,
errors: ['Password must contain at least one special character']
});
});
});
describe('edge cases', () => {
it('should handle empty string', () => {
expect(validatePassword('')).toEqual({
valid: false,
errors: ['Password must be at least 8 characters']
});
});
it('should handle unicode characters', () => {
expect(validatePassword('Valid1!日本語')).toEqual({
valid: true,
errors: []
});
});
});
});
```
**Why This Is Good:**
- Organized by test category
- Covers happy path, validation rules, and edge cases
- Uses clear, descriptive test names
- Shows expected output structure
```
### Security Auditor
```markdown
### Example 1: Threat Model
**Input:**
Create a threat model for the user authentication API.
**Output:**
```markdown
# Threat Model: Authentication API
## Assets
| Asset | Sensitivity | Description |
|-------|-------------|-------------|
| User Credentials | Critical | Passwords, MFA tokens |
| Session Tokens | High | JWT access/refresh tokens |
| User Profile Data | Medium | Email, preferences |
## Trust Boundaries
1. Client (Browser/Mobile) → API Gateway
2. API Gateway → Auth Service
3. Auth Service → Database
## Threats (STRIDE)
### Spoofing
| Threat | Risk | Mitigation |
|--------|------|------------|
| Credential stuffing | High | Rate limiting, CAPTCHA, breached password check |
| Session hijacking | High | Secure cookies, token rotation, IP binding |
### Tampering
| Threat | Risk | Mitigation |
|--------|------|------------|
| JWT manipulation | Medium | Asymmetric signing (RS256), short expiry |
| Parameter tampering | Medium | Input validation, HMAC signatures |
### Repudiation
| Threat | Risk | Mitigation |
|--------|------|------------|
| Denied login attempts | Low | Comprehensive audit logging |
### Information Disclosure
| Threat | Risk | Mitigation |
|--------|------|------------|
| Credential leakage | Critical | TLS 1.3, no passwords in logs |
| Timing attacks | Medium | Constant-time comparison |
### Denial of Service
| Threat | Risk | Mitigation |
|--------|------|------------|
| Login flood | High | Rate limiting, account lockout |
### Elevation of Privilege
| Threat | Risk | Mitigation |
|--------|------|------------|
| Role manipulation | Critical | Server-side role verification |
## Security Controls
1. **Authentication**: Bcrypt (cost 12), MFA via TOTP
2. **Authorization**: JWT with 15-minute expiry
3. **Monitoring**: Failed login alerts, anomaly detection
```
**Why This Is Good:**
- Uses STRIDE framework systematically
- Quantifies risk levels
- Provides specific, actionable mitigations
- Covers all trust boundaries
```
## Agent Example Requirements
| Agent | Example Count | Required Scenarios |
|-------|---------------|-------------------|
| Requirements Analyst | 3 | User story, Use case, NFR analysis |
| Test Engineer | 3 | Unit test, Integration test, E2E test |
| Security Auditor | 3 | Threat model, Security review, Mitigation plan |
| API Designer | 3 | REST endpoint, Error handling, Versioning |
| Software Architect | 3 | Component design, ADR, System integration |
| Code Reviewer | 3 | Bug detection, Performance issue, Security flaw |
| Technical Writer | 3 | API docs, User guide, Changelog |
| DevOps Engineer | 3 | CI/CD pipeline, Deployment config, Monitoring |
## Implementation Priority
**Phase 1: Core Agents**
1. Orchestrator
2. Requirements Analyst
3. Test Engineer
4. API Designer
**Phase 2: Specialized Agents**
5. Security Auditor
6. Software Architect
7. Code Reviewer
8. Technical Writer
**Phase 3: Remaining Agents**
9-20. All other agents
## Validation Checklist
Before finalizing an agent definition:
- [ ] 2-3 examples included
- [ ] Examples cover simple/moderate/complex scenarios
- [ ] All outputs are complete (no truncation)
- [ ] Examples use realistic domain scenarios
- [ ] Output format matches agent deliverables
- [ ] Quality annotations explain what makes examples good
- [ ] No placeholders or TODOs in examples
## Example Quality Review
When reviewing agent examples:
| Criterion | Check |
|-----------|-------|
| Completeness | Is output fully rendered? |
| Realism | Would this occur in production? |
| Format | Does it match agent's actual output? |
| Diversity | Are scenarios sufficiently different? |
| Quality | Would you accept this output? |
## References
- @.aiwg/research/findings/REF-019-toolformer.md - Research foundation
- @agentic/code/frameworks/sdlc-complete/agents/ - Agent definitions
- @agentic/code/frameworks/sdlc-complete/docs/agent-examples.md - Example catalog
- #193 - Implementation issue
**Rule Status**: ACTIVE
**Last Updated**: 2026-01-25