Quick DevSAFE
The Agent Harness for AI-Human Collaboration, inspired by the AI-DLC (AI-Driven Development Lifecycle)
Overview
The Agent Harness for AI-Human Collaboration, inspired by the AI-DLC (AI-Driven Development Lifecycle)
3bb5b08404b5OBSERVED · 2026-10-12Host compatibility
What the documentation claims. We have not run a compatibility test.
| Host | Status | Notes |
|---|---|---|
| openclaw | mentioned |
What it tells the agent
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: quick-dev
description: Quick Task workflow — skip Idea→Proposal, create tasks directly, execute, and verify.
license: AGPL-3.0
metadata:
author: chorus
version: "0.22.1"
category: project-management
mcp_server: chorus
---
# Quick Dev Skill
Skip the full AI-DLC pipeline (Idea → Elaboration → Proposal → Approval) and create tasks directly. Ideal for small, well-understood work. The goal is for agents to **autonomously record their development work and verify task completion** through structured acceptance criteria.
> **Tool namespace:** Chorus tools are exposed by the connected MCP server under a `chorus__` prefix on OpenClaw (e.g. `chorus__chorus_create_tasks`). Bare names are used below for readability — prepend `chorus__` when invoking. See `/chorus` for the full rule.
---
## Overview
The standard AI-DLC flow ensures quality through structured planning, but adds overhead that slows down small tasks. Quick Dev provides a lightweight alternative:
```
check explicit task:admin permission → create/claim → implement → self-check AC → submit → independent task review → verify or hand off
```
**Use Quick Dev when:**
- Bug fixes with clear reproduction steps
- Small features (< 2 story points)
- Post-delivery patches and gap-filling after a proposal's tasks are done
- Prototype or exploratory tasks
- Urgent hotfixes that can't wait for proposal review
**Do NOT use Quick Dev when:**
- The feature needs a PRD or tech design document
- Multiple interdependent tasks require upfront planning
- Stakeholder elaboration is needed to clarify requirements
- The work impacts architecture or shared components significantly
For complex work, use `/idea` + `/proposal` instead.
---
## Pre-Flight: Permission Check
Call `chorus_checkin` and inspect the active agent's effective permissions. Set `canVerifyTask` to true **only** when `chorus_checkin().agent.permissions.task` explicitly contains `"admin"` (the `task:admin` permission).
Never infer verification authority from the agent's name, persona, preset/role label, task ownership, or tool availability. Do not prompt the user to choose: the explicit permission determines the terminal path.
---
## Tools
| Tool | Purpose |
|------|---------|
| `chorus_create_tasks` | Create task(s) — omit `proposalUuid` for standalone Quick Task, or pass it to attach to an existing proposal |
| `chorus_update_task` | Edit task fields (title, description, priority, AC, dependencies) or change status |
| `chorus_claim_task` | Claim a task (open → assigned) |
| `chorus_report_work` | Report progress with optional status update |
| `chorus_report_criteria_self_check` | Self-check acceptance criteria before submitting |
| `chorus_submit_for_verify` | Submit for admin verification |
| `chorus_admin_verify_task` | **(admin only)** Verify task — use when self-verification is approved |
---
## Workflow
### Step 1: Create a Quick Task
**`acceptanceCriteriaItems` is required** — `chorus_create_tasks` rejects any task without at least one non-blank criterion (and rejects the whole batch if any task is missing them). These are also the foundation for self-checking in Step 6. Write specific, testable criteria that you can objectively verify after development. Vague AC like "works correctly" defeats the purpose; prefer "returns 200 on GET /api/foo with valid token".
```
chorus_create_tasks({
projectUuid: "<project-uuid>",
tasks: [{
title: "Fix login redirect loop on Safari",
description: "Safari loses session cookie after redirect...",
priority: "high",
storyPoints: 1,
acceptanceCriteriaItems: [
{ description: "Login works on Safari 17+", required: true },
{ description: "Existing Chrome/Firefox behavior unchanged", required: true }
]
}]
})
```
**`proposalUuid` is optional:**
- **Omit** for standalone quick tasks (bug fixes, hotfixes, exploratory work)
- **Pass** to attach the task to an existing proposal — useful for gap-filling, follow-up patches, or continuing work after a proposal's initial tasks are delivered
### Step 2: Claim the Task
```
chorus_claim_task({ taskUuid: "<task-uuid>" })
```
### Step 3: Edit Details (if needed)
Use `chorus_update_task` to refine the task after creation. Tasks always have AC (creation requires them), but **update them when your understanding changes during development**. Passing `acceptanceCriteriaItems` **replaces** the task's criteria with the provided non-empty set; omit the field to leave them unchanged (it cannot be used to clear AC).
```
chorus_update_task({
taskUuid: "<task-uuid>",
description: "Updated with more details...",
acceptanceCriteriaItems: [
{ description: "Login works on Safari 17+", required: true },
{ description: "Added CSRF token handling", required: true }
],
addDependsOn: ["<other-task-uuid>"]
})
```
### Step 4: Start Working
```
chorus_update_task({ taskUuid: "<task-uuid>", status: "in_progress" })
```
**Sub-agents:** create your own session first (manual on OpenClaw — see `/develop`), then pass `sessionUuid` for attribution:
```
chorus_update_task({ taskUuid: "<task-uuid>", status: "in_progress", sessionUuid: "<session-uuid>" })
```
### Step 5: Report Progress
```
chorus_report_work({
taskUuid: "<task-uuid>",
report: "Fixed Safari cookie issue:\n- Root cause: SameSite=Strict incompatible with redirect\n- Changed to SameSite=Lax\n- Commit: abc1234",
sessionUuid: "<session-uuid>"
})
```
### Step 6: Self-Check Acceptance Criteria
```
chorus_report_criteria_self_check({
taskUuid: "<task-uuid>",
criteria: [
{ uuid: "<ac-uuid-1>", devStatus: "passed", devEvidence: "Tested on Safari 17.2" },
{ uuid: "<ac-uuid-2>", devStatus: "passed", devEvidence: "Chrome/Firefox regression tests pass" }
]
})
```
### Step 7: Submit and Run Independent Review
```
chorus_submit_for_verify({
taskUuid: "<task-uuid>",
summary: "Fixed Safari login redirect loop. Changed SameSite cookie policy. All AC passed."
})
```
SubmittiTrust audit
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.
| Layer | What it checks | Result |
|---|---|---|
| L0 | Provenance & inventory | WARN |
| L1 | Static analysis of the code | NA |
| L2 | Instruction surface (what it tells the agent) | PASS |
| L3 | Class-specific surface | PASS |
| L4 | Behavioural (sandbox) | SKIPPED |
What the source does
- Filesystem
- none-observed
- Network
- none-observed
- Shell
- none-observed
- Dependencies
- pinned
- Secrets in source
- none-found
Findings (1)
.agents/skills
Gates applied: no_behavioural_pass.
3bb5b08404b5full audit observations/trust-audit/skill/chorus-aidlc__quick-dev.json · Report an issue / request a re-scanAudit history
Every audit this skill has had.
| Date | Source | Verdict | Grade | Score | Change |
|---|---|---|---|---|---|
| 2026-10-12 | 3bb5b08404b5 | SAFE | B | 89 | first audit |
Questions
What does the Quick Dev skill do?
The Agent Harness for AI-Human Collaboration, inspired by the AI-DLC (AI-Driven Development Lifecycle)
Is Quick Dev safe to install?
The audit found nothing in the source that contradicts what it says it does, and graded it B (89/100). Grade A is held back for packages that have also passed a sandboxed behavioural run, which is why a clean skill reads B.
What can Quick Dev access on my machine?
The audit observed no filesystem, network or shell use at all in its source.
Which assistants does Quick Dev work with?
Its documentation mentions openclaw. That is what the text claims, not a compatibility test we ran.
How current is this page?
The grade is for one exact copy of the source (3bb5b08404b5), read on 2026-10-12. The repository is watched, and a new audit runs when it changes — this is the first audit.