@zcy2nn/agent-forge 1.0.5 → 1.1.0

package/dist/hooks/index.d.ts

@@ -9,5 +9,6 @@ export { processImageAttachments } from './image-hook';
 export { createJsonErrorRecoveryHook } from './json-error-recovery';
 export { createPhaseReminderHook } from './phase-reminder';
 export { createPostFileToolNudgeHook } from './post-file-tool-nudge';
+export { createSessionBootstrapHook } from './session-bootstrap';
 export { createTaskSessionManagerHook } from './task-session-manager';
 export { createTodoContinuationHook } from './todo-continuation';

package/dist/hooks/session-bootstrap/index.d.ts

@@ -0,0 +1,32 @@
+/**
+ * Session bootstrap hook — injects lightweight assessment framework
+ * into the first user message of each session.
+ *
+ * This gives the orchestrator a "work manual front page" so it assesses
+ * task complexity before jumping into implementation.
+ * Only injected for the orchestrator agent, only once per session.
+ */
+interface MessageInfo {
+    role: string;
+    agent?: string;
+    sessionID?: string;
+}
+interface MessagePart {
+    type: string;
+    text?: string;
+    [key: string]: unknown;
+}
+interface MessageWithParts {
+    info: MessageInfo;
+    parts: MessagePart[];
+}
+/**
+ * Creates the experimental.chat.messages.transform hook for session bootstrap.
+ * Injects the assessment framework into the first user message, orchestrator only.
+ */
+export declare function createSessionBootstrapHook(): {
+    'experimental.chat.messages.transform': (_input: Record<string, never>, output: {
+        messages: MessageWithParts[];
+    }) => Promise<void>;
+};
+export {};

package/dist/index.js

@@ -23425,6 +23425,80 @@ function createPostFileToolNudgeHook(options = {}) {
     }
   };
 }
