AutoCraft - AI-Powered Project Execution Platform#

🚀 Empower non-technical product managers to drive complex software development with 3-6x efficiency

Version: v2.1.0 Updated: 2026-05-20 Changes: Complete skill package with installation automation

---

📦 System Installation#

One-Click Install & Deploy#

bash

# 1. Install skill from ClawHub
clawhub install autocraft

# 2. Navigate to autocraft directory
cd autocraft

# 3. Run one-click installation script
bash install.sh

# 4. Access the system
# Frontend UI: http://localhost:8080
# API Docs:    http://localhost:9001/docs

install.sh automatically:

• Downloads complete system code from GitHub/Gitee (~5.6MB)
• Installs backend dependencies (Python + FastAPI)
• Installs frontend dependencies (Node.js + Vue3)
• Starts backend service (port 9001)
• Starts frontend service (port 8080)

Manual Installation (Optional)#

bash

# Clone complete system code
git clone https://github.com/Robin-Chen2025/autocraft-opensource.git
cd autocraft-opensource

# Backend setup
cd backend
pip install -r requirements.txt
python3 -m uvicorn main:app --host 0.0.0.0 --port 9001

# Frontend setup (new terminal)
cd ..
npm install
npm run dev

---

📊 Real Case: Complete Education Platform in 10 Days#

text

📈 Project Scale:
   Plans: 19
   Tasks: 71
   Success: 70 (99% success rate)

🔧 Quality Metrics:
   Bugs Found: 7 (all auto-fixed)
   Test Coverage: 100% (L1+L2+L3)
   Manual Interventions: Only 3 key decisions

⏱️ Efficiency Comparison:
   Traditional Estimate: 1-2 months
   AutoCraft: 10 days (3-6x improvement)

---

🎯 Your Role#

You are the project manager - make decisions, break down tasks, verify deliverables. Don't write code.

You DoYou Don'tClarify requirements, choose solutionsWrite specific codeReview and approve documentsDirectly operate databaseBreak down and schedule tasksTrust agent's "completed"Verify deliverablesSkip verification steps

---

Two-Phase Model#

text

Phase 1: Design Phase (Without AutoCraft)
    │
    │  PRD → Feature Design → Tech Solution → API/DB/UI Design
    │  → Test Plan → Development Plan (Overview + Work Plans)
    │  → Overall Verification
    │
    ▼  Development Plan Finalized
Phase 2: Execution Phase (Enter AutoCraft)
    │
    │  Break down task tickets → Import via API
    │  → Execution engine runs tasks (AI agents)
    │  → Auto verification → Manager approval → Status cascade
    │
    ▼  Project Complete

---

Phase 1: Design Phase#

Design Document System#

Follow references/design-specs/设计阶段文档规范-总纲.md.

Required Documents:

#DocumentCodeSpecChecklist01PRDPRD01-PRD规范09-PRD审核03System Feature DesignFUNC03-系统功能设计11-功能设计审核04Tech SolutionTECH04-技术方案12-技术方案审核07API DesignAPI07-API设计14-API设计审核08Database DesignDB08-数据库设计15-数据库设计审核18Overall VerificationVERIFY-18-整体性验证

Optional Documents:

#DocumentCodeSpecChecklist00Requirements ListREQ00-需求清单See spec chapter 602Business FlowFLOW02-业务流程10-业务流程审核05UI DesignUI05-UI设计13-UI设计审核06Component SpecCOMP06-组件规范16-组件规范审核

Document Generation Flow#

Use sub-agents to generate documents:

text

1. Prepare input materials (prior docs + spec files)
2. Sub-agent generates first version
3. Sub-agent reviews against checklist
4. Fix based on issues found
5. Re-review to confirm
6. Finalize (Boss approval)

Sub-agent Invocation:

Design phase uses multi-turn session mode:

bash

# Create persistent session (supports multiple review-fix cycles)
openclaw agent --session-id explicit:doc_session_{project_name}_{timestamp} \
  --agent-id ac-glm5 \
  --model glm-5 \
  --message "Read the following spec files and input materials, generate {document_type} document..."

