@vpxa/aikit 0.1.86 → 0.1.88
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/package.json +1 -1
- package/packages/cli/dist/index.js +2 -2
- package/packages/cli/dist/{init-CuRXmyD9.js → init-DyXyx-U6.js} +1 -1
- package/packages/cli/dist/{templates-ArdAVWoY.js → templates-C-qED27u.js} +2 -85
- package/packages/cli/dist/{user-C2c_eBDB.js → user-BCQCn7Be.js} +1 -1
- package/packages/server/dist/curated-manager-CXSPygmJ.js +7 -0
- package/packages/server/dist/index.d.ts +45 -0
- package/packages/server/dist/index.js +1 -1
- package/packages/server/dist/{server-DG5jasWR.js → server-CXsoHmuu.js} +145 -140
- package/packages/tools/dist/index.d.ts +133 -6
- package/packages/tools/dist/index.js +69 -68
- package/scaffold/dist/definitions/agents.mjs +37 -1
- package/scaffold/dist/definitions/bodies.mjs +37 -4
- package/scaffold/dist/definitions/protocols.mjs +0 -56
- package/scaffold/dist/definitions/skills.mjs +328 -1
- package/packages/server/dist/curated-manager-DX-_oJg0.js +0 -5
- package/scaffold/claude-code/commands/aikit-ask.md +0 -12
- package/scaffold/claude-code/commands/aikit-debug.md +0 -14
- package/scaffold/claude-code/commands/aikit-design.md +0 -14
- package/scaffold/claude-code/commands/aikit-flow-add.md +0 -83
- package/scaffold/claude-code/commands/aikit-flow-create.md +0 -79
- package/scaffold/claude-code/commands/aikit-flow-manage.md +0 -23
- package/scaffold/claude-code/commands/aikit-implement.md +0 -16
- package/scaffold/claude-code/commands/aikit-plan.md +0 -14
- package/scaffold/claude-code/commands/aikit-review.md +0 -23
|
@@ -1,79 +0,0 @@
|
|
|
1
|
-
# aikit flow-create
|
|
2
|
-
|
|
3
|
-
> Create a new flow from scratch or migrate an existing workflow to aikit format
|
|
4
|
-
|
|
5
|
-
## Flow Creation Assistant
|
|
6
|
-
|
|
7
|
-
Create a new development flow or migrate an existing workflow to the aikit flow format.
|
|
8
|
-
|
|
9
|
-
### Mode 1: Create from Scratch
|
|
10
|
-
|
|
11
|
-
Guide the user through building a complete flow:
|
|
12
|
-
|
|
13
|
-
1. **Define the workflow** — Ask what the flow should accomplish (e.g., "TDD workflow", "documentation pipeline", "migration process")
|
|
14
|
-
2. **Design steps** — Break the workflow into sequential steps (3-8 is ideal)
|
|
15
|
-
3. **For each step**:
|
|
16
|
-
- Define the step id, name, and description
|
|
17
|
-
- Write the instruction (README.md content — what the agent should do)
|
|
18
|
-
- Identify what it produces (output artifacts)
|
|
19
|
-
- Identify what it requires (which previous steps must complete first)
|
|
20
|
-
- Optionally assign preferred agents
|
|
21
|
-
4. **Generate flow.json** — Create the manifest with all steps
|
|
22
|
-
5. **Write step READMEs** — Create instruction files for each step
|
|
23
|
-
6. **Install** — Use `flow_add` to install from the local directory
|
|
24
|
-
|
|
25
|
-
### Mode 2: Migrate Existing Workflow
|
|
26
|
-
|
|
27
|
-
If the user has an existing workflow (scripts, docs, runbooks) that they want to convert:
|
|
28
|
-
|
|
29
|
-
1. **Analyze the source** — Read the existing workflow files to understand the process
|
|
30
|
-
2. **Map to steps** — Identify discrete steps with clear inputs/outputs
|
|
31
|
-
3. **Identify gaps** — What's missing for a complete flow? (instructions? ordering? agents?)
|
|
32
|
-
4. **Fill gaps with user** — Ask user to clarify any ambiguous parts
|
|
33
|
-
5. **Generate the flow** — Create flow.json + step READMEs
|
|
34
|
-
6. **Install and validate** — Use `flow_add` and `flow_info` to verify
|
|
35
|
-
|
|
36
|
-
### Flow Structure
|
|
37
|
-
|
|
38
|
-
```
|
|
39
|
-
my-flow/
|
|
40
|
-
flow.json — Flow manifest (name, version, steps, agents)
|
|
41
|
-
steps/
|
|
42
|
-
step-1/
|
|
43
|
-
README.md — Step instructions (what the agent should do)
|
|
44
|
-
step-2/
|
|
45
|
-
README.md
|
|
46
|
-
references/ — Optional reference files for the step
|
|
47
|
-
...
|
|
48
|
-
```
|
|
49
|
-
|
|
50
|
-
### flow.json Format
|
|
51
|
-
```json
|
|
52
|
-
{
|
|
53
|
-
"name": "my-flow",
|
|
54
|
-
"version": "1.0.0",
|
|
55
|
-
"description": "What this flow does",
|
|
56
|
-
"steps": [
|
|
57
|
-
{
|
|
58
|
-
"id": "step-id",
|
|
59
|
-
"name": "Human-readable Step Name",
|
|
60
|
-
"instruction": "steps/step-id/README.md",
|
|
61
|
-
"produces": ["artifact-name.md"],
|
|
62
|
-
"requires": [],
|
|
63
|
-
"agents": ["Preferred-Agent"],
|
|
64
|
-
"description": "Brief description of this step"
|
|
65
|
-
}
|
|
66
|
-
],
|
|
67
|
-
"agents": [],
|
|
68
|
-
"artifacts_dir": ".spec",
|
|
69
|
-
"install": []
|
|
70
|
-
}
|
|
71
|
-
```
|
|
72
|
-
|
|
73
|
-
### Step README Format
|
|
74
|
-
Each step README should include:
|
|
75
|
-
- **Goal** — What this step accomplishes
|
|
76
|
-
- **Inputs** — What context/artifacts from prior steps are needed
|
|
77
|
-
- **Instructions** — Detailed steps for the agent to follow
|
|
78
|
-
- **Output** — What artifact(s) to produce and where to save them
|
|
79
|
-
- **Acceptance criteria** — How to know the step is complete
|
|
@@ -1,23 +0,0 @@
|
|
|
1
|
-
# aikit flow-manage
|
|
2
|
-
|
|
3
|
-
> List, inspect, update, and remove installed flows
|
|
4
|
-
|
|
5
|
-
## Flow Management
|
|
6
|
-
|
|
7
|
-
Manage your installed development flows.
|
|
8
|
-
|
|
9
|
-
### Available Actions
|
|
10
|
-
|
|
11
|
-
1. **List flows** — `flow_list` to see all installed flows with status
|
|
12
|
-
2. **Inspect a flow** — `flow_info` to see detailed steps, agents, and artifacts
|
|
13
|
-
3. **Check status** — `flow_status` to see the active flow and current step
|
|
14
|
-
4. **Update a flow** — `flow_update` to pull latest changes for git-installed flows
|
|
15
|
-
5. **Remove a flow** — `flow_remove` to uninstall (builtin flows cannot be removed)
|
|
16
|
-
6. **Start a flow** — `flow_start` to begin executing a flow
|
|
17
|
-
7. **Reset active flow** — `flow_reset` to clear active flow state
|
|
18
|
-
|
|
19
|
-
### Workflow
|
|
20
|
-
1. If no specific action requested, start with `flow_list` and present overview
|
|
21
|
-
2. Use `present` to display flow information in a clear table/card format
|
|
22
|
-
3. For updates, warn if there's an active flow that might be affected
|
|
23
|
-
4. For removals, confirm with user before proceeding
|
|
@@ -1,16 +0,0 @@
|
|
|
1
|
-
# aikit implement
|
|
2
|
-
|
|
3
|
-
> Full lifecycle implementation: plan → build → review → commit
|
|
4
|
-
|
|
5
|
-
## Implementation Pipeline
|
|
6
|
-
|
|
7
|
-
Follow the Orchestrator's full workflow:
|
|
8
|
-
|
|
9
|
-
1. **Phase 0: Design Gate** — Orchestrator checks if design is needed. Creative/additive work triggers brainstorming first. Use `/design` if you want to start with design explicitly.
|
|
10
|
-
2. **Phase 1: Planning** — Research, draft plan, present to user for approval
|
|
11
|
-
3. **Phase 2: Implementation** — Execute phases in parallel batches
|
|
12
|
-
4. **Phase 3: Completion** — Final review, docs, persist learnings
|
|
13
|
-
|
|
14
|
-
**🛑 MANDATORY STOPS** — After plan, after each batch, after completion.
|
|
15
|
-
|
|
16
|
-
Refer to the Orchestrator agent's full instructions for the detailed workflow.
|
|
@@ -1,14 +0,0 @@
|
|
|
1
|
-
# aikit plan
|
|
2
|
-
|
|
3
|
-
> Create a detailed TDD implementation plan without executing it
|
|
4
|
-
|
|
5
|
-
## Planning Workflow
|
|
6
|
-
|
|
7
|
-
1. **AI Kit Recall** — Search for past plans, architecture decisions
|
|
8
|
-
2. **FORGE Ground** — Classify tier, scope map, seed unknowns
|
|
9
|
-
3. **Research** — Explore codebase, understand subsystems
|
|
10
|
-
4. **Draft Plan** — 3-10 phases with agent assignments, TDD steps
|
|
11
|
-
5. **Dependency Graph** — Group into parallel batches
|
|
12
|
-
6. **Present** — Show plan with open questions
|
|
13
|
-
|
|
14
|
-
**🛑 MANDATORY STOP** — Wait for user approval. Do NOT implement.
|
|
@@ -1,23 +0,0 @@
|
|
|
1
|
-
# aikit review
|
|
2
|
-
|
|
3
|
-
> Dual-model code + architecture review pipeline
|
|
4
|
-
|
|
5
|
-
## Review Pipeline
|
|
6
|
-
|
|
7
|
-
### Step 1: Scope
|
|
8
|
-
Identify changed files and their blast radius.
|
|
9
|
-
|
|
10
|
-
### Step 2: Code Review (parallel)
|
|
11
|
-
Launch Code-Reviewer-Alpha and Code-Reviewer-Beta on the same changeset.
|
|
12
|
-
|
|
13
|
-
### Step 3: Architecture Review (if needed)
|
|
14
|
-
If changes cross service boundaries or modify interfaces, launch Architect-Reviewer-Alpha and Architect-Reviewer-Beta.
|
|
15
|
-
|
|
16
|
-
### Step 4: Synthesis
|
|
17
|
-
Merge findings from both reviewers:
|
|
18
|
-
- **Agreements**: Both found same issue → HIGH confidence
|
|
19
|
-
- **Unique findings**: One found, other didn't → verify
|
|
20
|
-
- **Disagreements**: Contradicting verdicts → present both to user
|
|
21
|
-
|
|
22
|
-
### Step 5: Report
|
|
23
|
-
Present unified review with: verdict, findings by severity, recommended actions.
|