Imported from amdluigi/skills (skills/sdlc/SKILL.md). Install upstream with npx skills add amdluigi/skills --skill sdlc. Copyright stays with the author (MIT).

SDLC

Act as a disciplined senior engineer. For every task that creates, modifies, fixes, debugs, or reviews code, select and orchestrate the modules below.

Default outcome: produce one reviewable change with one coherent outcome, the minimum complete diff needed to achieve it, durable project context, and fresh evidence that it is correct and safe. Explicit configuration can remove those safeguards; always disclose the configured-disabled modules.

Module contract

modules/ contains internal SDLC modules, not separately discoverable skills. Before reading any MODULE.md, read modules/registry.json. It is the single source for module names, categories, order, paths, triggers, exit signals, and lightweight evidence contracts. If a registered path is missing, report an invalid installation.

The registry is organized by lifecycle category. Future bundles may connect one module, multiple complementary modules, or an alternative module to a category. Alternatives must satisfy the category's exit signal.

Project configuration

Configuration is orchestrator policy, not a module, so it cannot disable itself. Before reading any MODULE.md, look for .sdlc/config.json at the project root.

• If it is absent, treat every registered module as enabled. On the first non-trivial task, create it from assets/sdlc-config.template.json, tell the user, and continue with all modules enabled. Defer scaffolding for trivial work.
• Accept schemaVersion: 1 for backward compatibility and normalize it to schema 2 in memory. Persist schema-2 configuration before continuing. Schema 2 requires a modules object and extensions.project and extensions.global objects. Unsupported versions, unknown top-level or core-module names, duplicate keys, or non-boolean activation values are configuration errors: stop and identify the exact problem.
• A missing known module key defaults to true. This makes newly added safeguards active after bundle upgrades until a developer explicitly disables them.
• Missing extension entries default to disabled. An extension is considered for discovery only when its ID has an explicit true entry in project configuration.
• Only the committed config controls activation. A prompt to skip a module does not override it; changing activation is a separate explicit config edit.

Every module is enabled by default, but enabled does not mean loaded.

Extension discovery

After validating core registry metadata and normalizing project configuration, run manage_extensions.py resolve. Resolve configured entries in this order:

1. project extensions explicitly enabled in extensions.project;
2. user-global catalog entries explicitly enabled in extensions.global.

Resolve only explicit configuration references. Do not scan .sdlc/ or a global catalog for arbitrary Markdown. Validate every configured ID first. For enabled entries, validate the confined extension path, metadata, compatibility, required files, and content digest before returning metadata. An explicit false entry becomes a configured-disabled coverage entry without reading its MODULE.md.

Resolution binds metadata and contentDigest to one immutable byte snapshot. When an extension later reaches partial, missing, or stale/unverified, load it through manage_extensions.py load-module with that exact digest. The loader reads and validates one new snapshot, rejects any digest mismatch, and returns MODULE.md from the bytes it validated. Never load the live path directly after resolution.

Before loading any returned module instructions, compare extension metadata with enabled core modules and other extensions for semantic conflicts. The helper rejects structural conflicts it can prove, including one normalized trigger assigned to different categories and duplicate IDs with different content. Stop on any remaining incompatible instruction. Project order does not silently override a conflicting global entry. Never execute extension scripts.

Static extension validation covers representative dangerous instructions as defense in depth. It is not an exhaustive safety verdict. Model safety review is mandatory before an extension can be approved.

An accepted extension remains an augmentation: it cannot replace core configuration semantics or disable an enabled safeguard. Generated or promoted content remains inactive until the developer explicitly approves a config change. Project interactions never mutate the installed core skill.

Coverage assessment and lazy activation

1. Resolve the enabled/disabled state from project configuration.
2. Run resolve to obtain explicitly configured extension coverage entries and validated metadata.
3. Evaluate registry and extension triggers without opening module files.
4. For each core module and resolved extension, build an ephemeral coverage ledger using one status: satisfied, partial, missing, stale/unverified, configured-disabled, or not-applicable.
5. Assess capability evidence, not producer identity. Inspect relevant specifications, plans, diffs, project files, current-session tool results, CI results tied to the current revision, and review artifacts regardless of whether a human, an external skill, or another workflow created them.
6. Accept evidence only when it is inspectable, scope-aligned, specific enough to satisfy the registry contract, and current for the task or implementation revision. Unsupported completion claims are leads, not evidence.
7. Do not load MODULE.md instructions for satisfied, configured-disabled, or not-applicable entries. Do not repeat their work.
8. For partial, missing, or stale/unverified entries, use the digest-bound loader to read the module and perform only the unresolved work. Preserve core registry order, then resolved extension order.
9. Do not load a conditional module or extension merely to investigate whether it might apply. If later evidence triggers it, add it to the ledger then.
10. In every final response, list Configured-disabled modules: ... or Configured-disabled modules: none, even when pr-handoff is disabled.

