AI-Assisted SDLC PlaybookSmall prompts. Verified work.

Public guide only. Paste prompts into an approved AI tool with approved context. This site never creates tickets, runs code or sends data to an AI. Sharing rules

Your first story

New to AI-assisted work? Follow six steps with a fictional task app. Already comfortable? Go to the SDLC flow, jump to Develop one story, or generate a review markdown before tickets.

1. Choose where to work

Ask your lead: “Which AI tool and model are approved, which repository and branch should I use, and what checks must pass?” Use the project’s existing setup instructions.

  • Editor or coding agent with an approved local project: paste prompts in its chat. Confirm it has the correct project open and can inspect files. Restrict permissions to the task; review proposed edits and commands.
  • Browser chat without project access: paste only approved text for planning or explanation. It cannot inspect your local files, run tests or verify your branch unless an approved integration gives it that access. Ask it what context it needs; do not upload a whole repository.

You do not need a ticket system, code host or MCP integration to practice this fictional example.

Next: read the example below. Do not ask the AI to implement until requirements and the plan are clear.

2. Plan the story with a filled prompt

Story: As a task-app user, I need a valid title before saving a task.

Acceptance criteria (the agreed conditions for completion): reject empty or whitespace-only titles; allow 1–100 characters after trimming spaces at the ends; reject 101 or more; show a helpful validation error. These are synthetic requirements, not a recommendation for every product.

Normally you replace [STORY] and [AC] in a template. Here they are already filled. Paste this in your approved AI chat:

Plan only; do not edit code or create files.
Story: A task-app user must enter a valid title before saving a task.
Approved acceptance criteria for this fictional example:
- Reject empty or whitespace-only titles.
- Trim spaces at the ends; allow 1–100 characters after trimming.
- Reject 101 or more characters and show a helpful validation error.
Use only approved context. If you have repository access, inspect relevant form, validation and test files and cite their paths. Otherwise state that existing patterns are unknown and ask for the minimum approved context; do not invent file paths or test results.
List unanswered questions, the smallest independently testable changes, how to verify each, and what is outside scope. Flag how Unicode characters are counted as a question for the ticket owner. Do not silently decide it.

Next: compare the response with step 3 before allowing edits.

3. Check the answer and resolve questions

Illustrative response shape — not a real repository inspection

  • Known: blank titles fail, end spaces are trimmed, the length limit is 100.
  • Unknown: existing validation and test commands until code is inspected; the product’s definition of a Unicode character.
  • Possible first slice: implement and test rejection of empty and whitespace-only titles using the existing validation pattern.
  • Later slices: enforce the agreed length rule, then verify the form’s error display and saving behavior. Actual slice boundaries depend on the inspected code.
  • Outside scope: redesigning the task form, adding accounts, or changing unrelated fields.

A slice is one small change you can check on its own. If a proposed slice is too large or unclear, ask the AI to split or explain it, then ask your lead to review if you still cannot judge it.

Unclear requirement? Ask the ticket owner, record the answer in the approved work item, and update the plan. Do not accept an AI guess as an approved requirement.

Next: choose one understood, approved slice. If you cannot explain what will change and how you will check it, stop here and ask for help.

4. Implement one agreed change

Use this only in an approved coding environment with project access. The example handles blank titles; it does not claim to finish the whole story.

Implement only this agreed slice in the task app: reject empty and whitespace-only titles using the existing validation behavior.
First confirm the repository, branch and uncommitted changes. Preserve unrelated work. Inspect the relevant validation code and tests before editing.
Add a regression test for each rejected input and check that a normal title still passes. Use the project’s documented test commands. If a command or required access is unknown, ask; do not invent it.
Do not change length validation or unrelated features in this slice. Stop if the slice requires broader changes and explain why.
Report changed files, commands actually run and their observed results, remaining acceptance criteria, and one proposed next action. Do not mark the whole story complete.

Next: inspect what changed. A confident AI answer is not proof that the change works.

5. Verify the result yourself

  1. Find the required checks: read the project README, contribution guide and existing CI configuration. Ask your lead if you cannot identify the commands.
  2. Review the diff: inspect the changed lines in your editor’s source-control view. They should match the agreed slice.
  3. Run the checks: record the command and actual outcome. “Not run” is a valid status; “passed” without execution is not.
  4. Try the behavior: for the blank-title slice, try empty input, spaces only, and a normal title. For the full story, also check the agreed 100/101-character boundary, trimming, and visible errors.
  5. Handle failures: keep the exact error privately, ask for investigation before another edit, and change strategy after two unsuccessful attempts. Do not remove a failing test just to get a pass.

