| name | eng-team |
| description | Secure engineering team skill providing methodology guidance for building security-hardened software. Invoked when users request system design, implementation, code review, testing, CI/CD security, or incident response with security considerations. Routes to 10 specialized agents covering architecture through post-deployment. Integrates NIST SSDF governance, Microsoft SDL phases, OWASP ASVS verification, SLSA supply chain integrity, and DevSecOps automation patterns. |
| version | 1.0.0 |
| agents | ["eng-architect","eng-lead","eng-backend","eng-frontend","eng-infra","eng-devsecops","eng-qa","eng-security","eng-reviewer","eng-incident"] |
| allowed-tools | Read, Write, Edit, Glob, Grep, Bash, WebSearch, WebFetch, mcp__context7__resolve-library-id, mcp__context7__query-docs |
| activation-keywords | ["secure design","threat model","secure architecture","STRIDE","DREAD","secure implementation","code review for security","SAST","DAST","supply chain security","incident response","DevSecOps","OWASP","ASVS","CWE","CIS benchmark","SSDF","SLSA","build a secure","security requirements"] |
Eng-Team Skill
Version: 1.0.0
Framework: Jerry Eng-Team
Constitutional Compliance: Jerry Constitution v1.0
SSOT References: ADR-PROJ010-001 (Agent Team Architecture), ADR-PROJ010-002 (Skill Routing & Invocation), ADR-PROJ010-003 (LLM Portability)
Project: PROJ-010 Cyber Ops | EPIC-003 (/eng-team Skill Build) | FEAT-020 through FEAT-025
Document Sections
Document Audience (Triple-Lens)
This SKILL.md serves multiple audiences:
Purpose
The Eng-Team skill provides a structured secure software engineering framework through 10 specialized agents. Each agent produces persistent artifacts that survive context compaction, enforce security standards at every phase, and build a cumulative knowledge base of security-hardened engineering decisions.
Key Capabilities
- Secure Architecture -- System design with threat modeling (STRIDE/DREAD/PASTA) and architecture decision records
- Implementation Planning -- Standards enforcement, dependency governance, and SAMM maturity assessment
- Secure Backend Engineering -- Server-side implementation with OWASP Top 10 and ASVS verification
- Secure Frontend Engineering -- Client-side implementation with XSS prevention, CSP, and CORS hardening
- Secure Infrastructure -- IaC security, container hardening, SBOM generation, and SLSA supply chain integrity
- DevSecOps Automation -- SAST/DAST pipeline integration, secrets scanning, dependency analysis
- Security QA -- Test strategy, fuzzing, property-based testing, and coverage enforcement
- Manual Security Review -- Secure code review against CWE Top 25 and ASVS requirements
- Final Quality Gate -- Architecture compliance with /adversary integration for C2+ deliverables
- Incident Response -- Post-deployment IR runbooks, vulnerability lifecycle, and remediation tracking
When to Use This Skill
Activate when:
- Designing a new system or service that requires security hardening
- Performing threat modeling on an architecture
- Implementing backend or frontend components with security requirements
- Setting up secure CI/CD pipelines and DevSecOps automation
- Writing security-focused test cases or fuzzing campaigns
- Conducting manual secure code review
- Creating incident response plans or runbooks
- Reviewing deliverables against security standards (OWASP, NIST, CIS, SLSA)
- Planning infrastructure with container security and supply chain integrity
Available Agents
| Agent | Role | Output Location |
|---|
eng-architect | Solution Architect and Threat Modeler | projects/${JERRY_PROJECT}/engagements/{engagement-id}/eng-architect-{topic-slug}.md |
eng-lead | Engineering Lead and Standards Enforcer | projects/${JERRY_PROJECT}/engagements/{engagement-id}/eng-lead-{topic-slug}.md |
eng-backend | Secure Backend Engineer | projects/${JERRY_PROJECT}/engagements/{engagement-id}/eng-backend-{topic-slug}.md |
eng-frontend | Secure Frontend Engineer | projects/${JERRY_PROJECT}/engagements/{engagement-id}/eng-frontend-{topic-slug}.md |
eng-infra | Secure Infrastructure Engineer | projects/${JERRY_PROJECT}/engagements/{engagement-id}/eng-infra-{topic-slug}.md |
eng-devsecops | DevSecOps Pipeline Engineer | projects/${JERRY_PROJECT}/engagements/{engagement-id}/eng-devsecops-{topic-slug}.md |
eng-qa | Security QA Engineer | projects/${JERRY_PROJECT}/engagements/{engagement-id}/eng-qa-{topic-slug}.md |
eng-security | Security Code Review Specialist | projects/${JERRY_PROJECT}/engagements/{engagement-id}/eng-security-{topic-slug}.md |
eng-reviewer | Final Review Gate and Quality Enforcer | projects/${JERRY_PROJECT}/engagements/{engagement-id}/eng-reviewer-{topic-slug}.md |
eng-incident | Incident Response Specialist | projects/${JERRY_PROJECT}/engagements/{engagement-id}/eng-incident-{topic-slug}.md |
All agents produce output at three levels:
- L0 (Executive Summary): Accessible summary for non-technical stakeholders. Answers "What does this mean for the project?"
- L1 (Technical Detail): Implementation-focused content with specifics, code examples, and configuration guidance.
- L2 (Strategic Implications): Trade-offs, long-term risks, alignment with security posture, and architectural evolution.
Invoking an Agent
Option 1: Natural Language Request
Simply describe what you need:
"Design a secure microservice architecture with threat model"
"Review this API implementation for OWASP Top 10 vulnerabilities"
"Set up a DevSecOps pipeline with SAST and container scanning"
"Create an incident response runbook for credential compromise"
"Test this authentication flow with fuzzing and boundary testing"
The orchestrator selects the appropriate agent based on keywords and context.
Option 2: Explicit Agent Request
Request a specific agent:
"Use eng-architect to create a threat model for the payment service"
"Have eng-devsecops design the CI/CD security pipeline"
"I need eng-security to review the authentication module"
Option 3: Native Agent Invocation
Agents are registered via plugin.json and discovered by Claude Code automatically. The orchestrator invokes them as named subagents:
Task(
description="eng-architect: Threat model for payment service",
subagent_type="eng-architect",
prompt="""
## ENG CONTEXT (REQUIRED)
- **Engagement ID:** ENG-0042
- **Topic:** Payment Service Threat Model
## TASK
Produce a threat model for the payment service using STRIDE analysis
with DREAD risk scoring. Include architecture diagrams, trust boundaries,
data flow analysis, and prioritized threat matrix.
"""
)
Claude Code enforces the agent's tools frontmatter — eng-architect only has access to Read, Write, Edit, Glob, Grep, Bash, WebSearch, WebFetch and the Context7 MCP server.
Orchestration Flow
8-Step Sequential Phase-Gate Workflow
The /eng-team skill follows an 8-step sequential workflow with phase gates. Each step must complete before the next begins, except Step 3 where three agents execute in parallel.
Step 1: eng-architect (Design + Threat Model)
|
Step 2: eng-lead (Implementation Plan + Security Standards)
|
Step 3: eng-backend / eng-frontend / eng-infra (Parallel Implementation)
|
Step 4: eng-devsecops (Automated Security Scans)
|
Step 5: eng-qa (Testing + Fuzzing)
|
Step 6: eng-security (Manual Security Review)
|
Step 7: eng-reviewer (Final Gate + /adversary for C2+)
|
Step 8: eng-incident (IR Plan + Runbooks, Post-Deployment)
Step 1 -- eng-architect: Produces the system design, architecture decision records, and threat model (STRIDE/DREAD at minimum). All subsequent agents consume this as their security context.
Step 2 -- eng-lead: Receives the architecture and threat model. Produces the implementation plan, coding standards, dependency governance decisions, and security standards mapping.
Step 3 -- eng-backend / eng-frontend / eng-infra (parallel): Three agents execute in parallel. Each receives the implementation plan and security standards from eng-lead. Backend handles server-side, frontend handles client-side, infra handles IaC and containers.
Step 4 -- eng-devsecops: Receives implementation artifacts. Configures and runs automated security scans: SAST, DAST, secrets scanning, container scanning, dependency analysis. Produces scan results and remediation guidance.
Step 5 -- eng-qa: Receives implementation artifacts and scan results. Produces security test cases, fuzzing campaigns, property-based tests, and coverage reports.
Step 6 -- eng-security: Receives all prior artifacts. Performs manual secure code review against CWE Top 25 and OWASP ASVS. Produces findings with severity ratings and remediation guidance.
Step 7 -- eng-reviewer: Mandatory final gate. Reviews all artifacts for architecture compliance, security standards compliance, and test coverage. Invokes /adversary for C2+ deliverables per R-013 at >= 0.95 quality threshold.
Step 8 -- eng-incident: Post-deployment phase. Produces incident response plans, runbooks, monitoring configuration, and vulnerability lifecycle management. Activates independently of the build workflow.
State Passing Between Agents
Agents reference each other's output using state keys:
| Agent | Output Key | Provides |
|---|
| eng-architect | architect_output | System design, threat model, ADRs, trust boundaries |
| eng-lead | lead_output | Implementation plan, standards mapping, dependency decisions |
| eng-backend | backend_output | Server-side implementation, API security artifacts |
| eng-frontend | frontend_output | Client-side implementation, CSP/CORS configuration |
| eng-infra | infra_output | IaC templates, container configs, SBOM |
| eng-devsecops | devsecops_output | Scan results, pipeline configs, remediation list |
| eng-qa | qa_output | Test results, coverage reports, fuzzing findings |
| eng-security | security_output | Code review findings, ASVS verification results |
| eng-reviewer | reviewer_output | Final gate decision, quality scores, compliance status |
| eng-incident | incident_output | IR plans, runbooks, monitoring configuration |
Mandatory Persistence (P-002)
All agents MUST persist their output to files. This ensures:
- Context Rot Resistance -- Findings survive session compaction
- Knowledge Accumulation -- Artifacts build project security knowledge base
- Auditability -- Security decisions can be traced and reviewed
- Compliance Evidence -- Persisted artifacts serve as compliance documentation
Output Structure
projects/${JERRY_PROJECT}/engagements/
└── {engagement-id}/
├── eng-architect-{topic-slug}.md
├── eng-lead-{topic-slug}.md
├── eng-backend-{topic-slug}.md
├── eng-frontend-{topic-slug}.md
├── eng-infra-{topic-slug}.md
├── eng-devsecops-{topic-slug}.md
├── eng-qa-{topic-slug}.md
├── eng-security-{topic-slug}.md
├── eng-reviewer-{topic-slug}.md
└── eng-incident-{topic-slug}.md
Layered SDLC Governance
The /eng-team skill references a 5-layer governance model. Every agent maps to one or more layers:
| Layer | Framework | Purpose | Agents |
|---|
| 1. Governance | NIST SP 800-218 SSDF (4 practice groups, 19 practices, 43 tasks) | Organizational security practices | eng-architect, eng-lead, eng-reviewer |
| 2. Lifecycle | Microsoft SDL (5 phases: Requirements, Design, Implementation, Verification, Release) | Phase-gated secure development | All agents |
| 3. Assessment | OWASP SAMM (3 maturity levels across 15 practices) | Maturity measurement | eng-lead, eng-security |
| 4. Supply Chain | Google SLSA (4 build levels) | Build integrity and provenance | eng-infra, eng-devsecops |
| 5. Automation | DevSecOps patterns (CI/CD security gates) | Automated enforcement | eng-devsecops, eng-qa |
Every security activity includes SSDF practice references (e.g., PW.7 for code review, PS.1 for secrets management).
Adversarial Quality Mode
SSOT Reference: .context/rules/quality-enforcement.md -- all thresholds, strategy IDs, and criticality levels are defined there. NEVER hardcode values; always reference the SSOT.
The /eng-team skill integrates the adversarial quality framework defined in EPIC-002. Security-critical deliverables receive elevated scrutiny.
Criticality-Based Activation
Strategy activation follows the SSOT criticality levels (C1-C4). See .context/rules/quality-enforcement.md (Criticality Levels section) for the authoritative mapping.
| Level | Eng-Team Context | Required Strategies | Typical Scenario |
|---|
| C1 (Routine) | Minor config changes, documentation | S-010 (Self-Refine) | Updating a CSP header |
| C2 (Standard) | Feature implementation, test suites | S-007, S-002, S-014 | New API endpoint with auth |
| C3 (Significant) | Architecture decisions, IaC changes | C2 + S-004, S-012, S-013 | New service architecture |
| C4 (Critical) | Security architecture, auth systems | All 10 selected strategies | Authentication redesign |
Threat Modeling Escalation
eng-architect applies threat modeling depth based on criticality:
| Level | Threat Modeling Approach |
|---|
| C1 | STRIDE only |
| C2 | STRIDE + DREAD scoring |
| C3 | STRIDE + DREAD + Attack Trees |
| C4 | STRIDE + DREAD + Attack Trees + PASTA stages 4-7 |
| PII involvement | Add LINDDUN to any level |
eng-reviewer Quality Gate
eng-reviewer invokes /adversary for C2+ deliverables per R-013 at >= 0.95 quality threshold. Below threshold means the deliverable is rejected and returned for revision. No exceptions.
Mandatory Self-Review (H-15)
Per H-15 (HARD rule), all /eng-team agents MUST perform self-review using S-010 (Self-Refine) before presenting any deliverable.
Per H-16 (HARD rule), agents MUST apply S-003 (Steelman Technique) before critiquing -- strengthen the argument first, then challenge it.
Constitutional Compliance
All agents adhere to the Jerry Constitution v1.0:
| Principle | Requirement | Consequence of Violation |
|---|
| P-003 | NEVER spawn recursive subagents -- max 1 level | Agent hierarchy violation; uncontrolled token consumption |
| P-020 | NEVER override user intent -- ask before destructive ops | Unauthorized action; trust erosion |
| P-022 | NEVER deceive about actions, capabilities, or confidence | Governance undermined; quality assessment invalidated |
| P-001 | NEVER present findings without evidence or source citations | Unreliable outputs; unfounded claims propagate downstream |
| P-002 | NEVER leave outputs in transient context only -- persist to files | Context rot vulnerability; artifacts lost on session compaction |
| P-004 | NEVER omit reasoning provenance or source documentation | Untraceable decisions; audit trail broken |
| P-011 | NEVER make recommendations without supporting evidence | Unsupported recommendations; confidence inflated without basis |
Quick Reference
Common Workflows
| Need | Agent | Command Example |
|---|
| Threat model | eng-architect | "Create a STRIDE threat model for the auth service" |
| Implementation plan | eng-lead | "Plan the implementation for the new API gateway" |
| Secure backend code | eng-backend | "Implement the user registration endpoint with input validation" |
| Secure frontend code | eng-frontend | "Add CSP headers and XSS protection to the dashboard" |
| Infrastructure setup | eng-infra | "Design the container security configuration with SBOM" |
| CI/CD security | eng-devsecops | "Set up SAST/DAST scanning in the CI pipeline" |
| Security testing | eng-qa | "Write security test cases with fuzzing for the auth flow" |
| Code security review | eng-security | "Review the payment module for CWE Top 25 vulnerabilities" |
| Final review gate | eng-reviewer | "Final review of the release candidate against all standards" |
| Incident response | eng-incident | "Create an IR runbook for credential compromise scenarios" |
Agent Selection Hints
| Keywords | Likely Agent |
|---|
| design, architecture, threat model, STRIDE, DREAD, ADR, trust boundary | eng-architect |
| plan, standards, dependencies, code standards, lead, SAMM | eng-lead |
| backend, API, server, auth, database, input validation, OWASP Top 10 | eng-backend |
| frontend, XSS, CSP, CORS, client, browser, output encoding | eng-frontend |
| infrastructure, IaC, container, secrets, SBOM, SLSA, supply chain | eng-infra |
| pipeline, SAST, DAST, CI/CD, scanning, DevSecOps, automation | eng-devsecops |
| test, QA, fuzzing, coverage, boundary testing, property-based | eng-qa |
| code review, CWE, ASVS, manual review, vulnerability, security review | eng-security |
| final review, quality gate, compliance, release, /adversary | eng-reviewer |
| incident, runbook, response, monitoring, post-deployment, remediation | eng-incident |
Agent Details
For detailed agent specifications, see:
skills/eng-team/agents/eng-architect.mdskills/eng-team/agents/eng-lead.mdskills/eng-team/agents/eng-backend.mdskills/eng-team/agents/eng-frontend.mdskills/eng-team/agents/eng-infra.mdskills/eng-team/agents/eng-devsecops.mdskills/eng-team/agents/eng-qa.mdskills/eng-team/agents/eng-security.mdskills/eng-team/agents/eng-reviewer.mdskills/eng-team/agents/eng-incident.md
Routing Disambiguation
When this skill is the wrong choice and what happens if misrouted.
| Condition | Use Instead | Consequence of Misrouting |
|---|
| Offensive security testing or penetration testing | /red-team | Defensive security methodology (STRIDE/DREAD threat modeling, OWASP ASVS compliance) applied to offensive tasks produces security architecture artifacts instead of attack narratives; 10 security-focused agents loaded when task requires offensive methodology |
| Adversarial quality review or tournament scoring | /adversary | Eng-team agents evaluate security compliance, not deliverable quality; S-014 scoring rubric and adversarial strategy templates not loaded |
| General code review without security focus | /problem-solving (ps-reviewer) | 10 security-specific agents loaded into context when task requires routine defect detection; OWASP/NIST/CIS governance overhead applied to non-security review |
| Root cause analysis or debugging | /problem-solving (ps-investigator) | Security methodology (STRIDE, CWE analysis) applied to general investigation produces threat models instead of causal chains; root cause not isolated |
| Requirements engineering or V&V | /nasa-se | Eng-team produces security requirements and threat models, not general requirements; NASA SE traceability and V&V methodology absent |
| Architecture design without security requirements | /architecture | Eng-team loads security governance layers (NIST SSDF, MS SDL, SLSA) that add overhead when task is pure structural design; hexagonal architecture methodology is in /architecture |
| General research or landscape survey | /problem-solving (ps-researcher) | Eng-team agents are implementation-focused; no divergent research methodology for technology surveys |
References and Traceability
Architecture Decision Records
| ADR | Title | Relevance |
|---|
| ADR-PROJ010-001 | Agent Team Architecture | 10-agent roster (AD-002), 8-step workflow, capability boundaries, SDLC governance (AD-008), threat modeling methodology (AD-009), standalone design (AD-010) |
| ADR-PROJ010-002 | Skill Routing & Invocation | SKILL.md structure, keyword triggers, routing table, workflow patterns, circuit breaker integration |
| ADR-PROJ010-003 | LLM Portability | 38-field portable agent schema, body_format: markdown, RCCF prompt assembly, provider adapters |
Architecture Decisions Implemented
| AD | Title | Implementation |
|---|
| AD-001 | Methodology-First Design | All agents produce methodology guidance, not autonomous execution |
| AD-002 | 21-Agent Roster (10 eng + 11 red) | 10 /eng-team agents defined per roster specification |
| AD-008 | Five-Layer SDLC Governance | SSDF + MS SDL + SAMM + SLSA + DevSecOps in Layered SDLC Governance section |
| AD-009 | STRIDE+DREAD Default Threat Modeling | eng-architect criticality-based escalation (C1-C4) with LINDDUN for PII |
| AD-010 | Standalone Capable Design | All agents implement 3-level tool degradation (Level 0/1/2) |
Phase 1 Research Provenance
| Artifact | Title | Contribution |
|---|
| A-001 through A-004 | Role Completeness Analysis | Validated 10-agent roster against elite organizations (Google, Microsoft, CrowdStrike, Mandiant) |
| B-003 | Security Standards Analysis | OWASP, NIST, CIS, SANS standards mapped to per-agent responsibilities |
| F-001 | SDLC Framework Comparison | MS SDL phase-to-agent mapping, SSDF practice-to-agent mapping |
| S-002 | Architecture Implications Synthesis | Agent architecture specification input, handoff protocols, cross-skill integration |
Standards References
Feature Traceability
| Feature | Title | Status |
|---|
| FEAT-020 | SKILL.md & Routing | Completed |
| FEAT-021 | Architecture Agents (eng-architect, eng-lead) | Completed |
| FEAT-022 | Implementation Agents (eng-backend, eng-frontend, eng-infra) | Completed |
| FEAT-023 | Quality Agents (eng-qa, eng-security, eng-reviewer, eng-devsecops, eng-incident) | Completed |
| FEAT-024 | Templates & Playbook | Pending |
| FEAT-025 | /adversary Integration | Pending |
Skill Version: 1.0.0
Constitutional Compliance: Jerry Constitution v1.0
PROJ-010: Cyber Ops -- Secure Engineering Team
Last Updated: 2026-02-22
