structure
npx machina-cli add skill auge2u/lisa-helps-ralph-loops/structure --openclawStructure Skill (Stage 3)
This skill extracts work items from the project and structures them as Gastown Beads and Convoys.
When to Use
Use this skill when:
- Have completed Stage 1 (Discover) and optionally Stage 2 (Plan)
- Ready to create actionable work items
- Want to structure work for Gastown multi-agent execution
- Need to bundle related tasks for efficient assignment
Output Structure
project/
├── .gt/
│ ├── beads/
│ │ ├── gt-abc12.json # Individual work items
│ │ ├── gt-def34.json
│ │ └── ...
│ └── convoys/
│ ├── convoy-001.json # Bundled work assignments
│ └── ...
└── [existing project files]
Part 1: Bead Extraction
Extraction Sources (Priority Order)
Scan for work items in:
-
GitHub Issues (most authoritative)
gh issue list --state open --json number,title,body,labels -
PRD Documents
docs/*.mdwith user storiesdocs/PRD*.mdfiles
-
TODO Comments in Source Code
// TODO:,# TODO:,/* TODO */// FIXME:,// HACK:,// XXX:
-
Existing Roadmap Outputs
scopecraft/EPICS_AND_STORIES.md(from Stage 2)scopecraft/OPEN_QUESTIONS.md
-
Backlog Files
BACKLOG.md,TODO.mddocs/backlog/,docs/roadmap/
Bead Schema
Aligned with the real bd Issue schema (from github.com/steveyegge/beads):
{
"$schema": "bead-v1",
"id": "gt-abc12",
"title": "Add user authentication",
"description": "Implement OAuth2 login flow and session management",
"design": "Use Passport.js with Google and GitHub strategies",
"acceptance_criteria": "User can sign up with email\nUser can sign in with Google OAuth\nSession persists across page refresh",
"notes": "See docs/PRD-auth.md for background",
"issue_type": "feature",
"priority": 1,
"status": "open",
"assignee": "",
"labels": ["auth", "security"],
"dependencies": [],
"metadata": {
"complexity": "L",
"epic": "User Management",
"evidence": {
"source": "docs/PRD-auth.md",
"line": 42,
"extracted": "2026-01-27T10:00:00Z"
}
}
}
Schema notes (from real bd types):
acceptance_criteriais a string (newline-separated), not an arraypriorityis an integer: 0=critical, 1=high, 2=medium, 3=low, 4=backlogstatusisopen(notpending) — real values: open | in_progress | blocked | deferred | closedissue_typemaps directly tobdtypes (nottype)complexityandevidencelive inmetadata(not top-levelbdfields)
Issue Types
| Type | Description | Source Indicators |
|---|---|---|
feature | New functionality | PRDs, user stories, feature requests |
bug | Defect fix | FIXME comments, bug issues |
task | Generic work item | TODO comments, operational tasks |
chore | Maintenance, refactoring | HACK comments, tech debt |
epic | Large feature container | Feature areas, milestones |
decision | Architecture decision | ADRs, design docs |
Priority Values
| Value | Label | Description |
|---|---|---|
| 0 | P0 / critical | Blockers, production issues |
| 1 | P1 / high | Sprint priorities |
| 2 | P2 / medium | Normal work (default) |
| 3 | P3 / low | Nice-to-have |
| 4 | P4 / backlog | Future consideration |
Complexity Estimates (metadata only)
| Size | Description | Typical Effort |
|---|---|---|
XS | Trivial change | < 1 hour |
S | Small task | 1-4 hours |
M | Medium task | 1-2 days |
L | Large task | 3-5 days |
XL | Epic-sized | 1-2 weeks |
ID Generation
Bead IDs use the rig prefix + 5-char alphanumeric. For the gastown rig the prefix is gt-:
import random
import string
def generate_bead_id():
chars = string.ascii_lowercase + string.digits
return f"gt-{''.join(random.choices(chars, k=5))}"
Bead Quality Requirements
Every bead must have:
- Clear, actionable title
- Substantive description (why + what)
- Acceptance criteria (as newline-separated string)
- Evidence in metadata linking to source file
- Valid complexity in metadata (XS/S/M/L/XL)
- Unique ID in
gt-xxxxxformat
bd CLI Integration
Lisa's .gt/beads/*.json files are a staging format. To create real bd issues:
# Option 1: Import from a markdown file Lisa generates
bd create --file=.gt/beads/bd-import.md
# Option 2: Create one at a time (for scripting)
bd create "Add user authentication" \
--type=feature --priority=1 \
--acceptance="User can sign up with email\nSession persists" \
--description="Implement OAuth2 login"
# Check unblocked work
bd ready
# Claim and complete
bd update gt-abc12 --status=in_progress
bd close gt-abc12
bd sync # commit beads changes to git
Part 2: Convoy Bundling
Convoy Creation Rules
| Rule | Requirement |
|---|---|
| Size | 3-7 beads per convoy (optimal batch) |
| Coherence | Related beads grouped together |
| Dependencies | Respect bead dependency order |
| Parallelization | Independent convoys can run concurrently |
Bundling Strategies
-
By Epic
- Group all beads from same epic/feature area
- Best for feature-focused sprints
-
By Dependency Chain
- Chain dependent beads sequentially
- Best for complex features with prerequisites
-
By Skill
- Group beads requiring similar expertise
- Best for specialist assignment
-
By Size
- Combine small beads (XS/S) together
- Isolate large beads (L/XL)
- Best for balanced workloads
Convoy Schema
{
"$schema": "convoy-v1",
"id": "convoy-001",
"name": "Authentication Sprint",
"description": "Implement core user authentication features",
"beads": ["gt-abc12", "gt-def34", "gt-ghi56"],
"assigned_to": null,
"status": "pending",
"created": "2026-01-27T10:00:00Z",
"gt_convoy_cmd": "gt convoy create \"Authentication Sprint\" gt-abc12 gt-def34 gt-ghi56",
"metadata": {
"epic": "User Management",
"estimated_days": 5
}
}
The gt_convoy_cmd field is the actual gt CLI command to create this convoy in a live Gastown environment. Polecats are assigned via gt sling <bead-id> <rig>.
ID Generation
Convoy IDs: convoy- + 3-digit number
- Sequential numbering:
convoy-001,convoy-002, etc. - Pad with zeros for sorting
Convoy Quality Requirements
Every convoy must have:
- 3-7 beads (optimal batch size)
- Coherent theme (epic, skill, or dependency chain)
- All referenced beads exist in
.gt/beads/ - Clear description of bundle purpose
Execution Procedure
Step 1: Create Directories
mkdir -p .gt/beads .gt/convoys
Step 2: Extract Beads
For each source:
- Scan for work items
- Extract title, description, criteria
- Classify type and complexity
- Generate unique ID
- Link evidence to source
- Write to
.gt/beads/gt-xxxxx.json
Step 3: Bundle into Convoys
- Group beads by chosen strategy
- Ensure 3-7 beads per convoy
- Verify all bead references exist
- Generate convoy ID
- Write to
.gt/convoys/convoy-xxx.json
Step 4: Validate
python plugins/lisa/hooks/validate.py --stage structure
Quality Gates
Bead Gates
| Gate | Requirement |
|---|---|
beads_extracted | At least 1 bead created |
beads_have_criteria | All beads have acceptance_criteria string |
beads_have_sources | All beads have evidence.source |
beads_valid_ids | All IDs match gt-[a-z0-9]{5} pattern |
Convoy Gates
| Gate | Requirement |
|---|---|
convoy_created | At least 1 convoy created |
convoy_size_valid | All convoys have 3-7 beads |
convoy_beads_exist | All referenced bead IDs exist in .gt/beads/ |
Integration with Gastown
Lisa's .gt/beads/ and .gt/convoys/ are staging directories. The real Gastown toolchain uses:
bd— the beads CLI (issue tracking, Dolt-backed SQL database in.beads/)bv— the graph analysis CLI (read-only, usebv --robot-triagenot barebv)gt— the Gastown workspace manager (convoys, polecats, rigs, worktrees)
Live Integration Workflow
# 1. Create real bd issues from Lisa's staging beads
# Either run individual bd create commands, or produce a markdown file:
bd create --file=.gt/beads/bd-import.md
# 2. Create a convoy in Gastown from the bead IDs
gt convoy create "Authentication Sprint" gt-abc12 gt-def34 gt-ghi56
# 3. Sling work to polecats (ephemeral workers) or crew
gt sling gt-abc12 <rig> # assign to a polecat on the rig
gt convoy status hq-cv-abc # track convoy progress
# 4. Workers pick up and complete
bd ready # see unblocked work
bd update gt-abc12 --status=in_progress
bd close gt-abc12
bd sync # commit beads changes to git
Real Bead Status Values
open → in_progress → closed
↓
blocked
deferred
The Propulsion Principle
Gastown agents follow: "If you find something on your hook, YOU RUN IT." When a bead is slotted to a polecat, it executes immediately — no confirmation needed. Lisa's quality gates and acceptance criteria are what make that safe to do.
Templates
See templates/ directory for JSON templates:
templates/bead.json- Bead templatetemplates/convoy.json- Convoy template
Source
git clone https://github.com/auge2u/lisa-helps-ralph-loops/blob/main/plugins/lisa/skills/structure/SKILL.mdView on GitHub Overview
Structure skill extracts project work items and formats them as Gastown Beads, then bundles related items into Convoys for multi-agent execution. It sources items from GitHub Issues, PRD documents, TODO comments, and backlog outputs, writing structured beads to project/.gt/beads and grouped convoys to project/.gt/convoys. This standardizes metadata using the bead schema to enable scalable assignment.
How This Skill Works
It scans prioritized sources (GitHub Issues, PRD documents, TODOs, and backlog files) and converts each item into a bead JSON using the bd-inspired schema (id, title, description, design, acceptance_criteria, priority, status, labels, dependencies, and metadata). Each bead is saved under project/.gt/beads with a gt- ID, then related beads are grouped into convoy JSONs saved under project/.gt/convoys for coordinated Gastown execution.
When to Use It
- Have completed Stage 1 (Discover) and optionally Stage 2 (Plan) and are ready to create actionable work items.
- Need to extract work items from GitHub Issues, PRD documents, TODO comments, and backlog/backlog files to structure them.
- Want to bundle related tasks into convoys for efficient multi-agent execution.
- Want standardized bead metadata following the bd-like schema (id, title, description, design, acceptance_criteria, priority, status, etc).
- Need outputs organized under project/.gt/beads and project/.gt/convoys for traceability and reuse.
Quick Start
- Step 1: Identify sources (GitHub Issues, PRDs, TODOs, backlog) and extract candidate work items.
- Step 2: Convert each item into a bead JSON using the bd-inspired schema and save under project/.gt/beads (gt- prefix IDs).
- Step 3: Group related beads into convoys and save under project/.gt/convoys for Gastown execution.
Best Practices
- Follow the bead schema closely: include id, title, description, design, acceptance_criteria, priority, status, assignee, labels, dependencies, and metadata.
- Keep acceptance_criteria as a newline-delimited string per the schema.
- Map issue priority to numeric values: 0 critical, 1 high, 2 medium, 3 low, 4 backlog.
- Use valid status values: open, in_progress, blocked, deferred, or closed.
- Review beads before convoy creation and ensure dependencies are accurate and convoys reflect related items.
Example Use Cases
- Bead gt-auth01 derived from a GitHub Issue 'Add user authentication' with acceptance_criteria for sign-up, sign-in, and session persistence, bundled into convoy convoy-001.
- Bead gt-dashboard03 from a PRD document detailing a dashboard redesign, with design notes and stories, grouped into convoy convoy-002 for frontend and backend tasks.
- Bead gt-cache07 created from a code TODO 'Implement caching layer' with high priority, included in convoy convoy-003 for performance work.
- Bead gt-backlog11 from BACKLOG.md 'Improve error handling across services' scheduled in convoy convoy-004.
- Bead gt-mobile04 from docs/EPICS_AND_STORIES.md 'Mobile feature flags' included in convoy convoy-005.