Next: repeat steps 3–5 for the remaining approved slices, then request review.

6. Request review and hand off honestly

Ask your team’s reviewer to assess the change in the approved code host. AI review is additional help; it does not replace required human review or authorize merging or deployment.

These checkboxes are a personal reminder for this visit. They reset on reload and do not update your ticket or approve delivery.

Review the current diff for the agreed task-title story: reject blank titles, trim end spaces, allow 1–100 characters by the agreed counting rule, reject longer titles and show a helpful error.
Do not edit code. Check each criterion against actual code and test evidence. List actionable issues with file and line references, and identify missing checks. Distinguish observed test results from tests not run. If you cannot access the diff or repository, ask for minimum approved context instead of claiming a review.

You are ready for real work. Open Develop one story in the SDLC flow, replace placeholders with your approved ticket, and keep using plan → slice → verify. If work must pause, use the handoff guide.

Where are you starting?

Choose what you already have. Start there, then work through one stage at a time.

AI-Assisted SDLC Playbook — a free, tool-agnostic AI software development lifecycle method: nine stages of copyable prompts from vague requirements to verified release, including review-markdown before tickets and optional second-AI critique.

Vague requirement? Start with a review markdown

Before creating tickets, generate a private markdown (clarify → epic → design → stories), then ask a different approved AI to critique it. Humans adapt the feedback, then create tickets only for the approved set. Full guide












Replace placeholders in your approved AI tool. Keep real project context there. New to AI-assisted work?


Need to pause or resume work?







A little guidance, when you need it


Tools, workflow and boundaries. Open only what you need. Look up a term.



Choose and prepare your AI tool


Use the tool and model your team approves. Ask your lead before sending any real work: “Which tool may I use, what information may I share, and which project setup instructions should I follow?” The AI-Assisted SDLC Playbook does not approve a provider for your client.


Two ways to use the prompts


    

  • Browser chat: useful for discussing approved requirements or explaining permitted snippets. Without an approved connection, it cannot inspect your local repository, verify a branch or run tests. Paste the prompt in its chat and supply only the minimum approved context it asks for.
    • 

  • Editor or coding agent: open the approved local project and use the tool’s chat. Confirm the correct workspace and branch, follow the project’s setup guide, and check that relevant files are accessible. Review proposed edits and commands before accepting them under your team’s policy.
    • 



You do not need to install a new tool just for this guide. Existing approved editors or agents can use these prompts. This guide is free to read; tool subscriptions, model access and usage limits vary.


Before allowing edits


    

  1. Identify the repository and branch with your lead if you are unsure. Preserve existing work that belongs to someone else.
    2. 

  2. Read the project README or contribution guide for setup and test commands. Ask for help if the environment does not run.
    3. 

  3. Choose your current SDLC stage. At development, start with “Plan this story”. Resolve questions and understand the proposed first slice before implementation.
    4. 

  4. Keep file access and permissions limited to what the task needs. Do not hand over credentials or copy a whole repository into a chat just to get started.
    5. 



Optional integrations


MCP means Model Context Protocol: a way to connect AI tools to systems or data. It is not required for this workflow. Add integrations only when your team approves the access and data handling. A connection to your ticket system or code host is not automatically configured by this website. Deterministic tools such as the project’s test runner, formatter and source-control view remain the evidence for actual behavior and changes.


Companion: ticket → PR agent checklist


