claude-code-workflow 7.2.15 → 7.2.16

package/.codex/skills/team-lifecycle/phases/05-completion-report.md

@@ -1,309 +0,0 @@
-# Phase 5: Completion Report
-
-> **COMPACT PROTECTION**: This is an execution document. After context compression, phase instructions become summaries only. You MUST immediately re-read this file via `Read("~/~  or <project>/.codex/skills/team-lifecycle/phases/05-completion-report.md")` before continuing. Never execute based on summaries.
-
-## Objective
-
-Summarize pipeline results, list all deliverable artifacts, update session status to completed, close any remaining agents, and present the user with next-step options.
-
----
-
-## Input
-
-| Input | Source | Required |
-|-------|--------|----------|
-| sessionDir | Phase 2 output | Yes |
-| state | team-session.json (final) | Yes |
-| state.pipeline | All tasks with final status | Yes |
-| state.mode | Pipeline mode | Yes |
-| state.started_at | Session start timestamp | Yes |
-
----
-
-## Execution Steps
-
-### Step 5.1: Load Final State
-
-```javascript
-const state = JSON.parse(Read("<session-dir>/team-session.json"))
-```
-
-### Step 5.2: Agent Cleanup
-
-Close any remaining active agents (defensive -- should be none at this point).
-
-```javascript
-for (const agentEntry of state.active_agents) {
-  try {
-    close_agent({ id: agentEntry.agent_id })
-  } catch (e) {
-    // Agent already closed, ignore
-  }
-}
-state.active_agents = []
-```
-
-### Step 5.3: Compute Summary Statistics
-
-```javascript
-const totalTasks = state.pipeline.length
-const completedTasks = state.pipeline.filter(t => t.status === "completed").length
-const failedTasks = state.pipeline.filter(t => t.status === "failed").length
-const partialTasks = state.pipeline.filter(t => t.status === "partial").length
-const revisionTasks = state.pipeline.filter(t => t.revision_of !== null).length
-
-const startTime = new Date(state.started_at)
-const endTime = new Date()
-const durationMs = endTime - startTime
-const durationMin = Math.round(durationMs / 60000)
-
-const successRate = totalTasks > 0
-  ? Math.round((completedTasks / totalTasks) * 100)
-  : 0
-```
-
-### Step 5.4: Collect Deliverable Artifacts
-
-Scan completed tasks for artifact paths. Group by pipeline phase.
-
-```javascript
-const artifacts = {
-  spec: [],
-  plan: [],
-  impl: [],
-  test: [],
-  review: [],
-  discussions: [],
-  qa: []
-}
-
-for (const task of state.pipeline) {
-  if (task.status !== "completed" || !task.artifact_path) continue
-
-  if (task.id.startsWith("RESEARCH") || task.id.startsWith("DRAFT") || task.id.startsWith("QUALITY")) {
-    artifacts.spec.push({ task_id: task.id, path: task.artifact_path })
-  } else if (task.id.startsWith("PLAN")) {
-    artifacts.plan.push({ task_id: task.id, path: task.artifact_path })
-  } else if (task.id.startsWith("IMPL") || task.id.startsWith("DEV-FE")) {
-    artifacts.impl.push({ task_id: task.id, path: task.artifact_path })
-  } else if (task.id.startsWith("TEST")) {
-    artifacts.test.push({ task_id: task.id, path: task.artifact_path })
-  } else if (task.id.startsWith("REVIEW")) {
-    artifacts.review.push({ task_id: task.id, path: task.artifact_path })
-  } else if (task.id.startsWith("QA-FE")) {
-    artifacts.qa.push({ task_id: task.id, path: task.artifact_path })
-  }
-}
-
-// Also collect discussion records
-const discussionFiles = Glob("<session-dir>/discussions/*.md")
-for (const df of discussionFiles) {
-  artifacts.discussions.push({ path: df })
-}
-```
-
-### Step 5.5: Collect Wisdom Summary
-
-Read wisdom files to include key findings in the report.
-
-```javascript
-const wisdomSummary = {
-  learnings: Read("<session-dir>/wisdom/learnings.md") || "(none)",
-  decisions: Read("<session-dir>/wisdom/decisions.md") || "(none)",
-  conventions: Read("<session-dir>/wisdom/conventions.md") || "(none)",
-  issues: Read("<session-dir>/wisdom/issues.md") || "(none)"
-}
-```
-
-### Step 5.6: Check for Consensus Warnings
-
-Collect any consensus-blocked results across the pipeline.
-
-```javascript
-const consensusIssues = state.pipeline
-  .filter(t => t.discuss_verdict === "consensus_blocked")
-  .map(t => ({
-    task_id: t.id,
-    severity: t.discuss_severity,
-    revision: t.revision_of ? `revised as ${state.revision_chains[t.revision_of]}` : null
-  }))
-```
-
-### Step 5.7: Update Session Status
-
-```javascript
-state.status = "completed"
-state.updated_at = new Date().toISOString()
-state.completed_at = new Date().toISOString()
-
-Write("<session-dir>/team-session.json",
-  JSON.stringify(state, null, 2))
-
-// Update message bus meta.json status
-const meta = JSON.parse(Read("<session-dir>/.msg/meta.json"))
-meta.status = "completed"
-meta.updated_at = new Date().toISOString()
-Write("<session-dir>/.msg/meta.json", JSON.stringify(meta, null, 2))
-
-// Log completion event to message bus
-const msgCounter = getLastMsgCounter("<session-dir>/.msg/messages.jsonl") + 1
-logToMessageBus("<session-dir>", msgCounter, {
-  from: "coordinator",
-  type: "shutdown",
-  summary: `Pipeline completed: ${completedTasks}/${totalTasks} tasks (${successRate}%)`,
-  data: {
-    tasks_completed: completedTasks,
-    tasks_total: totalTasks,
-    success_rate: successRate,
-    duration_min: durationMin,
-    failed_tasks: failedTasks
-  }
-})
-```
-
-### Step 5.8: Output Completion Report
-
-Format and display the final report to the user.
-
-```
-==============================================================
-[orchestrator] PIPELINE COMPLETE
-==============================================================
-
-Session: <session-id>
-Mode: <mode>
-Duration: <duration-min> minutes
-Progress: <completed>/<total> tasks (<success-rate>%)
-
---------------------------------------------------------------
-TASK SUMMARY
---------------------------------------------------------------
-| Task ID | Agent | Status | Discuss | Artifact |
-|---------|-------|--------|---------|----------|
-| RESEARCH-001 | analyst | V | DISCUSS-001: reached | spec/discovery-context.json |
-| DRAFT-001 | writer | V | DISCUSS-002: reached | spec/product-brief.md |
-| ... | ... | ... | ... | ... |
-
-V=completed  X=failed  ~=partial  R=revision
-
---------------------------------------------------------------
-DELIVERABLES
---------------------------------------------------------------
-
-Specification:
-  <artifact-list from artifacts.spec>
-
-Plan:
-  <artifact-list from artifacts.plan>
-
-Implementation:
-  <artifact-list from artifacts.impl>
-
-Testing:
-  <artifact-list from artifacts.test>
-
-Review:
-  <artifact-list from artifacts.review>
-
-Discussions:
-  <discussion-file-list>
-
-QA:
-  <artifact-list from artifacts.qa>
-
---------------------------------------------------------------
-CONSENSUS NOTES
---------------------------------------------------------------
-<if consensusIssues.length > 0>
-  <for each issue>
-    <task-id>: consensus_blocked (<severity>) <revision-note>
-  <end>
-<else>
-  All discussions reached consensus.
-<end>
-
---------------------------------------------------------------
-WISDOM HIGHLIGHTS
---------------------------------------------------------------
-Key learnings: <summary from wisdom/learnings.md>
-Key decisions: <summary from wisdom/decisions.md>
-Issues flagged: <summary from wisdom/issues.md>
-
---------------------------------------------------------------
-NEXT STEPS
---------------------------------------------------------------
-Available actions:
-  1. Exit - session complete
-  2. View artifacts - read specific deliverable files
-  3. Extend - add more tasks to this pipeline
-  4. New session - start a fresh lifecycle
-  5. Generate lite-plan - create a lightweight implementation plan from spec
-
-Session directory: <session-dir>
-==============================================================
-```
-
-### Step 5.9: Handle User Response
-
-After presenting the report, wait for user input.
-
-| User Choice | Action |
-|-------------|--------|
-| exit / done | Final cleanup, orchestrator stops |
-| view `<artifact-path>` | Read and display the specified artifact |
-| extend `<description>` | Re-enter Phase 1 with extend context, resume session |
-| new `<description>` | Start fresh Phase 1 (new session) |
-| lite-plan | Generate implementation plan from completed spec |
-
-For "extend": the orchestrator reads the existing session, appends new requirements, and re-enters Phase 3 to create additional tasks appended to the existing pipeline.
-
-For "view": simply read the requested file and display contents, then re-present the next steps menu.
-
----
-
-## Output
-
-| Output | Type | Destination |
-|--------|------|-------------|
-| Completion report | Text | Displayed to user |
-| Updated state | JSON | team-session.json with status="completed" |
-| User choice | String | Determines post-pipeline action |
-
----
-
-## Success Criteria
-
-- All agents closed (no orphaned agents)
-- State file updated to status="completed"
-- All artifact paths verified (files exist)
-- Completion report includes all task statuses
-- Consensus issues documented
-- Wisdom highlights extracted
-- Next steps presented to user
-
----
-
-## Error Handling
-
-| Error | Resolution |
-|-------|------------|
-| State file read error | Attempt to reconstruct from available artifacts |
-| Artifact file missing | Report as "(artifact missing)" in deliverables list |
-| Agent close failure | Ignore (agent already closed) |
-| Wisdom file empty | Report "(no entries)" for that category |
-| User input not recognized | Re-present available options |
-
----
-
-## Post-Pipeline
-
-This is the final phase. The orchestrator either stops (exit) or loops back to an earlier phase based on user choice.
-
-```
-User choice routing:
-  exit     -> orchestrator stops
-  view     -> display file -> re-present Step 5.9
-  extend   -> Phase 1 (with resume context) -> Phase 3 -> Phase 4 -> Phase 5
-  new      -> Phase 1 (fresh) -> Phase 2 -> Phase 3 -> Phase 4 -> Phase 5
-  lite-plan -> generate plan from spec artifacts -> present to user
-```