+// src/hooks/session-bootstrap/index.ts
+var BOOTSTRAP_MARKER = "<session_bootstrap>";
+var BOOTSTRAP_CONTENT = `${BOOTSTRAP_MARKER}
+## Instruction Priority
+1. User's explicit instructions (CLAUDE.md, AGENTS.md, direct requests) — highest
+2. Superpowers skills — override default system behavior where they conflict
+3. Default system prompt — lowest
+
+## Subagents
+Subagents dispatched to execute a specific task skip this flow.
+
+## Task Complexity Assessment
+Assess task complexity before responding:
+**Simple (direct answer):** Single step, knowledge question, small edit, config change, debug single error
+**Medium or Complex (proposal flow):** Multi-file changes, design decisions, new features, cross-module, architecture changes
+
+## Proposal Flow
+Present three tiers:
+Suggested approach:
+── Lightweight ── [Phase]
+── Recommended ── [Phase] → [Phase] → [Phase] → [Phase]
+── Full ── [Phase (strategy)] → [Phase] → [Phase (strategy)] → [Phase + Review]
+Pick one, or tell me custom steps.
+
+## Phase & Skill Mapping
+[Design] = brainstorming
+[Plan] = writing-plans
+[Implement] = test-driven-development / subagent-driven-development / dispatching-parallel-agents
+[Verify] = verification-before-completion
+[Review] = requesting-code-review
+Encounter bug → systematic-debugging (available at any phase)
+
+## Proposal Guidance
+- Don't over-simplify: if the task involves multi-file changes or design decisions, don't suggest "implement directly"
+- Don't over-complicate: simple questions don't need the proposal flow
+- Lightweight must include [Verify]: even a single-phase approach must run verification commands. Lightweight means fewer phases, not skipping discipline.
+- Be specific: describe what will be done clearly, avoid vague terms
+
+## Skill Types
+**Rigid** (TDD, debugging): Follow the spirit at all tiers. Simple tasks may use abbreviated forms (test-after, quick fix with verification), but the discipline of verify-before-claim always applies.
+**Flexible** (brainstorming, writing-plans): Adapt principles to context. Simple tasks may skip these entirely.
+
+## Skill Access
+Use the skill tool to list and load skills on demand.
+${BOOTSTRAP_MARKER}`;
+function createSessionBootstrapHook() {
+  return {
+    "experimental.chat.messages.transform": async (_input, output) => {
+      const { messages } = output;
+      if (messages.length === 0) {
+        return;
+      }
+      const firstUserMessage = messages.find((m) => m.info.role === "user");
+      if (!firstUserMessage) {
+        return;
+      }
+      const agent = firstUserMessage.info.agent;
+      if (agent && agent !== "orchestrator") {
+        return;
+      }
+      const textPartIndex = firstUserMessage.parts.findIndex((p) => p.type === "text" && typeof p.text === "string");
+      if (textPartIndex === -1) {
+        return;
+      }
+      const originalText = firstUserMessage.parts[textPartIndex].text ?? "";
+      if (originalText.includes(BOOTSTRAP_MARKER)) {
+        return;
+      }
+      firstUserMessage.parts[textPartIndex].text = `${BOOTSTRAP_CONTENT}
+
+${originalText}`;
+    }
+  };
+}
 // src/hooks/task-session-manager/index.ts
 import path9 from "node:path";
 var AGENT_NAME_SET = new Set([
@@ -32455,6 +32529,7 @@ var OhMyOpenCodeLite = async (ctx) => {
   let multiplexerSessionManager;
   let autoUpdateChecker;
   let phaseReminderHook;
+  let sessionBootstrapHook;
   let filterAvailableSkillsHook;
   let sessionAgentMap;
   let postFileToolNudgeHook;
@@ -32540,6 +32615,7 @@ var OhMyOpenCodeLite = async (ctx) => {
       autoUpdate: config.autoUpdate ?? true
     });
     phaseReminderHook = createPhaseReminderHook();
+    sessionBootstrapHook = createSessionBootstrapHook();
     filterAvailableSkillsHook = createFilterAvailableSkillsHook(ctx, config);
     sessionAgentMap = new Map;
     postFileToolNudgeHook = createPostFileToolNudgeHook({
@@ -32922,6 +32998,7 @@ ${output.system[0]}` : "");
     },
     "experimental.chat.messages.transform": async (input, output) => {
       const typedOutput = output;
+      await sessionBootstrapHook["experimental.chat.messages.transform"](input, typedOutput);
       for (const message of typedOutput.messages) {
         if (message.info.role !== "user") {
           continue;

package/dist/tui.js

@@ -236,6 +236,20 @@ var plugin = {
     api.slots.register({
       order: 900,
       slots: {
+        home_prompt_right(_ctx, _props) {
+          return box({
+            flexDirection: "row",
+            alignItems: "center",
+            gap: 1
+          }, [
+            box({
+              paddingLeft: 1,
+              paddingRight: 1,
+              backgroundColor: api.theme.current.accent
+            }, [text({ fg: api.theme.current.background }, ["AGF"])]),
+            text({ fg: api.theme.current.textMuted }, [`v${version}`])
+          ]);
+        },
         sidebar_content(_ctx, _props) {
           return renderSidebar(snapshot, version, api.theme.current);
         }

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@zcy2nn/agent-forge",
-  "version": "1.0.5",
+  "version": "1.1.0",
   "description": "Lightweight agent orchestration plugin for OpenCode - a slimmed-down fork of oh-my-opencode",
   "main": "dist/index.js",
   "types": "dist/index.d.ts",

package/src/skills/brainstorming/SKILL.md

@@ -10,12 +10,20 @@ Help turn ideas into fully formed designs and specs through natural collaborativ
 Start by understanding the current project context, then ask questions one at a time to refine the idea. Once you understand what you're building, present the design and get user approval.
 
 <HARD-GATE>
-Do NOT invoke any implementation skill, write any code, scaffold any project, or take any implementation action until you have presented a design and the user has approved it. This applies to EVERY project regardless of perceived simplicity.
+For Medium/Complex tasks: Do NOT invoke any implementation skill, write any code, scaffold any project, or take any implementation action until you have presented a design and the user has approved it.
+
+For Simple tasks: You may proceed directly if the task is a knowledge question, small config change, or single-file edit with no design decisions. If uncertain whether a design is needed, err on the side of presenting a Lightweight design (2-3 sentences) and getting oral confirmation.
 </HARD-GATE>
 
-## Anti-Pattern: "This Is Too Simple To Need A Design"
+## Complexity Adaptation
+
+This skill adapts to the complexity tier determined by session-bootstrap:
+
+- **Simple tasks** (direct answer tier): Skip this skill entirely unless the task involves design decisions. If a Simple task does need design, use Lightweight mode.
+- **Medium tasks**: Use Lightweight or Standard mode.
+- **Complex tasks**: Use Standard or Deep mode. The HARD-GATE above applies in full.
 
-Every project goes through this process. A todo list, a single-function utility, a config change — all of them. "Simple" projects are where unexamined assumptions cause the most wasted work. The design can be short (a few sentences for truly simple projects), but you MUST present it and get approval.
+Don't skip design when it matters — "simple" tasks with unexamined assumptions cause the most wasted work. But don't force ceremony when it genuinely doesn't add value.
 
 ## Checklist
 
@@ -150,6 +158,7 @@ Wait for the user's response. If they request changes, make them and re-run the
 - Skip context exploration, skip one-by-one questions
 - Give 2-3 options directly for user to pick
 - No spec document — oral confirmation is enough
+- Applies when session-bootstrap classifies the task as Simple and design is still warranted
 
 **Standard usage:**
 - Full flow: explore context → one-by-one questions → compare approaches → present design → write spec

package/src/skills/systematic-debugging/SKILL.md

@@ -16,10 +16,13 @@ Random fixes waste time and create new bugs. Quick patches mask underlying issue
 ## The Iron Law
 
 ```
-NO FIXES WITHOUT ROOT CAUSE INVESTIGATION FIRST
+For Medium/Complex bugs: NO FIXES WITHOUT ROOT CAUSE INVESTIGATION FIRST
+For Simple bugs: Quick fix is acceptable if the cause is obvious, but verify the fix works
 ```
 
-If you haven't completed Phase 1, you cannot propose fixes.
+If you haven't completed Phase 1 for a Medium/Complex bug, you cannot propose fixes.
+
+For Simple bugs (single error, obvious symptom, config typo, known pattern): you may fix directly, but must verify the fix resolves the issue. If the quick fix doesn't work, escalate to full investigation immediately.
 
 ## When to Use
 
@@ -39,9 +42,14 @@ Use for ANY technical issue:
 - You don't fully understand the issue
 
 **Don't skip when:**
-- Issue seems simple (simple bugs have root causes too)
 - You're in a hurry (rushing guarantees rework)
 - Manager wants it fixed NOW (systematic is faster than thrashing)
+- Previous fix didn't work (symptom fixing masks root cause)
+
+**When abbreviated investigation is acceptable:**
+- session-bootstrap classifies the task as Simple
+- The cause is obvious from the error message (e.g., config typo, missing import)
+- If the quick fix doesn't work, immediately escalate to full investigation
 
 ## The Four Phases
 
@@ -290,8 +298,10 @@ These techniques are part of systematic debugging and available in this director
 ## Complexity Assessment
 
 **Lightweight usage:**
-- Reproduce → read error → fix directly
+- Reproduce → read error → fix directly (only when cause is obvious)
 - Skip hypothesis verification and root cause analysis
+- Applies when session-bootstrap classifies the task as Simple
+- If quick fix doesn't work, escalate to Standard immediately
 
 **Standard usage:**
 - Full flow: reproduce → gather evidence → hypothesize → verify → fix → regression test

package/src/skills/test-driven-development/SKILL.md

@@ -15,34 +15,43 @@ Write the test first. Watch it fail. Write minimal code to pass.
 
 ## When to Use
 
-**Always:**
+**Always (for Medium/Complex tasks):**
 - New features
 - Bug fixes
 - Refactoring
 - Behavior changes
 
+**Simple tasks (test-after acceptable):**
+- Config changes
+- Typo fixes
+- Single-line corrections
+- Obvious corrections with no logic change
+
 **Exceptions (ask your human partner):**
 - Throwaway prototypes
 - Generated code
 - Configuration files
+- Simple edits classified by session-bootstrap (config changes, typos, single-line fixes)
 
 Thinking "skip TDD just this once"? Stop. That's rationalization.
 
 ## The Iron Law
 
 ```
-NO PRODUCTION CODE WITHOUT A FAILING TEST FIRST
+For Medium/Complex tasks: NO PRODUCTION CODE WITHOUT A FAILING TEST FIRST
+For Simple tasks: Test-after is acceptable, but verification is still required
 ```
 
-Write code before the test? Delete it. Start over.
+**Medium/Complex tasks:** Write code before the test? Delete it. Start over.
 
-**No exceptions:**
 - Don't keep it as "reference"
 - Don't "adapt" it while writing tests
 - Don't look at it
 - Delete means delete
 
-Implement fresh from tests. Period.
+**Simple tasks** (as classified by session-bootstrap): If the change is a config change, typo fix, single-line correction, or similar trivial edit — implement first, then write a test or run verification. If the change affects behavior or logic, TDD still applies.
+
+Implement fresh from tests. Period (for Medium/Complex).
 
 ## Red-Green-Refactor
 

package/src/skills/verification-before-completion/SKILL.md

@@ -21,6 +21,10 @@ NO COMPLETION CLAIMS WITHOUT FRESH VERIFICATION EVIDENCE
 
 If you haven't run the verification command in this message, you cannot claim it passes.
 
+**This applies at ALL complexity tiers.** What varies is the depth of verification:
+- **Simple tasks:** Run the relevant verification command (tests, linter, build) and confirm it passes
+- **Medium/Complex tasks:** Run full verification suite, check coverage, verify edge cases, review against requirements
+
 ## The Gate Function
 
 ```
@@ -134,14 +138,16 @@ From 24 failure memories:
 
 **Lightweight usage:**
 - Run core tests, confirm pass
+- Applies when session-bootstrap classifies the task as Simple
 
 **Standard usage:**
 - Run all tests + check coverage + verify edge cases
 
-## The Bottom Line
+**Deep usage:**
+- Standard + requirements checklist + line-by-line verification + cross-reference with design spec
 
-**No shortcuts for verification.**
+## The Bottom Line
 
-Run the command. Read the output. THEN claim the result.
+**No shortcuts for verification.** The principle is non-negotiable; the depth adapts to complexity.
 
-This is non-negotiable.
+Run the command. Read the output. THEN claim the result. Whether you run one test or the full suite depends on the task's complexity tier, but you must ALWAYS run something before claiming completion.

package/dist/cli/migration.d.ts

@@ -1,46 +0,0 @@
-/** Result of a migration attempt. */
-export interface MigrationResult {
-    /** Whether a legacy config was detected. */
-    detected: boolean;
-    /** Whether the migration was performed. */
-    migrated: boolean;
-    /** Path to the new config file, if migrated. */
-    newPath?: string;
-    /** Path to the legacy config file that was found. */
-    legacyPath?: string;
-    /** Error message if migration failed. */
-    error?: string;
-}
-/**
- * Get all possible legacy config file paths (json and jsonc).
- */
-export declare function getLegacyConfigPaths(): string[];
-/**
- * Detect whether a legacy `oh-my-opencode-slim.json` config exists.
- * Returns the path if found, or undefined.
- */
-export declare function detectLegacyConfig(): string | undefined;
-/**
- * Check if a config object contains any legacy agent names
- * in its presets or agents sections.
- */
-export declare function hasLegacyAgentNames(config: Record<string, unknown>): boolean;
-/**
- * Migrate agent names in a config object.
- *
- * - Renames primary mapping keys (explorer→researcher, oracle→reviewer,
- *   designer→implementer).
- * - For secondary mappings (librarian→researcher, fixer→implementer),
- *   only applies if the primary mapping target doesn't already exist.
- * - Removes observer entries entirely.
- * - Preserves all non-agent config keys unchanged.
- */
-export declare function migrateAgentNames(config: Record<string, unknown>): Record<string, unknown>;
-/**
- * Perform the full migration:
- * 1. Read legacy config
- * 2. Migrate agent names
- * 3. Write to `agent-forge.json`
- * 4. Rename legacy file to `.bak`
- */
-export declare function performMigration(legacyPath: string): MigrationResult;