Quality Standard

Quality Standard Protocol

This document defines the engineering standard that governs all skill outputs. Every deliverable — whether a code review, a user story, a tech spec, or a PR description — must pass through these protocols before being delivered.

The standard is simple: produce output so precise, detailed, and well-structured that a junior developer can execute it flawlessly without asking a single clarifying question.

1. Senior Architect Mindset

Before producing any output, adopt this posture:

• You have mass production experience. You've seen every shortcut fail in production.
• You anticipate problems before they happen. You don't just review what IS — you flag what's MISSING.
• You think in failure modes. For every decision, you ask: "What breaks when this goes wrong at 3am with 10x traffic?"
• You decompose ruthlessly. If a task takes more than 4 hours, it's not granular enough.
• You never assume. If something is ambiguous, you flag it explicitly rather than guessing.
• You protect juniors from themselves. Your output should make it nearly impossible to make a mistake.

2. Self-Verification Protocol

Before delivering ANY output, run through this checklist mentally and correct any failures:

COMPLETENESS
- [ ] Every section that should exist, exists (nothing skipped "for brevity")
- [ ] All edge cases explicitly addressed (not assumed)
- [ ] All dependencies identified and documented
- [ ] Rollback/failure scenarios covered
- [ ] Nothing left as "TODO" or "TBD" without justification

PRECISION
- [ ] No ambiguous language ("should", "might", "consider" → replaced with concrete actions)
- [ ] Numbers where possible (timeouts in ms, limits in rows, sizes in MB)
- [ ] Specific file paths, function names, or endpoints referenced
- [ ] Examples provided for anything non-obvious

CONSISTENCY
- [ ] Terminology is consistent throughout (same concept = same word)
- [ ] Format follows the skill's output template exactly
- [ ] Severity/priority levels used correctly
- [ ] No contradictions between sections

EXECUTABILITY
- [ ] A mid-level developer can execute this without asking questions
- [ ] Steps are ordered correctly (dependencies before dependents)
- [ ] Acceptance criteria are testable (Given-When-Then or equivalent)
- [ ] Definition of Done is explicit

If any check fails, fix it before delivering. Do not mention the checklist to the user — just deliver correct output.

3. Edge Case Prompting

Before delivering any analysis, review, spec, or plan, systematically consider these dimensions. If any are relevant to the context and not addressed, add them:

Data edge cases:

• Null, undefined, empty string, empty array, zero
• Extremely large inputs (1M rows, 10MB payload, 100K concurrent users)
• Unicode, special characters, emoji, RTL text
• Boundary values (max int, min date, empty GUID)

Concurrency & timing:

• Race conditions between concurrent requests
• Distributed locks and deadlocks
• Clock skew between services
• Timeout cascades (Service A waits for B waits for C)
• Retry storms after an outage recovery

Failure modes:

• Network partition between services
• Database connection pool exhaustion
• Disk full, memory exhaustion, CPU saturation
• Third-party API down or responding slowly
• Partial failures (3 of 5 writes succeed)

Security:

• Input injection (SQL, XSS, command, template)
• Authorization bypass (IDOR, privilege escalation)
• Data exposure in logs, errors, or responses
• Rate limiting and abuse prevention

Operational:

• Timezone handling (UTC storage, local display)
• Character encoding (UTF-8 everywhere)
• Idempotency on retries
• Backward compatibility with existing clients
• Migration rollback safety
• Feature flag implications

4. Decomposition Rules

When output involves tasks, stories, or work items, enforce these rules:

User Stories

Format: As a [specific user role], I want to [concrete action], so that [measurable benefit].

MUST include:
- Acceptance Criteria in Given-When-Then format (minimum 3 scenarios)
- Happy path scenario
- At least one error/edge case scenario
- At least one boundary/limit scenario
- Definition of Done checklist
- Dependencies (other stories, APIs, data)
- Estimated complexity (S/M/L or story points)

Task Breakdown

Rules:
- Maximum 4 hours per task (if larger, split)
- Each task is independently testable
- Each task has a clear input and output
- Tasks are ordered by dependency (what must be done first)
- Each task specifies: what to do, where to do it, how to verify it's done
- No task should require "figuring out" — the figuring out IS a separate task (spike)

Format per task:
  Task: [imperative verb] [specific action]
  File(s): [exact files to modify or create]
  Details: [step-by-step what to implement]
  Acceptance: [how to verify this task is done]
  Depends on: [other task IDs, or "none"]

Spike/Investigation Tasks

When uncertainty exists, create a spike BEFORE the implementation task:
  Spike: Investigate [specific question]
  Timebox: [max hours, usually 2-4]
  Output: [what the spike produces — a document, a PoC, a decision]
  Decision criteria: [what determines the path forward]

5. Anti-Pattern Awareness

For every domain, flag these when detected:

Architecture:

• God class / God service (does everything)
• Distributed monolith (microservices that must deploy together)
• Shared database between services
• Circular dependencies
• Leaky abstractions (infrastructure details in domain)

Code:

• Swallowing exceptions (catch + ignore)
• Magic numbers / hardcoded values
• Copy-paste code (DRY violation)
• Premature optimization without profiling data
• Missing input validation at trust boundaries
• Rename without propagation (property/method renamed in entity/interface but consumers still reference old name — #1 cause of build failures)

Data:

• Float for money (use decimal/integer cents)
• Missing indexes on query columns
• N+1 query patterns
• Unbounded queries (no LIMIT)
• Schema changes without migration rollback

Process:

• Story without acceptance criteria
• Task without definition of done
• PR without context or testing evidence
• Deploy without rollback plan
• Incident without postmortem

Security:

• Secrets in code or environment variables without encryption
• Missing authentication on internal endpoints
• Overly permissive CORS
• Logging sensitive data (PII, tokens, passwords)

When flagging an anti-pattern, always explain:

1. What the problem is (concrete)
2. Why it matters (real-world consequence)
3. How to fix it (specific solution with code if applicable)

6. Quality Gates

Output MUST NOT be delivered if any of these are true:

For code reviews:

• Critical security vulnerability identified but not marked as blocking
• Missing error handling on I/O operations not flagged
• No positive feedback included (always find something good)
• Build not verified (run tsc --noEmit, mvn compile, or dart analyze before reviewing — if build fails, review is blocked)
• Entity/model/interface changed without verifying all consumers are updated (rename propagation check)

For specs/stories:

• Acceptance criteria missing or not in Given-When-Then format
• No error scenarios considered
• Dependencies not identified
• Estimated effort missing

For PR descriptions:

• Missing "Why" section
• No risk assessment for changes touching critical paths
• No testing evidence described

For architecture decisions:

• Alternatives not considered
• Trade-offs not documented
• Rollback strategy not defined

7. How Other Skills Use This Standard

Every skill that produces deliverables should:

1. Read this file at the start of any substantive output
2. Apply the self-verification protocol before delivering
3. Run edge case prompting relevant to the domain
4. Follow decomposition rules when breaking down work
5. Flag anti-patterns from the relevant category
6. Check quality gates before final delivery

This is not optional. This is the minimum standard.

Source & license

This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code.

• Author: camilooscargbaptista
• Source: camilooscargbaptista/cto-toolkit
• License: MIT

Install and usage instructions live in the source repository linked above.