package/.codex/skills/team-lifecycle/specs/document-standards.md

@@ -1,192 +0,0 @@
-# Document Standards
-
-Defines format conventions, YAML frontmatter schema, naming rules, and content structure for all spec-generator outputs.
-
-## When to Use
-
-| Phase | Usage | Section |
-|-------|-------|---------|
-| All Phases | Frontmatter format | YAML Frontmatter Schema |
-| All Phases | File naming | Naming Conventions |
-| Phase 2-5 | Document structure | Content Structure |
-| Phase 6 | Validation reference | All sections |
-
----
-
-## YAML Frontmatter Schema
-
-Every generated document MUST begin with YAML frontmatter:
-
-```yaml
----
-session_id: SPEC-{slug}-{YYYY-MM-DD}
-phase: {1-6}
-document_type: {product-brief|requirements|architecture|epics|readiness-report|spec-summary}
-status: draft|review|complete
-generated_at: {ISO8601 timestamp}
-stepsCompleted: []
-version: 1
-dependencies:
-  - {list of input documents used}
----
-```
-
-### Field Definitions
-
-| Field | Type | Required | Description |
-|-------|------|----------|-------------|
-| `session_id` | string | Yes | Session identifier matching spec-config.json |
-| `phase` | number | Yes | Phase number that generated this document (1-6) |
-| `document_type` | string | Yes | One of: product-brief, requirements, architecture, epics, readiness-report, spec-summary |
-| `status` | enum | Yes | draft (initial), review (user reviewed), complete (finalized) |
-| `generated_at` | string | Yes | ISO8601 timestamp of generation |
-| `stepsCompleted` | array | Yes | List of step IDs completed during generation |
-| `version` | number | Yes | Document version, incremented on re-generation |
-| `dependencies` | array | No | List of input files this document depends on |
-
-### Status Transitions
-
-```
-draft -> review -> complete
-  |                   ^
-  +-------------------+  (direct promotion in auto mode)
-```
-
-- **draft**: Initial generation, not yet user-reviewed
-- **review**: User has reviewed and provided feedback
-- **complete**: Finalized, ready for downstream consumption
-
-In auto mode (`-y`), documents are promoted directly from `draft` to `complete`.
-
----
-
-## Naming Conventions
-
-### Session ID Format
-
-```
-SPEC-{slug}-{YYYY-MM-DD}
-```
-
-- **slug**: Lowercase, alphanumeric + Chinese characters, hyphens as separators, max 40 chars
-- **date**: UTC+8 date in YYYY-MM-DD format
-
-Examples:
-- `SPEC-task-management-system-2026-02-11`
-- `SPEC-user-auth-oauth-2026-02-11`
-
-### Output Files
-
-| File | Phase | Description |
-|------|-------|-------------|
-| `spec-config.json` | 1 | Session configuration and state |
-| `discovery-context.json` | 1 | Codebase exploration results (optional) |
-| `product-brief.md` | 2 | Product brief document |
-| `requirements.md` | 3 | PRD document |
-| `architecture.md` | 4 | Architecture decisions document |
-| `epics.md` | 5 | Epic/Story breakdown document |
-| `readiness-report.md` | 6 | Quality validation report |
-| `spec-summary.md` | 6 | One-page executive summary |
-
-### Output Directory
-
-```
-.workflow/.spec/{session-id}/
-```
-
----
-
-## Content Structure
-
-### Heading Hierarchy
-
-- `#` (H1): Document title only (one per document)
-- `##` (H2): Major sections
-- `###` (H3): Subsections
-- `####` (H4): Detail items (use sparingly)
-
-Maximum depth: 4 levels. Prefer flat structures.
-
-### Section Ordering
-
-Every document follows this general pattern:
-
-1. **YAML Frontmatter** (mandatory)
-2. **Title** (H1)
-3. **Executive Summary** (2-3 sentences)
-4. **Core Content Sections** (H2, document-specific)
-5. **Open Questions / Risks** (if applicable)
-6. **References / Traceability** (links to upstream/downstream docs)
-
-### Formatting Rules
-
-| Element | Format | Example |
-|---------|--------|---------|
-| Requirements | `REQ-{NNN}` prefix | REQ-001: User login |
-| Acceptance criteria | Checkbox list | `- [ ] User can log in with email` |
-| Architecture decisions | `ADR-{NNN}` prefix | ADR-001: Use PostgreSQL |
-| Epics | `EPIC-{NNN}` prefix | EPIC-001: Authentication |
-| Stories | `STORY-{EPIC}-{NNN}` prefix | STORY-001-001: Login form |
-| Priority tags | MoSCoW labels | `[Must]`, `[Should]`, `[Could]`, `[Won't]` |
-| Mermaid diagrams | Fenced code blocks | ````mermaid ... ``` `` |
-| Code examples | Language-tagged blocks | ````typescript ... ``` `` |
-
-### Cross-Reference Format
-
-Use relative references between documents:
-
-```markdown
-See [Product Brief](product-brief.md#section-name) for details.
-Derived from [REQ-001](requirements.md#req-001).
-```
-
-### Language
-
-- Document body: Follow user's input language (Chinese or English)
-- Technical identifiers: Always English (REQ-001, ADR-001, EPIC-001)
-- YAML frontmatter keys: Always English
-
----
-
-## spec-config.json Schema
-
-```json
-{
-  "session_id": "string (required)",
-  "seed_input": "string (required) - original user input",
-  "input_type": "text|file (required)",
-  "timestamp": "ISO8601 (required)",
-  "mode": "interactive|auto (required)",
-  "complexity": "simple|moderate|complex (required)",
-  "depth": "light|standard|comprehensive (required)",
-  "focus_areas": ["string array"],
-  "seed_analysis": {
-    "problem_statement": "string",
-    "target_users": ["string array"],
-    "domain": "string",
-    "constraints": ["string array"],
-    "dimensions": ["string array - 3-5 exploration dimensions"]
-  },
-  "has_codebase": "boolean",
-  "phasesCompleted": [
-    {
-      "phase": "number (1-6)",
-      "name": "string (phase name)",
-      "output_file": "string (primary output file)",
-      "completed_at": "ISO8601"
-    }
-  ]
-}
-```
-
----
-
-## Validation Checklist
-
-- [ ] Every document starts with valid YAML frontmatter
-- [ ] `session_id` matches across all documents in a session
-- [ ] `status` field reflects current document state
-- [ ] All cross-references resolve to valid targets
-- [ ] Heading hierarchy is correct (no skipped levels)
-- [ ] Technical identifiers use correct prefixes
-- [ ] Output files are in the correct directory

