| name | docs-contract-sync |
| description | Synchronize implementation changes with framework/app docs contracts across API surfaces, behavior specs, and constraints. Use when code changes must be reflected in docs. |
Skill: docs-contract-sync
Trigger Signals
Use this skill when requests include:
- "update docs with changes"
- "docs drift"
- "implementation vs docs"
- "sync contracts"
Do Not Use When
- Request explicitly asks to avoid docs updates.
- Behavior/API is intentionally experimental and not yet contract-ready.
Required Inputs
- Code changes in scope.
- Relevant doc sets:
- framework docs (
docs/ai/framework/*)
- app docs (
docs/ai/apps/asyra-design/*)
Preflight
- Build list of changed code files.
- Map each changed area to contract type:
- API surface
- runtime behavior
- boundary/rule
- PRD/BDD behavior
- Find docs currently describing each contract.
Deterministic Procedure
- Update minimum required docs in same change.
- Remove or rewrite stale statements that conflict with code.
- Keep path references exact after file moves/renames.
- Keep cross-doc consistency (feature doc vs PRD vs API surfaces).
- Do not add future plan items unless explicitly requested.
Validation Matrix
- No known contradictions between implementation and touched docs.
- Referenced file paths exist.
- Behavior statements match current runtime behavior.
Required Output Format
Contract Changes Detected
Docs Updated
Validation
Deferred Drift
Guardrails
- Do not mention deprecated/old doc trees in new docs unless explicitly required.
- Avoid vague wording; prefer concrete behavior contracts.
- Local commits may close completed, validated steps/stages; never push unless
the user explicitly requests the remote operation. Follow
docs/ai/workflows/git-commit-push-policy.md.
Failure Policy
If behavior is still evolving:
- mark section as pending explicitly
- avoid pretending final behavior is settled