takomi 2.1.38 → 2.1.39
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/.agents/plugins/marketplace.json +32 -0
- package/.pi/agents/architect.md +4 -2
- package/.pi/agents/designer.md +2 -0
- package/.pi/agents/orchestrator.md +9 -9
- package/.pi/prompts/design-prompt.md +3 -1
- package/.pi/prompts/genesis-prompt.md +2 -0
- package/.pi/prompts/takomi-prompt.md +10 -9
- package/README.md +38 -24
- package/assets/.agent/skills/takomi-flow/SKILL.md +235 -0
- package/assets/.agent/workflows/README.md +3 -3
- package/assets/.agent/workflows/mode-architect.md +7 -5
- package/assets/.agent/workflows/vibe-design.md +3 -1
- package/assets/.agent/workflows/vibe-genesis.md +2 -0
- package/assets/Takomi-Agents/custom_modes.yaml +1253 -1252
- package/assets/Takomi-Agents/vibe-architect.yaml +11 -6
- package/assets/Takomi-Agents/vibe-orchestrator.yaml +2 -2
- package/docs/features/TakomiFlow_Portable_Plugin.md +78 -0
- package/docs/takomi-flow-onboarding.md +76 -0
- package/docs/takomi-flow-public-distribution.md +94 -0
- package/package.json +19 -2
- package/plugins/takomi-codex/.codex-plugin/plugin.json +37 -0
- package/plugins/takomi-codex/assets/composer-icon.png +0 -0
- package/plugins/takomi-codex/assets/logo-dark.png +0 -0
- package/plugins/takomi-codex/assets/logo.png +0 -0
- package/plugins/takomi-codex/scripts/takomi-board.ps1 +197 -0
- package/plugins/takomi-codex/scripts/takomi-detect.ps1 +125 -0
- package/plugins/takomi-codex/scripts/takomi-doctor.ps1 +88 -0
- package/plugins/takomi-codex/scripts/takomi-harness.ps1 +52 -0
- package/plugins/takomi-codex/scripts/takomi-pi-dispatch.ps1 +93 -0
- package/plugins/takomi-codex/scripts/takomi-policy.ps1 +108 -0
- package/plugins/takomi-codex/skills/takomi-codex/SKILL.md +194 -0
- package/plugins/takomi-flow/.codex-plugin/plugin.json +36 -0
- package/plugins/takomi-flow/.mcp.json +11 -0
- package/plugins/takomi-flow/assets/capabilities.json +171 -0
- package/plugins/takomi-flow/assets/collection.schema.json +29 -0
- package/plugins/takomi-flow/assets/composer-icon.png +0 -0
- package/plugins/takomi-flow/assets/examples.json +94 -0
- package/plugins/takomi-flow/assets/logo-dark.png +0 -0
- package/plugins/takomi-flow/assets/logo.png +0 -0
- package/plugins/takomi-flow/assets/request.schema.json +67 -0
- package/plugins/takomi-flow/assets/result.schema.json +45 -0
- package/plugins/takomi-flow/assets/templates/image-request.json +13 -0
- package/plugins/takomi-flow/assets/templates/video-request.json +15 -0
- package/plugins/takomi-flow/package.json +38 -0
- package/plugins/takomi-flow/pnpm-lock.yaml +813 -0
- package/plugins/takomi-flow/references/flow-provider-contract.md +326 -0
- package/plugins/takomi-flow/scripts/lib/agent-plan.mjs +130 -0
- package/plugins/takomi-flow/scripts/lib/api.mjs +113 -0
- package/plugins/takomi-flow/scripts/lib/args.mjs +57 -0
- package/plugins/takomi-flow/scripts/lib/audit.mjs +65 -0
- package/plugins/takomi-flow/scripts/lib/browser.mjs +39 -0
- package/plugins/takomi-flow/scripts/lib/capabilities.mjs +11 -0
- package/plugins/takomi-flow/scripts/lib/collect.mjs +53 -0
- package/plugins/takomi-flow/scripts/lib/commands.mjs +175 -0
- package/plugins/takomi-flow/scripts/lib/doctor.mjs +77 -0
- package/plugins/takomi-flow/scripts/lib/examples.mjs +17 -0
- package/plugins/takomi-flow/scripts/lib/flow-outcome.mjs +90 -0
- package/plugins/takomi-flow/scripts/lib/flow-ui.mjs +165 -0
- package/plugins/takomi-flow/scripts/lib/generation.mjs +90 -0
- package/plugins/takomi-flow/scripts/lib/inspect.mjs +81 -0
- package/plugins/takomi-flow/scripts/lib/mcp-prompts.mjs +39 -0
- package/plugins/takomi-flow/scripts/lib/mcp-resources.mjs +16 -0
- package/plugins/takomi-flow/scripts/lib/mcp-tools.mjs +150 -0
- package/plugins/takomi-flow/scripts/lib/media.mjs +78 -0
- package/plugins/takomi-flow/scripts/lib/observe.mjs +54 -0
- package/plugins/takomi-flow/scripts/lib/paths.mjs +37 -0
- package/plugins/takomi-flow/scripts/lib/playwright-loader.mjs +23 -0
- package/plugins/takomi-flow/scripts/lib/prompts.mjs +72 -0
- package/plugins/takomi-flow/scripts/lib/report.mjs +141 -0
- package/plugins/takomi-flow/scripts/lib/request-validator.mjs +58 -0
- package/plugins/takomi-flow/scripts/lib/request.mjs +55 -0
- package/plugins/takomi-flow/scripts/lib/resource-files.mjs +69 -0
- package/plugins/takomi-flow/scripts/lib/result.mjs +31 -0
- package/plugins/takomi-flow/scripts/lib/review.mjs +44 -0
- package/plugins/takomi-flow/scripts/lib/selftest.mjs +153 -0
- package/plugins/takomi-flow/scripts/lib/settings-plan.mjs +39 -0
- package/plugins/takomi-flow/scripts/lib/templates.mjs +37 -0
- package/plugins/takomi-flow/scripts/lib/trusted-chrome.mjs +67 -0
- package/plugins/takomi-flow/scripts/lib/workflow.mjs +56 -0
- package/plugins/takomi-flow/scripts/mcp-server.mjs +18 -0
- package/plugins/takomi-flow/scripts/mcp-smoke.mjs +142 -0
- package/plugins/takomi-flow/scripts/takomi-flow.mjs +17 -0
- package/plugins/takomi-flow/skills/takomi-flow/SKILL.md +235 -0
- package/plugins/takomi-flow/skills/takomi-flow/agents/openai.yaml +7 -0
- package/scripts/install-takomi-flow.ps1 +85 -0
- package/src/pi-takomi-core/orchestration.ts +1 -1
- package/src/pi-takomi-core/workflows.ts +4 -4
- package/src/skills-catalog.js +11 -7
|
@@ -0,0 +1,32 @@
|
|
|
1
|
+
{
|
|
2
|
+
"name": "jstarfilmsstudios",
|
|
3
|
+
"interface": {
|
|
4
|
+
"displayName": "J StaR Films Studios"
|
|
5
|
+
},
|
|
6
|
+
"plugins": [
|
|
7
|
+
{
|
|
8
|
+
"name": "takomi-codex",
|
|
9
|
+
"source": {
|
|
10
|
+
"source": "local",
|
|
11
|
+
"path": "./plugins/takomi-codex"
|
|
12
|
+
},
|
|
13
|
+
"policy": {
|
|
14
|
+
"installation": "AVAILABLE",
|
|
15
|
+
"authentication": "ON_INSTALL"
|
|
16
|
+
},
|
|
17
|
+
"category": "Productivity"
|
|
18
|
+
},
|
|
19
|
+
{
|
|
20
|
+
"name": "takomi-flow",
|
|
21
|
+
"source": {
|
|
22
|
+
"source": "local",
|
|
23
|
+
"path": "./plugins/takomi-flow"
|
|
24
|
+
},
|
|
25
|
+
"policy": {
|
|
26
|
+
"installation": "AVAILABLE",
|
|
27
|
+
"authentication": "ON_INSTALL"
|
|
28
|
+
},
|
|
29
|
+
"category": "Productivity"
|
|
30
|
+
}
|
|
31
|
+
]
|
|
32
|
+
}
|
package/.pi/agents/architect.md
CHANGED
|
@@ -6,7 +6,7 @@ tools: read,bash,grep,find,ls
|
|
|
6
6
|
You are the Takomi Architect.
|
|
7
7
|
|
|
8
8
|
Your mode pattern is:
|
|
9
|
-
GATHER -> ANALYZE -> DESIGN -> PLAN -> HANDOFF.
|
|
9
|
+
GATHER -> ANALYZE -> TECHNICAL DESIGN -> PLAN -> HANDOFF.
|
|
10
10
|
|
|
11
11
|
## Role Scope
|
|
12
12
|
- feature and system planning
|
|
@@ -35,7 +35,7 @@ Compare viable approaches with:
|
|
|
35
35
|
|
|
36
36
|
Make a recommendation when the evidence is clear.
|
|
37
37
|
|
|
38
|
-
## Phase 3: Design
|
|
38
|
+
## Phase 3: Technical Design
|
|
39
39
|
Produce implementation-ready structure when relevant:
|
|
40
40
|
- system components and boundaries
|
|
41
41
|
- data models and schemas
|
|
@@ -44,6 +44,8 @@ Produce implementation-ready structure when relevant:
|
|
|
44
44
|
- diagrams or flows when helpful
|
|
45
45
|
- risks and mitigations
|
|
46
46
|
|
|
47
|
+
This is technical planning, not the Takomi Design lifecycle stage. If the work is about visual systems, mockups, interaction flows, or UI/UX polish, route it to Design.
|
|
48
|
+
|
|
47
49
|
Stay at architecture level; do not write product code.
|
|
48
50
|
|
|
49
51
|
## Phase 4: Planning
|
package/.pi/agents/designer.md
CHANGED
|
@@ -15,6 +15,8 @@ DISCOVER -> STRUCTURE -> SYSTEMIZE -> MOCK UP -> HANDOFF.
|
|
|
15
15
|
- requirements translated into build-ready mockups
|
|
16
16
|
- interaction and responsive behavior
|
|
17
17
|
|
|
18
|
+
This role does not own application architecture, database schemas, API contracts, backend boundaries, deployment strategy, or implementation planning. Route those decisions to Genesis or the Architect role.
|
|
19
|
+
|
|
18
20
|
## Phase 1: Discovery
|
|
19
21
|
Read requirements and constraints first.
|
|
20
22
|
Clarify or infer:
|
|
@@ -106,15 +106,15 @@ Before calling `takomi_board expand_stage`:
|
|
|
106
106
|
- Do not leave generated task files with `Scope: None specified`, `Definition Of Done: None specified`, or `Expected Artifacts: None specified`.
|
|
107
107
|
- If `takomi_board` produced generic task packets, immediately repair them with detailed markdown before dispatching more work.
|
|
108
108
|
|
|
109
|
-
## Phase 4: Delegation
|
|
110
|
-
After decomposition, delegation is the default execution path. Use `takomi_subagent` for implementer work and a separate reviewer pass, then return to the main orchestrator for synthesis, board updates, acceptance, redispatch decisions, and user handoff.
|
|
111
|
-
|
|
112
|
-
Direct execution remains appropriate for small one-shot tasks, unavailable delegation tooling, or explicit user overrides such as "do it yourself", "no subagents", "no new threads", or `/takomi subagents off`.
|
|
113
|
-
|
|
114
|
-
When delegating:
|
|
115
|
-
- send self-contained task instructions
|
|
116
|
-
- include required workflow and relevant context
|
|
117
|
-
- preserve conversation IDs for review loops
|
|
109
|
+
## Phase 4: Delegation
|
|
110
|
+
After decomposition, delegation is the default execution path. Use `takomi_subagent` for implementer work and a separate reviewer pass, then return to the main orchestrator for synthesis, board updates, acceptance, redispatch decisions, and user handoff.
|
|
111
|
+
|
|
112
|
+
Direct execution remains appropriate for small one-shot tasks, unavailable delegation tooling, or explicit user overrides such as "do it yourself", "no subagents", "no new threads", or `/takomi subagents off`.
|
|
113
|
+
|
|
114
|
+
When delegating:
|
|
115
|
+
- send self-contained task instructions
|
|
116
|
+
- include required workflow and relevant context
|
|
117
|
+
- preserve conversation IDs for review loops
|
|
118
118
|
- keep retries scoped and actionable
|
|
119
119
|
- do not overload a subagent with unrelated work
|
|
120
120
|
|
|
@@ -7,9 +7,11 @@ description: Run the full Takomi Vibe Design workflow for the next request
|
|
|
7
7
|
You are the **VibeCode Design Architect**. You are a Senior UI/UX Designer and Design Systems Engineer.
|
|
8
8
|
Your goal is to define the visual identity of the project before any code is written.
|
|
9
9
|
|
|
10
|
+
**Boundary:** This workflow is strictly for UI and UX. Do not design application architecture, database schemas, API contracts, backend boundaries, deployment strategy, or implementation task plans here. Those belong in Genesis or Architect planning artifacts.
|
|
11
|
+
|
|
10
12
|
**Your Core Responsibilities:**
|
|
11
13
|
1. **Brand Discovery:** Understand the visual "vibe" (colors, typography, aesthetics).
|
|
12
|
-
2. **Sitemap
|
|
14
|
+
2. **Visual Sitemap:** Generate the complete user-facing sitemap/screen inventory.
|
|
13
15
|
3. **Design System Foundation:** Create a portable `design-system.html` file.
|
|
14
16
|
4. **Page Mockups:** Generate HTML mockups for every page in the sitemap.
|
|
15
17
|
5. **Builder Prompt Update:** Enforce mockup usage in the Builder Prompt.
|
|
@@ -11,6 +11,8 @@ description: Run the full Takomi Vibe Genesis workflow for the next request
|
|
|
11
11
|
Your job is to understand the project vision and create the blueprints.
|
|
12
12
|
You do **not** write implementation code here — you design the foundation.
|
|
13
13
|
|
|
14
|
+
Genesis owns product planning and technical planning: requirements, PRD, issue/task breakdown, architecture decisions, data models, API contracts, implementation strategy, and orchestration setup. The later Design stage is UI/UX only.
|
|
15
|
+
|
|
14
16
|
---
|
|
15
17
|
|
|
16
18
|
## Provider / Model Selection
|
|
@@ -13,14 +13,15 @@ Always-on Takomi behavior.
|
|
|
13
13
|
- Keep JSON/session state as bookkeeping, continuity, and dispatch metadata.
|
|
14
14
|
- Route deliberately: Genesis, Design, Build, Review, or Orchestration.
|
|
15
15
|
- Be explicit about current stage and next stage.
|
|
16
|
-
- Do not blend
|
|
16
|
+
- Do not blend Genesis planning, UI/UX Design, and implementation sloppily.
|
|
17
|
+
- Treat the lifecycle stage named Design as UI/UX only. Architecture, data models, API contracts, product requirements, and implementation strategy belong in Genesis or Architect planning, not in Design.
|
|
17
18
|
- When the right path is clear, make a recommendation instead of hedging.
|
|
18
19
|
- For broad work, Genesis may create the orchestration session that carries work into later stages.
|
|
19
|
-
- Orchestration sessions use canonical timestamp IDs: `orch-YYYYMMDD-HHMMSS`.
|
|
20
|
-
- Orchestration sessions are markdown-first: author `master_plan.md` and task packets first, then call `takomi_board` with the same `sessionId`, `masterPlanMarkdown`, task `taskMarkdown`, and matching task statuses. Do not create a second board session for already-authored session docs.
|
|
21
|
-
- `takomi_board` never runs subagents. Use `takomi_subagent` for execution, then come back to `takomi_board update_task` to record results.
|
|
22
|
-
- When Takomi creates subtasks, roadbook tasks, or an orchestration session, delegation is the default next step: implementer `takomi_subagent`, reviewer `takomi_subagent`, then main-agent synthesis and board update.
|
|
23
|
-
- Preserve direct execution for small clear work and explicit user overrides such as "do it yourself", "no subagents", "no new threads", or `/takomi subagents off`.
|
|
20
|
+
- Orchestration sessions use canonical timestamp IDs: `orch-YYYYMMDD-HHMMSS`.
|
|
21
|
+
- Orchestration sessions are markdown-first: author `master_plan.md` and task packets first, then call `takomi_board` with the same `sessionId`, `masterPlanMarkdown`, task `taskMarkdown`, and matching task statuses. Do not create a second board session for already-authored session docs.
|
|
22
|
+
- `takomi_board` never runs subagents. Use `takomi_subagent` for execution, then come back to `takomi_board update_task` to record results.
|
|
23
|
+
- When Takomi creates subtasks, roadbook tasks, or an orchestration session, delegation is the default next step: implementer `takomi_subagent`, reviewer `takomi_subagent`, then main-agent synthesis and board update.
|
|
24
|
+
- Preserve direct execution for small clear work and explicit user overrides such as "do it yourself", "no subagents", "no new threads", or `/takomi subagents off`.
|
|
24
25
|
|
|
25
26
|
## Shared Mode Pattern
|
|
26
27
|
- Load context before acting.
|
|
@@ -55,9 +56,9 @@ Before using `takomi_subagent`, setting a model override, or naming a provider/m
|
|
|
55
56
|
- run `pi --list-models` only when registry context is missing or the user asks for visible diagnostics
|
|
56
57
|
|
|
57
58
|
## Routing Rule
|
|
58
|
-
- Genesis for PRDs, issues, coding rules, requirements, and orchestration-session setup.
|
|
59
|
-
- Design for sitemap, design system, mockups, and visual direction
|
|
59
|
+
- Genesis for PRDs, issues, coding rules, requirements, architecture decisions, data models, API contracts, implementation planning, and orchestration-session setup.
|
|
60
|
+
- Design for UI/UX only: visual sitemap, user journeys, interaction flows, design system, mockups, accessibility, and visual direction.
|
|
60
61
|
- Build for implementation, verification, and handoff
|
|
61
62
|
- Review for audits, QA, or high-risk changes
|
|
62
|
-
- Orchestration for broad, multi-step, or delegated work
|
|
63
|
+
- Orchestration for broad, multi-step, or delegated work
|
|
63
64
|
|
package/README.md
CHANGED
|
@@ -36,17 +36,31 @@ takomi setup skills
|
|
|
36
36
|
takomi setup pi-features
|
|
37
37
|
```
|
|
38
38
|
|
|
39
|
-
Useful management commands:
|
|
39
|
+
Useful management commands:
|
|
40
40
|
|
|
41
41
|
```bash
|
|
42
42
|
takomi refresh # one-command update: Takomi + Pi/assets/skills
|
|
43
43
|
takomi status
|
|
44
44
|
takomi doctor
|
|
45
45
|
takomi setup all
|
|
46
|
-
takomi setup project
|
|
47
|
-
```
|
|
48
|
-
|
|
49
|
-
|
|
46
|
+
takomi setup project
|
|
47
|
+
```
|
|
48
|
+
|
|
49
|
+
### TakomiFlow For Google Flow Assets
|
|
50
|
+
|
|
51
|
+
TakomiFlow packages Google Flow image/video generation as a Codex plugin with MCP tools plus a CLI fallback. It can generate Flow keyframes, short video shots, moodboards, collect downloaded assets, extract review frames, and record Flow project URLs.
|
|
52
|
+
|
|
53
|
+
Install the full plugin from this suite:
|
|
54
|
+
|
|
55
|
+
```powershell
|
|
56
|
+
.\scripts\install-takomi-flow.ps1 -InstallDependencies
|
|
57
|
+
```
|
|
58
|
+
|
|
59
|
+
If someone only has skills but not the plugin, install/use the bundled `takomi-flow` skill first. It teaches Codex how to use the skill directly, fetch this suite when needed, install the full TakomiFlow plugin globally after approval, and verify the setup.
|
|
60
|
+
|
|
61
|
+
See [TakomiFlow Onboarding](docs/takomi-flow-onboarding.md) and [TakomiFlow Public Distribution](docs/takomi-flow-public-distribution.md).
|
|
62
|
+
|
|
63
|
+
Legacy commands like `takomi install pi`, `takomi sync pi`, `takomi upgrade`, and `takomi init` still work, but the simpler mental model is: **setup once, refresh when stale, run `takomi` to use it.**
|
|
50
64
|
|
|
51
65
|
During `takomi setup pi` or `takomi setup pi-features`, Takomi offers optional Pi feature packs with recommended/manual/select-all/skip choices. Current defaults install **Takomi Interview** (`npm:@juicesharp/rpiv-ask-user-question`) so models can ask structured clarification questions. **Takomi Todo** (`npm:@juicesharp/rpiv-todo`), **Takomi Browser QA** (`npm:pi-chrome`), and **Takomi Doc Preview** (`npm:pi-markdown-preview`) remain opt-in. `takomi refresh` runs Pi's package updater so installed optional, custom, old, and new Pi packages are reconciled together.
|
|
52
66
|
|
|
@@ -115,25 +129,25 @@ run vibe genesis
|
|
|
115
129
|
continue build with takomi
|
|
116
130
|
```
|
|
117
131
|
|
|
118
|
-
Install the Takomi protocol suite:
|
|
119
|
-
|
|
120
|
-
```bash
|
|
121
|
-
npx -y skills add https://github.com/JStaRFilms/VibeCode-Protocol-Suite --skill takomi
|
|
122
|
-
```
|
|
123
|
-
|
|
124
|
-
Original Takomi-authored skills in this bundle include `21st-dev-components`, `takomi`, `global-brand-namer`, `jstar-reviewer`, and the core VibeCode/Takomi workflow skills that ship with the CLI.
|
|
125
|
-
|
|
126
|
-
### Codex Plugin Quick Start
|
|
127
|
-
|
|
128
|
-
For the newer repo-local Codex plugin path, enable `takomi-codex` from `.agents/plugins/marketplace.json`. That marketplace entry points Codex at `./plugins/takomi-codex`, which includes plugin metadata, the `takomi-codex` skill, and local verification scripts.
|
|
129
|
-
|
|
130
|
-
This plugin path is distinct from `skills add --skill takomi`, which installs the older global Takomi skill. Use natural language such as `use takomi-codex to inspect this repo`, `use Takomi to plan this feature`, or `create a Takomi roadbook for this work`.
|
|
131
|
-
|
|
132
|
-
See [Takomi Codex Onboarding](docs/takomi-codex-onboarding.md) for activation, first-run verification, policy loading, roadbooks, dry-run dispatch, no-Pi fallback, and troubleshooting.
|
|
133
|
-
|
|
134
|
-
---
|
|
135
|
-
|
|
136
|
-
## 📦 Skill Ecosystem
|
|
132
|
+
Install the Takomi protocol suite:
|
|
133
|
+
|
|
134
|
+
```bash
|
|
135
|
+
npx -y skills add https://github.com/JStaRFilms/VibeCode-Protocol-Suite --skill takomi
|
|
136
|
+
```
|
|
137
|
+
|
|
138
|
+
Original Takomi-authored skills in this bundle include `21st-dev-components`, `takomi`, `global-brand-namer`, `jstar-reviewer`, and the core VibeCode/Takomi workflow skills that ship with the CLI.
|
|
139
|
+
|
|
140
|
+
### Codex Plugin Quick Start
|
|
141
|
+
|
|
142
|
+
For the newer repo-local Codex plugin path, enable `takomi-codex` from `.agents/plugins/marketplace.json`. That marketplace entry points Codex at `./plugins/takomi-codex`, which includes plugin metadata, the `takomi-codex` skill, and local verification scripts.
|
|
143
|
+
|
|
144
|
+
This plugin path is distinct from `skills add --skill takomi`, which installs the older global Takomi skill. Use natural language such as `use takomi-codex to inspect this repo`, `use Takomi to plan this feature`, or `create a Takomi roadbook for this work`.
|
|
145
|
+
|
|
146
|
+
See [Takomi Codex Onboarding](docs/takomi-codex-onboarding.md) for activation, first-run verification, policy loading, roadbooks, dry-run dispatch, no-Pi fallback, and troubleshooting.
|
|
147
|
+
|
|
148
|
+
---
|
|
149
|
+
|
|
150
|
+
## 📦 Skill Ecosystem
|
|
137
151
|
|
|
138
152
|
Think of skills as specialized team members you can summon on demand. From security audits to AI video generation — there's a skill for that.
|
|
139
153
|
|
|
@@ -0,0 +1,235 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: takomi-flow
|
|
3
|
+
description: "Use when Codex needs to operate Google Flow as a reusable agent tool through safe browser automation: bootstrap/login a persistent Flow profile, smoke-check access without spending credits, prepare image or video generation request files, run guarded Flow generations, download assets, inspect results, or integrate Flow assets into a video pipeline. Trigger for TakomiFlow, Flow browser provider, use Google Flow credits, Flow automation, generate with Flow, or agent-first Flow workflows."
|
|
4
|
+
---
|
|
5
|
+
|
|
6
|
+
# TakomiFlow
|
|
7
|
+
|
|
8
|
+
TakomiFlow is an agent-first workflow for using Google Flow through visible browser automation. Treat it as a local tool layer for Codex agents, not as an unofficial API.
|
|
9
|
+
|
|
10
|
+
## Runtime Choice
|
|
11
|
+
|
|
12
|
+
Use this skill as the single TakomiFlow entrypoint.
|
|
13
|
+
|
|
14
|
+
1. If the active harness is Codex and the user approves plugin installation or repair, install or reuse the global Codex plugin and then prefer its MCP tools.
|
|
15
|
+
2. If the plugin already exists, verify it with `doctor` and use MCP tools when the session exposes them.
|
|
16
|
+
3. If MCP is unavailable, use the TakomiFlow CLI directly.
|
|
17
|
+
4. If the harness is not Codex or does not support plugins, keep using this skill as the workflow guide and call the CLI when shell access exists.
|
|
18
|
+
5. If there is no shell access, provide the exact commands as a handoff checklist and stop.
|
|
19
|
+
|
|
20
|
+
Never install, update, or write to global plugin locations without telling the user what path will be changed and getting approval.
|
|
21
|
+
|
|
22
|
+
## Install Or Repair The Plugin
|
|
23
|
+
|
|
24
|
+
Only follow this path when the user asks to install/repair TakomiFlow or agrees after you detect that the Codex plugin is missing.
|
|
25
|
+
|
|
26
|
+
1. Check for an existing user plugin:
|
|
27
|
+
|
|
28
|
+
```powershell
|
|
29
|
+
Test-Path "$HOME\plugins\takomi-flow"
|
|
30
|
+
Test-Path "$HOME\.agents\plugins\marketplace.json"
|
|
31
|
+
```
|
|
32
|
+
|
|
33
|
+
2. If the plugin exists, inspect it:
|
|
34
|
+
|
|
35
|
+
```powershell
|
|
36
|
+
node "$HOME\plugins\takomi-flow\scripts\takomi-flow.mjs" doctor
|
|
37
|
+
```
|
|
38
|
+
|
|
39
|
+
If this works, do not reinstall unless the user asked to update or repair.
|
|
40
|
+
|
|
41
|
+
3. If missing, locate or get the VibeCode Protocol Suite:
|
|
42
|
+
|
|
43
|
+
```powershell
|
|
44
|
+
git clone https://github.com/JStaRFilms/VibeCode-Protocol-Suite "$HOME\Source\VibeCode-Protocol-Suite"
|
|
45
|
+
```
|
|
46
|
+
|
|
47
|
+
4. Install the plugin globally for the current user:
|
|
48
|
+
|
|
49
|
+
```powershell
|
|
50
|
+
cd "$HOME\Source\VibeCode-Protocol-Suite"
|
|
51
|
+
.\scripts\install-takomi-flow.ps1 -InstallDependencies
|
|
52
|
+
```
|
|
53
|
+
|
|
54
|
+
This copies/registers the plugin at:
|
|
55
|
+
|
|
56
|
+
```text
|
|
57
|
+
~/plugins/takomi-flow
|
|
58
|
+
~/.agents/plugins/marketplace.json
|
|
59
|
+
```
|
|
60
|
+
|
|
61
|
+
5. Verify:
|
|
62
|
+
|
|
63
|
+
```powershell
|
|
64
|
+
node "$HOME\plugins\takomi-flow\scripts\takomi-flow.mjs" doctor
|
|
65
|
+
```
|
|
66
|
+
|
|
67
|
+
If Git is unavailable, ask the user to download the VibeCode Protocol Suite ZIP and run the installer from the extracted repo. MCP is optional; the CLI works without MCP.
|
|
68
|
+
|
|
69
|
+
## Agent Tool Surface
|
|
70
|
+
|
|
71
|
+
Prefer MCP tools when they are available in the active Codex session. Use the CLI commands as the stable fallback.
|
|
72
|
+
|
|
73
|
+
MCP tools:
|
|
74
|
+
|
|
75
|
+
- `takomi_flow_capabilities`
|
|
76
|
+
- `takomi_flow_doctor`
|
|
77
|
+
- `takomi_flow_audit`
|
|
78
|
+
- `takomi_flow_examples`
|
|
79
|
+
- `takomi_flow_template`
|
|
80
|
+
- `takomi_flow_prepare`
|
|
81
|
+
- `takomi_flow_workflow`
|
|
82
|
+
- `takomi_flow_validate`
|
|
83
|
+
- `takomi_flow_observe`
|
|
84
|
+
- `takomi_flow_generate`
|
|
85
|
+
- `takomi_flow_selftest`
|
|
86
|
+
- `takomi_flow_inspect`
|
|
87
|
+
- `takomi_flow_latest`
|
|
88
|
+
- `takomi_flow_runs`
|
|
89
|
+
- `takomi_flow_assets`
|
|
90
|
+
- `takomi_flow_review`
|
|
91
|
+
- `takomi_flow_collect`
|
|
92
|
+
- `takomi_flow_report`
|
|
93
|
+
|
|
94
|
+
MCP resources:
|
|
95
|
+
|
|
96
|
+
- `takomi-flow://contract`
|
|
97
|
+
- `takomi-flow://capabilities`
|
|
98
|
+
- `takomi-flow://examples`
|
|
99
|
+
- `takomi-flow://schemas/request`
|
|
100
|
+
- `takomi-flow://schemas/result`
|
|
101
|
+
- `takomi-flow://schemas/collection`
|
|
102
|
+
- `takomi-flow://templates/video`
|
|
103
|
+
- `takomi-flow://templates/image`
|
|
104
|
+
|
|
105
|
+
MCP prompts:
|
|
106
|
+
|
|
107
|
+
- `takomi_flow_video_workflow`
|
|
108
|
+
- `takomi_flow_image_workflow`
|
|
109
|
+
- `takomi_flow_review_workflow`
|
|
110
|
+
- `takomi_flow_collect_workflow`
|
|
111
|
+
|
|
112
|
+
Browser-opening MCP tools require `allowBrowser=true`. Generation still requires request `allowSpend=true` or `TAKOMI_FLOW_ALLOW_SPEND=true` before it can submit.
|
|
113
|
+
|
|
114
|
+
## Core Rules
|
|
115
|
+
|
|
116
|
+
- Use public Flow UI automation only.
|
|
117
|
+
- Do not bypass captchas, login challenges, quotas, safety checks, rate limits, or hidden endpoints.
|
|
118
|
+
- Prefer headed mode first so the user can handle Google login, consent, quota, and safety prompts.
|
|
119
|
+
- Never submit a paid generation unless the user explicitly requested it and `allowSpend` or `TAKOMI_FLOW_ALLOW_SPEND=true` is set.
|
|
120
|
+
- Keep credentials out of prompts, logs, metadata, and project files.
|
|
121
|
+
- Store run artifacts in a predictable folder and report the exact result paths.
|
|
122
|
+
|
|
123
|
+
## Commands
|
|
124
|
+
|
|
125
|
+
From the plugin root:
|
|
126
|
+
|
|
127
|
+
```bash
|
|
128
|
+
node scripts/takomi-flow.mjs bootstrap
|
|
129
|
+
node scripts/takomi-flow.mjs bootstrap --browser-channel chrome
|
|
130
|
+
node scripts/takomi-flow.mjs trusted-chrome
|
|
131
|
+
node scripts/takomi-flow.mjs doctor
|
|
132
|
+
node scripts/takomi-flow.mjs audit
|
|
133
|
+
node scripts/takomi-flow.mjs selftest
|
|
134
|
+
node scripts/takomi-flow.mjs capabilities
|
|
135
|
+
node scripts/takomi-flow.mjs examples
|
|
136
|
+
node scripts/takomi-flow.mjs observe
|
|
137
|
+
node scripts/takomi-flow.mjs smoke
|
|
138
|
+
node scripts/takomi-flow.mjs template --kind video
|
|
139
|
+
node scripts/takomi-flow.mjs prepare --kind video --prompt "cinematic AI lab scene" --variations 2
|
|
140
|
+
node scripts/takomi-flow.mjs workflow --kind video --prompt "cinematic AI lab scene" --variations 2
|
|
141
|
+
node scripts/takomi-flow.mjs validate --request output/takomi-flow/requests/<file>.json
|
|
142
|
+
node scripts/takomi-flow.mjs generate --request output/takomi-flow/requests/<file>.json
|
|
143
|
+
node scripts/takomi-flow.mjs inspect --run output/takomi-flow/<runId>/run.json
|
|
144
|
+
node scripts/takomi-flow.mjs latest --output-dir output/takomi-flow
|
|
145
|
+
node scripts/takomi-flow.mjs runs --output-dir output/takomi-flow --limit 10
|
|
146
|
+
node scripts/takomi-flow.mjs assets --run output/takomi-flow/<runId>/run.json --frames 4
|
|
147
|
+
node scripts/takomi-flow.mjs review --run output/takomi-flow/<runId>/run.json --frames 4
|
|
148
|
+
node scripts/takomi-flow.mjs collect --run output/takomi-flow/<runId>/run.json --target-dir output/pipeline-assets --frames 4 --include-frames
|
|
149
|
+
node scripts/takomi-flow.mjs report --run output/takomi-flow/<runId>/run.json
|
|
150
|
+
node scripts/takomi-flow.mjs report --output-dir output/takomi-flow --limit 10
|
|
151
|
+
```
|
|
152
|
+
|
|
153
|
+
Important defaults:
|
|
154
|
+
|
|
155
|
+
- Profile dir: `%USERPROFILE%\.takomi-flow\browser-profile`
|
|
156
|
+
- Output dir: `%USERPROFILE%\.takomi-flow\runs`
|
|
157
|
+
- Browser channel: real Chrome by default on Windows/macOS when available
|
|
158
|
+
- Headed mode: enabled by default
|
|
159
|
+
- Spend guard: disabled by default
|
|
160
|
+
|
|
161
|
+
## Workflow
|
|
162
|
+
|
|
163
|
+
1. First-run/runtime detection:
|
|
164
|
+
- Run `doctor` first when the installation state is unknown.
|
|
165
|
+
- Check whether `http://127.0.0.1:9222/json/version` is already reachable.
|
|
166
|
+
- If the CDP endpoint is reachable, reuse it with `--cdp-url http://127.0.0.1:9222`.
|
|
167
|
+
- If the CDP endpoint is not reachable, launch `trusted-chrome`.
|
|
168
|
+
- If MCP tools are unavailable, use CLI commands from this plugin root.
|
|
169
|
+
- If the harness has no MCP support, TakomiFlow still works through shell commands.
|
|
170
|
+
2. Bootstrap login:
|
|
171
|
+
- Prefer `trusted-chrome` for Google login because Google may reject Playwright-launched browsers.
|
|
172
|
+
- Log into Google Flow manually in the opened trusted Chrome window.
|
|
173
|
+
- Keep that Chrome window open and use `--cdp-url http://127.0.0.1:9222` for observe/generate.
|
|
174
|
+
- A signed-in dashboard should show project cards and a `New project` button during `observe`.
|
|
175
|
+
- The project editor prompt textbox currently contains `What do you want to create?`.
|
|
176
|
+
- Prefer video durations `4`, `6`, `8`, or `10` seconds to avoid a Flow follow-up question.
|
|
177
|
+
- Use `bootstrap` only when Google accepts the launched browser.
|
|
178
|
+
- Ask the user to log into Google Flow manually in the opened browser.
|
|
179
|
+
- Do not automate credential entry.
|
|
180
|
+
3. Doctor check:
|
|
181
|
+
- Run `doctor` before browser work when reliability matters.
|
|
182
|
+
- Report missing Playwright, FFmpeg, profile, or output path issues.
|
|
183
|
+
4. Readiness audit:
|
|
184
|
+
- Run `audit` when an agent needs safe next actions and gated actions in one payload.
|
|
185
|
+
- Treat missing profile as a login/bootstrap gate, not a script failure.
|
|
186
|
+
5. Self-test:
|
|
187
|
+
- Run `selftest` after install, after edits, or before trusting TakomiFlow in a new project.
|
|
188
|
+
- Confirm no-spend request preparation, validation, spend guard behavior, and media extraction work.
|
|
189
|
+
6. Capability discovery:
|
|
190
|
+
- Run `capabilities` when an agent needs supported kinds, modes, request fields, variations, aspect ratios, outputs, and safety rules.
|
|
191
|
+
- Run `examples` or read `takomi-flow://examples` when an agent needs known-good request patterns.
|
|
192
|
+
7. Observe Flow UI:
|
|
193
|
+
- Run `observe` after bootstrap to capture current Flow controls, text inputs, buttons, screenshots, and manual-action state without submitting generation.
|
|
194
|
+
- Use observation output before changing selectors.
|
|
195
|
+
8. Smoke check:
|
|
196
|
+
- Run `smoke` to open Flow and save status metadata/screenshots.
|
|
197
|
+
- Confirm no generation was submitted.
|
|
198
|
+
9. Prepare request:
|
|
199
|
+
- Use `template --kind video` or `template --kind image` when an agent needs a known-good request skeleton.
|
|
200
|
+
- Use `takomi-flow://schemas/request` when an agent needs a machine-readable request shape.
|
|
201
|
+
- Use `takomi-flow://schemas/result` and `takomi-flow://schemas/collection` to consume run metadata and collected outputs.
|
|
202
|
+
- Use `prepare` to create a JSON request for image or video generation.
|
|
203
|
+
- Use `workflow` when an agent should prepare, validate, and optionally submit from one call.
|
|
204
|
+
- Include prompt, variations, aspect ratio, duration, model/mode hints, and output folder.
|
|
205
|
+
- Read `settingsPlan` to see which requested Flow options are automatic versus selector-dependent.
|
|
206
|
+
10. Validate request:
|
|
207
|
+
- Run `validate --request <file>` before `generate`.
|
|
208
|
+
- Fix failed source assets, invalid kinds, or malformed request JSON before opening Flow.
|
|
209
|
+
- Treat spend-guard warnings as expected unless the user explicitly approved spending credits.
|
|
210
|
+
11. Generate:
|
|
211
|
+
- Run `generate` only when spend is explicitly allowed.
|
|
212
|
+
- Expect Flow to ask for credit approval; approve only when `allowSpend=true` or the user explicitly approved spending.
|
|
213
|
+
- Stop for manual intervention if the UI asks for login, captcha, quota, safety, or consent.
|
|
214
|
+
- Preserve `settingsPlan` in the run metadata so downstream agents can see requested options.
|
|
215
|
+
12. Inspect:
|
|
216
|
+
- Read `run.json`, `status.json`, screenshots, and downloaded assets.
|
|
217
|
+
- Record and report `projectUrl` for every created Flow project so future runs can reuse or inspect it.
|
|
218
|
+
- Prefer `runs`, `inspect`, or `latest` for agent-readable summaries.
|
|
219
|
+
- Use `assets --frames 4` to catalog downloaded images/videos and extract review frames.
|
|
220
|
+
- Use `review --frames 4` to combine inspect, asset cataloging, frame extraction, and Markdown report creation.
|
|
221
|
+
- Use `collect` to copy reviewed outputs into a downstream project folder with a manifest.
|
|
222
|
+
- Use `report` to write a Markdown handoff for a single run or recent history.
|
|
223
|
+
- Report successes, errors, and manual next steps.
|
|
224
|
+
|
|
225
|
+
## Request Shape
|
|
226
|
+
|
|
227
|
+
Read `references/flow-provider-contract.md` before modifying scripts or integrating TakomiFlow into another project.
|
|
228
|
+
|
|
229
|
+
## Integration Guidance
|
|
230
|
+
|
|
231
|
+
- For a project pipeline, call TakomiFlow as an external provider and pass prompt/settings by JSON file.
|
|
232
|
+
- Keep Flow-specific selectors isolated in `scripts/lib/flow-ui.mjs`.
|
|
233
|
+
- Keep generation follow-up polling, credit approval, and completion/failure detection in `scripts/lib/flow-outcome.mjs`.
|
|
234
|
+
- Keep request/result parsing stable so other agents can use it without reading script internals.
|
|
235
|
+
- If a file approaches 200 lines, split it before adding more responsibilities.
|
|
@@ -128,7 +128,7 @@ Understanding the difference:
|
|
|
128
128
|
| Workflow | Purpose | When to Use | Generates |
|
|
129
129
|
|----------|---------|-------------|-----------|
|
|
130
130
|
| `/vibe-genesis` | **V3 Architect** — Plans with templates | Starting new project | PRD, Issues (1 per FR), Guidelines template |
|
|
131
|
-
| `/vibe-design` | The Designer — Creates visual system | After Genesis, before Build | `docs/design/design-system.html`, `docs/mockups/*.html` |
|
|
131
|
+
| `/vibe-design` | The Designer — Creates UI/UX visual system and mockups | After Genesis, before Build | `docs/design/design-system.html`, `docs/mockups/*.html` |
|
|
132
132
|
| `/vibe-build` | **V3 Builder** — With verification gates | After Genesis (and optionally Design) | Project structure, MUS features with verification |
|
|
133
133
|
| `/vibe-continueBuild` | **Resume work** — Post-build sessions | New chat after initial build | Continues from incomplete FRs |
|
|
134
134
|
| `/vibe-finalize` | **Final handoff** — Verification + report | When MUS complete | `docs/Builder_Handoff_Report.md` |
|
|
@@ -142,7 +142,7 @@ Inspired by KiloCode's mode system, these workflows provide specialized capabili
|
|
|
142
142
|
| Workflow | Purpose | When to Use |
|
|
143
143
|
|----------|---------|-------------|
|
|
144
144
|
| `/mode-orchestrator` | **Coordinate complex projects** — Delegate to sub-agents | Multi-step projects requiring coordination across domains |
|
|
145
|
-
| `/mode-architect` | **Plan
|
|
145
|
+
| `/mode-architect` | **Plan technical architecture** — Create technical specifications | Before implementation, defining systems, breaking down complex problems |
|
|
146
146
|
| `/mode-code` | **Write and refactor code** — Full implementation access | Implementing features, fixing bugs, creating files |
|
|
147
147
|
| `/mode-debug` | **Diagnose issues** — Systematic problem solving | Troubleshooting errors, investigating bugs, analyzing failures |
|
|
148
148
|
| `/mode-ask` | **Explain and analyze** — Answer questions without changes | Understanding concepts, analyzing code, getting recommendations |
|
|
@@ -481,7 +481,7 @@ These skills are auto-loaded based on context. Location: `.agent/skills/`
|
|
|
481
481
|
| I want to... | Use this |
|
|
482
482
|
|--------------|----------|
|
|
483
483
|
| **Start a new project** | `/vibe-genesis` |
|
|
484
|
-
| **Design the UI** | `/vibe-design` |
|
|
484
|
+
| **Design the UI/UX** | `/vibe-design` |
|
|
485
485
|
| **Build the foundation** | `/vibe-build` |
|
|
486
486
|
| **Resume work (new session)** | `/vibe-continueBuild` |
|
|
487
487
|
| **Finish and hand off** | `/vibe-finalize` |
|
|
@@ -4,10 +4,10 @@ description: The VibeCode Architect Mode - Plan, design, and strategize before i
|
|
|
4
4
|
|
|
5
5
|
# Workflow: Architect
|
|
6
6
|
|
|
7
|
-
> **The VibeCode Planner** — Gather requirements, create technical specifications, and
|
|
7
|
+
> **The VibeCode Planner** — Gather requirements, create technical specifications, and define technical architecture before coding begins.
|
|
8
8
|
|
|
9
9
|
**You are the VibeCode Architect.**
|
|
10
|
-
Your goal is to understand the problem deeply and create a clear, actionable plan. You do NOT write implementation code — you
|
|
10
|
+
Your goal is to understand the problem deeply and create a clear, actionable plan. You do NOT write implementation code — you create the technical plan.
|
|
11
11
|
|
|
12
12
|
---
|
|
13
13
|
|
|
@@ -30,7 +30,7 @@ Use `/mode-architect` when:
|
|
|
30
30
|
│ ARCHITECT MODE PATTERN │
|
|
31
31
|
├─────────────────────────────────────────────────────────────┤
|
|
32
32
|
│ │
|
|
33
|
-
│ GATHER ──► ANALYZE ──► DESIGN ──► PLAN ──► HANDOFF
|
|
33
|
+
│ GATHER ──► ANALYZE ──► TECHNICAL DESIGN ──► PLAN ──► HANDOFF │
|
|
34
34
|
│ │ │ │ │ │ │
|
|
35
35
|
│ ▼ ▼ ▼ ▼ ▼ │
|
|
36
36
|
│ Requirements Context Solution Steps Builder │
|
|
@@ -136,7 +136,9 @@ Provide clear guidance:
|
|
|
136
136
|
|
|
137
137
|
---
|
|
138
138
|
|
|
139
|
-
## Phase 3: Design
|
|
139
|
+
## Phase 3: Technical Design
|
|
140
|
+
|
|
141
|
+
This is technical planning, not the `/vibe-design` UI/UX lifecycle workflow. Use this phase for architecture, data models, API contracts, implementation plans, and technical boundaries. Use `/vibe-design` only for UI/UX, visual systems, user journeys, interaction flows, and mockups.
|
|
140
142
|
|
|
141
143
|
### 3.1 Data Models
|
|
142
144
|
|
|
@@ -170,7 +172,7 @@ Define the interface boundaries:
|
|
|
170
172
|
|
|
171
173
|
### 3.3 Component Architecture
|
|
172
174
|
|
|
173
|
-
|
|
175
|
+
Define the technical UI/component structure:
|
|
174
176
|
|
|
175
177
|
```
|
|
176
178
|
App
|
|
@@ -7,9 +7,11 @@ description: The VibeCode Designer - Generate Design System and Page Mockups.
|
|
|
7
7
|
You are the **VibeCode Design Architect**. You are a Senior UI/UX Designer and Design Systems Engineer.
|
|
8
8
|
Your goal is to define the visual identity of the project before any code is written.
|
|
9
9
|
|
|
10
|
+
**Boundary:** This workflow is strictly for UI and UX. Do not design application architecture, database schemas, API contracts, backend boundaries, deployment strategy, or implementation task plans here. Those belong in Genesis or Architect planning artifacts.
|
|
11
|
+
|
|
10
12
|
**Your Core Responsibilities:**
|
|
11
13
|
1. **Brand Discovery:** Understand the visual "vibe" (colors, typography, aesthetics).
|
|
12
|
-
2. **Sitemap
|
|
14
|
+
2. **Visual Sitemap:** Generate the complete user-facing sitemap/screen inventory.
|
|
13
15
|
3. **Design System Foundation:** Create a portable `design-system.html` file.
|
|
14
16
|
4. **Page Mockups:** Generate HTML mockups for every page in the sitemap.
|
|
15
17
|
5. **Builder Prompt Update:** Enforce mockup usage in the Builder Prompt.
|
|
@@ -9,6 +9,8 @@ description: The VibeCode Architect V3 - Initialize a new project with Plans, Do
|
|
|
9
9
|
**You are the VibeCode Project Orchestrator and Architect.**
|
|
10
10
|
Your goal is to understand the project vision and create the blueprints. You do NOT write implementation code — you design the foundation.
|
|
11
11
|
|
|
12
|
+
Genesis owns product planning and technical planning: requirements, PRD, issue/task breakdown, architecture decisions, data models, API contracts, implementation strategy, and orchestration setup. The later Design stage is UI/UX only.
|
|
13
|
+
|
|
12
14
|
---
|
|
13
15
|
|
|
14
16
|
## Steps
|