AI-Native SDLC with Ultrapowers

The AI-Native SDLC playbook describes six connected stages: Plan, Design, Build, Test, Deploy and Maintain. This article maps that model to Ultrapowers, a skills-based workflow for coding agents. It shows how one ticket moves through the system, where a person must decide, and which parts of the lifecycle still require other tooling.

Ultrapowers standardizes project setup and ticket-driven development around reusable skills, versioned artifacts, tests and review gates. This walkthrough follows the workflow documented in Ultrapowers 2.2.0. Check the repository and release notes for the version you have installed and any command changes. The introduction to Ultrapowers explains the design; this article focuses on the workflow.

How the six stages map to Ultrapowers

Two supporting skills deserve special distinction. requesting-code-review checks implementation work, while task-review combines whole-ticket code review, the vulnerability hunt and QA into a single verdict. vulnerability-hunt and qa-specialist are beta features. Their reports support a human decision; they are not a guarantee of defect-free or secure software.

Ultrapowers covers much of planning through review and branch integration. It does not provide an evaluation runner for CI, an agent-operated deployment pipeline, or a metrics and anomaly-detection system. Creating an evals/ folder or recording a stage log is not the same as running evaluations or measuring delivery outcomes.

One ticket, end to end

The example uses a fictional GitHub issue, GH-web-7, in a repository called web. The ticket is illustrative; the commands are the workflow’s commands. Follow the current repository documentation if a command or version has changed.

1. Set up the project

/ultrapowers:init

Init identifies whether the project needs a new scaffold, a join, an upgrade, a repair or a read-only check. It prepares a dry run showing the files and configuration it intends to create or change. Review that list and explicitly approve it before anything is written. The scaffold includes a shared AGENTS.md, agent-specific imports where supported, knowledge folders, MCP configuration and repository hygiene.

To inspect the setup later without writing changes, use /ultrapowers:init check. Read the output before choosing an upgrade or repair.

2. Create a ticket brief

/ultrapowers:new-task GH-web-7

The skill fetches the ticket from its configured source, creates the task, spec, plan and review folders, and writes a brief that captures context, readiness, completion criteria and related documentation. It keeps the source ticket for traceability. A fetch failure or a detected secret stops the process rather than creating a guessed brief. Review the brief against the issue before moving on.

3. Ground and approve the design

/ultrapowers:brainstorm-task GH-web-7

The skill reads the brief, confirms which repositories are in scope, examines relevant code and records what it used as evidence. It then asks focused questions and drafts the spec. Review the assumptions, alternatives and decision record. Approve or revise the spec before planning; do not let the agent quietly fill important gaps with guesses.

4. Write and approve the plan

/ultrapowers:writing-plans

The plan breaks the approved spec into small, testable tasks with file paths, interfaces, assertions and verification commands. Review the plan and choose how to execute it. If implementation materially changes the approach or scope, return to the plan rather than treating the original approval as permanent.

5. Build with test-first feedback

Choose one execution mode:

/ultrapowers:subagent-driven-development

or

/ultrapowers:executing-plans

Subagent-driven development uses a fresh agent for each task and reviews the result between tasks. Executing-plans carries out the plan in the current session and reviews the branch at the end. Both use the test-driven development workflow: write a failing test, confirm it fails for the expected reason, implement the smallest change, then rerun verification.

When parallel work is useful, using-git-worktrees isolates branches and working directories. Use it only when the work is genuinely independent and the baseline is understood. More parallel sessions can increase the review burden, so scale concurrency to the team’s ability to verify results.

6. Run QA and the whole-ticket review

For a configured application, you can run the QA gate directly:

/ultrapowers:qa-specialist GH-web-7

The beta QA specialist checks the running app through seven configured lanes: browser UI, logs, API, database, observability, test suites and content. It writes reviews/GH-web-7/QA-REPORT.md with a verdict. Read the report and its preconditions; an incomplete run is not a pass.

The whole-ticket review combines code review for each repository in scope, a vulnerability hunt, and the QA gate:

/ultrapowers:task-review GH-web-7

It writes reviews/GH-web-7/TASK-REVIEW.md and, where applicable, a security report. The vulnerability hunt is beta and uses the audit tools installed in your environment; it does not fix findings. A verifier attempts to refute higher-severity findings, but this does not guarantee that every vulnerability will be found or that the report is complete. Use --post only when you want the reports posted to the ticket and pull request.

A QA run performed by itself refreshes the QA report, not the whole-ticket verdict. Re-run task-review after a fix so the final verdict reflects the current change.

7. Finish the branch

/ultrapowers:finishing-a-development-branch

The skill runs verification and checks whether the whole-ticket review is present and current. If the verdict is missing or stale, it requests a fresh review before presenting the integration choices. You choose to merge locally, open a pull request or keep the branch. A FAIL or BLOCKED verdict results in a draft pull request rather than a normal ready-for-review one. The final integration decision remains yours.

At any point, /ultrapowers:task GH-web-7 reports the ticket’s artifacts, branches and next step without starting new work. team-memory can preserve verified, durable lessons in .agents/memory/ so they can be reused by later sessions and developers.

