catlog22/Claude-Code-Workflow
1
0
Fork 0
mirror of https://github.com/catlog22/Claude-Code-Workflow.git synced 2026-03-25 19:48:33 +08:00
Code Issues Packages Projects Releases Wiki Activity

feat: migrate all codex team skills from spawn_agents_on_csv to spawn_agent + wait_agent architecture

Browse Source 
- Delete 21 old team skill directories using CSV-wave pipeline pattern (~100+ files)
- Delete old team-lifecycle (v3) and team-planex-v2
- Create generic team-worker.toml and team-supervisor.toml (replacing tlv4-specific TOMLs)
- Convert 19 team skills from Claude Code format (Agent/SendMessage/TaskCreate)
  to Codex format (spawn_agent/wait_agent/tasks.json/request_user_input)
- Update team-lifecycle-v4 to use generic agent types (team_worker/team_supervisor)
- Convert all coordinator role files: dispatch.md, monitor.md, role.md
- Convert all worker role files: remove run_in_background, fix Bash syntax
- Convert all specs/pipelines.md references
- Final state: 20 team skills, 217 .md files, zero Claude Code API residuals

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
This commit is contained in:
catlog22
2026-03-24 16:54:48 +08:00
parent 54283e5dbb
commit 1e560ab8e8
334 changed files with 28996 additions and 35516 deletions
Download Patch File Download Diff File Expand all files Collapse all files

136
.codex/skills/team-lifecycle-v4/specs/knowledge-transfer.md Normal file
View File

@@ -0,0 +1,136 @@
# Knowledge Transfer Protocols
## 1. Transfer Channels
| Channel | Method | Producer | Consumer |
|---------|--------|----------|----------|
| Artifacts | Files in `<session>/artifacts/` | Task executor | Next task in pipeline |
| Discoveries | Files in `<session>/discoveries/{task_id}.json` | Task executor | Coordinator + downstream |
| Wisdom | Append to `<session>/wisdom/*.md` | Any role | All roles |
| Context Accumulator | In-memory aggregation | Inner loop only | Current task |
| Exploration Cache | `<session>/explorations/` | Analyst / researcher | All roles |
## 2. Context Loading Protocol (Before Task Execution)
Every role MUST load context in this order before starting work.
| Step | Action | Required |
|------|--------|----------|
| 1 | Read `<session>/tasks.json` -- locate upstream task entries, check status and findings | Yes |
| 2 | Read `<session>/discoveries/{upstream_id}.json` for each upstream dependency -- get detailed findings and artifact paths | Yes |
| 3 | Read artifact files from upstream discovery's `artifacts_produced` paths | Yes |
| 4 | Read `<session>/wisdom/*.md` if exists | Yes |
| 5 | Check `<session>/explorations/cache-index.json` before new exploration | If exploring |
**Loading rules**:
- Never skip step 1 -- tasks.json contains task status, wave progression, and summary findings
- Never skip step 2 -- discoveries contain detailed key_findings, decisions, and artifact references
- If artifact path in discovery does not exist, log warning and continue
- Wisdom files are append-only -- read all entries, newest last
## 3. Context Publishing Protocol (After Task Completion)
| Step | Action | Required |
|------|--------|----------|
| 1 | Write deliverable to `<session>/artifacts/<task-id>-<name>.md` | Yes |
| 2 | Write `<session>/discoveries/{task_id}.json` with payload (see schema below) | Yes |
| 3 | Append wisdom entries for learnings, decisions, issues found | If applicable |
## 4. Discovery File Schema
Written to `<session>/discoveries/{task_id}.json` on task completion.
```json
{
"task_id": "<TASK-NNN>",
"worker": "<TASK-NNN>",
"timestamp": "2026-03-24T10:15:00+08:00",
"type": "<pipeline_phase>",
"status": "completed | failed",
"findings": "Summary string (max 500 chars)",
"quality_score": null,
"supervision_verdict": null,
"error": null,
"data": {
"key_findings": [
"Finding 1",
"Finding 2"
],
"decisions": [
"Decision with rationale"
],
"files_modified": [
"path/to/file.ts"
],
"verification": "self-validated | peer-reviewed | tested"
},
"artifacts_produced": [
"<session>/artifacts/<task-id>-<name>.md"
]
}
```
**Field rules**:
- `artifacts_produced`: Always artifact paths, never inline content
- `data.key_findings`: Max 5 items, each under 100 chars
- `data.decisions`: Include rationale, not just the choice
- `data.files_modified`: Only for implementation tasks
- `data.verification`: One of `self-validated`, `peer-reviewed`, `tested`
**Supervisor-specific extensions** (CHECKPOINT tasks only):
```json
{
"supervision_verdict": "pass | warn | block",
"supervision_score": 0.85,
"data": {
"risks_logged": 0,
"blocks_detected": 0
}
}
```
- `supervision_verdict`: Required for CHECKPOINT tasks. Determines pipeline progression.
- `supervision_score`: Float 0.0-1.0. Aggregate of individual check scores.
- `data.risks_logged`: Count of risks written to wisdom/issues.md.
- `data.blocks_detected`: Count of blocking issues found. >0 implies verdict=block.
## 5. Exploration Cache Protocol
Prevents redundant research across tasks.
| Step | Action |
|------|--------|
| 1 | Read `<session>/explorations/cache-index.json` |
| 2 | If angle already explored, read cached result from `explore-<angle>.json` |
| 3 | If not cached, perform exploration |
| 4 | Write result to `<session>/explorations/explore-<angle>.json` |
| 5 | Update `cache-index.json` with new entry |
**cache-index.json format**:
```json
{
"entries": [
{
"angle": "competitor-analysis",
"file": "explore-competitor-analysis.json",
"created_by": "RESEARCH-001",
"timestamp": "2026-01-15T10:30:00Z"
}
]
}
```
**Rules**:
- Cache key is the exploration `angle` (normalized to kebab-case)
- Cache entries never expire within a session
- Any role can read cached explorations; only the creator updates them
## 6. Platform Mapping Reference
| Claude Code Operation | Codex Equivalent |
|----------------------|------------------|
| `team_msg(operation="get_state", role=<upstream>)` | Read `tasks.json` + Read `discoveries/{upstream_id}.json` |
| `team_msg(type="state_update", payload={...})` | Write `discoveries/{task_id}.json` |
| `TaskCreate` / `TaskUpdate` status fields | Read/Write `tasks.json` task entries |
| In-memory state aggregation | Parse `tasks.json` + glob `discoveries/*.json` |