package/.codex/skills/team-lifecycle/specs/quality-gates.md

@@ -1,207 +0,0 @@
-# Quality Gates
-
-Per-phase quality gate criteria and scoring dimensions for spec-generator outputs.
-
-## When to Use
-
-| Phase | Usage | Section |
-|-------|-------|---------|
-| Phase 2-5 | Post-generation self-check | Per-Phase Gates |
-| Phase 6 | Cross-document validation | Cross-Document Validation |
-| Phase 6 | Final scoring | Scoring Dimensions |
-
----
-
-## Quality Thresholds
-
-| Gate | Score | Action |
-|------|-------|--------|
-| **Pass** | >= 80% | Continue to next phase |
-| **Review** | 60-79% | Log warnings, continue with caveats |
-| **Fail** | < 60% | Must address issues before continuing |
-
-In auto mode (`-y`), Review-level issues are logged but do not block progress.
-
----
-
-## Scoring Dimensions
-
-### 1. Completeness (25%)
-
-All required sections present with substantive content.
-
-| Score | Criteria |
-|-------|----------|
-| 100% | All template sections filled with detailed content |
-| 75% | All sections present, some lack detail |
-| 50% | Major sections present but minor sections missing |
-| 25% | Multiple major sections missing or empty |
-| 0% | Document is a skeleton only |
-
-### 2. Consistency (25%)
-
-Terminology, formatting, and references are uniform across documents.
-
-| Score | Criteria |
-|-------|----------|
-| 100% | All terms consistent, all references valid, formatting uniform |
-| 75% | Minor terminology variations, all references valid |
-| 50% | Some inconsistent terms, 1-2 broken references |
-| 25% | Frequent inconsistencies, multiple broken references |
-| 0% | Documents contradict each other |
-
-### 3. Traceability (25%)
-
-Requirements, architecture decisions, and stories trace back to goals.
-
-| Score | Criteria |
-|-------|----------|
-| 100% | Every story traces to a requirement, every requirement traces to a goal |
-| 75% | Most items traceable, few orphans |
-| 50% | Partial traceability, some disconnected items |
-| 25% | Weak traceability, many orphan items |
-| 0% | No traceability between documents |
-
-### 4. Depth (25%)
-
-Content provides sufficient detail for execution teams.
-
-| Score | Criteria |
-|-------|----------|
-| 100% | Acceptance criteria specific and testable, architecture decisions justified, stories estimable |
-| 75% | Most items detailed enough, few vague areas |
-| 50% | Mix of detailed and vague content |
-| 25% | Mostly high-level, lacking actionable detail |
-| 0% | Too abstract for execution |
-
----
-
-## Per-Phase Quality Gates
-
-### Phase 1: Discovery
-
-| Check | Criteria | Severity |
-|-------|----------|----------|
-| Session ID valid | Matches `SPEC-{slug}-{date}` format | Error |
-| Problem statement exists | Non-empty, >= 20 characters | Error |
-| Target users identified | >= 1 user group | Error |
-| Dimensions generated | 3-5 exploration dimensions | Warning |
-| Constraints listed | >= 0 (can be empty with justification) | Info |
-
-### Phase 2: Product Brief
-
-| Check | Criteria | Severity |
-|-------|----------|----------|
-| Vision statement | Clear, 1-3 sentences | Error |
-| Problem statement | Specific and measurable | Error |
-| Target users | >= 1 persona with needs described | Error |
-| Goals defined | >= 2 measurable goals | Error |
-| Success metrics | >= 2 quantifiable metrics | Warning |
-| Scope boundaries | In-scope and out-of-scope listed | Warning |
-| Multi-perspective | >= 2 CLI perspectives synthesized | Info |
-
-### Phase 3: Requirements (PRD)
-
-| Check | Criteria | Severity |
-|-------|----------|----------|
-| Functional requirements | >= 3 with REQ-NNN IDs | Error |
-| Acceptance criteria | Every requirement has >= 1 criterion | Error |
-| MoSCoW priority | Every requirement tagged | Error |
-| Non-functional requirements | >= 1 (performance, security, etc.) | Warning |
-| User stories | >= 1 per Must-have requirement | Warning |
-| Traceability | Requirements trace to product brief goals | Warning |
-
-### Phase 4: Architecture
-
-| Check | Criteria | Severity |
-|-------|----------|----------|
-| Component diagram | Present (Mermaid or ASCII) | Error |
-| Tech stack specified | Languages, frameworks, key libraries | Error |
-| ADR present | >= 1 Architecture Decision Record | Error |
-| ADR has alternatives | Each ADR lists >= 2 options considered | Warning |
-| Integration points | External systems/APIs identified | Warning |
-| Data model | Key entities and relationships described | Warning |
-| Codebase mapping | Mapped to existing code (if has_codebase) | Info |
-
-### Phase 5: Epics & Stories
-
-| Check | Criteria | Severity |
-|-------|----------|----------|
-| Epics defined | 3-7 epics with EPIC-NNN IDs | Error |
-| MVP subset | >= 1 epic tagged as MVP | Error |
-| Stories per epic | 2-5 stories per epic | Error |
-| Story format | "As a...I want...So that..." pattern | Warning |
-| Dependency map | Cross-epic dependencies documented | Warning |
-| Estimation hints | Relative sizing (S/M/L/XL) per story | Info |
-| Traceability | Stories trace to requirements | Warning |
-
-### Phase 6: Readiness Check
-
-| Check | Criteria | Severity |
-|-------|----------|----------|
-| All documents exist | product-brief, requirements, architecture, epics | Error |
-| Frontmatter valid | All YAML frontmatter parseable and correct | Error |
-| Cross-references valid | All document links resolve | Error |
-| Overall score >= 60% | Weighted average across 4 dimensions | Error |
-| No unresolved Errors | All Error-severity issues addressed | Error |
-| Summary generated | spec-summary.md created | Warning |
-
----
-
-## Cross-Document Validation
-
-Checks performed during Phase 6 across all documents:
-
-### Completeness Matrix
-
-```
-Product Brief goals  ->  Requirements (each goal has >= 1 requirement)
-Requirements         ->  Architecture (each Must requirement has design coverage)
-Requirements         ->  Epics (each Must requirement appears in >= 1 story)
-Architecture ADRs    ->  Epics (tech choices reflected in implementation stories)
-```
-
-### Consistency Checks
-
-| Check | Documents | Rule |
-|-------|-----------|------|
-| Terminology | All | Same term used consistently (no synonyms for same concept) |
-| User personas | Brief + PRD + Epics | Same user names/roles throughout |
-| Scope | Brief + PRD | PRD scope does not exceed brief scope |
-| Tech stack | Architecture + Epics | Stories reference correct technologies |
-
-### Traceability Matrix Format
-
-```markdown
-| Goal | Requirements | Architecture | Epics |
-|------|-------------|--------------|-------|
-| G-001: ... | REQ-001, REQ-002 | ADR-001 | EPIC-001 |
-| G-002: ... | REQ-003 | ADR-002 | EPIC-002, EPIC-003 |
-```
-
----
-
-## Issue Classification
-
-### Error (Must Fix)
-
-- Missing required document or section
-- Broken cross-references
-- Contradictory information between documents
-- Empty acceptance criteria on Must-have requirements
-- No MVP subset defined in epics
-
-### Warning (Should Fix)
-
-- Vague acceptance criteria
-- Missing non-functional requirements
-- No success metrics defined
-- Incomplete traceability
-- Missing architecture review notes
-
-### Info (Nice to Have)
-
-- Could add more detailed personas
-- Consider additional ADR alternatives
-- Story estimation hints missing
-- Mermaid diagrams could be more detailed