agents

Software Release Pipeline Agents

This directory contains AI agents that represent different roles in a structured software development lifecycle (SDLC) and release pipeline.

Purpose

Each agent is designed to handle a specific phase of the software development and release process, ensuring comprehensive coverage from initial development through production deployment. These agents work together to maintain high code quality, security standards, and production readiness.

Project Focus: The core focus of this project is software development. The agents below are organized into the primary SDLC pipeline agents and supplementary domain-specific agents that serve specialized side use cases.

Choosing how much process you want

Two switches decide how many agents touch a change. Both default to the cheapest setting, so doing nothing keeps the work with one agent.

You want	Type this	What happens
One agent only (default)	nothing	The agent implements, validates, self-reviews, and closes out. No handoff, no second context.
One agent, plus a security review	review: on	The agent finishes, then offers the review handoff once.
The agent to judge whether a review is needed	review: auto	Restores risk-scaled dispatch: security boundaries, destructive operations, migrations, concurrency, public APIs, cross-module contracts, or a large unfamiliar diff.
The full four-agent cycle	cycle: full	Architect → engineer → reviewer → writer, progressing on its own.
To stop a cycle that is running	cycle: off	Ends it at the current stage. That stage becomes the closer and reports where the chain ended.

With everything off, a single agent still validates its own work, self-reviews the diff, and names any risk it sees — it just recommends the review instead of running one. Nothing is skipped; only the second opinion is.

Specification completion workflow

/complete-specifications is an explicit high-agency workflow for a repository whose requirements and implementation have drifted apart. It is a Prompt-led Custom agent package rather than a Skill: the controller, implementer, and reviewer need different enforced tool and delegation surfaces, and running the workflow must always be a deliberate choice.

Custom agent	Responsibility	Boundary
spec-completion-controller	Build the closure matrix, dependency graph, ledger, integration branch, validation evidence, and final percentages	May delegate only to the two workers below; no web, browser, session, or issue-tracker tools under either tool naming
spec-work-implementer	Implement one immutable work item test-first in one isolated worktree	Cannot delegate or perform shared live actions
spec-completion-reviewer	Review one work item, its security boundary, or the completion accounting	Read-only; cannot delegate or edit

The controller gives every atomic work item its own implementer and every result an independent review. It distinguishes implemented, locally tested, and live- verified behavior; every non-duplicate engineering row stays in the primary denominator. Live validation defaults to off and requires a direct containment- profile digest when enabled. A separate runner with a hash-pinned profile owns read-only or disposable endpoint access; the controller and workers keep empty egress. Review and accounting records go through a pinned append-only appender with a verified hash chain, outside every repository process's writable roots. Shared or production changes are written as supervised procedures and never counted as live proof.

Tool names in agent-host sessions

A VS Code agent-host (Copilot SDK) session passes an agent's tools: list unchanged to the Copilot runtime, which treats it as a strict allow-list and silently drops every VS Code name it does not resolve (github/copilot-cli#4594). Without a runtime name, a selected agent loses web access, search, questions, the browser, and the session tools that a chat with no agent selected still has. Every profile therefore keeps its VS Code names and declares the runtime name next to each one:

VS Code name	Runtime name added next to it
web/fetch	web_fetch
search, search/codebase, search/fileSearch, search/listDirectory, search/textSearch	grep, glob
vscode/askQuestions	ask_user
browser	vscodeBrowser/openBrowserPage, vscodeBrowser/readPage, vscodeBrowser/screenshotPage, vscodeBrowser/navigatePage, vscodeBrowser/clickElement, vscodeBrowser/typeInPage, vscodeBrowser/hoverElement, vscodeBrowser/dragElement, vscodeBrowser/handleDialog, vscodeBrowser/runPlaywrightCode