# Review in same session
openclaw agent --session-id explicit:doc_session_{project_name}_{timestamp} \
  --message "Review the generated document against checklist..."

# Fix in same session
openclaw agent --session-id explicit:doc_session_{project_name}_{timestamp} \
  --message "Fix the document based on review report..."

Key Requirements:

• Design phase document generation uses multi-turn session mode
• Sub-agent must read corresponding spec files and review checklists before generating
• Immediately self-review after generation using checklist
• Score ≥80 to submit for Boss review, <70 regenerate
• Use GLM-5 model for design phase work

Test Plan#

Generate according to references/design-specs/质量检测方案/:

DocumentPathPurposeTest Plan Overview21-总纲生成规范Overall test strategyBE-L2 Test Plan22-BE-L2规范Backend integration testsFE-L2 Test Plan23-FE-L2规范Frontend integration testsL3-E2E Test Plan24-L3-E2E规范End-to-end testsL1 Test Plan30/31规范Unit tests

Development Plan#

Generate according to references/design-specs/开发计划方案/:

Two-layer structure:

• Development Plan Overview: Batch order, module dependencies, feature overview
• Work Plan List: Task ticket structure for each work plan

DocumentSpecReviewOverview40-生成规范43-总览审核Overview Details41-总览生成-List42-清单生成44-清单审核Overall-45-整体性审核

---

Phase 2: Execution Phase#

Import to AutoCraft#

After development plan is finalized, main agent breaks down task tickets and imports via API:

bash

# 1. Create project profile
curl -X POST http://localhost:9001/api/profiles \
  -H "Content-Type: application/json" \
  -d '{"profile_id":"...", "profile_name":"...", ...}'

# 2. Create phases and workflows
curl -X POST http://localhost:9001/api/profiles/{id}/phases -d '...'
curl -X POST http://localhost:9001/api/profiles/{id}/workflows -d '...'

# 3. Create work plans
curl -X POST http://localhost:9001/plans -d '...'

# 4. Create task tickets one by one
curl -X POST http://localhost:9001/tasks -d '...'

Task Creation#

⚠️ Follow references/task-creator/SKILL.md, including:

• Standard input_data format and required fields
• workflow_type to task_type mapping
• input_files configuration guide
• Batch creation example code
• Common errors and checklists

Core Rules:

1. All paths must be absolute paths
2. project_path must point to correct project root
3. input_files must contain at least 1 design document
4. requirements must be detailed and specific
5. expected_output_files must list all expected files
6. input_data must be converted to JSON string via json.dumps()

Simple FlowTicket Execution#

Invocation:

bash

# 1. Submit execution request (async)
curl -X POST http://localhost:9001/api/v2/tasks/execute \
  -H "Content-Type: application/json" \
  -d '{
    "task_id": <task_id>,
    "model": "glm-5.1",
    "label": "Execute task XXX",
    "timeout": 1800
  }'

# 2. Query task status (polling)
curl -X GET "http://localhost:9001/api/v2/tasks/{task_id}/status"

# 3. Check execution result
# - Status "completed" or "verified" = success
# - Status "failed" or "verification_failed" = failure
# - execution_log and verification_log contain details

Task Status Flow:

text

pending → in_progress → completed → verifying → verified
                     ↓
                   failed → (can re-execute)
                                  ↓
                          verification_failed

Model Configuration:

PurposeModelAgent IDExecutionGLM-5.1ac-glm5VerificationDeepSeek-V3.2-thinkingac-validator

Verification Dimensions (7)#

DimensionCheckFAIL Condition1. CompletenessDo output files existFiles don't exist2. CorrectnessIs code syntax correctCompile/parse fails3. FunctionalityDoes it meet requirementsCore features missing4. StandardsDoes it follow code standardsSerious violations5. TestabilityCan tests runTests can't execute6. ArchitectureDoes it follow SRPViolates SRP7. Design ComplianceDoes it match design docsDeviates from design

Approval Rules#

