name: build description: FABER Phase 3 - Implements solution from specification with autonomous execution and deep planning model: claude-opus-4-5

Build Skill

You receive full workflow context including Frame and Architect results. Specs are structured into phases, and you implement one phase per session for optimal context management.

Key Philosophy: Think deeply, plan thoroughly, execute completely. No premature stops.

<CRITICAL_RULES>

Use Thinking Mode - ALWAYS engage extended thinking before implementation to create a detailed plan
Plan Before Code - ALWAYS document your complete implementation plan BEFORE writing any code
Complete Current Phase - Implement the current spec phase IN ITS ENTIRETY without stopping
No Premature Stops - NEVER suggest "pausing for now", "breaking into phases", or "picking up later"
Accept Compaction - If context compacts mid-session, CONTINUE from where you left off
Follow Specification - ALWAYS implement according to the spec from Architect phase
Commit at Boundaries - Create semantic commits at logical work boundaries within the phase
Phase Checkpoint - After completing the phase, trigger the checkpoint workflow
Handle Retries - If retry, ALWAYS consider failure reasons from previous attempts
No Confirmation Seeking - Do NOT ask "should I proceed?" or "would you like me to continue?" </CRITICAL_RULES>

<AUTONOMY_GUIDANCE>

Why These Rules Matter

Claude has a tendency to:

Stop when context is running low ("let's pause here")
Split work into phases ("we can do this next time")
Ask for confirmation at each step ("should I proceed?")
Suggest incremental approaches ("let's start with X and see")

These behaviors are explicitly prohibited in the Build skill. The spec already defines what to build - your job is to execute the current phase completely.

What To Do Instead

When context feels low: Trust auto-compaction, continue working
When work feels large: It's already broken into phases - just complete THIS phase
When uncertain: Refer to the spec, make a decision, document it
When hitting blockers: Work around them or document as implementation note, don't stop </AUTONOMY_GUIDANCE>

Context Provided:

{
  "work_id": "abc12345",
  "work_type": "/feature",
  "retry_count": 0,
  "retry_context": "",
  "current_phase": "phase-1",
  "frame": {"work_item_title": "...", "branch_name": "..."},
  "architect": {"spec_file": "...", "key_decisions": [...]},
  "session_summary": null
}

Phase Context:

current_phase: Which spec phase to implement (e.g., "phase-1", "phase-2")
session_summary: Summary from previous session (if resuming)

Create Implementation Plan - Use extended thinking to plan the entire phase
Load Specification - Read spec file, identify current phase and tasks
Consider Resume Context - If session_summary present, review what was done
Execute Phase Tasks - Implement all tasks in current phase
Commit at Boundaries - Create semantic commits at logical points
Trigger Phase Checkpoint - Update spec, final commit, issue comment
Signal Phase Complete - Return results to faber-manager

See workflow/basic.md for detailed implementation steps.

Phase-Based Execution

┌─────────────────────────────────────────────────────────┐
│  BUILD SKILL EXECUTION                                   │
├─────────────────────────────────────────────────────────┤
│                                                          │
│  1. PLAN (Extended Thinking)                            │
│     ├─ Read spec and current phase                      │
│     ├─ Identify all tasks                               │
│     ├─ Determine file changes needed                    │
│     └─ Document complete plan                           │
│                                                          │
│  2. EXECUTE (Autonomous)                                 │
│     ├─ Implement task 1 → commit                        │
│     ├─ Implement task 2 → commit                        │
│     ├─ ...                                              │
│     └─ Implement task N → commit                        │
│                                                          │
│  3. CHECKPOINT (Phase Complete)                         │
│     ├─ Update spec (mark phase complete)                │
│     ├─ Final commit if needed                           │
│     ├─ Post issue comment with progress                 │
│     └─ Create session summary                           │
│                                                          │
│  4. RETURN (Signal faber-manager)                       │
│     └─ Phase complete, ready for next or evaluate       │
│                                                          │
└─────────────────────────────────────────────────────────┘

See: plugins/faber/docs/RESPONSE-FORMAT.md for complete specification.

Success Response (Phase Complete):

{
  "status": "success",
  "message": "Build phase completed - phase-1 implementation committed successfully",
  "details": {
    "phase": "build",
    "spec_phase": "phase-1",
    "commits": ["sha1", "sha2"],
    "files_changed": ["file1.py", "file2.ts"],
    "tasks_completed": 4,
    "retry_count": 0,
    "next_phase": "phase-2",
    "recommend_session_end": true
  },
  "session_summary": {
    "accomplished": ["Created SKILL.md", "Updated workflow"],
    "decisions": ["Used pattern X for Y"],
    "files_changed": ["file1.py", "file2.ts"],
    "remaining_phases": ["phase-2", "phase-3"]
  }
}

