eng-team

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

Section	Purpose
Document Audience	Triple-Lens audience guide
Purpose	Skill overview and key capabilities
When to Use This Skill	Activation triggers
Available Agents	10-agent roster with roles and output locations
Invoking an Agent	Three invocation methods with examples
Orchestration Flow	8-step sequential phase-gate workflow
State Passing Between Agents	Output keys and handoff data
Mandatory Persistence	P-002 file persistence requirements
Layered SDLC Governance	5-layer governance model (AD-008)
Adversarial Quality Mode	/adversary integration and criticality escalation
Constitutional Compliance	Governing principles
Quick Reference	Common workflows and agent selection hints
Agent Details	Agent file paths
Routing Disambiguation	When this skill is the wrong choice
References and Traceability	ADR baseline, architecture decisions, research provenance

Document Audience (Triple-Lens)

This SKILL.md serves multiple audiences:

Level	Audience	Sections to Focus On
L0 (ELI5)	New users, stakeholders	Purpose, When to Use This Skill, Quick Reference
L1 (Engineer)	Developers invoking agents	Invoking an Agent, Agent Details, Adversarial Quality Mode
L2 (Architect)	Workflow designers	Orchestration Flow, State Passing Between Agents, Layered SDLC Governance

---

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:

1. Context Rot Resistance -- Findings survive session compaction
2. Knowledge Accumulation -- Artifacts build project security knowledge base
3. Auditability -- Security decisions can be traced and reviewed
4. 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.md
• skills/eng-team/agents/eng-lead.md
• skills/eng-team/agents/eng-backend.md
• skills/eng-team/agents/eng-frontend.md
• skills/eng-team/agents/eng-infra.md
• skills/eng-team/agents/eng-devsecops.md
• skills/eng-team/agents/eng-qa.md
• skills/eng-team/agents/eng-security.md
• skills/eng-team/agents/eng-reviewer.md
• skills/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

Standard	Version	URL
NIST SP 800-218 SSDF	v1.1 (2022)	https://csrc.nist.gov/publications/detail/sp/800-218/final
Microsoft SDL	2024	https://www.microsoft.com/en-us/securityengineering/sdl
OWASP ASVS	v5.0 (2025)	https://owasp.org/www-project-application-security-verification-standard/
OWASP Top 10	2021	https://owasp.org/www-project-top-ten/
CWE Top 25	2025	https://cwe.mitre.org/top25/archive/2025/2025_cwe_top25.html
Google SLSA	v1.0 (2023)	https://slsa.dev/spec/v1.0/
OWASP SAMM	v2.0	https://owaspsamm.org/
CIS Benchmarks	Various	https://www.cisecurity.org/cis-benchmarks
NIST CSF	v2.0 (2024)	https://www.nist.gov/cyberframework
NIST SP 800-61	r3 (2024)	https://csrc.nist.gov/publications/detail/sp/800-61/rev-3/final

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