125
.codex/skills/team-lifecycle-v4/specs/pipelines.md Normal file
View File

@@ -0,0 +1,125 @@
# Pipeline Definitions
## 1. Pipeline Selection Criteria
| Keywords | Pipeline |
|----------|----------|
| spec, design, document, requirements | `spec-only` |
| implement, build, fix, code | `impl-only` |
| full, lifecycle, end-to-end | `full-lifecycle` |
| frontend, UI, react, vue | `fe-only` or `fullstack` |
| Ambiguous / unclear | request_user_input |
## 2. Spec-Only Pipeline
**6 tasks + 2 optional checkpoints**
```
RESEARCH-001 -> DRAFT-001 -> DRAFT-002 -> [CHECKPOINT-001] -> DRAFT-003 -> DRAFT-004 -> [CHECKPOINT-002] -> QUALITY-001
```
| Task | Role | Description |
|------|------|-------------|
| RESEARCH-001 | analyst | Research domain, competitors, constraints |
| DRAFT-001 | writer | Product brief, self-validate |
| DRAFT-002 | writer | Requirements PRD |
| CHECKPOINT-001 | supervisor | Brief<->PRD consistency, terminology alignment |
| DRAFT-003 | writer | Architecture design, self-validate |
| DRAFT-004 | writer | Epics & stories, self-validate |
| CHECKPOINT-002 | supervisor | Full spec consistency (4 docs), quality trend |
| QUALITY-001 | reviewer | Quality gate scoring |
**Checkpoint**: After QUALITY-001 -- pause for user approval before any implementation.
**Supervision opt-out**: Set `supervision: false` in tasks.json to skip CHECKPOINT tasks.
## 3. Impl-Only Pipeline
**4 tasks + 1 optional checkpoint**
```
PLAN-001 -> [CHECKPOINT-003] -> IMPL-001 -> TEST-001 + REVIEW-001
```
| Task | Role | Description |
|------|------|-------------|
| PLAN-001 | planner | Break down into implementation steps, assess complexity |
| CHECKPOINT-003 | supervisor | Plan<->input alignment, complexity sanity check |
| IMPL-001 | implementer | Execute implementation plan |
| TEST-001 | tester | Validate against acceptance criteria |
| REVIEW-001 | reviewer | Code review |
TEST-001 and REVIEW-001 run in parallel after IMPL-001 completes.
**Supervision opt-out**: Set `supervision: false` in tasks.json to skip CHECKPOINT tasks.
## 4. Full-Lifecycle Pipeline
**10 tasks + 3 optional checkpoints = spec-only (6+2) + impl (4+1)**
```
[Spec pipeline with CHECKPOINT-001/002] -> PLAN-001(blockedBy: QUALITY-001) -> [CHECKPOINT-003] -> IMPL-001 -> TEST-001 + REVIEW-001
```
PLAN-001 is blocked until QUALITY-001 passes and user approves the checkpoint.
**Supervision opt-out**: Set `supervision: false` in tasks.json to skip all CHECKPOINT tasks.
## 5. Frontend Pipelines
| Pipeline | Description |
|----------|-------------|
| `fe-only` | Frontend implementation only: PLAN-001 -> IMPL-001 (fe-implementer) -> TEST-001 + REVIEW-001 |
| `fullstack` | Backend + frontend: PLAN-001 -> IMPL-001 (backend) + IMPL-002 (frontend) -> TEST-001 + REVIEW-001 |
| `full-lifecycle-fe` | Full spec pipeline -> fullstack impl pipeline |
## 6. Conditional Routing
PLAN-001 outputs a complexity assessment that determines the impl topology.
| Complexity | Modules | Route |
|------------|---------|-------|
| Low | 1-2 | PLAN-001 -> IMPL-001 -> TEST + REVIEW |
| Medium | 3-4 | PLAN-001 -> ORCH-001 -> IMPL-{1..N} (parallel) -> TEST + REVIEW |
| High | 5+ | PLAN-001 -> ARCH-001 -> ORCH-001 -> IMPL-{1..N} -> TEST + REVIEW |
- **ORCH-001** (orchestrator): Coordinates parallel IMPL tasks, manages dependencies
- **ARCH-001** (architect): Detailed architecture decisions before orchestration
## 7. Task Metadata Registry
| Task ID | Role | Phase | Depends On | Priority |
|---------|------|-------|------------|----------|
| RESEARCH-001 | analyst | research | - | P0 |
| DRAFT-001 | writer | product-brief | RESEARCH-001 | P0 |
| DRAFT-002 | writer | requirements | DRAFT-001 | P0 |
| DRAFT-003 | writer | architecture | DRAFT-002 | P0 |
| DRAFT-004 | writer | epics | DRAFT-003 | P0 |
| QUALITY-001 | reviewer | readiness | CHECKPOINT-002 (or DRAFT-004) | P0 |
| CHECKPOINT-001 | supervisor | checkpoint | DRAFT-002 | P1 |
| CHECKPOINT-002 | supervisor | checkpoint | DRAFT-004 | P1 |
| CHECKPOINT-003 | supervisor | checkpoint | PLAN-001 | P1 |
| PLAN-001 | planner | planning | QUALITY-001 (or user input) | P0 |
| ARCH-001 | architect | arch-detail | PLAN-001 | P1 |
| ORCH-001 | orchestrator | orchestration | PLAN-001 or ARCH-001 | P1 |
| IMPL-001 | implementer | implementation | PLAN-001 or ORCH-001 | P0 |
| IMPL-{N} | implementer | implementation | ORCH-001 | P0 |
| TEST-001 | tester | validation | IMPL-* | P0 |
| REVIEW-001 | reviewer | review | IMPL-* | P0 |
## 8. Dynamic Specialist Injection
When task content or user request matches trigger keywords, inject a specialist task.
| Trigger Keywords | Specialist Role | Task Prefix | Priority | Insert After |
|------------------|----------------|-------------|----------|--------------|
| security, vulnerability, OWASP | security-expert | SECURITY-* | P0 | PLAN |
| performance, optimization, latency | performance-optimizer | PERF-* | P1 | IMPL |
| data, pipeline, ETL, migration | data-engineer | DATA-* | P0 | parallel with IMPL |
| devops, CI/CD, deployment, infra | devops-engineer | DEVOPS-* | P1 | IMPL |
| ML, model, training, inference | ml-engineer | ML-* | P0 | parallel with IMPL |
**Injection rules**:
- Specialist tasks inherit the session context and wisdom
- They write discoveries/{task_id}.json on completion like any other task
- P0 specialists block downstream tasks; P1 run in parallel

