jig21nesh/ai-sdlc
Research product ideas into intent and apply twenty reusable software delivery skills from any project.
Design or run evaluations of skill selection, delivery-agent task performance, or shipped AI behavior when introducing or changing prompts, skills, models, tools, or agent workflows. Use for baseline comparisons and regressions, not as a substitute for ordinary software tests.
Implement an authorized, bounded software change using its accepted intent, repository conventions and meaningful checks; return the reviewable patch and actual verification evidence.
Assess a consequential architecture, integration or migration choice using repository evidence, tradeoffs, trust boundaries and a decision record. Use for material design uncertainty within a specification, not every routine edit.
Turn a rough product idea, user problem, ticket or incident into an intent brief, researching competitors, alternatives or feasibility when needed. Use to explore what to build before specification; implementation planning belongs to ai-sdlc-plan.
Set or assess the operating agreement for AI-assisted delivery: ownership, policy sources, data/tool boundaries, artifact authority and a bounded adoption pilot. Use for onboarding or a material workflow change.
Design, inspect and test runtime boundaries for agent tools, build hooks or consequential-action approvals. Use when configuring or assessing an actual control, not to treat a prompt or profile as enforcement.
Convert measured delivery outcomes, incidents and repeated agent mistakes into a scoped process, context, skill or evaluation improvement, with a baseline comparison and regression evidence.
Investigate service health or an incident, execute only authorized bounded runbook actions, verify the resulting state and produce evidence-linked follow-up intent.
Coordinate an authorized delivery task when dependencies, multiple work owners, resumable handoffs, or independent verification need explicit orchestration. Use scoped sessions or subagents only when available and authorized; a simple single-owner edit does not require delegation.
Plan implementation of an accepted change: inspect the repository, choose an approach, map files and proof, and prepare bounded task handoffs. This is Build-phase planning; use discovery for initial intent.
Translate a specific owned policy into a reusable agent procedure with applicability, exceptions and behavioral cases. Use when creating or revising policy-derived skills, not to invent policy or approve a compliance exception.
Prepare CI delivery integration, a reviewable release, or an already authorized deployment, binding checks and decisions to the exact artifact, environment, effects and recovery conditions.
Inspect, create or maintain repository instructions and task context when agents need reliable commands, package boundaries, conventions or durable lessons. Use for context maintenance, not as a mandatory prelude to every code edit.
Plan and, when authorized, execute retirement of software, an AI workflow or a model integration, accounting for consumers, retained data, jobs, credentials and closure evidence.
Review an actual change or pull request against requirements and policy, or repair supported review findings when fixes are requested. Produce revision-bound findings, recheck evidence and owner disposition; a review-only request does not authorize edits, posting, merge or deployment.
Independently assess a specific software change, skill bundle or agent workflow for reproducible security risks when security review is requested or required by its risk. Use for candidate assessment, not recurring scan administration or penetration-test authorization.
Plan authorized recurring security scans or triage dated scanner findings into verified, deduplicated work with coverage and follow-up evidence. Use for scan programs and scan-result intake, not as penetration-test permission or a replacement for a targeted independent review.
Produce or reconcile a combined requirements and design specification from an intent, including acceptance scenarios, policy conflicts and traceability. Use before implementation planning or when accepted behavior changes.
Evaluate an interface, documentation, skill bundle, or agent handoff through realistic tasks when usability assessment is requested or required. Report observed friction, accessibility coverage and recovery, and recheck authorized fixes; do not substitute generated feedback for user research.
Verify a specific software candidate against accepted behavior and risk, assess whether its tests are meaningful, and separate software evidence from delivery-agent and product-AI evaluations.