aiblueprint-cli 1.4.104 → 1.4.106

package/agents-config/skills/use-goal/references/claude-code-goal.md

@@ -1,65 +0,0 @@
-# Claude Code Goal Reference
-
-Use this reference when the active agent is Claude Code.
-
-Official reference:
-
-- https://code.claude.com/docs/en/goal
-
-## Manual Activation
-
-Claude Code has `/goal`, but the model cannot launch it unless the harness exposes a slash-command dispatch tool. If no dispatch tool is available, output the exact `/goal ...` command, ask the user to paste/run it manually, and wait for confirmation before continuing Goal-driven work.
-
-Do not say Claude Code lacks `/goal`. Do not call `/goal` Codex-only. Do not replace `/goal` with a task list, TODO list, or goal file and describe it as equivalent. Those can be supporting artifacts only when the user asks for them or when they are useful after the manual `/goal` command has been provided.
-
-If the user asks to continue without manually pasting the command, continue normal work only after acknowledging that no Claude Code Goal is active.
-
-## Command Surface
-
-Claude Code uses `/goal` to set a completion condition for the current session.
-
-- `/goal <condition>` sets the Goal and immediately starts a turn using the condition as the directive.
-- `/goal` with no argument shows the current state, evaluated turns, token spend, and latest evaluator reason.
-- `/goal clear` removes the active Goal before it is met.
-- `stop`, `off`, `reset`, `none`, and `cancel` are aliases for `clear`.
-- `/clear` starts a new conversation and removes any active Goal.
-- `claude -p "/goal <condition>"` can run a Goal non-interactively until the condition is met or the process is interrupted.
-
-Only one Goal can be active per Claude Code session. Setting a new `/goal <condition>` replaces the active Goal. Do not overwrite an existing Goal unless the user explicitly asks to replace it.
-
-If an active Goal existed when a Claude Code session ended, it is restored on `--resume` or `--continue`; the condition carries over, but the timer, turn count, and token-spend baseline reset.
-
-## Requirements
-
-Claude Code `/goal` requires Claude Code v2.1.139 or later.
-
-It only runs in trusted workspaces because it uses the hooks system. It is unavailable when hooks are disabled through `disableAllHooks` or restricted through `allowManagedHooksOnly`; Claude Code should explain that condition when the command fails.
-
-## Evaluator Behavior
-
-Claude Code evaluates the Goal after each turn with a separate small fast model. A "no" result starts another turn and passes the evaluator reason as guidance. A "yes" result clears the Goal and records the achieved condition in the transcript.
-
-The evaluator does not call tools, read files, or run commands independently. It judges only the condition and what Claude has surfaced in the conversation so far. Therefore the Goal must require Claude to put the proof in the transcript.
-
-Good Claude Code Goal conditions include:
-
-- one measurable end state, such as a passing test, clean build, target count, or empty queue
-- a stated check, such as a command exiting `0`, a generated report, or a reviewed artifact
-- constraints that matter, such as files not to modify or behavior not to regress
-- a bounded stop clause when useful, such as "or stop after 20 turns with the remaining blocker"
-
-Goal conditions can be up to 4,000 characters. If the instructions are longer, put details in a file and make the Goal point to that file.
-
-## Claude Code Draft Pattern
-
-Prefer this pattern:
-
-```text
-/goal <desired end state>, verified by <proof Claude must surface in the transcript>, while preserving <constraints>. First inspect <files/docs/logs>. After each turn, report the current checkpoint, command/artifact result, remaining gap, and next smallest step. Stop when the proof is in the transcript, or after <bound> with attempted paths, evidence, blocker, and needed input.
-```
-
-For test or build work:
-
-```text
-/goal <desired end state>, verified by `<test/build command>` exiting 0 with the relevant output included in the transcript, while preserving <constraints>. First inspect <files/logs>. After each turn, rerun the narrowest relevant check and summarize the result. Stop only when the command output proves success, or stop after <bound> with the failing output, attempted fixes, and missing input.
-```

package/agents-config/skills/use-goal/references/codex-goal.md