After stories exist as real tickets, teams can use [Ticket Flow](https://smg99.github.io/ticket-flow/) ([repo](https://github.com/smg99/ticket-flow)) — Cursor rules/skills + thin scripts — so agents follow a fixed path: fetch issue → branch → implement → tests → human confirm → commit/PR → optional chat notify. That companion is orchestration for development workspaces; this playbook stays the stage prompts and gates through release.




Generate a review markdown before tickets


Prefer a private review markdown over creating tickets immediately. Humans review the draft epic and stories, answer blocking questions, then create tickets only for the approved set.


This keeps client context out of the public playbook site. Store the markdown only in an approved private location.


On the SDLC home view, the generate prompt and a second-pass review prompt are visible with copy buttons. Use those first; this guide explains the full loop.


When to use it


    

  • You received vague or meeting-note requirements and need an epic plus stories to review.
    • 

  • You want questions and assumptions visible before any ticket system entry.
    • 

  • You are practicing the SDLC stages without writing tickets yet.
    • 



How it works


    

  1. On SDLC flow home, copy the generate prompt into an approved AI tool.
    2. 

  2. Paste your approved requirement and optional target repos.
    3. 

  3. Save the model’s markdown privately.
    4. 

  4. Copy the critique prompt into a different approved AI tool (or a fresh session) and paste that markdown for a second-pass review.
    5. 

  5. Adapt useful feedback; answer P0 questions with the owner.
    6. 

  6. Run Review & create stories in readiness-only mode (validate drafts; still do not invent ticket IDs).
    7. 

  7. Only after human approval, create tickets through approved access.
    8. 



Reusable generate prompt


Copy from the SDLC home panel, or use:


You are running the AI-Assisted SDLC Playbook offline as a review workflow.

Source of truth for stage prompts:
https://smg99.github.io/engineering-ai-playbook/
(or local engineering-ai-playbook/assets/flow-data.js)

Goal:
Produce ONE markdown file for human review. Do NOT create tickets.
Do NOT invent ticket IDs or claim approval.

Process — run these stages in order using the EXACT playbook prompt text for each:
1) Clarify requirements
2) Define the epic
3) Design the approach
4) Draft stories
5) Review & create stories in READINESS-ONLY mode: validate drafts for clarity,
   ownership, testability and gaps. Still do NOT create tickets or invent IDs.

Markdown must include:
- The client requirement enclosed verbatim in a fenced code block
- For each stage: the exact playbook prompt used, then your output
- Clear labels: Known facts / Assumptions / Unknowns / Proposals / DRAFT
- Blocking questions for the owner (P0/P1/P2)
- One draft epic
- For stateful domains (queues, workflows, approvals): explicit entity states
  and allowed transitions before story AC that depend on them
- User stories with: summary, need/value, scope/exclusions, dependencies,
  numbered Given/When/Then AC, negative/boundary cases, QA mapped to AC,
  test requirements, definition of done
- One owning story per observable behavior; do not test later-story behavior
  inside earlier foundation stories
- Full story detail only for the proposed MVP set; label the rest as backlog themes
  (title + intent only) until expanded
- Cite the team’s agreed coverage gate for new/changed code; if unknown, ask.
  Do not invent a gate. Prefer 100% only when that is the team’s stated gate.
- If timeline conflicts with scope: propose an MVP cut vs stretch
- A short "Playbook feedback" section: what worked / what to improve

Rules from the playbook:
- Separate facts from assumptions; do not invent answers
- If blocked, continue with a provisional brief labeled as assumptions
- Prefer existing system patterns; call out false-friend modules if found
- Keep real client context out of the public playbook repo
- No code changes unless I explicitly ask

Optional context (only if provided):
- Target repos/paths: …
- Team conventions / coverage gate: …

Client requirement:
"""
[PASTE REQUIREMENT HERE]
"""


Reusable critique prompt (second AI)


After the markdown exists, paste it into a different approved model or a fresh session:


Review this AI-Assisted SDLC Playbook review-markdown as a critical tech lead.
Do NOT rewrite the whole document unless asked. Do NOT create tickets.

Return:
1) Verdict: discovery-ready / needs revision / not ready
2) High/medium findings table: issue, why it matters, what to change
3) Missing state/transition or operating-model gaps
4) Story-ownership leaks (early stories testing later capabilities)
5) Vague AC that lack pass/fail thresholds
6) Whether stretch items are wrongly treated as full stories
7) Whether coverage gate is explicit or still assumed
8) The smallest revision checklist before readiness-only re-validation

Document to review:
"""
[PASTE REVIEW MARKDOWN HERE]
"""


After both passes


    

  • Answer P0 questions or explicitly accept assumptions.
    • 

  • Cut stretch themes if the timeline cannot hold them.
    • 

  • Create tickets only for the approved epic and MVP stories.
    • 

  • Keep using Develop one story for implementation; the markdown is planning evidence, not completion proof.
    • 