The browser tool set is deprecated in VS Code 1.139.1. For a bare browser tool name the agent-file checker suggests the browser/… and vscodeBrowser/… forms, so the tools are named through vscodeBrowser, the one that is not deprecated; the runtime matches a client tool by its name after the slash. The VS Code names the runtime already resolves — read/readFile, the edit/* tools, execute/runInTerminal, agent, and client tools the agent host registers under the name after the slash, such as search/usages — need no second name.

Every agent that is not contained also gets a common baseline: web (web/fetch, web_fetch), search (search, grep, glob), questions (vscode/askQuestions, ask_user), and the agent-host session tools set_workspace, list_sessions, get_current_session, get_session_context, add_artifact_or_reference, list_artifacts_and_references, and remove_artifact_or_reference. No agent declares create_session, send_message, rename_chat, or delete_session. web_search is not declared because a session with no agent selected does not offer it here.

The contained agents are software-engineer-contoso and the three specification-completion agents. They get a runtime name only for a VS Code name they already declare, and never web_fetch, web_search, a browser tool, or a session tool.

Two agent-host limits sit outside these lists, so containment there is per agent, not per host. The agent host forwards an agent's name, description, model, tools, skills, and prompt to the runtime, but not its agents: allow-list: an agent that holds agent, such as software-engineer-contoso or spec-completion-controller, can dispatch any Custom or built-in agent, including ones with live web tools. And list_sessions with get_session_context reads the transcript of any existing session, so an open agent can read a contained agent's session.

VS Code shows a faded Unknown tool '…' will be ignored hint for each runtime name. That hint is the accepted cost; do not add a target: field to hide it. tests/AgentRuntimeToolNames.Tests.ps1 enforces the pairing, the baseline, and the containment, and decision 0026 records when the extra names can be removed.

Core SDLC Pipeline Agents

These agents form the primary software development and release pipeline.

The full development cycle

The four agents below chain into one opt-in workflow. Ask for cycle: full — or "the full development cycle" — and the stages run in order:

software-architect  →  software-engineer  →  security-reviewer  →  technical-writer
   Design Concept        implement + test       pass / fail gate       document + close out
                                 ↑                     │
                                 └── fail: you click to send it back ──┘

The cycle is off by default; a single agent finishes its own work and stops. When it is requested, only the final stage writes the changelog entry and the commit — the earlier stages verify, refresh activeContext.md, and hand over. Every forward handoff auto-submits, so progressing does not ask for a second confirmation. The one handoff that does not is the reviewer's fail path back to the engineer: two auto-submitting handoffs pointing at each other is an unbounded loop, and no prose cap can stop it, because each handoff starts the receiving agent with fresh context and neither side can count rounds. Re-entering implementation therefore costs one deliberate click — the human is the bound.

Ask for it with cycle: full or any of: "full development cycle", "full workflow", "development cycle", "full SDLC", "full pipeline", "the whole pipeline", "the full agent chain", "all four agents", "design to documentation", "concept to docs", "run the complete workflow".

It will not start on "end-to-end" (that means end-to-end tests), "do it properly", "the whole thing", or "ship it" — four agents is too expensive to spend on a guess, so those get a question instead.

Worth knowing: progression is surfaced as a handoff button, not an unattended agent switch. send: true means selecting it submits immediately rather than waiting for a second confirmation; send: false fills the box and waits for you. VS Code hands you to another agent; an agent cannot hand itself. Ask for a cycle at the engineer rather than the architect and it hands back upstream, because there is no signed-off Design Concept to implement if you start in the middle.

1. Software Architect Agent

Role: Requirements and Design
Phase: Before Code Exists
File: software-architect.agent.md

Responsibilities:

• Adversarial requirements elicitation before any artifact is produced
• Quantification of unmeasurable quality words into Scale, Meter, and targets
• Design option comparison with an explicit recommendation and runner-up
• Design Concept authoring with Acceptance criteria and Non-goals
• Decision record authoring once the user signs a durable choice off

Key Features:

• Interview depth scaled to blast radius, from a full twelve-category interrogation down to no interview at all
• Deliverable is a document; source, tests, configuration, and pseudocode are out of bounds
• Toolset omits the implementation accelerators (test runner, task runner, notebook execution, code interpreter) so the productive exit is a handoff
• Explicit sign-off gate before any implementation begins
• Handoffs to the Software Engineer Agent and the Security & QA Agent
• Applies the grill-me and gilb-requirements-engineering skills

When to Use:

• Starting a new system, service, or public contract
• An epic or requirement that still contains unquantified quality words
• Choosing between competing designs before anyone writes code
• An irreversible data, schema, or dependency decision
• A requirement gap the Software Engineer Agent cannot resolve locally

---

2. Software Engineer Agent

Role: Development and Implementation
Phase: Code Development
File: software-engineer.agent.md

Responsibilities:

• Production-ready, maintainable code development
• Focused exploration and incremental implementation
• SOLID principles and design patterns
• Behavior-driven tests and regression guards
• Executable validation scaled to change risk
• Interactive browser validation for user-facing web changes

Key Features:

• Compact execution contract with no duplicated lifecycle rules
• Immediate focused validation after each substantive edit
• Closed browser feedback loop: reproduce, inspect, fix, and repeat
• Engineering excellence standards (SOLID, Clean Code, DRY, YAGNI, KISS)
• Risk-scaled testing strategy (Unit → Integration → E2E)
• Self-review on every change; independent review is opt-in (review: on) and never auto-dispatched
• Agentic-security review for agents, LLM features, RAG, and MCP servers

When to Use:

• Building new features or projects
• Refactoring existing code
• Implementing bug fixes
• Creating technical documentation
• Setting up test suites

---

3. Security & Quality Assurance Agent

Role: Security Validation and Production Readiness
Phase: Pre-Production Validation
File: security-reviewer.agent.md

Responsibilities:

• Comprehensive security audits and threat assessments
• Code quality validation
• Compliance verification
• Production readiness decisions
• Vulnerability remediation guidance
• Continuous threat intelligence integration

Key Features:

• Multi-layer security assessment framework:
  • Layer 1: Static Application Security Testing (SAST)
  • Layer 2: Dependency & Supply Chain Security
  • Layer 3: Secrets & Credentials Management
  • Layer 4: Configuration & Infrastructure Security
  • Layer 5: Threat Intelligence & Attack Pattern Detection
• CVSS-based risk assessment (0.0-10.0)
• Production readiness decisions (PASS/FAIL/CONDITIONAL)
• Integration with existing security rules (PS001-PS060 for PowerShell)
• 2025 threat landscape awareness (AI/ML, supply chain, zero-trust)
• Comprehensive reporting with executive summaries

When to Use:

• Before production deployments
• After major feature implementations
• Security audits and compliance reviews
• Dependency updates validation
• Post-incident security reviews
• Regulatory compliance validation

---

4. Technical Writer & Documentation Agent

Role: Content Creation and Documentation
Phase: Documentation and Knowledge Transfer
File: technical-writer.agent.md

Responsibilities:

• Comprehensive article and documentation writing
• Autonomous repository and project research
• Web research using fetch tool for external sources
• Technical accuracy verification through code inspection
• Professional content structuring for target audiences
• Meticulous source citation and attribution
• Publication-ready content delivery

Key Features:

• Zero-confirmation autonomous workflow
• Six-phase writing process:
  • Phase 0: Scope Understanding & Planning
  • Phase 1: Repository & Project Analysis
  • Phase 2: External Research & Verification
  • Phase 3: Outline & Structure Design
  • Phase 4: Content Creation
  • Phase 5: Editing & Quality Assurance
  • Phase 6: Publication & Documentation
• Multiple article templates (technical blog, API docs, newspaper, tutorials)
• Journalistic integrity with CRAAP source evaluation
• Comprehensive research documentation
• Memory Bank integration for knowledge retention

When to Use:

• Writing technical articles about projects
• Creating comprehensive project documentation
• Producing newspaper articles for non-technical audiences
• Developing API documentation
• Creating tutorials and how-to guides
• Writing comparative analysis pieces
• Producing white papers and technical reports

---

5. Technical Troubleshooter Agent

Role: Problem Diagnosis and Resolution
Phase: Incident Response and Investigation
File: troubleshooter.agent.md

Responsibilities:

• Systematic diagnosis of infrastructure, application, and security problems
• Root cause analysis using the hypothetico-deductive method
• Evidence-based hypothesis testing and elimination
• Postmortem documentation and prevention recommendations
• Knowledge capture for recurring problem patterns

Key Features:

• Six-phase troubleshooting workflow (Google SRE-inspired):
  • Phase 1: Problem Report — Capture and Clarify
  • Phase 2: Triage — Assess Severity and Stabilize
  • Phase 3: Examine — Gather Data (read-only)
  • Phase 4: Diagnose — Form and Narrow Hypotheses
  • Phase 5: Test and Treat — Validate Hypotheses
  • Phase 6: Cure and Document — Fix and Prevent
• Diagnostic toolbox: Windows/AD commands, event log analysis, Kerberos troubleshooting
• Common error code reference (Kerberos, network, authentication)
• Curated web resource list for research (MS Learn, SRE Book, MSRC, Update Catalog)
• Structured hypothesis tracking and postmortem templates
• Triage-first approach: stabilize before root-causing
• Divide-and-conquer, "what changed?", and bisection techniques
• Handoff to Software Engineer Agent for implementation of fixes

When to Use:

• Investigating system outages or degraded performance
• Diagnosing authentication failures (Kerberos, NTLM, certificate-based)
• Troubleshooting Active Directory replication, GPO, or DNS issues
• Analyzing event logs for error patterns
• Root-cause analysis of build, test, or deployment failures
• Post-incident investigation and postmortem writing
• Debugging Windows Update or patching issues

---

---

Domain-Specific Agents (Supplementary)

These agents are not part of the core software development pipeline. They serve specialized domain-specific use cases and are maintained as supplementary side content.

6. Legal Researcher Agent (DE)

Role: German Legal Research and Document Drafting
Scope: Supplementary — not part of the SDLC pipeline
File: legal-researcher.agent.md

Responsibilities:

• German law research and legal analysis (Rechtsrecherche)
• Formal legal document drafting in German (Schriftsätze)
• Case management with persistent memory bank
• Deadline tracking and escalation (Fristenkalender)
• Tenant and landlord dispute resolution
• Betriebskosten (operating cost) analysis

Key Features:

• Specialized in German tenancy law (Mietrecht), operating costs (Betriebskosten), and real estate law (Immobilienrecht)
• Five-phase legal reasoning workflow (ERFASSEN → PRÜFEN → SUBSUMIEREN → FASSEN → LIEFERN)
• Persistent case memory bank under .memory-bank/legal/, multiple document templates, norm-first reasoning
• Mandatory RDG disclaimer on all outputs
• Bilingual operation (analysis in English or German; legal documents always in formal German)

---

7. Tax Researcher Agent (DE)

Role: German Tax Research and Document Drafting
Scope: Supplementary — not part of the SDLC pipeline
File: tax-researcher.agent.md

Responsibilities:

• German tax research (Steuerrecherche) across Einkommensteuer (EStG) and procedural tax law (AO)
• Tax document drafting in formal German: Einspruch, Antrag auf Aussetzung der Vollziehung, Stellungnahmen, Erläuterungen zur Steuererklärung
• Assessment-notice review (Bescheidprüfung) — estimation assessments (§ 162 AO), late-filing surcharges (§ 152 AO), joint assessment (§ 26b EStG)
• Rental income analysis (V+V § 21 EStG) including depreciation (AfA §§ 7, 7b EStG), Werbungskosten (§ 9 EStG)
• Deadline calculation and tracking (Einspruchsfrist, Klagefrist, Festsetzungsverjährung per §§ 108, 122 AO)
• ELSTER filing support and persistent case memory bank

Key Features:

• Mandatory StBerG/RDG disclaimer on every substantive output
• Persistent case memory bank under .memory-bank/tax/ with topic files for estimation details, per-object V+V, Werbungskosten, Sonderausgaben
• Session-lifecycle protocol that flags imminent Einspruchsfrist, Klagefrist, and Festsetzungsverjährung
• Norm-first reasoning and procedurally precise drafting
• Bilingual operation (analysis in English or German; tax documents always in formal German)

---

8. QC Inspector Agent

Role: Quality Control Inspection for Oil & Gas, Energy, and Industrial Sectors
Scope: Supplementary — not part of the SDLC pipeline
File: qc-inspector.agent.md

Responsibilities:

• Product quality inspection (NDT, welding, coating, pressure testing, material certification)
• Asset integrity management (RBI, FFS, corrosion management per API standards)
• Supplier evaluation and management (audits, AVL/AML, expediting)
• Regulatory compliance (PED, ATEX, Machinery Regulation, CBAM, CSDDD, CRA, ESPR)
• Energy transition QC (hydrogen, CCS, LNG, offshore wind, BESS)
• Non-conformance management (NCR, RCA, CAPA, 8D)

Key Features:

• Comprehensive EU regulatory awareness (CBAM, CSDDD, CRA, AI Act, ESPR/DPP, Battery Regulation, Machinery Regulation)
• Industry standards coverage (API, ASME, EN/ISO, NORSOK, DNV)
• Inspection document generation (ITP, NCR, audit reports, expediting reports)
• Bilingual operation (German/English with industry terminology)
• Risk-based thinking per ISO 9001:2015

---

Release Pipeline Workflow (Core Agents Only)

The following pipeline covers the core software development focus of this project. Domain-specific agents (Legal Researcher, Tax Researcher, QC Inspector, Training Writers) operate independently and are not part of this workflow.

flowchart LR
    Arch[Software Architect<br/>Agent] -->|Design Signed Off| Dev[Software Engineer<br/>Agent]
    Dev -->|Requirement Gap| Arch
    Dev -->|Code Complete| QA[Security & QA<br/>Agent]
    QA -->|PASS| Doc[Technical Writer<br/>Agent]
    QA -->|FAIL, you resend| Dev
    QA -->|CONDITIONAL| Risk[Risk<br/>Acceptance]
    Risk -->|Approved| Doc
    Risk -->|Rejected| Dev
    Doc -->|Documented + closed out| Prod[Production<br/>Deployment]

    style Arch fill:#9C27B0
    style Dev fill:#4CAF50
    style QA fill:#FF9800
    style Doc fill:#00BCD4
    style Prod fill:#2196F3
    style Risk fill:#FFC107

Loading

Run the whole thing with cycle: full, or work any single phase on its own — see Choosing how much process you want.

Recommended Workflow

1. Design Phase (Software Architect Agent)

   • Interrogate the requirement at a depth matched to the blast radius
   • Quantify every quality word or strike it from the requirement
   • Compare design options and name a recommendation
   • Emit the Design Concept and wait for explicit sign-off
   • Record the durable choice as a Decision record

2. Development Phase (Software Engineer Agent)

   • Implement features/fixes
   • Write comprehensive tests
   • Document changes in Memory Bank
   • Ensure quality gates pass
   • Update CHANGELOG

3. Security & Quality Validation (Security & QA Agent)

   • Execute automated security scans (SAST, dependency audit, secrets scan)
   • Perform manual security review
   • Validate quality gates and compliance
   • Conduct threat modeling and risk assessment
   • Generate comprehensive security report
   • Make production readiness decision

4. Production Decision

   • PASS: Deploy to production
   • CONDITIONAL: Risk acceptance required for medium severity issues
   • FAIL: Return to development phase for remediation

Severity Classification & Decision Matrix

Severity	CVSS Score	Blocker?	Decision
Critical	9.0-10.0	✅ YES	BLOCK - Must remediate before production
High	7.0-8.9	✅ YES	BLOCK - Remediate or leadership risk acceptance
Medium	4.0-6.9	⚠️ CONDITIONAL	CONDITIONAL - Remediation plan required
Low	0.1-3.9	❌ NO	APPROVE - Recommendations provided
Info	0.0	❌ NO	APPROVE - Optional improvements

Memory Bank Integration

All agents use the shared Pre-flight and Post-flight Instructions. For durable repository work, Pre-flight loads the memory-bank Skill when the canonical base is missing or incomplete and creates only missing files. Existing content is never overwritten. Read-only and transient tasks do not initialize a Memory Bank.

The canonical base is:

• index.md: Loading mode, authority order, and task routes
• projectbrief.md: Project scope and objectives
• productContext.md: Business context and user impact
• systemPatterns.md: Architecture and design decisions
• techContext.md: Technology stack and dependencies
• progress.md: Current status and completed work
• activeContext.md: Current work focus and recent changes
• promptHistory.md: Interaction tracking and decision history

Only index.md is read unconditionally. Its routing table selects the smallest relevant set for the task; ambiguous or unsafe routing fails open to the full available base. Seven files are required and version-controlled; local promptHistory.md and optional glossary.md join the fallback only when present. Routine pre-flight does not read promptHistory.md.

Role-specific schemas in the active agent extend this base with case files, incident logs, investigation dossiers, threat models, article registries, or training registries. Only the active durable workflow initializes those files. Every agent uses the shared Definition of Done gate in Post-flight; its own quality checklist remains additive.

Career, Legal, and Tax keep their records under .memory-bank/career/, .memory-bank/legal/, and .memory-bank/tax/. Before creating a missing namespaced record, those agents check for legacy direct-child files and load the memory-bank Skill. Its role-record migration plans first, asks the user to assign ambiguous records, previews with -WhatIf, and copies only after explicit confirmation. It never moves or deletes a source record.

Durable knowledge without an existing owner may use an explicitly routed Memory Bank topic under .memory-bank/topics/. Decision records remain under .memory-bank/decisions/. Neither directory is loaded wholesale; the memory-bank Skill includes a read-only health and compactness check.

Usage Instructions

Activating an Agent

In VS Code with GitHub Copilot:

1. Open the Chat view
2. Select the agent from the agents dropdown
3. Choose the appropriate agent for your current phase:
   • Design & Requirements: "software-architect"
   • Development: "Software Engineer Agent"
   • Development (regulated / high-security environment): "software-engineer-contoso"
   • Troubleshooting: "Technical Troubleshooter Agent"
   • Security/QA: "Security & Quality Assurance Agent"
   • Documentation: "Technical Writer & Documentation Agent"
   • Training Content (supplementary): "Training Content Writer"
   • DevOps Training (supplementary): "DevOps Training Writer"
   • Legal Research (supplementary): "legal-researcher"
   • Tax Research (supplementary): "tax-researcher"
   • QC Inspection (supplementary): "QC Inspector"
   • Career Coaching (supplementary): "career-coach"
   • Web Research & Investigation (supplementary): "research-analyst"

Example Workflows

Design → Implementation

1. Activate: software-architect
   Prompt: "We need a rate limiter for the public API."
   (Interview, then a Design Concept, then explicit sign-off.)

2. Handoff: Implement the Design Concept
   Target: Software Engineer Agent

Feature Development → Security Validation

1. Activate: Software Engineer Agent
   Prompt: "Implement user authentication with OAuth2 and JWT tokens"
   
2. Activate: Security & Quality Assurance Agent
   Prompt: "Perform comprehensive security assessment of the authentication implementation"

Security Audit of Existing Code

1. Activate: Security & Quality Assurance Agent
   Prompt: "Execute full security assessment of the codebase with focus on authentication and data handling"

Pre-Production Validation

1. Activate: Security & Quality Assurance Agent
   Prompt: "Validate production readiness for deployment to production environment"

Troubleshooting Infrastructure Issues

1. Activate: Technical Troubleshooter Agent
   Prompt: "Users report Kerberos authentication failures after installing the January 2026 cumulative update."

2. Activate: Software Engineer Agent  (if code fix needed)
   Prompt: "Implement the fix identified in the troubleshooting analysis above."

Domain-Specific: Legal Research & Document Drafting

1. Activate: legal-researcher
   Prompt: "The tenant has not paid operating costs for Q3. Draft an Aufforderungsschreiben with a 14-day deadline."

Domain-Specific: QC Inspection

1. Activate: QC Inspector
   Prompt: "Create an ITP for API 6A wellhead equipment with hold/witness points for a European manufacturer."

Domain-Specific: Career Coaching & Job Applications

1. Activate: career-coach
   Prompt: "Here's my master CV and a job ad for a Senior Platform Engineer role at Acme. Tailor my CV and draft a cover letter."

2. Activate: career-coach
   Prompt: "I have an offer: 95k base, 10% bonus, 40k RSU over 4 years. Build a counter-offer strategy."

Best Practices

For Development Phase

• ✅ Update Memory Bank after significant changes
• ✅ Write tests alongside code (TDD)
• ✅ Document architectural decisions
• ✅ Follow language-specific coding instructions (Instructions/)
• ✅ Run local quality checks before handoff

For Security/QA Phase

• ✅ Review ALL automated scan results
• ✅ Validate findings with evidence
• ✅ Provide specific remediation guidance
• ✅ Document risk acceptance for conditional approvals
• ✅ Update threat detection rules based on findings
• ✅ Share lessons learned with team

Cross-Phase

• ✅ Maintain clear communication in Memory Bank
• ✅ Document all critical decisions with rationale
• ✅ Track security debt and remediation plans
• ✅ Keep threat intelligence current
• ✅ Continuously improve detection rules and quality gates

9. Training Content Writer Agent

Role: Generic Training & Workshop Content Creation
Scope: Supplementary — not part of the SDLC pipeline
File: training-writer.agent.md

Responsibilities:

• Modular, GitHub-hosted training content creation
• Didactical design using Bloom's taxonomy and constructive alignment
• Self-contained module architecture with flexible agendas
• Lab and exercise integration with starter/solution scaffolding
• Facilitator guide and cheat sheet generation

Key Features:

• Bloom's revised taxonomy alignment (Remember → Create) with action verbs
• Progressive disclosure pattern (WHY → WHAT → HOW → PRACTICE → REFLECT)
• Constructive alignment triangle (Objectives ↔ Activities ↔ Assessment)
• Modular design: each module stands alone with declared prerequisites
• Flexible agenda system: pre-built configurations (lightning, half-day, full-day)
• Five lab types (guided, semi-guided, challenge, code-along, exploration)
• GitHub Flavored Markdown optimized (alerts, Mermaid diagrams, collapsible solutions)
• Repository structure templates for training projects
• Cognitive load management (chunking, worked examples, scaffolding)
• Active learning techniques (think-pair-share, polling, retrospectives)

When to Use:

• Creating any training, workshop, or presentation content
• Designing modular learning paths with labs
• Structuring GitHub-hosted educational repositories
• Building facilitator guides and agenda configurations

---

10. Career Coach Agent

Role: Career Coaching, CV Writing, Job Search, Application Tracking, Interview Prep, Negotiation
Scope: Supplementary — not part of the SDLC pipeline
File: career-coach.agent.md

Responsibilities:

• Candidate self-assessment (skills, experience, achievements, constraints, drivers)
• Career strategy and positioning (target roles, industries, geographies, comp range, value proposition)
• CV / resume / Lebenslauf crafting (region-aware: US/UK/IE/CA/AU resume vs. DE/AT/CH Lebenslauf vs. EuroPass vs. Academic CV)
• Cover letter / Anschreiben drafting tailored per role
• LinkedIn / Xing profile optimization (headline, about, experience, skills, featured)
• Application pipeline tracking with status taxonomy and KPI monitoring (response rate, conversion, time-to-response by channel)
• Interview preparation (panel research, STAR/CAR stories, questions to ask, mock-interview debrief)
• Offer negotiation (total-comp modeling, equity vesting analysis, counter-offer scripts)
• 30-60-90 onboarding plan and graceful resignation

Key Features:

• Five-phase career workflow (ASSESS → POSITION → CRAFT → APPLY → ADVANCE)
• Persistent Memory Bank under .memory-bank/career/ (profile.md, career-strategy.md, applications.md, deadlines.md, plus per-job dossiers and per-interview prep files)
• Application status vocabulary with consistent icons (🎯 RESEARCHING, 📤 APPLIED, 🎤 INTERVIEWING, 💰 OFFER, ✅ ACCEPTED, ❌ REJECTED, 👻 GHOSTED)
• ATS-aware formatting rules (single column, standard headings, parseable dates, no white-text keyword stuffing)
• STAR / CAR / XYZ achievement framing with quantified outcomes
• Bilingual operation (EN/DE) with region-appropriate conventions and protected-data rules
• Ethics-first: never fabricates experience, qualifications, metrics, or credentials
• Skill integration: pdf-to-markdown, docx-to-markdown, xlsx-to-markdown for ingestion; pandoc-docx-export for final DOCX rendering; create-outlook-draft / send-outlook-email for application emails; outlook-calendar-export for interview tracking; microsoft-todo-tasks for follow-up reminders; grammar-check for proofreading; whisper-pyannote-transcription for mock-interview debriefs; marp-slide-overflow for portfolio decks
• Handoff to legal-researcher for German employment-law matters (Kündigung, Aufhebungsvertrag, PIP, contract clauses)
• Handoff to technical-writer for LinkedIn articles and thought-leadership content
• Mandatory escalation rules for visa / immigration, equity / IP / non-compete clauses, employment disputes, scam detection

When to Use:

• Building or refreshing a CV / Lebenslauf for a specific target role
• Drafting tailored cover letters, application emails, or LinkedIn content
• Parsing a job ad and producing a fit-gap analysis with a tailored CV
• Tracking an active job-search pipeline with deadlines and follow-ups
• Preparing for phone screens, technical interviews, panel loops, or executive finals
• Modeling total compensation across competing offers and crafting a counter-offer
• Negotiating salary, equity, signing bonus, or relocation
• Planning the first 30-60-90 days at a new role

---

11. DevOps Training Writer Agent

Role: Specialized DevOps/Ops Training Content Creation
Scope: Supplementary — not part of the SDLC pipeline
File: devops-training-writer.agent.md
Composes With: Training Content Writer Agent for bounded curriculum planning

Responsibilities:

• DevOps, SRE, and Platform Engineering training content
• CI/CD pipeline, IaC, container, and monitoring labs
• DevOps-specific workshop formats (Game Day, Pipeline Dojo, Automation Kata)
• Tool landscape comparisons across DevOps ecosystem

Key Features:

• Delegates substantial curriculum architecture to training-writer, then applies the returned plan through its DevOps-specific rules
• Five DevOps audience profiles (DevOps Engineer, SRE, Platform Engineer, Ops/Sysadmin, Developer)
• DevOps content domain map (Foundation → Build & Deploy → Infrastructure → Operate → Platform)
• Domain-specific module patterns for CI/CD, IaC, Containers, Monitoring, DevSecOps
• Seven lab environment strategies (Codespaces, Dev Containers, AutomatedLab, Docker Compose, Terraform, Kind/Minikube, GitHub Actions)
• Progressive lab complexity (Level 1: follow recipe → Level 5: debug & troubleshoot)
• Four DevOps slide patterns (Before & After, Pipeline Slide, Tool Landscape, Real Incident)
• Three specialized workshop formats (Game Day, Pipeline Dojo, Automation Kata)
• DevOps terminology glossary (CI, CD, IaC, GitOps, SRE, Shift Left, etc.)
• DevOps-specific anti-patterns (tool worship, happy-path-only, ignoring security)

Composition Architecture:

devops-training-writer (coordinator)
   │
   ├── delegates curriculum planning to training-writer
   │       ├── Didactical framework (Bloom's, constructive alignment)
   │       ├── GitHub Markdown format and repository structure
   │       ├── Lab integration patterns
   │       ├── Modular design rules
   │       └── Flexible agenda system
   │
   └── applies the returned plan with specialist guidance
         ├── DevOps audience profiles
         ├── DevOps content domains
         ├── DevOps lab strategies
         └── DevOps workshop formats

When to Use:

• Creating DevOps, SRE, or Platform Engineering training content
• Designing CI/CD, IaC, container, or monitoring labs
• Building DevOps workshops with hands-on pipeline exercises
• Creating automation and scripting training for operations audiences

---

12. Research Analyst Agent

Role: Technical and Scientific Web Research & Investigation
Scope: Supplementary — research upstream for the SDLC pipeline and the domain-specific agents
File: research-analyst.agent.md

Responsibilities:

• Fact-driven web research on technologies, products, scientific claims, vendors, incidents, and standards
• Source-traced verification with confidence-graded findings (Established / Probable / Contested / Weak / Speculation)
• Adversarial self-review (active counter-evidence search) before any claim is graded Established or Probable
• Persistent investigation files with annotated bibliography and a replication-grade query log
• Hand-off of research dossiers to technical-writer for publication, or of domain questions to legal-researcher / tax-researcher

Key Features:

• Five-phase investigation workflow (SCOPE → SOURCE → VERIFY → SYNTHESIZE → DELIVER) modelled on PRISMA-style systematic-review practice adapted for open-web research
• Falsifiable research question + explicit inclusion/exclusion criteria + stop condition written before searching
• Strict source hierarchy: standards > primary literature > source code & official docs > regulatory > established secondary > community-curated > vendor marketing > social media (leads only, never citable)
• Triangulation rule (≥ 3 independent primary sources for any Established Tier-1 claim) and lateral-reading discipline (assess sources from outside, not from inside)
• Per-claim verification recipes for statistical/numeric claims, software-version claims, standards references, CVEs, quotations, images/video, news events, vendor claims, and AI/ML capability claims
• Anti-hallucination guardrail: citations generated by an LLM are treated as unverified hypotheses until the source is fetched and the cited content is confirmed
• Mandatory archive-snapshot capture (web.archive.org / archive.today) for every cited URL
• Persistent memory bank (investigation-<slug>.md, -sources.md, -querylog.md, -notes.md) so investigations survive context resets
• Dossier template with confidence grades, evidence table, divergences and open questions, methodology section, known limits, reference list with archive URLs, and a replication-log link — separated from publication prose
• Mandatory disclaimer that research alone is not legal, medical, financial, or engineering advice

When to Use:

• Verifying a contested technical or scientific claim before relying on it
• Comparing products, libraries, standards, or vendors with defensible evidence
• Investigating a security incident, CVE, vendor claim, or regulatory question from open sources
• Producing a research dossier that a writer (or you) can later turn into an article via technical-writer
• Any task where the failure mode of "plausible-sounding but unsourced" is unacceptable

---

13. Software Engineer (Contoso) Agent

Role: Implementation inside a regulated, data-classified corporate trust boundary
Scope: Corporate overlay on the core SDLC pipeline
File: software-engineer-contoso.agent.md
Inherits From: Software Engineer Agent (all engineering rules)

Responsibilities:

• Everything the Software Engineer Agent does, under a tightened operating envelope
• Containment of Contoso source, configuration, topology, and regulated data
• Supply-chain control on every dependency added or upgraded
• Separation of duties on anything that leaves the local working tree

Key Features:

• Inherits every rule from the Software Engineer Agent by carrying its contract inline, not by linking it — VS Code resolves referenced instructions files into the prompt, so a Markdown link to another .agent.md is inert and an overlay that only links its base inherits nothing. tests/AgentInheritance.Tests.ps1 compares the inlined block byte-for-byte against the base and fails on drift
• Adds constraints only, never relaxes one; where the overlay and the inherited contract disagree, the stricter rule wins
• Least-privilege toolset: the egress and supply-chain tools are removed under both tool namings — the VS Code names (web/fetch, web/githubRepo, web/githubTextSearch, browser, github, useMcp, vscode/installExtension, vscode/extensions, codeInterpreter) and the runtime names (web_fetch, web_search, the vscodeBrowser/* browser tools, and the agent-host session tools) — so no network tool is there to complete the lethal trifecta. The terminal and delegation paths below are closed by rule, not by tooling. It keeps only the runtime names grep, glob, and ask_user for the VS Code search and question tools it already declares
• Agent-host limits: the agent host does not enforce the agents: allow-list, so delegation there can reach any agent, and an open agent in another session can read this session's transcript through list_sessions and get_session_context
• Terminal egress and handoffs are explicitly closed as workarounds — no curl/Invoke-WebRequest substitution, no agent switch to regain network access
• Subagent egress rule: security-reviewer carries its own outbound tools, so it is dispatched with repository paths and questions, never with pasted source or data
• Untrusted-content rule: external text is data, never instruction; suspected prompt injection is quoted, labelled, and refused
• Secrets by reference from the approved vault; a discovered secret is treated as burned (rotate, then scrub — never silently deleted)
• Internal-mirror-only dependencies with pinned version, integrity verification, approved license, and SBOM entry — all four or nothing
• "Never ship" Blocker list (hand-rolled crypto, disabled TLS verification, dynamic execution, injection-prone concatenation, wildcard authorization, swallowed security failures, sensitive logging, weakened controls)
• Separation of duties: local commits only — no push, PR, merge, tag, publish, deploy, or production target; no control bypass (--no-verify, suppressions, -Force)
• Raised review bar: full suite plus mandatory security-reviewer review for security-relevant diffs, new dependencies, new network paths, and first-time repositories
• Seven-item hard-stop list with a four-part escalation report (what stopped you, what you did not do, what state you left, who must act)
• Memory Bank extension (contoso-controls.md, data-classification.md) that explicitly avoids the security-reviewer files

Inheritance Architecture:

The overlay carries the base body inline between <!-- BEGIN INHERITED --> markers, so the two files are one prompt at runtime rather than a link the resolver never follows.

software-engineer (base)
    ├── Execution loop and proportional planning
    ├── Focused executable validation, TDD, regression guards
    ├── Self-review and risk-scaled independent review
    └── Error recovery and completion bar
        │
        └── software-engineer-contoso (corporate overlay)
                ├── Trust boundary and containment-first toolset
                ├── Secrets, supply chain, regulated data
                ├── Separation of duties and change control
                └── Raised validation, review, and escalation bar

When to Use:

• Implementation work on a repository holding confidential, customer, or regulated data
• Any environment where source and configuration must not leave the trust boundary
• Change-controlled organizations where release actions belong to an entitled human
• As a template for another corporate overlay: copy it, rename to software-engineer-<company>, and adjust the control set

---

Future Agents (Planned)

• Release Manager Agent: Deployment orchestration and rollback management
• DevOps Agent: Infrastructure as Code and CI/CD pipeline management
• Performance Testing Agent: Load testing and performance optimization

Contributing

When creating new agents:

1. Follow the established pattern and structure
2. Include comprehensive responsibilities and key features
3. Define clear success criteria and quality gates
4. Define only role-specific Memory Bank extensions; inherit the canonical base and lifecycle from the shared Instructions
5. Document escalation protocols
6. Provide usage examples
7. Update this README with the new agent
8. Declare the runtime name next to each VS Code tool name, and classify the agent as open or contained in tests/AgentRuntimeToolNames.Tests.ps1; see Tool names in agent-host sessions

Related Documentation

• Project Brief
• Product Context
• System Patterns

---

Remember: The core agents (Software Architect, Software Engineer, Security & QA, Technical Writer, Technical Troubleshooter) are designed to work together as a cohesive release pipeline. Use them sequentially for best results, with clear handoffs between phases documented in the Memory Bank. The domain-specific agents (Legal Researcher, Tax Researcher, QC Inspector, Training Content Writer, DevOps Training Writer, Career Coach, Research Analyst) operate independently for their respective use cases. The Research Analyst is also a natural upstream for the Technical Writer (research dossier → publication article) and for any engineering decision that needs defensible evidence.