Ijfw Team

IJFW Team Assembly

Assembles a project-specific operating team. Team Assembly is project-agnostic: it works for software, books, content, design, research, business strategy, education, operations, and mixed projects.

Do not treat every team as a code-generation swarm. Generate the agents plus the operating contracts that let those agents coordinate around artifacts, claims, reviews, and handoffs.

CLI entry point: ijfw team init [--archetype <type>] [--name <team-name>]. ijfw team is the skill/workflow trigger; ijfw team init is the concrete command that writes .ijfw/team/, .ijfw/agents/, and Codex agent files.

How It Works

1. Receive project brief from Discovery stage (or ask for context)
2. Infer one or more project archetypes and artifact types
3. Identify the roles needed for creation, review, integration, and verification
4. Generate portable agent markdown files with proper frontmatter
5. Generate Codex custom-agent TOML when the Codex surface is present
6. Generate the team charter and workflow manifest
7. Present the proposed team and operating model for approval
8. Save approved outputs to .ijfw/agents/, .codex/agents/, and .ijfw/team/ as applicable

Operating Outputs

Team Assembly 2.0 produces three coordinated surfaces:

• .ijfw/agents/*.md -- portable human/platform-readable agent definitions
• .codex/agents/*.toml -- Codex custom agents generated from the same role contracts when Codex is installed or ijfw codex sync-agents is run
• .ijfw/team/charter.json -- team roster, role contracts, phase scope, owned artifacts, reviewed artifacts, conflict rules, handoff requirements, verification responsibilities
• .ijfw/team/workflow.json -- project work manifest: archetypes, artifacts, owners, dependencies, waves, review graph, verification commands or rubrics

Keep .ijfw/agents/*.md lightweight and role-focused. Put machine-readable ownership, dependency, review, and coordination details in the charter and workflow manifest.

Codex TOML agents are platform-native projections, not a separate source of truth. Regenerate them with ijfw codex sync-agents after changing the team charter, and check the local Codex install with ijfw codex doctor.

Project Archetypes

Infer archetypes from the brief, repository signals, existing files, and user corrections. Support mixed projects instead of forcing one label.

Common archetypes:

• software -- modules, APIs, tests, config, docs
• design -- screens, flows, tokens, components, prototypes
• content -- briefs, articles, landing copy, scripts, social posts
• book -- chapters, outline, continuity bible, timeline, notes
• research -- questions, corpus, methods, evidence table, synthesis
• business -- strategy docs, operating plans, models, risk register
• education -- curriculum, lessons, assessments, rubrics
• operations -- SOPs, workflows, runbooks, checklists
• mixed -- any project-specific combination

Domain Templates (starting points -- always customize to the project)

Software Development

• product-lead (sonnet) -- requirements, user stories, acceptance criteria
• architect (opus, high effort) -- system design, security, data model, API design
• senior-dev (sonnet) -- complex implementation, patterns, code review
• dev (sonnet) -- feature implementation, tests, bug fixes
• qa (sonnet) -- test strategy, edge cases, regression testing
• security (opus, high effort) -- threat model, auth, data protection, pen testing
• devops (haiku) -- CI/CD, deployment, infrastructure, monitoring
• docs (haiku) -- documentation, API docs, READMEs, guides

Book / Long-Form Writing

• story-architect (opus, high effort) -- plot structure, pacing, arcs, tension
• world-builder (sonnet) -- settings, environments, atmosphere, sensory detail
• lore-master (haiku) -- continuity bible, rules, history, faction tracking
• prose-stylist (sonnet) -- voice, tone, sentence craft, genre conventions
• continuity-editor (haiku) -- cross-chapter consistency, timeline, character tracking
• beta-reader (sonnet) -- fresh-eyes review, plot holes, reader experience

Content / Marketing

• strategist (opus, high effort) -- campaign strategy, audience, positioning
• copywriter (sonnet) -- headlines, body copy, CTAs, tone of voice
• seo-specialist (haiku) -- keywords, structure, meta, search intent
• editor (sonnet) -- clarity, grammar, consistency, brand voice
• social-media (haiku) -- platform adaptation, hooks, engagement

Business / Strategy

• ceo (opus, high effort) -- vision, strategy, decision-making, priorities
• cto (opus, high effort) -- technical strategy, architecture, build-vs-buy
• analyst (sonnet) -- research, data analysis, market assessment
• operations (sonnet) -- process design, workflows, efficiency
• finance (haiku) -- budgets, projections, cost analysis

Design / Creative

• creative-director (opus, high effort) -- vision, aesthetic direction, brand
• ux-designer (sonnet) -- user flows, wireframes, usability, accessibility
• ui-designer (sonnet) -- visual design, components, responsive layout
• researcher (haiku) -- user research, competitive analysis, testing

Any Other Domain

If the project doesn't match a template above, ask: "What roles would you need on a team to build this well?"

Then generate agents from the user's description. Map each role to a model tier:

• Roles requiring deep reasoning, strategy, or high-stakes decisions -> opus
• Roles doing the primary creation/implementation work -> sonnet
• Roles doing reference checks, lookups, or routine tasks -> haiku

Examples of non-standard teams:

• Game dev: game-designer, level-designer, systems-programmer, qa-tester, narrative-writer
• Scientific research: principal-investigator, literature-reviewer, data-analyst, methodology-reviewer
• Music production: producer, songwriter, mixing-engineer, mastering-engineer
• Event planning: event-director, logistics-coordinator, vendor-manager, creative-designer
• Education: curriculum-designer, subject-expert, assessment-writer, accessibility-reviewer

The templates above are starting points. Every team is customized to the specific project.

Role Contract Guidance

Every role should have a contract in .ijfw/team/charter.json with:

• name, role_type, model, and effort
• phase_scope such as discovery, shape, execute, review, integrate
• owns entries for artifact types and path globs or non-file artifact IDs
• reviews entries with review criteria
• handoff format and required sections
• coordination rules including claim requirements and conflict boundaries
• verification responsibility: commands for code, rubrics for non-code work

Example contract shape:

{
  "name": "ux-researcher",
  "role_type": "research",
  "model": "sonnet",
  "effort": "medium",
  "phase_scope": ["discovery", "shape", "review"],
  "owns": [
    {"artifact_type": "user_flow", "paths": ["design/flows/**"]}
  ],
  "reviews": [
    {"artifact_type": "screen", "criteria": ["usability", "accessibility"]}
  ],
  "handoff": {
    "format": "markdown",
    "required_sections": ["findings", "risks", "recommendations", "changed_artifacts"]
  },
  "coordination": {
    "parallel_safe": true,
    "conflicts_with": ["ui-designer when editing design/tokens/**"],
    "claim_required": true
  }
}

Workflow Manifest Guidance

The workflow manifest describes work in domain terms. It is not just a file list and must not assume code-only verification.

Each artifact entry should include:

• stable id
• domain type
• paths where file-backed, or a non-file artifact reference
• owner
• reviewers
• depends_on
• verification as commands, checks, rubrics, or acceptance criteria

Each wave should include:

• id
• mode: parallel, sequential, or review
• artifact_ids
• dependency rationale when work cannot run in parallel

Example manifest shape:

{
  "project_archetypes": ["software", "design"],
  "artifacts": [
    {
      "id": "design-preview-flow",
      "type": "prototype",
      "paths": [".planning/brainstorm/*.html"],
      "owner": "ui-designer",
      "reviewers": ["ux-designer", "accessibility-reviewer"],
      "depends_on": [],
      "verification": ["ijfw design push .planning/brainstorm/*.html"]
    }
  ],
  "waves": [
    {
      "id": "w1",
      "mode": "parallel",
      "artifact_ids": ["schema-foundation", "design-command-docs"]
    }
  ]
}

Agent File Format

Each generated agent follows this structure:

---
name: <role-name>
model: <haiku|sonnet|opus>
effort: <low|medium|high>
description: <when to use this agent -- 1-2 lines>
allowed-tools: <relevant tools for this role>
---

<Role-specific instructions for this project>

Context from project brief:
<Relevant details from the brief that this agent needs>

Rules:
<Role-specific rules>