Protect client information


The AI-Assisted SDLC Playbook repository and website are public. Use fictional examples here. Real tickets, source code, screenshots, private logs, architecture, credentials and customer records must stay in policy-approved private locations. Do not put them in this repository’s issues, pull requests or commit history.


Where should I put my real context?


Keep the work item in the team’s approved ticket system and application code in its approved code host. Use real context in an AI tool only when the client and organization explicitly permit that provider and the data being shared. Having a paid account does not establish permission.


This website only displays and copies text. It does not connect to your ticket system, code host, repository or an AI provider, and it has no form for submitting real ticket details. Clipboard contents are handled by your browser; you choose whether and where to paste them.


Safe practice example


Practice with “a fictional task app that requires a title” rather than a real customer’s ticket, screenshots or code. Replace names and sensitive values with placeholders only when your team confirms the remaining context is safe; anonymizing a name alone may not remove proprietary information.


If you are unsure


Stop and ask your lead what may be shared and where. Never paste passwords, tokens or production records into a prompt. Review proposed tool access rather than accepting it automatically. Keep project plans, test evidence and handoff notes in approved private locations. Follow your organization’s incident process if something restricted is shared accidentally.




From vague requirement to verified release


This is the execution guide for the **AI-Assisted SDLC Playbook**: use approved AI tools stage-by-stage from clarification through release, with human gates and verified evidence.


Choose where your work is now in SDLC flow. You can start with vague requirements, an existing epic, or an epic and stories. Stage selection is navigation; this website does not track or approve real work.


For a new vague requirement, use the visible review-markdown panel on the SDLC home view: generate a private markdown (clarify → epic → design → stories → readiness-only check), then ask a different approved AI to critique it. Adapt useful feedback with your owner before creating tickets. Details live in the Generate a review markdown before tickets guide.