Optional: run the middle with autopilot

/ultrapowers:autopilot GH-web-7 --mode gated

Autopilot moves the workflow’s approval points to the ticket tracker. In gated mode, the run pauses for a human to approve the spec-and-plan packet, then creates pull requests for review. The engine records stages and handles tracker actions; the agent is not meant to bypass the gates or merge the result.

Be precise about maturity: the documented live path for this version is Claude Code with GitHub and one repository in gated mode. The watcher and full mode are beta, and the QA stage inside an autopilot run has not been verified live in the version described here. Check the repository’s current acceptance notes before relying on a mode in production. Start with the manual workflow if you have not validated the integration in your environment.

Skill pipelines

These compact pipelines summarize the core skills documented in the 2.2.0 repository snapshot reviewed for this article. They describe the usual flow, not a substitute for each skill’s instructions. → means next step, ↻ means repeat or iterate, and ◇ marks a decision or gate.

Session and planning

• using-ultrapowers: session starts → identify the applicable skill → invoke it before acting.
• init: detect setup state → dry run → ◇ explicit approval → write scaffold; check mode is read-only.
• new-task: fetch ticket → validate source → create brief and folders → commit → brainstorm.
• brainstorm-task: read brief → ◇ confirm repository scope → inspect code → draft spec → ◇ approve/revise → commit.
• brainstorming: classify the work → ◇ approve approach → bounded work builds; architectural work produces a spec → ◇ approve spec.
• writing-plans: read spec → break into testable tasks → self-review → ◇ approve plan and execution mode.

Build and debug

• using-git-worktrees: detect existing isolation → ◇ consent → create worktree → setup and baseline checks.
• test-driven-development: failing test → confirm failure → minimal implementation → passing test → refactor ↻.
• subagent-driven-development: one agent per task → task review ↻ fixes → whole-branch review → integration choice.
• executing-plans: execute each planned task → check expected result ↻ debug mismatch → branch review → integration choice.
• dispatching-parallel-agents: group independent problems → scope agents → parallel work → reconcile conflicts → run full checks.
• systematic-debugging: investigate root cause → test a hypothesis ↻ → failing regression test → fix → verify; reconsider architecture after repeated failures.
• verification-before-completion: identify proof command → run it fresh → inspect output and exit code → claim only what the evidence supports.

Review and integration

• requesting-code-review: capture base/head → dispatch focused review → assess findings → fix Critical and Important issues.
• receiving-code-review: read finding → verify against code → clarify or challenge if needed → fix one item ↻ test each fix.
• task-review: validate scope → code review per repository → vulnerability hunt → QA → one verdict → optionally post reports.
• vulnerability-hunt (beta): confirm scope → parallel audit lanes → verify higher-severity findings → security report → optionally post.
• qa-specialist (beta): preflight → verify configuration → run/resume checks → collect evidence → triage → QA report and verdict.
• finishing-a-development-branch: run checks → validate current task-review verdict → ◇ merge, PR or keep → cleanup after local merge.

Knowledge, skills and automation

• team-memory: check whether a fact is durable and safe → save and index → prune if needed → lint and commit.
• writing-skills: baseline scenario → minimal skill → rerun scenario ↻ close loopholes → commit and deploy.
• diagnosing-ultrapowers: intake → locate session evidence → analyze transcripts → report cited findings → ◇ issue or bundle only with approval.
• task: read ticket artifacts → report status, completed work and next step; no work is started.
• autopilot: engine selects stage → agent performs the stage → engine records result ↻ → tracker gate → pull requests → human review and merge.

What remains outside the plugin

Ultrapowers is a workflow layer, not the entire delivery platform. The current version described here does not provide:

• A CI evaluation runner. The evals/ folder can hold evaluation artifacts, but running a suite and gating configuration changes needs other tooling.
• An agent deployment pipeline. Autopilot handles ticket stages and pull-request creation; it is not a production deployment agent.
• Operational metrics or anomaly detection. Stage logs record workflow events, not DORA performance or production health.
• A complete security boundary. Hooks and guardrails restrict agent behavior in supported contexts, but pattern-based hooks are not a sandbox. Use operating-system isolation, least-privilege credentials, repository protections and environment controls for guarantees.
• Guaranteed QA or security coverage. Results depend on configuration, available tools, application access and the scope of each run. Read the evidence and limitations, not only the verdict.

The companion playbook explains how to add evaluations, CI/CD controls and operational feedback around these gaps. The guiding distinction is the same: a skill gives an agent guidance; enforceable policy belongs in controls the agent cannot simply choose to ignore.

Where to start

1. Install Ultrapowers using the current instructions in the repository README.
2. Run /ultrapowers:init and review the dry run before approving it.
3. Choose one small ticket and follow the manual workflow through the spec, plan, tests and review.
4. Inspect the reports and verification output yourself before deciding whether to merge.
5. Consider autopilot only after you have validated its behavior with your tracker, repositories and guardrails.

The Ultrapowers first reviewed pull request tutorial gives a hands-on introduction. For the broader lifecycle and practices that Ultrapowers does not implement, return to The AI-Native SDLC: A Developer’s Playbook.