vibecode-pro-max-kit: Specs, Memory, and Multi-Agent Workflow for AI Coding

The easiest way to lose control of AI coding is not a dramatic model failure. It is usually one of three smaller failures: context gets truncated, plans live only in chat history, and decisions leave no trace. Every requirement change makes you explain the whole project again.

vibecode-pro-max-kit is trying to fix the workflow. It turns an AI coding agent into something closer to a spec-driven engineering team: write the spec first, plan before execution, and leave auditable records at each step. It is not a chat framework, and it does not replace CI/CD. Its narrower job is to make AI coding decisions traceable.

---

What problem it solves

Context loss: Long conversations get cut by compaction, and design decisions, boundary conditions, and debugging trails disappear. The next change either needs a fresh explanation or leaves the AI guessing.

Plans and decisions do not leave a trail: A Markdown export from chat is not structured documentation. During review, teammates cannot see why one approach was chosen or which options were rejected.

Multi-agent handoff is expensive: A task may be split across agents, but the handoff often relies on loose natural language. Who owns each step, what the output format is, and where the acceptance criteria live all require human supervision.

Together, these issues make AI coding feel like starting from scratch every time. vibecode-pro-max-kit puts them into one harness: spec first, plan in the middle, checkpoints during execution, and memory around the process.

---

Installation flow and safety audit

Install command

The README uses a remote shell install:

curl -fsSL https://raw.githubusercontent.com/withkynam/vibecode-pro-max-kit/main/install.sh | bash

After installation, run vc-setup in Claude Code; Codex users should follow the README and use /vc-setup. It creates the process/ directory and initializes the project configuration.

Files written by the install

The current README describes the install as non-destructive: it does not wipe existing .claude/skills/, .claude/agents/, process/, or settings.json; it only writes or updates kit-owned files. It still places these directories and files in the project:

Path	Content
.claude/agents	Claude Code agent definitions; the current README says 15
.claude/skills	Claude Code skill definitions; the current README says 33
.claude/hooks	Lifecycle hooks; the current README says 10
.codex/agents	Mirrored agents for Codex
.agents/skills	Symlink to .claude/skills for Codex discovery
CLAUDE.md	Claude Code orchestrator and routing rules
AGENTS.md	Cross-tool agent and skill registry
process/	Plan lifecycle and project memory directory

The README also says existing config is backed up to .vibecode-backup/, an existing CLAUDE.md is backed up as CLAUDE.md.pre-vibecode, and an existing process/ directory is not migrated directly by the installer. Instead, vc-setup / vc-update handles that interactively.

Safety audit checklist

Do not run curl | bash directly in a production repository. Even when the README calls the install non-destructive, the remote shell script still needs review because it writes to sensitive paths such as .claude/, .codex/, CLAUDE.md, and AGENTS.md.

For the first trial, use this flow:

1. fork or copy a non-production project
2. run the installer in that fork
3. inspect the files with git diff
4. migrate only after the configuration changes look expected

You still need to verify that the backup behavior fits your repository. Projects with custom vc- prefixed skills or agents should follow the README caveat and check the result carefully.

“Non-destructive” also does not mean “risk-free.” It lowers the chance of wiping an existing directory, but it does not replace supply-chain review, permission boundaries, or rollback planning. For a team project, the smallest safe move is still to read the script, run it in a copy, and ask a reviewer to inspect the diff.

---

Core idea: spec-driven workflow

Spec Kit background

The core idea behind vibecode-pro-max-kit comes from spec-driven development workflows such as Spec Kit. The flow is simple: write the spec first, refine it into a plan, split the plan into tasks, and then implement.

Each phase produces a Markdown artifact that gives structured context to the next phase:

Phase	Input	Output
Spec	Requirement description	Spec document with boundaries, constraints, and acceptance criteria
Plan	Spec document	Implementation plan with steps, owners, and dependencies
Tasks	Implementation plan	Concrete, verifiable task list
Implement	Task list	Code changes plus process notes

That workflow is not new, but vibecode-pro-max-kit installs it into the project: agents, skills, and hooks are all organized around the process.

Plan lifecycle

The current README emphasizes a RIPER-5 plan-first workflow and describes 7 gated phases:

Phase	What it does	Artifact
Research	Collect background and confirm boundaries	research artifact
Spec	Write user stories and requirement boundaries	spec artifact
Innovate	Compare options and make trade-off decisions	alternatives / decision notes
Plan	Detail steps, ownership, and validation	plan artifact
Validate	Check the plan and risks before execution	validation notes
Execute	Implement the tasks and record the process	code changes + execution notes
Update-Process	Update memory and clear stale notes	process / context updates