Success Response (All Phases Complete):

{
  "status": "success",
  "message": "Build phase completed - all spec phases implemented",
  "details": {
    "phase": "build",
    "spec_phase": "phase-3",
    "commits": ["sha1"],
    "files_changed": ["file3.py"],
    "tasks_completed": 2,
    "retry_count": 0,
    "next_phase": null,
    "recommend_session_end": false
  }
}

Warning Response (phase completed with minor issues):

{
  "status": "warning",
  "message": "Build phase completed with warnings",
  "details": {
    "phase": "build",
    "spec_phase": "phase-1",
    "commits": ["sha1"],
    "files_changed": ["file1.py"],
    "retry_count": 0,
    "next_phase": "phase-2"
  },
  "warnings": [
    "Deprecated API usage detected in file1.py",
    "TODO comments remain in implementation"
  ],
  "warning_analysis": "Implementation is complete but uses deprecated patterns that should be addressed",
  "suggested_fixes": [
    "Update API calls to use new interface",
    "Resolve TODO comments before release"
  ]
}

Failure Response:

{
  "status": "failure",
  "message": "Build phase failed - implementation could not be completed",
  "details": {
    "phase": "build",
    "spec_phase": "phase-1",
    "retry_count": 1
  },
  "errors": [
    "Type error in file1.py: Expected str, got int",
    "Import error: Module 'xyz' not found"
  ],
  "error_analysis": "Implementation failed due to type mismatches and missing dependencies",
  "suggested_fixes": [
    "Fix type annotation on line 45 of file1.py",
    "Add 'xyz' to requirements.txt and run pip install"
  ]
}

Start:

🔨 STARTING: Build Skill (Phase: phase-1)
Work ID: #262
Spec: /specs/WORK-00262-default-build-skill.md
───────────────────────────────────────

Creating implementation plan...

End:

✅ COMPLETED: Build Skill (Phase: phase-1)
Tasks completed: 4/4
Commits: 3
Files changed: 5
───────────────────────────────────────
Next: Phase complete. faber-manager will handle session lifecycle.

Manual Testing Workflow

The build skill can be manually tested by:

Create a test issue with phases:

/work:issue-create "Test: Build skill autonomy" --type feature

Run FABER workflow to Architect phase:

/faber run <work_id> --phases frame,architect

Verify spec has phase structure:
- Check for ### Phase N: sections
- Verify **Status**: ⬜ Not Started indicators
- Confirm - [ ] task checkboxes

Run Build phase:

/faber run <work_id> --phases build

Verify build behavior:
- Extended thinking plan created before code
- Tasks executed autonomously (no pause prompts)
- Commits created at logical boundaries
- Phase checkpoint triggered at completion

Checkpoint Verification

After build completes, verify checkpoint actions:

# Check spec was updated
grep "✅ Complete" specs/WORK-*-test.md

# Check session summary was created
ls -la .fractary/plugins/faber/runs/*/session-summaries/

# Check progress comment was posted
gh issue view <work_id> --comments

Error Handling Tests

Test resilience by simulating failures:

Read-only spec file:

chmod 444 specs/WORK-*-test.md
# Run build - should complete with warning

No git repository:

# Run from non-git directory
# Commit action should skip gracefully

Network offline:

# Disable network
# Comment post should fail with warning, build continues

Session Continuity Test

Test cross-session context:

Run build for phase-1, complete checkpoint
Start new Claude session
Run /faber run <work_id> --resume
Verify session summary is loaded:
- Previous accomplishments displayed
- Correct phase identified (phase-2)
- Files changed from phase-1 shown

Input Validation Tests

Verify sanitization works:

# Test with special characters in work item title
# Title: "Test `injection` $(whoami) attempt"
# Should be sanitized to safe string

# Test with long phase names
# Should be truncated to max length

Automated Test Coverage (Future)

Areas for automated testing:

Component	Test Type	Priority
Input sanitization	Unit test	High
Phase name validation	Unit test	High
Checkpoint error handling	Integration test	Medium
Session summary generation	Integration test	Medium
Context reconstitution	Integration test	Medium
Spec-updater operations	Unit test	High

Success Criteria

Build skill is working correctly when:

✅ Extended thinking plan visible in output
✅ No premature stop prompts during execution
✅ All phase tasks completed autonomously
✅ Commits created with semantic messages
✅ Spec updated with task checkmarks
✅ Phase status shows ✅ Complete
✅ Progress comment posted to issue
✅ Session summary file created
✅ Checkpoint failures don't break build

This Build skill implements solutions from specifications with autonomous execution, supporting the one-phase-per-session model for optimal context management.

build

SKILL.md