implementation-readiness ยท diff
git:20260704.611f52a to git:20260711.69cefd7
10 added, 7 removed. Audit A to A.
---
name: implementation-readiness
description: "Verify BRD-lite, PRD, SRS/FRS, UX, and test prerequisites before implementation starts."
metadata:
triggers:
keywords:
- implementation readiness
- workflow
---
# Implementation Readiness Skill
> [!IMPORTANT]
> Verify BRD-lite, PRD, SRS/FRS, UX, and test prerequisites before implementation starts.
- Optional args: slug=<feature>, ticket=<id/url>, mode=interactive|autonomous|channel, channel=<id>, auto_continue=true|false.
+ Optional args: slug=<feature>, ticket=<id/url>, mode=interactive|autonomous|channel, channel=<id>, auto_continue=true|false, profile=business|hybrid|technical.
## Instructions
When the user asks to perform this workflow, execute the following steps:
# Implementation Readiness Workflow
Goal: Decide whether a planned change is ready for implementation or must return to planning/design.
## Steps
1. Load artifacts:
- BRD-lite brief, PRD/story, SRS/FRS notes, UX/design links, implementation plan, test plan.
- Jira/GitHub/GitLab/ADO/Figma/Confluence MCP context when configured; otherwise use exported docs or local files.
2. Check readiness:
- BRD-lite has business goal, stakeholder, AS-IS to TO-BE, and measurable success metric.
- ACs atomic, testable, scoped by platform/market/role where relevant.
- PRD has stable requirement IDs, AC IDs, owner, priority, status, and last-updated note.
- SRS/FRS identifies touched modules, API/data/interface changes, migrations, permissions, failure modes, and NFR thresholds.
- Requirement trace is complete: BRD objective -> PRD requirement -> SRS/FRS contract -> test lane.
- UX/design states cover loading, empty, error, permission, and responsive/mobile cases when UI changes.
- Test strategy maps ACs to unit, integration, E2E/mobile, security, and Zephyr/manual coverage.
- Tool prerequisites known: credentials, environments, feature flags, test data, MCP availability.
3. Decide:
- READY: BA/PM/SRS/test prerequisites are present and implementation can start.
- BLOCKED: missing artifact, owner, unclear AC, missing design/architecture, unavailable environment, or unresolved risk.
- PARTIAL: only named slices can start; blocked slices have explicit owner/input.
4. Route:
- For autonomous/channel mode, return READY only with named slices, owners, verification lanes, and available environments.
- READY -> `implement-feature` or `dev-fix`.
- BLOCKED -> `plan-feature` or `design-solution`.
- PARTIAL -> slice task list plus blockers.
+ ## Runtime Contract
+ - Use before implementation starts to gate go/no-go.
+ - Required inputs: BRD-lite/PRD/SRS artifacts plus a test strategy to check against.
+ - Return BLOCKED only when a required artifact, owner, AC, design, environment, or risk is unresolved.
+ ## Handoff Payload
+ - `slug`, verdict (READY/BLOCKED/PARTIAL), ready slices, blocking gaps, outcome report, next workflow.
+ ## Blocking Questions
+ - Ask max 3 at a time with a recommended default and 2-3 options.
+
## Output Template
```md
# Implementation Readiness
## Verdict
## Ready Slices
## Blocking Gaps
| Area | Gap | Owner/Input Needed |
| --- | --- | --- |
| [area] | [gap] | [owner/input] |
## Outcome Report
feature_status: design_ready | partially_implemented | blocked
requirement_trace: BRD-OBJ-* -> REQ-* -> AC-* -> SRS-* -> planned evidence
completed_evidence: []; missing_evidence: []; decision_needed: []; recommended_next_workflow: implement-feature | plan-feature | design-solution
-
- ## Runtime Contract
-
- ## Handoff Payload
-
- ## Blocking Questions
## Next Workflow
## Cost Report
Call `get_session_cost(workflow="implementation-readiness")` before final handoff.
```