Each phase needs explicit approval before moving forward. That is the key control point: a human checks the direction before the agent keeps going.

Agents and skills

The README currently says 15 agents, 33 skills, and 10 hooks. That is the official README wording verified on June 23, 2026, not a permanent constant.

The skill structure follows Codex Skills and Claude Code skills: each skill has a SKILL.md file for instructions, with optional scripts/, references/, and assets/. A skill can be called explicitly or triggered implicitly when the task matches its boundary.

Two more concepts matter:

• context groups: context blocks organized by topic or feature, so the agent does not load the entire project every time
• feature folders: feature-level folders with their own spec and process material

---

Safety mechanisms

The README lists several safety and workflow mechanisms worth paying attention to:

Mechanism	Role	When it matters
privacy guardrails	Prevent sensitive information from entering process files or output	Before agent output and process updates
gated phases	Stop the agent from jumping straight to code	From Research through Update-Process
check loops	Let execution self-check and return to the plan	During execution and validation
deviation protocol	Record behavior that diverges from the original plan	When the plan changes or execution drifts
high-risk evidence pack	Require extra evidence for risky decisions	When a threshold is triggered

These mechanisms make it harder for the AI to make risky decisions without oversight. They still depend on hooks and configuration working correctly. If hooks are disabled, permissions are too broad, or the team never reviews process/, the mechanism can still fail.

---

Fit checklist

Scenario	Fit	Why
Long-lived maintenance project	Good fit	Memory settles in process/, and plans are auditable
Multi-person review	Good fit	Decisions leave a trail, and deviations can be traced
Complex requirement	Good fit	Multi-agent collaboration and phase-by-phase refinement help
Context is easy to lose	Good fit	Spec-driven structure gives the conversation shape
One-off script	Not a great fit	The workflow overhead is too high
Tiny fix	Not a great fit	The harness costs more than the change
Mature engineering process already exists	Use caution	It may conflict with existing CI/CD and review flow
You do not want an external harness	Not a fit	README, AGENTS.md, CLAUDE.md, and process files change the repository

The core question is whether the workflow overhead is worth it. Long-lived, complex, collaborative projects can trade that overhead for auditability and coordination. Short, simple, solo projects pay the overhead as pure cost.

---

Relationship to Spec Kit, Codex Skills, and Claude Code

Spec Kit: defines the background and process frame for SDD, or spec-driven development. It is conceptual and not tied to one specific agent.

Codex Skills: OpenAI’s skill directory shape: SKILL.md + scripts/ + references/. It packages instructions, resources, and scripts into reusable workflows.

Claude Code skills: similar structure, with SKILL.md plus supporting files. A skill acts as a reusable workflow unit and can be invoked explicitly or implicitly.

vibecode-pro-max-kit: installs those ideas into a project. It does not replace Spec Kit; it turns a spec-driven workflow into executable agents, skills, and hooks, with project configuration for Claude Code and Codex.

Migration cost: if the project already has .claude/agents, .claude/skills, CLAUDE.md, or AGENTS.md, inspect the diff and make sure your own custom configuration was not lost.

---

First trial workflow

Following the README, the first trial should happen outside production:

Step 1: fork or copy a non-production project

Do not work directly in the main repository. Use a fork or a local test copy.

Step 2: run the install command

curl -fsSL https://raw.githubusercontent.com/withkynam/vibecode-pro-max-kit/main/install.sh | bash

Step 3: run vc-setup

Run vc-setup in Claude Code; in Codex, follow the README and use /vc-setup. It creates process/ and initializes configuration.

Step 4: inspect the files written

git status
git diff .claude/ .codex/ .agents/ CLAUDE.md AGENTS.md process/

Confirm that the written files match expectations.

Step 5: try the first spec-driven workflow

Give the agent a simple request, such as “add a logging helper.” Watch the Research → Spec → Innovate → Plan → Validate → Execute → Update-Process flow, and confirm that each approval gate fires.

Step 6: validate the result

Look for artifacts under process/, readable changes in CLAUDE.md / AGENTS.md, and no errors from hooks or agents. Only then consider moving the setup into a real project.

---

Next steps and related reading

Related published posts:

• OpenClaw multi-agent routing practice
• A complete Claude Code workflow guide
• AI agent memory mechanisms

Follow-up topics in this series:

• A troubleshooting checklist for multi-agent collaboration
• A hands-on spec-driven project case study