-
Notifications
You must be signed in to change notification settings - Fork 0
Getting Started
This walkthrough shows the smallest useful way to use 8-habit-ai-dev: define the work, make the architecture decision explicit, implement with context, review before commit, and plan deployment before production.
Tip
Use a real small feature. The workflow is clearer when the output matters.
/requirements I need to add a rate limiter to our /api/search endpoint
Expected output: a short PRD with purpose, users, scope, out-of-scope items, success criteria, and Definition of Done.
Human checkpoint: correct the intent before any code is written.
/design
Expected output: at least two viable options with trade-offs for important decisions. The AI proposes; the human chooses.
Use an ADR when the decision affects architecture, public API, persistent data, security, or more than a small local change.
/breakdown
Expected output: atomic tasks with dependencies, priorities, and scope boundaries. Tasks should be small enough to review and test independently.
/build-brief
Expected output: a task brief based on existing code, local patterns, edge cases, and files likely to change.
Only implement after the agent has read the relevant code.
/review-ai
Expected output: findings ordered by severity, with concrete fixes. This is the default review step for AI-generated work.
Add focused checks when needed:
-
/security-checkfor auth, secrets, user input, dependencies, config, or infrastructure changes. -
/cross-verifyfor larger plans or pre-PR confidence. -
/scrutinizewhen the question is whether the change should exist at all.
/deploy-guide production
Expected output: staging steps, production steps, rollback commands, verification, and post-deploy checks.
For provider-managed canaries or capacity changes, the guide also asks you to reconcile the planned target with the provider-selected target before calling the change complete.
/monitor-setup
/reflect
Expected output: monitoring gaps closed, runbook updates identified, and a short lesson captured for future work.
Small, obvious fixes usually do not need every step. They still need /review-ai, and production-impacting changes still need /deploy-guide.
See Workflow Overview for skip guidance.
Source of truth: this wiki is generated from docs/wiki/. Edits made through the GitHub Wiki web UI may be overwritten by the next sync. To change a page, open a PR against the repository source file.
Repository · Issues · README · License
Workflow discipline for AI-assisted development
Start
Workflow
- Overview
- 0 · Research
- 1 · Requirements
- 2 · Design
- 3 · Breakdown
- 4 · Build Brief
- 5 · Review AI
- 6 · Deploy Guide
- 7 · Monitor Setup
Operations
Reference
- Habits Reference
- Maturity Model
- Architecture
- Limitations
- Vibe Coding vs Structured
- Harness Engineering
Project