Skip to main content
Engineering Docs’ standalone mode lets you call any of the 22 skills directly when you already know what document you need. Every skill in the plugin is independently callable — you don’t have to go through the using-engineering-docs orchestrator. Standalone mode skips the orchestrator’s phase sequencing and context-loading pipeline, and goes straight to the interview and generation for the one document you asked for. Each skill still interviews you for what it needs — standalone doesn’t mean unguided. It means the skill asks its own focused questions rather than the orchestrator’s broader project-level intake.
Use standalone mode when the orchestrator’s full pipeline would be overkill. If you already have a running system and just need a threat model for a new service, a runbook for a new team member, or an ADR for a decision you’re making today — standalone is the right path.

​
When to use standalone mode

You have partial documentation

Your .engineering-docs/ folder exists but you need one specific artifact — a runbook, a new ADR, a blueprint for a single feature.

You want a single document fast

The orchestrator’s full pipeline takes hours. Standalone delivers one document in minutes, targeted to exactly what you asked for.

The orchestrator already ran

The full pipeline completed for a project, but requirements changed and one document needs to be regenerated or extended.

You're producing a reactive artifact

Incident postmortems, threat models for specific incidents, ADRs for decisions in flight — these arise on demand, not as part of a plan.

​
What standalone mode skips

When you invoke a skill directly, the orchestrator’s multi-phase pipeline does not run:
  • ❌ Phase 0 business concept interview
  • ❌ Standing constraint questions (team size, hosting, budget, timeline, compliance)
  • ❌ Sequencing plan preview and document ordering
  • ❌ Cross-document consistency pass against the full document set
  • ❌ Master index update
What does still happen:
  • ✅ The skill’s own clarifying interview (one question at a time, via tool calls)
  • ✅ Document generation using the skill’s full template
  • ✅ YAML frontmatter metadata header on the output document
  • ✅ Reading of any prior documents you reference in your prompt (context you provide is used)

​
How to invoke a skill directly

Address the skill by name in your prompt. You can reference the skill using its kebab-case name:
Direct skill invocation syntax
Or simply describe what you want in enough detail that the skill activates naturally:
If the context you provide already contains details the skill would normally ask for (e.g., “Go with PostgreSQL and Redis”), the skill will not re-ask for that information. Prior context in your prompt is respected — only genuinely missing information is asked for.

​
Security threat model for an existing system

Use the security-threat-model skill when you need a STRIDE analysis for a specific service or feature — without running the full project pipeline.
What the skill interviews you for:
  • What external attack surface does this introduce (new webhook endpoints, redirect flows)?
  • What data does your platform store vs. pass through to Stripe?
  • Who has admin-level access to payout controls?
What you get: A STRIDE-based threat model covering spoofing, tampering, repudiation, information disclosure, denial of service, and elevation of privilege — with a risk register and prioritized mitigations, specific to the Stripe Connect surface.

​
Technical runbook for a production service

Use technical-runbook when you’re onboarding a new on-call rotation or documenting an existing service that was never formally documented.
What the skill interviews you for:
  • What monitoring and alerting do you currently have in place?
  • What’s the escalation path when a worker goes down?
  • What’s the rollback procedure if a bad deploy causes job failures?
What you get: A Google SRE-style operations manual with runbook sections for common failure modes, step-by-step diagnostic procedures, escalation contacts, and rollback procedures.

​
Architecture Decision Record for a new decision

Use architecture-decision-record when you’re making a significant technical decision and want to capture the context, options considered, and rationale — before the institutional memory fades.
What the skill interviews you for:
  • What are the constraints (team familiarity with event sourcing, operational overhead tolerance)?
  • What’s the read performance requirement for the order history view?
  • Are there other systems that need to consume these events?
What you get: An immutable ADR in MADR format — with context, decision drivers, options considered, the decision made, and consequences (positive and negative).

​
Test strategy for a specific service

Use test-strategy-document when you need a testing plan scoped to one service rather than a full-system test strategy.
What the skill interviews you for:
  • What CI system are you using, and what are the current gate requirements?
  • What’s the acceptable test execution time for the full suite?
  • Do you need E2E tests against Stripe’s sandbox, or will mocks suffice?
What you get: A testing pyramid document with unit, integration, and contract test requirements, mocking strategy for Stripe, CI gate definitions, and coverage targets — all scoped to the payments service.

​
Implementation plan for a targeted migration

Use implementation-plan when you’re planning a scoped change — a migration, a refactor, or a feature rollout — and need a dependency-ordered build sequence.
What the skill interviews you for:
  • What’s the data migration strategy for billing records?
  • What’s the feature flag / traffic-splitting approach for the cutover?
  • What are the rollback criteria and how quickly can you roll back?
What you get: A phase-gated implementation plan with dependency ordering, go/no-go criteria at each phase boundary, and explicit rollback procedures.

​
Standalone invocation: what the skill’s interview looks like

Regardless of which skill you invoke, the interview follows the same rules:
  1. One question per tool call — never batched
  2. Multiple-choice options preferred — with “I don’t know, you decide” as an escape hatch
  3. No re-asking — context you provided in your prompt is used; only genuinely missing information is asked for
  4. Maximum 2–3 questions — the skill extracts what it needs efficiently, then generates
Example interview exchange — security-threat-model

​
Cross-reference

For the full list of available skills, their descriptions, output formats, and what each document contains, see the Skills Reference. Each skill’s reference page includes:
  • What the skill produces
  • What questions to expect in the interview
  • The document template structure
  • Example outputs