130
.codex/skills/team-lifecycle-v4/specs/quality-gates.md Normal file
View File

@@ -0,0 +1,130 @@
# Quality Gates
## 1. Quality Thresholds
| Result | Score | Action |
|--------|-------|--------|
| Pass | >= 80% | Proceed to next phase |
| Review | 60-79% | Revise flagged items, re-evaluate |
| Fail | < 60% | Return to producer for rework |
## 2. Scoring Dimensions
| Dimension | Weight | Criteria |
|-----------|--------|----------|
| Completeness | 25% | All required sections present with substantive content |
| Consistency | 25% | Terminology, formatting, cross-references are uniform |
| Traceability | 25% | Clear chain: Goals -> Requirements -> Architecture -> Stories |
| Depth | 25% | ACs are testable, ADRs justified, stories estimable |
**Score** = weighted average of all dimensions (0-100 per dimension).
## 3. Per-Phase Quality Gates
### Phase 2: Product Brief
| Check | Pass Criteria |
|-------|---------------|
| Vision statement | Clear, one-paragraph, measurable outcome |
| Problem definition | Specific pain points with evidence |
| Target users | Defined personas or segments |
| Success goals | Quantifiable metrics (KPIs) |
| Success metrics | Measurement method specified |
### Phase 3: Requirements PRD
| Check | Pass Criteria |
|-------|---------------|
| Functional requirements | Each has unique ID (FR-NNN) |
| Acceptance criteria | Testable given/when/then format |
| Prioritization | MoSCoW applied to all requirements |
| User stories | Format: As a [role], I want [goal], so that [benefit] |
| Non-functional reqs | Performance, security, scalability addressed |
### Phase 4: Architecture
| Check | Pass Criteria |
|-------|---------------|
| Component diagram | All major components identified with boundaries |
| Tech stack | Each choice justified against alternatives |
| ADRs | At least 1 ADR per major decision, with status |
| Data model | Entities, relationships, key fields defined |
| Integration points | APIs, protocols, data formats specified |
### Phase 5: Epics & Stories
| Check | Pass Criteria |
|-------|---------------|
| Epic count | 2-8 epics (too few = too broad, too many = too granular) |
| MVP subset | Clearly marked MVP epics/stories |
| Stories per epic | 3-12 stories each |
| Story format | Title, description, ACs, estimate present |
### Phase 6: Readiness Gate
| Check | Pass Criteria |
|-------|---------------|
| All docs exist | Brief, PRD, Architecture, Epics all present |
| Cross-refs valid | All document references resolve correctly |
| Overall score | >= 60% across all dimensions |
| No P0 issues | Zero Error-class issues outstanding |
## 4. Cross-Document Validation
| Source | Target | Validation |
|--------|--------|------------|
| Brief goals | PRD requirements | Every goal has >= 1 requirement |
| PRD requirements | Architecture components | Every requirement maps to a component |
| PRD requirements | Epic stories | Every requirement covered by >= 1 story |
| Architecture components | Epic stories | Every component has implementation stories |
| Brief success metrics | Epic ACs | Metrics traceable to acceptance criteria |
## 5. Code Review Dimensions
For REVIEW-* tasks during implementation phases.
### Quality
| Check | Severity |
|-------|----------|
| Empty catch blocks | Error |
| `as any` type casts | Warning |
| `@ts-ignore` / `@ts-expect-error` | Warning |
| `console.log` in production code | Warning |
| Unused imports/variables | Info |
### Security
| Check | Severity |
|-------|----------|
| Hardcoded secrets/credentials | Error |
| SQL injection vectors | Error |
| `eval()` or `Function()` usage | Error |
| `innerHTML` assignment | Warning |
| Missing input validation | Warning |
### Architecture
| Check | Severity |
|-------|----------|
| Circular dependencies | Error |
| Deep cross-boundary imports (3+ levels) | Warning |
| Files > 500 lines | Warning |
| Functions > 50 lines | Info |
### Requirements Coverage
| Check | Severity |
|-------|----------|
| Core functionality implemented | Error if missing |
| Acceptance criteria covered | Error if missing |
| Edge cases handled | Warning |
| Error states handled | Warning |
## 6. Issue Classification
| Class | Label | Action |
|-------|-------|--------|
| Error | Must fix | Blocks progression, must resolve before proceeding |
| Warning | Should fix | Should resolve, can proceed with justification |
| Info | Nice to have | Optional improvement, log for future |