Add a sample-app-generator skill: scaffold runnable starter apps against an Azure DocumentDB cluster
Nobody has claimed this yet.
Assessment
- Difficulty
- 5/5
- Estimated time
- Over a week
- Newbie friendliness
- 35/100
- Issue type
- Feature
- Clarity
- Mostly clear
- Activity status
- Quiet
- Domain
- backend-api-design, cloud, developer-experience, tooling
Research direction
Read the existing skills//SKILL.md pattern, docs/SKILLS.md, and scripts/validate-skills.ps1 first, then inspect the referenced security, high-availability, and full-text-search skills. Resolve the open generation and Java-framework questions, add the proposed rules and Node.js/Python templates, and validate the skill. Done means the acceptance criteria pass, including maintainer verification against a live cluster.
Written by the indexing model from the issue text.
Description
Summary
Add a new skill — sample-app-generator — that scaffolds a runnable starter application against an Azure DocumentDB cluster. The skill should let an agent generate a minimal but production-shaped sample app for a target language/framework, wire it up to a user-provided cluster, and verify the connection works end-to-end.
Motivation
Every developer onboarding to Azure DocumentDB writes essentially the same first hundred lines: connection-string handling, TLS, retry, a minimal CRUD path, and a way to confirm "yes, I'm actually connected." Today there is no canonical scaffold and the existing skills (security, storage, HA, full-text-search) all assume the developer has already got a working client.
A sample-app-generator skill closes that gap and gives the rest of the agent-kit a concrete launch surface: "generate the starter, then ask me about indexing / FTS / RBAC."
Proposed scope
In scope (v1)
- Language / framework matrix — minimum viable set:
- Node.js + native
mongodbdriver - Python +
pymongo - C# +
MongoDB.Driver - Java +
mongodb-driver-sync
- Node.js + native
- Generated app shape (same across languages):
README.mdwith run instructions- Config via environment variables (
DOCUMENTDB_CONNECTION_STRING,DOCUMENTDB_DATABASE) - TLS-enabled client construction (matches
security-tls-requiredrule) - One
database+ onecollection - CRUD endpoints / functions: insert, find-by-id, update, delete, list-paged
- A
/healthz-style probe that does apingagainst the cluster - Basic retry with backoff on transient errors
- Dockerfile (where it makes sense) +
.env.example
- Auth modes — the generator should support choosing one at scaffold time:
- Connection-string + native admin user (default, easiest)
- Microsoft Entra ID via managed identity (matches
security-entra-rbacrule) — generated samples show theMONGODB-OIDCmechanism wired in
- Optional add-on flags:
--with-fts→ add a vector / full-text search example collection and a search endpoint (links into the existingfull-text-searchskill)--with-private-endpoint→ emit a Bicep snippet alongside the app for cluster + PE provisioning (links intosecurity-private-endpoint)
- Validation step — the skill should be able to run the generated app's
/healthzprobe to confirm the connection string works before handing off to the user.
Out of scope (v1)
- Migrating from MongoDB Atlas / CosmosDB-Mongo-vCore — that's a separate "migration" skill.
- Multi-region or read-replica wiring — covered by HA skill; the generator may reference it but not duplicate it.
- ORM-style abstractions (Mongoose, EF Core mappings) — keep v1 driver-native to stay close to the wire.
- Web UI / front-end — the sample is API/CLI only.
Proposed skill layout
Following the existing agent-kit pattern (skills/<name>/SKILL.md + rule files):
skills/sample-app-generator/
├── SKILL.md
├── rules/
│ ├── generator-language-matrix.md # which langs/frameworks are supported and why
│ ├── generator-connection-config.md # env-var contract, TLS, retry defaults
│ ├── generator-auth-mode-selection.md # native-user vs Entra OIDC; when to choose which
│ ├── generator-crud-shape.md # canonical CRUD endpoint/function signatures
│ ├── generator-healthz-probe.md # what a working probe looks like; failure modes
│ ├── generator-fts-addon.md # how the --with-fts flag composes with full-text-search skill
│ └── generator-private-endpoint-addon.md# how --with-private-endpoint composes with security skill
└── templates/
├── node/
├── python/
├── csharp/
└── java/
Templates live under templates/ and are rendered by the agent (or a small helper script in scripts/) given the user's choices.
Cross-references with existing skills
The generator deliberately doesn't re-state guidance that other skills own — it links to them:
| Generator concern | Owning skill |
|---|---|
| TLS on the client | security/security-tls-required |
| Auth mode (Entra OIDC) | security/security-entra-rbac, security/security-database-roles |
| Connection-string handling, admin password rotation | security/security-admin-password-and-identity-separation |
| Retry / replica behavior | high-availability/ |
Search / vector endpoints (--with-fts) |
full-text-search/ |
Private endpoint Bicep (--with-private-endpoint) |
security/security-private-endpoint |
Open questions
- Generation mechanism — pure-text templating with the agent doing the substitution, or a
cookiecutter-style helper script invoked by the skill? My instinct: start with text templates that the agent renders, ship a script later if it pays off. - Which Java framework — bare main + driver, Spring Boot, or both? Start with bare main and add Spring Boot in v1.1 unless feedback says otherwise.
- Versioning of generated apps — do we pin driver versions or use
latest? Pin, with a quarterly bump cadence. - Telemetry — should the generated app emit OpenTelemetry traces by default? Probably yes for production-shaped, but it bulks up the sample. Maybe behind a
--with-otelflag. - Test scaffolding — include a smoke-test file (one assertion per CRUD path) or leave it to the developer? Recommend yes, one per language, using each ecosystem's default runner.
Acceptance criteria
-
skills/sample-app-generator/SKILL.mdexists with frontmatter and is registered indocs/SKILLS.md. - All rule files listed in "Proposed skill layout" are present and pass
scripts/validate-skills.ps1. - Templates for at least Node.js and Python compile / run end-to-end against a live cluster (manual verification by a maintainer).
- A generated app's
/healthzprobe returns success against a real cluster using the default connection-string flow and the Entra-OIDC flow. - Cross-links to
security/,high-availability/,full-text-search/resolve.
Suggested follow-ups (not blockers)
- C# and Java templates if v1 lands with Node + Python first.
- IaC bundle: Bicep +
azd upintegration so--with-private-endpointcan provision a fully working cluster + PE in one shot. - Aspire-style local dev story (containerized DocumentDB emulator if/when available).
- Dominant language
- Shell
- Stars
- 6
- Forks
- 10
- Avg merge
- 11d 20h
- Merged PRs (30d)
- 2
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from Azure/documentdb-agent-kit
-
Difficulty 4/5 3-5 days Newbie friendliness 45/100
Azure/documentdb-agent-kit#20 · 1 comment ·
-
Difficulty 4/5 3-5 days Newbie friendliness 52/100
-
Difficulty 2/5 1-3 hours Newbie friendliness 58/100
-
Add a skill for RBAC Open
Difficulty 4/5 3-5 days Newbie friendliness 20/100
All issues in Azure/documentdb-agent-kit
Similar issues
-
good-start
Difficulty 2/5 1-3 hours Newbie friendliness 65/100
-
Difficulty 2/5 1-3 hours Newbie friendliness 70/100
-
Difficulty 2/5 1-3 hours Newbie friendliness 75/100
VilnaCRM-Org/user-service#497 ·
-
Difficulty 2/5 1-3 hours Newbie friendliness 75/100
conda-forge/spacy-feedstock#177 ·
-
area:jail bug security severity:low track:open-source
Difficulty 1/5 Under an hour Newbie friendliness 75/100