@@ -1,70 +0,0 @@
-# Codex Goal Reference
-
-Use this reference when the active agent is OpenAI Codex, including the Codex app, IDE extension, or CLI.
-
-Official references:
-
-- https://developers.openai.com/codex/use-cases/follow-goals
-- https://developers.openai.com/codex/app/commands
-- https://developers.openai.com/codex/cli/slash-commands
-
-## Command Surface
-
-`/goal <objective>` starts Goal mode. `/goal` views the current Goal. `/goal pause`, `/goal resume`, and `/goal clear` manage lifecycle.
-
-Goal objectives must be non-empty and at most 4,000 characters. For longer instructions, create or point to a file and make the Goal refer to that file.
-
-If `/goal` is missing, tell the user to enable Goals with:
-
-```toml
-[features]
-goals = true
-```
-
-They can also run:
-
-```bash
-codex features enable goals
-```
-
-## Tool Contract
-
-When Codex Goal tools are available, use the tools instead of printing a slash command for activation:
-
-1. Call `get_goal` before any lifecycle action.
-2. If the user asked to create, set, start, activate, or use a new Goal and no active Goal exists, call `create_goal` with the refined objective.
-3. Pass `token_budget` only when the user explicitly provided a budget.
-4. If a Goal already exists, do not overwrite, clear, pause, resume, mark complete, or mark blocked unless the user explicitly asked for that lifecycle action or the active Goal's stated status condition is actually met.
-
-Use slash-command text only when the user asks for a draft, the tool surface is unavailable, or the target is a separate Codex session.
-
-## Codex Goal Shape
-
-A strong Codex Goal should define:
-
-- one objective and one stopping condition
-- the files, docs, issue, logs, or plan Codex should inspect first
-- the commands, artifacts, screenshots, benchmarks, reports, or manual checks that prove progress
-- constraints that must not regress
-- checkpoint behavior and compact progress logging
-- the exact blocked stop condition and what evidence to report
-
-Prefer this pattern:
-
-```text
-<desired end state>, verified by <specific evidence>, while preserving <constraints>. Use <allowed inputs, tools, or boundaries>. Between iterations, <how to choose and record the next best action>. If blocked or no valid paths remain, stop with <attempted paths, evidence gathered, blocker, and next input needed>.
-```
-
-For implementation Goals, include exact commands when known:
-
-```text
-<desired end state>, verified by `<test or build command>` and <artifact/manual check>, while preserving <constraints>. First inspect <files/docs/logs>. Work in checkpoints: after each change, run the narrowest relevant verification, record the result, and choose the next smallest defensible step. Stop only when the verification passes, or stop blocked with the failed command output, attempted paths, and the missing input needed.
-```
-
-## Completion And Blocking
-
-Completion must be evidence-based. Compare the active Goal to concrete evidence in the thread: changed files, command output, tests, benchmarks, generated artifacts, logs, screenshots, or source-backed research findings.
-
-Do not mark a Goal complete because the work seems likely done, because a budget is exhausted, or because no more work is planned. Only mark it complete after verifying the stated stopping condition.
-
-Only mark a Goal blocked when the stated blocker has repeated enough that no meaningful progress is possible without user input or an external change. Report the attempted paths, gathered evidence, exact blocker, and input needed.

package/agents-config/skills/use-goal/references/verification-harnesses.md

