gru-ai 0.1.0

package/.claude/skills/directive/docs/pipeline/07b-project-brainstorm.md

@@ -0,0 +1,85 @@
+<!-- Pipeline doc: 07b-project-brainstorm.md | Source: pipeline-v2 directive -->
+
+## Project-Brainstorm: Task Decomposition
+
+After the CEO approves the COO's plan (approve step), each project needs task decomposition before execution. The COO defined WHAT projects to create and WHO works on them. This step defines HOW -- breaking each project into concrete tasks with DOD.
+
+### Participants
+
+- **The CTO** -- owns technical decomposition, DOD quality, sequencing
+- **The assigned builder** from the project's `agent` field -- provides implementation perspective, file-level scope awareness
+
+### Inputs
+
+The brainstorm participants receive:
+- **The COO's plan** (the approved project entry from plan.json) -- scope_summary, priority, cast
+- **Audit findings** (from audit step) -- active_files, baseline, recommended_approach per task scope area
+- **Directive brainstorm** (if it exists, from `.context/directives/{directive-id}/brainstorm.md`) -- approach decisions made during strategic/heavyweight brainstorm
+- **Vision guardrails** (`.context/vision.md`) and **CEO preferences** (`.context/preferences.md`)
+- **Relevant lessons** (`.context/lessons/` topic files matched to the project domain)
+
+### Process
+
+**For simple projects** (complexity = `simple`): The CTO produces the task breakdown solo. Spawn the CTO with the inputs above and the project brainstorm prompt below.
+
+**For moderate/complex projects**: Spawn the CTO + the assigned builder in sequence. The CTO produces the initial task breakdown, then the builder reviews and suggests adjustments based on implementation knowledge.
+
+### Project Brainstorm Prompt
+
+```
+You are decomposing a project into executable tasks. The project scope and cast are already decided. Your job is to define the TASKS -- what gets built, in what order, with what acceptance criteria.
+
+PROJECT:
+{project entry from the COO's plan -- id, title, scope_summary, agent, reviewers, auditor}
+
+AUDIT FINDINGS:
+{audit output for this project's scope area -- active_files, baseline, recommended_approach}
+
+DIRECTIVE BRAINSTORM (if available):
+{brainstorm.md content -- approach decisions, key constraints}
+
+For this project, produce a tasks array. Each task is a buildable unit that one engineer completes in one session.
+
+TASK DECOMPOSITION RULES:
+- Each task must be completable by the assigned builder in a single focused session
+- Tasks execute sequentially by array order -- this IS the dependency mechanism
+- Earlier tasks should establish foundations that later tasks build on
+- Each task needs 3-5 concrete, testable DOD criteria
+- DOD criteria must be verifiable by the reviewer (not vague like "improve quality")
+- Include the right phases for each task: simple fix = ["build", "review"], integration work = ["build", "code-review", "review"]
+
+OUTPUT (JSON):
+{
+  "project_id": "the project id",
+  "tasks": [
+    {
+      "id": "task-slug",
+      "title": "Human-readable task title",
+      "priority": "P0 | P1 | P2",
+      "complexity": "simple",
+      "phases": ["build", "review"],
+      "user_scenario": "One sentence: how the user will experience this change when it ships",
+      "scope": "2-4 sentences: what needs to happen in this task",
+      "definition_of_done": ["Concrete, testable criterion 1", "Criterion 2", "..."]
+    }
+  ],
+  "sequencing_rationale": "1-2 sentences explaining why the tasks are in this order"
+}
+
+CRITICAL: First character `{`, last `}`. JSON only.
+```
+
+### After Project Brainstorm
+
+1. **Parse the output** as JSON. If it fails to parse, re-prompt.
+2. **Write tasks into project.json** -- update the project.json created in the approve step with the full `tasks` array. Each task gets `status: "pending"`, `agent` from the project cast, and `dod` from the brainstorm output (each criterion as `{ "criterion": "...", "met": false }`).
+3. **Validate project.json** -- run `validate-project-json.sh` to confirm tasks, DOD, and agent fields are present.
+
+### When to Skip
+
+- **Lightweight directives** skip this step entirely -- they have no COO plan and no project.json.
+- If the project already has a `tasks` array populated (e.g., from a prior partial run or manual creation), skip the brainstorm and proceed to execution.
+
+### Update directive.json
+
+Set `current_step: "project-brainstorm"`. Update `pipeline["project-brainstorm"].status` to `"completed"` with output summary.

package/.claude/skills/directive/docs/pipeline/08-worktree-and-state.md

@@ -0,0 +1,50 @@
+<!-- Pipeline doc: 08-worktree-and-state.md | Source: SKILL.md restructure -->
+
+## Setup: Branch / Worktree Isolation
+
+After CEO approval, create a branch to isolate directive changes.
+
+**Default: branch-only (no worktree).** Create a branch for the directive:
+
+```bash
+git checkout -b directive/$ARGUMENTS
+```
+
+**Use worktree ONLY when** `git status` shows uncommitted changes that should be preserved. In that case:
+
+```bash
+git worktree add ../sw-directive-$ARGUMENTS -b directive/$ARGUMENTS
+```
+
+If the worktree already exists, reuse it. All agent spawn prompts must include `"Working directory: {worktree_path}"` so agents operate in the isolated copy.
+
+At the end (wrapup step), tell the CEO the branch name so they can review with `git diff main..directive/$ARGUMENTS`.
+
+**Skip isolation entirely if:** the user explicitly says "no branch", or all task phases are research-only (no code changes).
+
+**Update directive.json:** Set `current_step: "setup"`, `planning.worktree_path` to the worktree path (or null if branch-only or skipped). Update `pipeline.setup.status` to `"completed"` with output.
+
+## Setup (cont.): Verify Directive State
+
+Ensure `directive.json` has the correct state before execution:
+
+1. `pipeline.setup.status` = `"completed"`
+2. `pipeline.execute.status` = `"active"`
+3. `current_step` = `"execute"`
+4. `projects[]` array lists all projects from the COO's plan with `status: "pending"`
+5. `updated_at` is current
+
+The dashboard watches `directive.json` via chokidar for real-time pipeline progress. There is NO separate `current.json` — directive.json IS the single source of truth for both checkpoint/resume and dashboard display.
+
+## State Write Protocol
+
+directive.json is THE single source of truth. It stores both checkpoint/resume state and pipeline progress for the dashboard.
+
+**File:** `.context/directives/{directive-name}/directive.json`
+**Artifact files:** Write to the directive directory: `.context/directives/{directive-id}/projects/{project-id}/{phase}.md`
+
+> See [docs/reference/schemas/directive-json.md](../reference/schemas/directive-json.md) for the full schema.
+
+**Write mechanism:** Use the Write tool to overwrite directive.json. Always update `updated_at`. Update `pipeline.{step}` status/output after each step. Update `current_step` at each transition.
+
+**Artifact writes:** After each phase completes in the execute step, write the phase output (design doc, build report, review JSON) to the project directory. These survive context exhaustion and allow resumed runs to provide context to downstream phases.