Review .NET changes for bugs, regressions, architectural drift, missing tests, incorrect async or disposal behavior, and platform-specific pitfalls before you approve or merge…
MCAF: Feature Spec
Apply MCAF feature-spec guidance to create or update a feature spec under `docs/Features/` with business rules, user flows, system behaviour, verification, and Definition of Done. Use when the user asks for a feature spec, executable requirements, acceptance criteria, behaviour documentation, or a pre-implementation plan for non-trivial behaviour changes.
Trigger On
- add or change non-trivial behaviour
- behaviour is under-specified and engineers are guessing
- tests need a stable behavioural source of truth
Workflow
- Define scope first: in scope, out of scope, boundaries touched.
- If the feature doc is missing, scaffold from
references/feature-template.md. - Keep the spec executable:
- numbered rules - main flow - edge and failure flows - system behaviour - verification steps - Definition of Done
- Make the spec concrete enough that tests can be written without guessing.
- If the feature creates a new dependency, boundary, or major policy shift, update an ADR too.
Deliver
docs/Features/feature-name.md- a feature spec that engineers and agents can implement directly
Validate
- rules are testable, not aspirational
- edge cases are captured where they matter
- verification steps match the intended behaviour
- the doc can drive implementation without hidden tribal knowledge
Load References
- use
references/feature-template.mdonly for scaffolding
Related skills
Adopt MCAF governance in a .NET repository with the right AGENTS.md layout, repo-native docs, skill installation, verification rules, and non-trivial task workflow.
Apply MCAF agile-delivery guidance for backlog quality, roles, ceremonies, and engineering feedback.