1. Don't trust agent's "completed" - must check output files
2. Verification is automatic - PASS/FAIL per dimension, all PASS to pass
3. Output path must match - check files are in deliverables locations
4. Architecture check enforced - new dimension 6 "Architecture", SRP violation = FAIL
5. Design compliance enforced - new dimension 7 "Design Compliance", check implementation matches design docs

---

AutoCraft System Info#

ComponentAddressManagementUnified Backendhttp://localhost:9001systemd: autocraft-backendFrontend (View Window)http://localhost:8080systemd: autocraft-frontendAPI Docshttp://localhost:9001/docsOpenAPI interactive docs

Service Management:

bash

sudo systemctl restart autocraft-backend autocraft-frontend
sudo systemctl status autocraft-backend autocraft-frontend
curl http://localhost:9001/health  # Health check

---

Iron Rules#

RuleDescriptionConfirm with Boss before actionEvery key step (start project, generate docs, execute tasks, approve, etc.) must be explained to Boss and wait for confirmation before executingDesign phase multi-turn sessionDesign phase uses multi-turn session mode, same sub-agent (GLM-5) completes generate→review→fix cycleMain agent doesn't write codeYou are project manager, sub-agents do the workAll operations via APINo direct database operationsVerify deliverablesDon't trust "completed" wordGit standardsNo reset --hard, push --forceModel isolationDesign phase: GLM-5, Execution phase: GLM-5 (execute) + DeepSeek-V3.2 (verify)Session isolationExecution phase each task independent session, design phase multi-turn sessionDesign specs firstDocument generation must read spec files, don't write from memoryPaths must be absoluteAll file paths must be absolute, no relative pathsProject directory clearMust specify correct project_path, ensure files generated in correct location

---

Sub-Agent Guide#

Comprehensive guide for ac-glm5 (execution agent) and ac-validator (verification agent):

• ac-agent-guide: references/ac-agent-guide/SKILL.md
  • Role identification (auto-detect execution/verification by Agent ID)
  • Execution agent: 5 task types (BUILD-CODE/BUILD-TEST/BUILD-ENV/DOC/DESIGN)
  • Verification agent: 3 task types + PASS/FAIL judgment + verification dimensions
  • Auxiliary skill index: auto-select skill by tech stack
  • JSON result file format spec
  • Shared rules (file operations, output directory, common commands)

When sub-agent is invoked by AutoCraft execution engine, it should read this skill for role definition and behavior specs.

---

Architecture Check & Template Library#

Architecture Check Tool#

New verification dimension 6: Architecture, checks if code follows design principles:

DimensionCheck ItemsCriteriaArchitectureFile responsibility single (SRP), code structure clear, functional boundaries distinctViolates SRP → FAIL

Architecture check script: scripts/architecture-check/architecture_check.py

• Check file responsibility singularity (SRP principle)
• Check code structure rationality (layered architecture)
• Check functional boundary clarity (coupling)
• Generate architecture health report

Usage:

bash

python3 scripts/architecture-check/architecture_check.py --path /path/to/code --report architecture_report.json

Standardized Template Library#

Provides standard code templates to ensure architecture consistency:

TemplatePathPurposeFastAPI Router Templatetemplates/fastapi-module/router_template.pyRouter layer code templateService Layer Templatetemplates/fastapi-module/service_template.pyBusiness logic layer templateTest Templatetemplates/fastapi-module/test_template.pyTest code templatepytest Configtemplates/config-templates/pytest.iniTest config templateArchitecture Rulestemplates/architecture-rules/architecture_rules.mdArchitecture spec doc

---

Reference Document Index#

CategoryDirectoryFile CountDesign Specs - Doc Specsreferences/design-specs/doc-specs/20Design Specs - Dev Planreferences/design-specs/开发计划方案/9Design Specs - Quality Testreferences/design-specs/质量检测方案/28Design Specs - Overviewreferences/design-specs/设计阶段文档规范-总纲.md1Sub-Agent Guidereferences/ac-agent-guide/SKILL.md1Task Creationreferences/task-creator/SKILL.md1Architecture Check Toolscripts/architecture-check/3Standardized Templatestemplates/5