Follow the nine stages


    

  1. Clarify requirements: separate facts from assumptions, identify users and outcomes, surface relevant non-functional needs, and resolve blocking questions with the owner.
    2. 

  2. Define the epic: agree scope, exclusions, success criteria, risks and dependencies before treating the epic as ready.
    3. 

  3. Design the approach: capture a lightweight design note—touchpoints, contracts, NFRs and risks—and get tech-lead or owner agreement before splitting work.
    4. 

  4. Draft stories: split the epic into small independently testable stories for your ticket system. Every story needs numbered acceptance criteria (AC), QA scenarios, dependencies, test requirements and a definition of done.
    5. 

  5. Review and create stories: have the owner approve the AC and confirm the project. Create tickets only through approved access with explicit authorization, or enter the approved drafts manually. Never invent ticket IDs or approval.
    6. 

  6. Develop one story: inspect the approved repository and current changes, plan small slices, then implement and verify one slice at a time. Finish the current story before starting another. Optional: in an agentic IDE, run the companion [Ticket Flow](https://smg99.github.io/ticket-flow/) checklist (fetch issue → branch → implement → tests → confirm → commit/PR) against the same story—this site still owns the stage prompts and gates.
    7. 

  7. Verify and review: check every AC against actual code and meaningful tests, verify coverage evidence and obtain required human review (including tech-lead review when your team requires it).
    8. 

  8. QA validation: test each AC and relevant boundary, negative and regression cases in the approved environment; add a short exploratory pass. Record observed results and QA sign-off. Return failed stories to development; choose the next ready story when appropriate.
    9. 

  9. Release and monitor: include only accepted stories in the release scope. Confirm deployment authorization, environment promotion, rollout and rollback readiness, then verify actual post-release smoke checks and monitoring through the existing team process.
    10. 



Coverage and acceptance criteria


Each story must state the project’s agreed coverage gate for new or changed application code (prefer 100% line, branch, function and statement when tooling supports it). State the actual gate if it differs. Report the existing repository baseline separately. Document measurement limitations and approved exclusions; do not silently weaken the target or exclude code to inflate coverage. Missing tooling, unrun tests or unverified coverage are blockers, never evidence of a pass.


Acceptance criteria describe observable outcomes QA can test, including relevant error and boundary behavior. Coverage measures execution; it does not establish that those outcomes are correct. QA must verify them separately.


Stop and ask for help


    

  • Requirements conflict or expected behavior is unknown: ask the ticket owner.
    • 

  • You cannot explain the plan or its checks: ask your lead or reviewer.
    • 

  • The AI requests credentials, broader access or unapproved data: stop and check policy.
    • 

  • Unexpected files change or broader work is needed: review scope before accepting edits.
    • 

  • Checks fail: keep actual error evidence privately and investigate. After two unsuccessful attempts, change strategy or ask a teammate. Never report a pass you did not observe.
    • 



Use the pause/resume prompts to checkpoint the current stage and story in an approved private location. Real tickets, code and evidence stay in approved private project systems.




Advanced: save context and hand off work


Learn the basic story workflow first. You do not need to switch providers or monitor percentages to complete the worked example.


Keep each request focused


Give the AI the current objective, approved acceptance criteria, relevant file paths, constraints and actual error evidence. Avoid pasting entire chat histories or repositories. Use the project’s compiler, tests, formatter and source-control tools for checks rather than asking the AI to guess their results. Shorter prompts are useful only if they preserve the context needed for correct work; this guide does not guarantee token savings.


When work must pause


Finish at a safe point, inspect the current changes, and record what is actually known. Store the following STATE note only in a policy-approved private location. STATE is simply a factual continuation note, not a special tool or public file requirement.


Work item: [approved private ID]
Branch: [current branch]
Last verified commit: [actual commit identifier]
Completed: [verified changes]
Current: [one unfinished slice]
Tests: [commands run and actual results; say not run where applicable]
Uncommitted files: [changed paths]
Blockers and unresolved questions: [facts]
Next action: [one specific action]


Use “Pause work” under “Need to pause or resume work?” to help summarize it. Use “Resume work” in the next approved session. The receiving tool must recheck the repository, branch, changed files and evidence before editing. If it lacks access, it should ask for minimum approved context rather than claiming verification.


Usage limits are provider-specific


Read your provider’s actual usage dashboard. Some providers do not expose a meaningful percentage, and reset windows differ. A rough optional checkpoint around 85–90% may be useful if that metric exists, but it is not a universal threshold. Pause safely when needed; switch providers only if your team approves both the destination and the context transfer. A free agent may still use a paid model. Never assume price or data handling from a tool’s label.







FAQ: AI-assisted SDLC


What is an AI-assisted SDLC playbook?


A reusable engineering method for using approved AI tools across the software development lifecycle—clarify, epic, design, stories, develop, verify, QA and release—with human exit gates and verified evidence instead of unverified AI output.


How do I use AI for vague requirements before creating tickets?


Use the review-markdown panel on this home view: generate a private markdown, ask a different approved AI to critique it, adapt feedback with the owner, then create tickets only for the approved set.


Is this tied to a specific AI vendor?


No. It is tool-agnostic. Paste prompts into whichever AI tool your team approves. This site never runs AI or sends your data to a provider.


Does this site create tickets or change code?


No. It only displays and copies prompt text. Tickets, code, PRs and CI stay in your approved private systems.




Glossary




Story / acceptance criteria (AC)
A small user need and the agreed conditions that prove it is met. Ask the ticket owner when those conditions are unclear.


Epic
A larger goal delivered through several stories. Most beginners can start with their assigned story.


Design note
A lightweight agreed approach covering touchpoints, contracts, NFRs and risks before stories are split.


Review markdown
A private draft that runs clarify → epic → design → stories for human review before anyone creates tickets.


Ticket system / code host
Where work items live (for example Jira, Linear or GitHub Issues) and where application code, PRs and CI live (for example Bitbucket, GitHub or GitLab).


Slice / scope
A slice is one independently checkable change. Scope is the boundary of what you have agreed to change.


Repository / branch / diff
The project’s tracked files, a line of work within it, and the changed lines you inspect before review.


Regression test / CI
A test that catches a bug returning. Continuous integration (CI) runs the project’s automated checks; it may not cover every requirement.


Checkpoint / handoff / STATE
A safe stopping point, the summary needed to continue, and a short factual note recording that state in an approved private location.


Agent / MCP
An agent can use permitted tools to act on work. Model Context Protocol (MCP) connects tools or data; it is optional and does not automatically grant approved access.


Tokens / context / quota
Tokens are pieces of text processed by a model. Context is the information it receives. Quota is your provider’s usage allowance; its measurement varies.