stack/skills/ms-sdlc/SKILL.md

name, description, disable-model-invocation

name	description	disable-model-invocation
ms-sdlc	Use for all software delivery planning, implementation, review, CI, release, deployment, acceptance, and completion decisions.	false

Mosaic SDLC

This skill defines the default software delivery lifecycle. Repository contracts and an explicit operator ruling may narrow it. Silence never widens authority or waives a gate.

Roles and separation

• The product lead owns priority, requirements, delivery status, and product acceptance.
• The conductor or orchestrator coordinates implementation, review, integration, and deployment.
• The assigned author owns source changes and test evidence.
• An independent reviewer verifies the exact candidate. An author never reviews their own change.
• The operator performs final user acceptance for user-facing work.
• Domain or intake owners retain their declared data, sourcing, and domain-acceptance responsibilities.

Do not absorb another role because its seat is unavailable. Restore the assigned seat or escalate.

Delivery sequence

Use these states in order. Report the narrow current state rather than calling intermediate work done.

1. Intake accepted. Record the user need, owner, priority, and authority boundary.
2. Requirements approved. Define acceptance criteria, non-scope, dependencies, protected operations, and rollback expectations.
3. Plan approved. Pin the baseline and exact plan. Resolve contradictions before implementation.
4. Implementation chartered. Name the author, reviewer, worktree or branch, issue, allowed paths, test obligations, and forbidden operations.
5. Implementation ready for review. The author supplies an exact clean candidate and reproducible test evidence.
6. Implementation approved. An independent reviewer verifies the exact candidate and all findings are closed or explicitly rejected by the proper authority.
7. PR in CI. Publish only through the approved repository workflow. Run every CI gate implemented on the trusted target branch.
8. Merged. Use the repository's approved merge strategy. Verify the merged tree corresponds to the reviewed candidate.
9. Post-merge verified. Require terminal-green post-merge CI and immutable artifact identity.
10. Deployment approved. Review the immutable deployment pin, environment delta, rollback target, and protected-operation boundary.
11. Deployed healthy. Verify GitOps or runtime convergence, workload health, exact artifact identity, and rollback readiness.
12. Product accepted. Verify the stated acceptance criteria with situational evidence in the target environment.
13. Ready for user test. Give the operator a short test script with expected results. Do not call the feature done.
14. User approved. The operator tests user-facing behavior and explicitly approves it.
15. Done. Update canonical status records only after every applicable gate above passes.

Planning requirements

A plan must state:

• the user-visible outcome and exact acceptance criteria;
• the trusted baseline and dependencies;
• author and independent reviewer roles;
• in-scope and excluded files or systems;
• automated, situational, accessibility, security, and hostile-control evidence appropriate to the change;
• CI coverage and any important checks that CI does not run;
• deployment, rollback, and user-test procedures;
• credential, schema, production-data, and irreversible-operation boundaries.

If a requirement is unsafe, contradictory, or materially larger than approved scope, stop. Return it to planning and independent review. A defect correction may stay within the existing charter only when it does not change the approved requirement or authority boundary.

Interrupted work

Never reset or adopt interrupted work automatically.

1. Preserve the worktree exactly as found.
2. Return it to the original author.
3. Have the author inspect the diff and explain its intent.
4. Reverify the baseline, charter, and candidate provenance.
5. Run focused checks before continuing.
6. Record whether the partial work was retained, replaced, or reverted and why.

Verification and CI

Documentation is not proof of its own claims. Every completion claim cites a reproducible command, file, immutable identifier, or live measurement.

Required verification includes:

• author tests for the changed behavior and relevant regressions;
• independent exact-candidate review;
• every CI gate configured on the trusted target branch;
• feature-specific checks that CI does not run, reproduced independently when practical;
• branch or PR CI, approved merge, and post-merge CI;
• immutable build and deployment identity;
• target-environment product evidence.

Do not imply that CI covers a check it does not execute. An important repeatable missing CI check may justify a separate scoped CI task. Do not smuggle CI expansion into unrelated feature work unless the approved plan includes it.

A failed, missing, or unverifiable gate stops the transition. Diagnose it. Never bypass or relabel it green.

Deployment and protected operations

Routine deployment may proceed without repeated operator approval only when standing authority explicitly permits it and all required gates pass.

At minimum require:

• independent exact-head approval;
• green branch or PR CI;
• approved merge and green post-merge CI;
• reviewed immutable artifact and deployment pin;
• deployment health and exact runtime identity;
• a tested or otherwise verified rollback target;
• no undeclared schema migration, credential operation, production-data mutation, or irreversible action.

Credentials, schema changes, production-data mutations, destructive actions, and operations outside the approved envelope require their declared approval. For bounded production acceptance, prepare one explicit envelope naming fixtures, allowed mutations, verification, cleanup, and rollback. Any action outside it needs new approval.

A later candidate may combine undeployed changes only when the integration order is explicit, evidence proves every included requirement, unrelated work is excluded, and rollback remains clear.

Product and user acceptance

Automated checks cannot establish all product behavior. Use a real browser, client, API, or runtime when the acceptance criterion concerns layout, interaction, accessibility, timing, integration, or deployment behavior.

Product acceptance confirms the implementation meets the approved criteria. It does not replace user acceptance.

For user-facing work:

1. Deploy the approved candidate.
2. Complete product acceptance and rollback verification.
3. Mark it ready for user test.
4. Give the operator exact steps and expected results.
5. Wait for explicit operator approval.
6. Mark it done only after approval.

Without operator testing, the user-facing outcome remains unverified. If user testing fails, record the exact observation, reproduce it, and send the correction through implementation, independent review, CI, deployment, and user testing again. Never patch production directly.

For work with no meaningful user-testable behavior, the operator may explicitly waive hands-on testing for that delivery. Never infer a waiver from silence.

Concurrency

One source-changing feature is the default. Parallel source work requires isolated worktrees, named authors and reviewers, non-overlapping authority, and an explicit integration order. Read-only investigation, planning, and acceptance preparation may proceed concurrently.

Status and communication

• Report meaningful milestones, decisions, failed gates, scope changes, and protected-operation requests.
• Keep routine worker transitions within orchestration channels.
• Keep repository and fleet status synchronized with verified evidence.
• Preserve another owner's substantive acceptance claims unless coordinated with that owner.
• Use precise labels such as implementation approved, PR in CI, merged, deployed, ready for user test, and done.

Definition of done

A change is done only when every applicable requirement, review, test, CI, merge, deployment, product-acceptance, rollback, documentation, and user-approval gate has passed. Missing evidence means not done.