Home
Welcome to the Agentic Accelerator Framework wiki — a living record of building, extending, and operating the framework's four domains (Security, Accessibility, Code Quality, and FinOps) using custom GitHub Copilot agents, GitHub Advanced Security, and Microsoft Defender for Cloud.
This wiki captures real, non-deterministic agentic sessions where Copilot automode and subagents scaffold entire repositories, generate sample applications, build SARIF converters, produce Power BI PBIPs, create workshop labs, and automate screenshot capture — all from a single prompt invocation.
The DIY guide
walks through creating the Code Quality domain's two repositories —
code-quality-scan-demo-app (scanner platform with 5 sample apps in C#,
Python, Java, TypeScript, and Go) and code-quality-scan-workshop (10
hands-on labs). The following sections document a live Copilot automode session
executing this guide end-to-end.
With the Agentic Accelerator Framework workspace open in VS Code, the
/scaffold-domain domain=code-quality prompt is invoked. Copilot enters
automode and the DomainScaffolder agent begins orchestrating the build. The
Copilot Chat panel shows the agent's plan with a todo list tracking each
scaffolding phase:
Progress can be monitored in VS Code's Explorer panel or by watching newly created repositories appear in the GitHub organization:
Each run of the scaffolding agent produces a slightly different execution path — this is the nature of agentic workflows. The following screenshots document the first full journey from invocation to completion.
The agent analyzes the existing Accessibility and FinOps domain structures to determine the target layout for Code Quality. It reads the Domain Parity and Contribution Guide, the domain scaffolding skill, and the DIY documentation:
The agent formulates its execution plan, identifying all artifacts to generate — repository scaffolds, GitHub Actions workflows, SARIF converters, bootstrap scripts, and Copilot configuration files:
The workload is substantial — 5 sample apps, 10 workshop labs, SARIF converters, Power BI PBIP, bootstrap scripts, and CI/CD pipelines. The DomainScaffolder delegates to subagents (Explore for codebase research, Phase Implementor for file generation) to divide and parallelize the work:
With subagents active, files begin materializing. The agent creates directory structures, generates configuration files, and writes initial source code:
The scaffolding continues with GitHub Actions workflow files, Dockerfile templates, and Bicep infrastructure definitions:
Switching to the VS Code Explorer, the generated file tree becomes visible.
The demo-app repository takes shape with its expected structure — src/,
infra/, .github/workflows/, scripts/, and Copilot artifacts:
The workshop repository scaffolding has not started yet at this point — the agent completes the demo-app first before moving to the workshop:
Back in the Copilot Chat panel, the agent reports progress on the demo-app structure and prepares to generate the 5 sample applications:
The agent begins creating the 5 sample applications, each with intentional code quality violations to serve as scanner targets. The apps span C# (ASP.NET Minimal API), Python (Flask), Java (Spring Boot), TypeScript (Next.js), and Go (stdlib net/http):
The generation follows a deliberate order — C# first, then Python, then Java,
with each app including infra/main.bicep, Dockerfile,
start-local.ps1/stop-local.ps1, and an intentionally incomplete test
suite:
With sample apps generated, the agent moves to screenshot automation. It
creates capture-screenshots.ps1 and screenshot-manifest.json for
manifest-driven screenshot capture across all workshop labs:
The agent also generates the Power BI PBIP — a star schema semantic model with
Fact_CodeQualityFindings, dimension tables, and four report pages (Quality
Overview, Coverage by Repository, Complexity Analysis, Test Generation
Tracking):
The final major phase generates the 10 workshop labs (Labs 00–08 plus ADO variants for Labs 06 and 07). Each lab directory includes step-by-step instructions, expected outputs, and platform-specific sections:
The DomainScaffolder agent marks the task complete. The todo list shows all phases finished — repository structure, sample apps, SARIF converters, bootstrap scripts, GitHub Actions workflows, Power BI PBIP, screenshot automation, and workshop labs:
After the DomainScaffolder completes, manual verification is essential. Agentic scaffolding produces the bulk of the artifacts, but several configuration steps require human review before the repositories are production-ready. The checklist below documents each finding from the first iteration.
The code-quality-scan-workshop repository was created as a regular repo
instead of a GitHub template repository. The "Template repository" checkbox
in Settings → General must be enabled manually so that new workshop
instances can be created via Use this template:
GitHub Pages was not enabled on the workshop repository during scaffolding.
Navigate to Settings → Pages and select the deployment branch (typically
main or gh-pages) and folder (/docs or root) to activate the workshop
site:
Once Pages is enabled and the source branch is configured, GitHub deploys the Jekyll-based site. The Pages settings page confirms the deployment URL:
Enabling Pages should trigger the initial GitHub Actions deployment pipeline. Check the Actions tab to confirm the workflow runs successfully. The first run builds and deploys the Jekyll site:
The workshop labs render on GitHub Pages, but Mermaid diagrams embedded in the
Markdown do not display correctly. GitHub Pages' default Jekyll renderer does
not support Mermaid natively — a custom plugin, JavaScript include, or
pre-rendered SVG approach is needed. Screenshots are also missing at this
stage since capture-screenshots.ps1 has not been executed yet:
Known issues from first iteration:
- Mermaid diagrams render as raw code blocks — need Mermaid JS include or pre-rendered SVGs
- Screenshot placeholders are empty — run
capture-screenshots.ps1after demo apps are deployed
Both the code-quality-scan-demo-app and code-quality-scan-workshop
repositories are missing several metadata items that the existing
Accessibility and FinOps domains have:
-
No topics/tags — Add relevant GitHub topics (
code-quality,sarif,github-copilot,agentic-ai,workshop, etc.) - No description — Set the repository description in Settings → General
- No website link — Add the GitHub Pages URL to the About section (top-right of the repo page) so users can discover the workshop site
The following actions must be completed manually before the Code Quality domain reaches full parity with the existing Accessibility and FinOps domains:
-
Enable the template flag on
code-quality-scan-workshop - Add repository topics, description, and website URL to both repos
- Fix Mermaid rendering — add a Mermaid JS include to the Jekyll layout or pre-render diagrams as SVGs
-
Run
deploy-all.yml— deploy all 5 demo apps to Azure so the scanner targets are live -
Run
capture-screenshots.ps1— capture all workshop screenshots after demo apps are deployed -
Run bootstrap scripts (
setup-oidc.ps1,bootstrap-demo-apps.ps1) if Azure AD federation has not been configured
The deploy-all workflow is available in the demo-app repository's Actions tab. Trigger it manually to provision all 5 sample applications to Azure App Service:
Before deploy-all.yml can succeed, the Azure AD federation and GitHub
secrets infrastructure must be in place. This section documents the
bootstrap process and the issues encountered during the first iteration.
The correct execution order is:
-
setup-oidc.ps1— Creates Azure AD app registrations and federated credentials for workload identity federation (OIDC) -
bootstrap-demo-apps.ps1— Creates the 5 demo-app repositories, pushes content, and configures GitHub secrets and environments
Attempting to deploy before running these scripts results in authentication failures. The bootstrap script output confirms the initial setup:
The first run of bootstrap-demo-apps.ps1 encountered errors. The script
created the first two demo-app repositories successfully but failed midway
through the third:
The GitHub organization confirms that only two of the five expected repositories were created before the script halted:
The fix was applied directly in VS Code by editing the bootstrap script to handle the error condition:
Copilot can assist with identifying the next step when the bootstrap process
stalls. Asking Copilot for guidance surfaces that setup-oidc.ps1 must
run before the deployment workflows can authenticate:
Running setup-oidc.ps1 creates the Azure AD app registrations and
configures federated credentials for each demo-app repository:
Additional issues surface during the OIDC setup — typically around permissions, subscription scoping, or pre-existing registrations. Each issue is resolved iteratively:
After several iterations of fixing and re-running, both bootstrap scripts stabilize. A critical design principle emerged: both scripts must be idempotent — safe to re-run without duplicating resources or failing on already-existing artifacts:
The idempotency pattern uses az ad app list --filter and
gh repo view --json checks before creating resources, ensuring safe
re-execution:
A notable finding: the OIDC app registration required subscription-level scope because the target resource group did not yet exist. The deployment workflow itself creates the resource group, creating a circular dependency. For this proof of concept, subscription-level scope was used, though a production deployment should use a more restrictive RBAC approach:
Security note: Subscription-level Contributor is acceptable for a POC but should be scoped to a dedicated resource group in production. Consider pre-creating the resource group in a separate Bicep module or using a two-stage deployment (resource group first, then app deployment with scoped RBAC).
With OIDC configured and bootstrap complete, the deploy-all.yml workflow
can finally run. The first attempt surfaces deployment-specific issues that
need resolution:
The workflow presents multiple configuration options for resolving the deployment issue. The error details and proposed solutions are visible in the Actions log:
Option A requires creating a client secret for the Azure AD app registration. The following steps walk through the Azure portal configuration:
Navigate to Azure AD → App registrations → Certificates & secrets and create a new client secret:
Configure the secret description and expiration period:
After clicking Add, copy the generated secret value immediately (it is shown only once) and set it as a GitHub repository secret:
A key learning from the first iteration: the individual sample app
repositories (code-quality-demo-app-001 through demo-app-005) were
scaffolded without their own deploy.yml workflow files. The deploy-all.yml
in the parent repository expects each sample app to have a callable deployment
workflow:
After adding the missing deploy workflows, the bootstrap script is re-run (leveraging its idempotent design) to push the updated content to all repositories:
With all fixes in place, the deploy-all.yml workflow runs successfully.
However, the current implementation deploys all 5 apps sequentially rather
than in parallel, resulting in longer execution times:
Critical observations from the first iteration deploy-all:
- Sequential deployment — All 5 app deployments run sequentially. These should execute in parallel using a matrix strategy or separate concurrent jobs to reduce total deployment time.
- Silent failure masking — The workflow reports overall success even when individual app deployments fail. It should fail the entire run if any single deployment fails.
- Missing workflow summary — The completed workflow does not publish the deployed application URLs to the GitHub Actions job summary. The Accessibility and FinOps domains include summary links — Code Quality should match.
- Missing per-app documentation — Each demo-app repository should include a wiki page and screenshots showing the running application, matching the pattern established by the Accessibility and FinOps domains.
now deploy yields:
