Implementation ReadinessSAFE

A collection of Agent Skills Standard and Best Practice for Programming Languages, Frameworks that help our AI Agent follow best practies on frameworks and programming laguages

The instruction file, verbatim from the audited commit — this is the text the model reads, and the surface the audit's instruction layer examines. Quoted here so you can judge it without cloning anything.

---
name: implementation-readiness
description: "Verify BRD-lite, PRD, SRS/FRS, UX, and test prerequisites before implementation starts."
metadata:
  internal: true
  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, 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:
   - Load the task-linked approved brief/ticket, PRD/story or equivalent approved evidence, SRS/FRS when needed, UX/design evidence when relevant, implementation plan and test plan.
   - Do not require a separate filename when an approved task record supplies the necessary information. A matching record and stable slug are required; unrelated documents and working-tree changes are not authority or approval.

2. Check readiness:
   - Approved task record supplies outcome, constraints/non-goals, testable ACs, owner and approval; equivalent approved low-risk evidence suffices without separate BRD/PRD/SRS files. `approval: approved` passes; `pending` blocks; `assumed-autonomous` warns and blocks only when `snc_tier=high`. Sensitive trust-boundary changes still require applicable design/human floor.
   - ACs have one observable behavior per AC across happy, edge, and error paths, with necessary preconditions; truth tables for interacting conditions. Examine scope coverage and conflicts before issuing READY or PARTIAL; consequential conflicts block affected slices with consequence, owner, and required input without inventing business/error policy.
   - Available requirement/design evidence identifies affected modules and consequential API/data/interface/migration/permission/failure/NFR choices; unresolved sensitive or consequential choices route to technical design and human approval.
   - Requirement trace links business/product requirements to technical contracts and test lanes; review affected contracts, ACs, approvals and evidence for change impact without restarting unchanged decisions or inventing document detours.
   - UX/design evidence covers loading, empty, error, permission, responsive/mobile cases when UI changes.
   - Test strategy maps ACs to available unit, integration, E2E/mobile, security, Zephyr/manual lanes; record unavailable optional lanes as blockers on only affected slices.
   - Tool prerequisites known: credentials, environments, feature flags, test data, MCP availability. Schedulable delivery dependencies required; legitimate business or state loops are not delivery-dependency cycles, but unresolved behavioral, permission, environment, or scheduling prerequisites block affected slices.
3. Decide:
   - READY: approved evidence, owner, ACs, required design/approval and test prerequisites permit the named slice(s) to start.
   - BLOCKED: required authority/approval, owner, unclear AC, consequential design, environment, or risk remains unresolved; do not recommend unconditional implementation.
   - PARTIAL: name each independently bounded ready slice with owner, approval and verification lane; name each blocked slice with its owner, dependency/input and reason. Only ready slices may flow downstream.
4. Route:
   - For autonomous/channel mode, return READY only with named slices, owners, verification lanes, approval and available required environments.
   - READY -> `implement-feature` or `dev-fix`.
   - BLOCKED -> `plan-feature` or `design-solution`; do not emit an unconditional implementation recommendation.
   - PARTIAL -> send only explicitly ready slices downstream with their blockers and owners; downstream execution cannot absorb blocked slices or claim their activation.
   - Write the run record to `artifacts/runs/[slug]/[compactISO]-implementation-readiness.json` when file writes are allowed.

## Runtime Contract
- Use before implementation starts to gate go/no-go.
- Required inputs: a matching approved task record/ticket or equivalent evidence, owner, testable ACs and the design/test prerequisites applicable to each proposed slice. Separate BRD/PRD/SRS filenames are not required when the task record carries equivalent information.
## 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
{schema_version: 1, run_id: "[run-id]", slug: "[slug]", workflow: implementation-readiness, feature_status: design_ready, started_at: "[timestamp]", completed_at: "[timestamp]", requirement_trace: {brd_objectives: [], requirements: [], acceptance_criteria: [], srs: []}, completed_evidence: [], missing_evidence: [], decision_needed: [], recommended_next_workflow: implement-feature, cost: {source: unavailable}, agent: {identity: "[agent-identity]", model: "[model]"}}

## Next Workflow

## Cost Report
Call `get_session_cost(workflow="implementation-readiness")` before final handoff.
```

SAFEgrade B · trust 89/100 Nothing in the source contradicts what it says it does. Grade A is reserved for packages that have also passed the behavioural sandbox.

What the source does

Filesystem

none-observed

Network

none-observed

Shell

none-observed

Dependencies

pinned

Secrets in source

none-found

Findings (0)

No findings outside the package's declared scope.

Gates applied: no_behavioural_pass.