@@ -1,108 +0,0 @@
-# Verification Harnesses For Refactors
-
-Use this reference when a Goal involves refactoring, deletion, migration, moving files, eliminating a pattern, or reducing a code smell. The core tactic is to create a small measurable harness before the main work, then make the Goal continue until the harness reaches the target.
-
-## Principle
-
-For broad changes, do not rely only on subjective review. Convert the desired end state into a number, list, or deterministic command result.
-
-Examples:
-
-- Remove all explicit TypeScript `any` -> count explicit `any` occurrences and require `0`.
-- Delete dead files -> scan imports/references and require no references to removed paths.
-- Move a module -> scan imports and require all imports use the new path.
-- Rename an API -> count old symbol references and require `0`, then run tests/typecheck.
-- Remove a dependency -> scan package manifests and lockfiles, then run install/typecheck/test.
-- Split a large file -> check file size or exported symbol boundaries, then run typecheck/test.
-
-The harness should make progress visible after every iteration.
-
-## Harness Rules
-
-1. First establish the baseline count or failure list before editing.
-2. Prefer existing repo tooling: tests, lint rules, typecheck, dependency analyzers, codemods, static analyzers.
-3. If no existing command measures the target, create a narrow validation script.
-4. Make the script deterministic and fast enough to run repeatedly.
-5. Exclude generated, vendored, build output, lockfiles, snapshots, and irrelevant binary assets unless the task explicitly includes them.
-6. Print actionable output: total count, grouped files, and the top remaining offenders.
-7. Exit with code `0` only when the target condition is met. Exit non-zero while work remains.
-8. Keep the harness scoped to the Goal. Remove temporary harnesses before completion unless they are useful project validation and the user or repo conventions support keeping them.
-
-## Goal Pattern
-
-Use this shape for count-based refactor Goals:
-
-```text
-<desired refactor>, verified by `<validation command>` returning success with <target count/list condition>, while preserving <tests/typecheck/public behavior>. First establish the baseline with `<validation command>` and inspect the highest-signal offenders. Work in checkpoints: after each batch, rerun `<validation command>`, record the count/list delta, run the narrowest relevant tests, and continue until the validation command exits 0. If the target cannot be reached safely, stop with the remaining offenders, attempted paths, failing output, and the decision needed.
-```
-
-Example:
-
-```text
-Remove all explicit TypeScript `any` from the codebase, verified by `node scripts/check-explicit-any.mjs` exiting 0 with count 0, while keeping `pnpm typecheck` and relevant tests green. First run the checker to record the baseline and prioritize files with the most occurrences. Work in checkpoints: after each batch, rerun the checker, record the remaining count, and run the narrowest relevant typecheck/tests. Continue until the checker exits 0. If some `any` cannot be removed safely, stop with the remaining locations, attempted replacements, compiler/test output, and the type information needed.
-```
-
-## Script Patterns
-
-Use structured parsers when reasonable. For TypeScript, prefer the TypeScript compiler API, `ts-morph`, ESLint, or an existing lint rule over raw text search when false positives matter.
-
-For a quick bootstrap harness, a text scanner is acceptable if the Goal explicitly treats it as an approximate first pass and follows up with typecheck/lint.
-
-Example quick scanner:
-
-```js
-#!/usr/bin/env node
-import { readdirSync, readFileSync, statSync } from "node:fs";
-import { join } from "node:path";
-
-const root = process.cwd();
-const ignoredDirs = new Set([".git", "node_modules", "dist", "build", ".next", "coverage"]);
-const extensions = new Set([".ts", ".tsx"]);
-const matches = [];
-
-function walk(dir) {
-  for (const entry of readdirSync(dir)) {
-    const path = join(dir, entry);
-    const stat = statSync(path);
-    if (stat.isDirectory()) {
-      if (!ignoredDirs.has(entry)) walk(path);
-      continue;
-    }
-    if (![...extensions].some((ext) => path.endsWith(ext))) continue;
-    const text = readFileSync(path, "utf8");
-    const lines = text.split("\n");
-    lines.forEach((line, index) => {
-      if (/\bany\b/.test(line)) matches.push(`${path.replace(`${root}/`, "")}:${index + 1}: ${line.trim()}`);
-    });
-  }
-}
-
-walk(root);
-
-console.log(`explicit_any_count=${matches.length}`);
-for (const match of matches.slice(0, 50)) console.log(match);
-if (matches.length > 50) console.log(`...and ${matches.length - 50} more`);
-process.exit(matches.length === 0 ? 0 : 1);
-```
-
-## Refactor Targets
-
-For deletion Goals, verify both absence and behavior:
-
-- target files or symbols are gone
-- no imports, string references, routes, config entries, docs links, or tests point to them
-- typecheck/build/test still passes
-
-For moving Goals, verify all call sites:
-
-- old import path count is `0`
-- new import path exists where expected
-- public exports remain compatible unless changing them is part of the Goal
-- typecheck/build/test still passes
-
-For migration Goals, verify old surface removal and new surface behavior:
-
-- old package/API/pattern count reaches `0` or the explicitly allowed exception list
-- new package/API/pattern is used consistently
-- tests/typecheck/build pass
-- manual or browser verification is included when behavior is visual or interactive