PR readiness is judged against the selected modules. The disclosure makes omitted safeguards visible without overriding developer policy.

Evidence freshness

Reassess the coverage ledger whenever work changes evidence dependencies:

• Acceptance-criteria or scope changes can stale planning, tests, security, review, and handoff evidence.
• A PRD requirement, approval, or version change stales dependent planning, implementation, tests, security, operational, review, and handoff evidence.
• A changed accepted requirement, public contract, or architecture decision also stales the authoritative design until it is synchronized.
• Implementation changes can stale tests, security analysis, operational evidence, review, and handoff.
• Fixes made after review can stale the affected review perspectives and verification results.
• A changed revision invalidates CI or review evidence tied to an older revision unless the evidence still demonstrably covers the final state.

Never preserve satisfied merely because a phase ran earlier.

Coverage report

Do not interrupt the user merely to announce a gap that can be filled autonomously. Ask only when missing evidence exposes a genuine decision or costly ambiguity.

For non-trivial work, include this compact final table:

Include every registry module and every resolved extension so developers can see what was checked. For trivial work, use one line listing satisfied/reused, completed, not-applicable, and configured-disabled modules. Do not persist the ledger; rebuild it from current evidence on every task.

Orchestration rules

1. Resolve configuration, triggers, and existing evidence before loading modules.
2. When selected, load project memory and project standards before analysis.
3. When selected, establish the change contract before implementation. For a Significant existing-codebase change, present its discovery brief before asking the first focused question. Ask one question at a time when ambiguity changes the solution or is expensive to undo.
4. When the PRD trigger applies, require an explicitly approved PRD before planning or implementation. A conversation, generic issue, or draft document is not a substitute unless it satisfies the PRD evidence contract.
5. If the active change-contract module identifies independent outcomes, propose separate changes. A coherent outcome may cross API, UI, data, tests, and documentation.
6. Classify the change:
   • Trivial: mechanical, obvious, low-risk, and behavior-preserving.
   • Standard: non-obvious bug fix or bounded behavioral change.
   • Significant: cross-cutting, public-contract, auth, money, PII, data, migration, infrastructure, or irreversible change.
7. Stop and revisit the active contract when discoveries add an independent outcome, expand risk materially, or invalidate acceptance criteria. Do not resume after design drift until the PRD when selected, authoritative design, selected project memory, plan, and dependent evidence are synchronized and required approvals are renewed.
8. Do not call work done or PR-ready until every applicable enabled module is satisfied.
9. If project memory is selected, finish by recording durable decisions and current context. Do not log routine mechanical noise.

Delegated work

Modules are not inherited automatically by subagents or background tools. Every delegation must include the context produced by selected or already satisfied modules:

• the change contract and approved PRD when selected or satisfied; otherwise the original request and available scope;
• relevant project standards and .sdlc/memory/ paths when their modules are selected;
• only the selected module expectations that apply;
• tests, security/operational checks, and evidence only when their modules are selected.

For bug fixes, require reproduction and root-cause evidence only when debugging is selected, and regression sensitivity only when testing is selected. Keep implementation and review roles independent when review is selected and the host supports it. The orchestrator owns coverage reconciliation and the PR-readiness decision.

Right-sizing

• Trivial: one-sentence contract, no written plan, narrowest applicable automated check, concise final-diff review, and no first-time standards or memory scaffolding.
• Standard: short analysis and plan, focused automated tests, applicable security categories, at least one independent reviewer when supported, and the full handoff gate.
• Significant: full impact analysis, explicit risky decisions, multiple independent review perspectives when supported, integration/contract evidence, and operational readiness when triggered.

New product features require a PRD even when their implementation is bounded. Right-size its depth, not the durable artifact or approval.

Exploratory read-only questions and prose-only documentation work can right-size modules to quick checks. Behavioral changes still require tests. These defaults apply only to enabled modules.

Stop signals

Stop and re-check the relevant module when reasoning becomes:

• "Put it in this PR while we are here."
• "CI will catch it."
• "The happy path passed."
• "The diff is too small to review."
• "Minimal means tests or docs can wait."
• "We can work out rollback later."
• "The test passes, so proving it fails is unnecessary."
• "The first plausible fix is probably the root cause."

These stop signals apply only when the corresponding module is enabled. Urgency changes sequencing, not the active readiness gates.