extract-constraints

foolishimp's avatarfrom foolishimp

Extract technical constraints (C-*) from ecosystem E(t) - timeouts, API limits, compliance requirements, platform dependencies. Acknowledges given constraints, not design choices. Use to document ecosystem realities that code must work within.

⭐0stars🔀0forks📁View on GitHub🕐Updated Dec 16, 2025

When & Why to Use This Skill

The extract-constraints skill is a specialized tool for software engineering that automates the identification and documentation of technical constraints (C-*) within a project's ecosystem. It systematically distinguishes between non-negotiable external realities—such as API rate limits, timeouts, and compliance standards—and flexible design choices. By acknowledging the fixed boundaries of the environment (E(t)), this skill ensures that architectural decisions are grounded in reality, reducing integration risks and ensuring regulatory compliance from the start of the development lifecycle.

Use Cases

  • API & Service Integration: Analyzing third-party documentation (e.g., Stripe, AWS) to extract specific timeouts and rate limits that the code must handle via backoff or circuit-breaking patterns.
  • Compliance & Security Mapping: Identifying mandatory regulatory constraints like GDPR data portability requirements or PCI-DSS storage prohibitions to ensure the system architecture is legally compliant.
  • Platform & Runtime Validation: Documenting fixed environment constraints such as specific Python versions, library dependencies, or cloud provider resource limits (e.g., RDS connection pools).
  • Requirements Disambiguation: Clarifying the 'given' constraints of a project to provide a solid foundation for Architecture Decision Records (ADRs), preventing the confusion of external limits with internal design preferences.
nameextract-constraints
descriptionExtract technical constraints (C-*) from ecosystem E(t) - timeouts, API limits, compliance requirements, platform dependencies. Acknowledges given constraints, not design choices. Use to document ecosystem realities that code must work within.
allowed-tools[Read, Write, Edit]

extract-constraints

Skill Type: Actuator (Requirements Disambiguation) Purpose: Extract C-* constraints acknowledging ecosystem E(t) Prerequisites: REQ-* requirement exists


Agent Instructions

You are extracting constraints (C-*) from the ecosystem E(t).

Constraints are GIVEN (external reality), not CHOSEN (design decisions).

Examples:

  • ✅ C-001: Stripe API timeout is 10 seconds (given by Stripe)
  • ❌ C-002: We will use PostgreSQL (this is a design choice → ADR)

Goal: Acknowledge ecosystem constraints that code must work within.


C-* Categories

1. API/Service Constraints

Timeouts:

C-001: Stripe API timeout
  - Value: 10 seconds (given by Stripe documentation)
  - Source: https://stripe.com/docs/api#timeouts
  - Fallback: Return error to user
  - Monitoring: Alert if approaching timeout (>8s)

Rate limits:

C-010: Stripe API rate limit
  - Limit: 100 requests per second
  - Source: Stripe API documentation
  - Behavior: Implement exponential backoff
  - Error: "Payment service temporarily unavailable"

2. Compliance Constraints

PCI-DSS:

C-020: PCI-DSS Level 1 compliance
  - Requirement: Never store full credit card numbers
  - Implementation: Tokenize via Stripe
  - Validation: No card numbers in logs or database
  - Audit: Regular PCI scans required

GDPR:

C-030: GDPR data portability
  - Requirement: Users can export their data
  - Format: JSON or CSV
  - Timeline: Within 30 days of request
  - Scope: All personal data

3. Platform Constraints

Language/runtime:

C-040: Python version
  - Minimum: Python 3.8
  - Reason: Using dataclasses, type hints
  - Source: Project decision (E(t) = team knows Python)
  - Validation: Check at startup

Dependencies:

C-050: bcrypt library
  - Library: bcrypt
  - Version: >=4.0.0
  - Reason: Password hashing (security requirement)
  - Source: Security team standard

4. Performance Constraints

Response time SLAs:

C-060: Login response time
  - Max time: 500ms (p95)
  - Measurement: End-to-end from request to response
  - Monitoring: Datadog APM
  - Alerting: >400ms warning, >500ms critical

Resource limits:

C-070: Database connection pool
  - Max connections: 20
  - Source: RDS instance limit
  - Behavior: Queue requests if pool exhausted
  - Timeout: 5 seconds wait for connection

5. Security Constraints

Authentication:

C-080: HTTPS requirement
  - Protocol: All auth requests must be HTTPS
  - Source: Security policy
  - Enforcement: Reject HTTP requests
  - Exception: None (no HTTP fallback)

Session management:

C-090: Session timeout
  - Duration: 30 minutes of inactivity
  - Source: Security team policy
  - Token: JWT with exp claim
  - Storage: Redis with TTL

Constraint vs Design Decision

Constraint (C-*) - GIVEN by ecosystem:

✅ C-001: Stripe API timeout is 10 seconds
   Source: Stripe documentation (external reality)
   We MUST work within this constraint

✅ C-002: PCI-DSS prohibits storing card numbers
   Source: Payment Card Industry regulation
   We MUST comply

✅ C-003: Team knows Python, not Java
   Source: Team capabilities (E(t))
   We work within this reality

Design Decision - CHOSEN by us:

❌ "We will use PostgreSQL" → This is ADR, not C-*
❌ "We will implement REST API" → This is ADR, not C-*
❌ "We will use MVC pattern" → This is ADR, not C-*

Rule: If it's a choice between alternatives → ADR (Design stage) If it's a given reality we must work within → C-* (Constraint)


Extraction Process

Step 1: Identify Ecosystem Sources

Ask:

  1. What external APIs/services are we using? (Stripe, Auth0, AWS)
  2. What compliance requirements apply? (PCI-DSS, GDPR, HIPAA)
  3. What platform constraints exist? (language version, libraries)
  4. What performance SLAs? (response time, uptime)
  5. What security policies? (HTTPS, encryption, session timeout)
  6. What team constraints? (skills, preferences, existing systems)

Step 2: Document Each Constraint

Template:

C-{ID}: {Constraint Name}
  - Value/Requirement: {What is constrained}
  - Source: {Where this constraint comes from - API docs, regulation, policy}
  - Ecosystem E(t): {What ecosystem component imposes this}
  - Implementation: {How code must handle this}
  - Validation: {How to verify compliance}
  - Autogenerate: {Yes/No}

Output Format

[EXTRACT CONSTRAINTS - <REQ-ID>]

Requirement: User login

Constraints Extracted:

API/Service Constraints (2):
  ✓ C-001: Database query timeout (100ms, RDS limit)
  ✓ C-002: Session storage (Redis, existing infrastructure)

Compliance Constraints (2):
  ✓ C-003: HTTPS required (security policy)
  ✓ C-004: Password hashing (bcrypt, security standard)

Performance Constraints (1):
  ✓ C-005: Login response time (<500ms, SLA requirement)

Total: 5 constraints

Ecosystem E(t) Acknowledged:
  - External: RDS connection limits, Redis infrastructure
  - Compliance: Security policies (HTTPS, bcrypt)
  - Performance: SLA requirements

Updated: docs/requirements/authentication.md
  Added: Constraints section with 5 C-*

✅ Constraint Extraction Complete!

Notes

Why extract constraints?

  • Acknowledge ecosystem E(t): Document external realities
  • Design context: Constraints inform ADRs (architecture decisions)
  • Code generation: Some constraints can be autogenerated (timeout checks)
  • Compliance: Document regulatory requirements

Homeostasis Goal:

desired_state:
  all_ecosystem_constraints_documented: true
  constraints_vs_choices_clear: true

"Excellence or nothing" 🔥