ctxora 6.2.2 → 6.3.0

package/src/harness_context/skills/ecc/benchmark-methodology/SKILL.md

@@ -0,0 +1,191 @@
+---
+name: benchmark-methodology
+description: >-
+  Use after competitive-platform-analysis has produced a tiered competitor set.
+  Scores each competitor across nine weighted dimensions (positioning, voice,
+  visual craft, offer packaging, evidence, enterprise-readiness, thought
+  leadership, pricing, client's strategic tension) with explicit 1–5 rubrics
+  and a tension-plot. Precedes competitive-report-structure.
+license: MIT
+---
+
+# Benchmark Methodology
+
+Use this skill to turn a scoped competitor set into **comparable, defensible
+scores**. Each competitor is assessed on the same nine dimensions, with
+explicit 1–5 rubrics, then captured in a uniform profile card. Consistency is
+the point: scores are only useful if the same evidence would earn the same
+number for any competitor.
+
+## When to Activate
+
+- A scoped, tiered competitor set from competitive-platform-analysis is ready to score.
+- Need comparable, evidence-anchored scores across competitors — not gut-feel rankings.
+- Client's strategic tension (the paired axes defining their target white-space) has been established.
+- Preparing to produce profile cards for assembly in competitive-report-structure.
+
+## Client positioning brief (establish first)
+
+Before scoring, establish the client's positioning brief. It supplies:
+
+- **Strategic tension** — the two axes (e.g., memorability × hireability) whose
+  intersection marks the client's target white-space. Dimension 9 is always
+  the client's named tension; report both poles separately, never averaged.
+- **Differentiator** — what makes the client's moat. This informs which
+  dimensions matter most for the client's positioning argument.
+- **Brand balance** — the intended mix of distinct strategic emphases. Strategic
+  recommendations must not break this balance without flagging it.
+
+## Why these dimensions
+
+The client competes on a **specific tension held across two poles**, not on
+service breadth. The dimensions are weighted to reflect that moat. Two
+dimensions — the tension poles — are scored **separately and never averaged
+together**, because the client's strategic question is precisely whether a rival
+achieves both simultaneously.
+
+## The nine dimensions (with weights)
+
+Weights guide synthesis emphasis, not a single blended score (avoid a false
+composite — see Bias controls). Sum = 100%.
+
+1. **Positioning clarity & distinctiveness** (18%) — Is the studio's position
+   sharp, ownable, and instantly legible? Or generic?
+2. **Brand voice / verbal distinctiveness** (15%) — Does the copy have an
+   ownable register, or is it interchangeable agency-speak?
+3. **Visual identity & site craft** (15%) — Quality and ownership of the visual
+   system; site as proof-of-craft.
+4. **Service offer & packaging** (12%) — Productized and legible (named
+   sprints/audits) vs vague. Packaging maturity.
+5. **Evidence & credibility** (12%) — Named clients, quantified outcomes,
+   case-study depth. Proof beyond assertion.
+6. **Enterprise-readiness / commercial maturity** (10%) — Signals they can land
+   and hold SaaS/fintech/B2B/enterprise work (process, logos, scale, contracts).
+7. **Thought leadership / content presence** (8%) — Owned POV: writing, talks,
+   newsletters, frameworks. Depth over volume.
+8. **Pricing transparency & engagement model** (5%) — Is pricing/engagement
+   legible? Productized vs bespoke vs opaque.
+9. **[Client's strategic tension]** (5% as a flag; **score BOTH poles,
+   report separately**) — Read the tension name and axis descriptions from the
+   client's positioning brief. Plot both; the gap is the insight. The client's
+   target quadrant is the single most important finding: who else is already
+   there?
+
+## Scoring rubric (1–5, applies to dimensions 1–8)
+
+Anchor every score to observable evidence. Generic descriptors below; adapt the
+specifics per dimension but keep the level meaning constant.
+
+- **1 — Absent / generic.** No discernible position or craft; indistinguishable
+  from a template. Active liability.
+- **2 — Below par.** Some intent but inconsistent, derivative, or unconvincing.
+  Wouldn't survive a side-by-side.
+- **3 — Competent / table-stakes.** Solid, professional, unremarkable. Meets
+  expectation, ownable by nobody.
+- **4 — Strong / distinctive.** Clearly above peers; a real strength a buyer
+  would notice and cite.
+- **5 — Category-defining.** Best-in-class, ownable, hard to imitate. Sets the
+  bar others react to.
+
+### Tension axes (dimension 9) — score each 1–5
+
+Read the axis labels and their 1/3/5 anchors from the client's positioning
+brief. Example anchors for a memorability × credibility tension:
+
+- **Memorability** — 1: forgotten instantly · 3: recognizable in context ·
+  5: unforgettable, talked-about, distinctively owned.
+- **Credibility** — 1: feels risky/amateur · 3: safe, competent,
+  unexciting · 5: enterprise-trusted, obvious safe choice.
+
+Plot competitors on the tension 2×2. The client's target quadrant is named in
+the positioning brief. Who else occupies that quadrant is the single most
+important finding of the benchmark.
+
+## How to collect the data
+
+For each competitor, work the dimensions in this order (cheapest signal first):
+
+1. **Competitor's own site** — positioning, voice, offer packaging, pricing
+   posture, named clients, manifesto/POV. Screenshot the homepage + one case
+   study.
+2. **Case studies / work** — evidence depth, quantified outcomes, client names.
+   Distinguish *asserted* ("we delivered X") from *proven* (metrics, named,
+   verifiable).
+3. **Review directories** — corroborate clients, project size, engagement model
+   → credibility & enterprise-readiness (e.g. Clutch.co or the niche equivalent).
+4. **LinkedIn** — team size/model, founder narrative, content cadence →
+   thought leadership, model.
+5. **Portfolio / craft platforms** — craft register (use the showcase native to
+   the niche: design boards, showreels, published samples, etc.).
+6. **Content channels** — newsletter/talks/writing → thought-leadership depth.
+
+**What to record per dimension:** the score, one-line justification, and the
+source link/screenshot that earned it. No score without evidence.
+
+## Bias controls
+
+- **No single composite score.** Report dimension scores and the tension plot
+  separately. A weighted average hides the asymmetry that matters.
+- **Asserted vs proven.** Downgrade credibility/evidence scores for
+  self-reported claims with no corroboration. Site copy is marketing, not fact.
+- **Aesthetic affinity bias.** Reviewers may over-score studios whose aesthetic
+  they share and under-score rivals' commercial strength. Score craft and
+  credibility independently; a "boring" site may be winning bigger clients.
+- **Recency / flashiness bias.** Award-winning, showpiece work dazzles but may
+  lack commercial depth — verify with directories/clients before scoring
+  credibility.
+- **Survivorship.** The visible, well-marketed studios aren't the whole market;
+  note strong-but-quiet operators found via directories/reviews.
+- **Calibrate across the set, not in isolation.** Before finalizing, re-read
+  scores side-by-side — a "4" must mean the same thing for every competitor.
+  Adjust outliers.
+
+## Competitor profile card (output format)
+
+Produce one card per profiled competitor — the atomic unit the report assembles
+from:
+
+```
+## <Competitor name>
+- **Profile / Tier:** <positioning stance · specialization · size band> / <Direct | Adjacent | Aspirational>
+- **One-liner:** <how they position themselves, in their words>
+- **Model / size / geography:** <solo|micro|boutique> · <region> · <pricing/engagement model>
+- **Notable clients / evidence:** <named, with proven/asserted tag>
+
+### Dimension scores
+| Dimension | Score (1–5) | Justification (1 line) | Source |
+|---|---|---|---|
+| Positioning clarity & distinctiveness | | | |
+| Brand voice / verbal distinctiveness | | | |
+| Visual identity & site craft | | | |
+| Service offer & packaging | | | |
+| Evidence & credibility | | | |
+| Enterprise-readiness / commercial maturity | | | |
+| Thought leadership / content presence | | | |
+| Pricing transparency & engagement model | | | |
+
+### Tension plot
+- **[Axis 1 from positioning brief]:** <1–5> — <why>
+- **[Axis 2 from positioning brief]:** <1–5> — <why>
+- **Quadrant:** <high/high | high-1/low-2 | low-1/high-2 | low/low>
+
+### Read for [client]
+- **Strength to learn from:** <…>
+- **Weakness to exploit / white-space it exposes:** <…>
+- **Threat to [client]:** <…>
+```
+
+Hand the completed cards plus the tension plot to `competitive-report-structure`.
+
+## Anti-Patterns
+
+- **Averaging the tension axes.** The two poles of the client's strategic tension must be scored and reported separately. Averaging destroys the insight — the gap between poles is the finding.
+- **Scoring without evidence.** Every score requires a one-line justification and a source link. A score without evidence is an opinion, not a benchmark.
+- **Creating a single composite score.** Report dimension scores individually. A weighted average hides the asymmetric strengths that matter for positioning.
+- **Applying generic rubric anchors without adapting.** The 1–5 anchors must be calibrated to the specific dimension and competitor set. The generic descriptions are a starting point, not a fixed standard.
+- **Running before the competitor set is scoped.** Use competitive-platform-analysis first to produce a tiered, pruned set. Scoring an unscoped list wastes effort on irrelevant competitors.
+
+## Related Skills
+
+- `competitive-platform-analysis` — the prerequisite; produces the tiered competitor set this skill scores.
+- `competitive-report-structure` — the next step; assembles the scored profile cards into a client-deliverable report.

package/src/harness_context/skills/ecc/benchmark-optimization-loop/LICENSE.ecc

@@ -0,0 +1,21 @@
+MIT License
+
+Copyright (c) 2026 Affaan Mustafa
+
+Permission is hereby granted, free of charge, to any person obtaining a copy
+of this software and associated documentation files (the "Software"), to deal
+in the Software without restriction, including without limitation the rights
+to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
+copies of the Software, and to permit persons to whom the Software is
+furnished to do so, subject to the following conditions:
+
+The above copyright notice and this permission notice shall be included in all
+copies or substantial portions of the Software.
+
+THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
+AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
+OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
+SOFTWARE.

package/src/harness_context/skills/ecc/benchmark-optimization-loop/SKILL.md

@@ -0,0 +1,71 @@
+---
+name: benchmark-optimization-loop
+description: Use when the user asks to make something faster, try many variants, run recursive optimization, benchmark latency/throughput/cost, or choose the best implementation by repeated measured tests.
+license: MIT
+metadata:
+  origin: ECC
+tools: Read, Write, Edit, Bash, Grep, Glob
+---
+
+# Benchmark Optimization Loop
+
+Use this skill to convert "make it 20x faster" or "try 50 recursive
+optimizations" into a bounded measured loop that can actually improve a system.
+
+## Required Baseline
+
+Do not optimize until these exist:
+
+- the operation being optimized;
+- the correctness gate that must stay green;
+- the metric: wall time, p95 latency, rows/sec, cost/run, memory, error rate;
+- the current baseline;
+- the search budget: max variants, max time, max spend, max data impact.
+
+If the user asks for an unrealistic target, keep the ambition but make the loop
+bounded and measurable.
+
+## Loop
+
+1. Measure the baseline.
+2. Identify bottlenecks from evidence.
+3. Generate variants that test one hypothesis each.
+4. Run variants with the same input shape.
+5. Reject variants that fail correctness, safety, or reproducibility.
+6. Promote the fastest safe variant.
+7. Codify the winning path in a script, command, test, config, or doc.
+8. Rerun the baseline and winner to confirm the delta.
+
+## Variant Table
+
+Track variants like this:
+
+```text
+Variant | Hypothesis | Command | Time | Correct? | Notes
+baseline | current path | npm run job | 120s | yes | stable
+batch-500 | fewer round trips | npm run job -- --batch 500 | 42s | yes | winner
+parallel-8 | more workers | npm run job -- --workers 8 | 31s | no | rate limited
+```
+
+## Recursive Search
+
+For recursive or hyperparameter work:
+
+- persist every run to a ledger;
+- compare against the prior accepted winner, not only the previous run;
+- keep a holdout or replay check;
+- stop when improvement is within noise, correctness fails, cost exceeds the
+  budget, or the search starts changing more variables than it can explain.
+
+Use phrases like "best measured safe variant" instead of "global optimum" unless
+the search space was actually exhaustive.
+
+## Promotion Gate
+
+A variant cannot become the new default until:
+
+- correctness tests pass;
+- the performance delta is repeated or explained;
+- rollback is obvious;
+- the change is encoded in source control or a durable runbook;
+- the final summary includes exact commands and measurements.

package/src/harness_context/skills/ecc/blender-motion-state-inspection/LICENSE.ecc

@@ -0,0 +1,21 @@
+MIT License
+
+Copyright (c) 2026 Affaan Mustafa
+
+Permission is hereby granted, free of charge, to any person obtaining a copy
+of this software and associated documentation files (the "Software"), to deal
+in the Software without restriction, including without limitation the rights
+to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
+copies of the Software, and to permit persons to whom the Software is
+furnished to do so, subject to the following conditions:
+
+The above copyright notice and this permission notice shall be included in all
+copies or substantial portions of the Software.
+
+THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
+AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
+OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
+SOFTWARE.

package/src/harness_context/skills/ecc/blender-motion-state-inspection/SKILL.md

@@ -0,0 +1,165 @@
+---
+name: blender-motion-state-inspection
+description: Use this skill when inspecting Blender characters, rigs, poses, animation retargeting, ground contact, facing direction, or model-vs-motion alignment where screenshots alone are not enough.
+metadata:
+  origin: ECC
+tools: Read, Write, Edit, Bash, Grep, Glob
+---
+
+# Blender Motion State Inspection
+
+## When to Use
+
+- A Blender character looks twisted, mirrored, flattened, offset, or foot-sliding in an animation.
+- A user asks whether an imported avatar, armature, or retargeted motion matches an expected pose.
+- You need to compare rendered evidence with structured facts such as bones, bounding boxes, contacts, and facing vectors.
+- A workflow depends on deciding whether a model is a character, prop, proxy mesh, control rig, or broken import.
+
+## Core Principle
+
+Do not judge animated 3D assets only from screenshots. Screenshots are review evidence, but they hide axis conventions, bone names, object scale, local transforms, parented meshes, material slots, and frame-by-frame contact state.
+
+First extract structured Blender state, then use viewport screenshots or renders to confirm what the facts imply.
+
+## How It Works
+
+1. Establish the clean scene and asset baseline before judging motion.
+2. Extract structured facts from Blender using an exporter or Blender Python run inside Blender's own interpreter.
+3. Sample the frames most likely to expose contact, orientation, scale, and retargeting errors.
+4. Compare the measured facts against the user's expected pose, direction, ground plane, and render goal.
+5. Return a concise report that separates confirmed facts, likely causes, and required fixes.
+
+## Inspection Workflow
+
+1. Inventory the scene.
+   - List meshes, armatures, empties, cameras, lights, modifiers, parent relationships, and hidden objects.
+   - Separate character meshes from helper/proxy geometry before judging the avatar.
+   - Record object-space and world-space bounding boxes.
+
+2. Identify the skeleton.
+   - Capture armature names, pose bones, bone heads/tails, roll, parent chains, constraints, and rest-pose axes.
+   - Map semantic bones such as hips, spine, neck, head, shoulders, elbows, hands, thighs, knees, ankles, and feet.
+   - Flag missing left/right pairs and unusual naming schemes.
+
+3. Determine forward, up, and side axes.
+   - Use the pelvis, spine, shoulders, hips, head, and feet together; do not rely on a single mesh normal.
+   - Compare local armature axes with world axes and imported file conventions such as glTF Y-up vs Blender Z-up.
+   - Mark likely mirrored or backwards imports when face/head/feet direction conflicts with root motion.
+
+4. Sample animation frames.
+   - Inspect first, middle, contact, airborne, and extreme frames.
+   - Record root location, root heading, pelvis height, torso lean, limb directions, foot clearance, and mesh bounds.
+   - For long or fast motion, sample more densely around flips, landings, turns, collisions, and floor contacts.
+
+5. Check model integrity before retargeting blame.
+   - Confirm the clean baseline shape before applying animation.
+   - Preserve original mesh, materials, armature, and skinning unless the user explicitly asks for repair.
+   - Treat unexplained sphere-like blobs, giant proxy meshes, or crushed bodies as import/selection issues until proven otherwise.
+
+6. Diagnose contact and motion issues.
+   - Ground penetration: compare lowest foot or shoe vertices with floor height per frame.
+   - Foot sliding: compare foot world positions across planted frames.
+   - Leg crossover: compare left/right thigh, knee, ankle, and foot side ordering.
+   - Twist damage: compare bone swing direction separately from roll/twist around the limb axis.
+   - Scale drift: compare animated mesh bounds against the clean baseline bounds.
+
+7. Report facts before opinions.
+   - Include frame numbers, object names, bone names, world coordinates, and thresholds.
+   - Separate confirmed failures from visual suspicions.
+   - Attach screenshots only after the structured state explains what to look for.
+
+## Recommended Report Shape
+
+```markdown
+## Blender Motion Inspection
+
+### Scene Inventory
+- Character candidates:
+- Armatures:
+- Helper/proxy objects:
+- Cameras/lights:
+
+### Orientation
+- World up:
+- Character forward:
+- Root heading:
+- Mirrored/backwards risk:
+
+### Baseline Integrity
+- Clean mesh bounds:
+- Animated mesh bounds:
+- Materials/skin preserved:
+- Suspicious non-character meshes:
+
+### Frame Findings
+| Frame | Finding | Evidence |
+| --- | --- | --- |
+| 1 | Clean baseline pose | hips/spine/feet aligned |
+| 96 | Foot penetrates floor | left_foot min_z = -0.04 |
+
+### Verdict
+- Pass/fail:
+- Required fix:
+- Render readiness:
+```
+
+## Examples
+
+### Walk Cycle With Foot Sliding
+
+Scenario: a retargeted character appears to skate during a walk cycle, but the front camera angle makes the foot contact hard to judge.
+
+Apply the workflow:
+- Inventory the scene: character mesh `HeroBody`, armature `HeroRig`, ground plane `Floor`, no hidden proxy meshes.
+- Identify the skeleton: semantic feet are `foot.L` and `foot.R`; hips are `pelvis`; root bone is `root`.
+- Sample animation frames: inspect frames 1, 18, 24, 30, 42, and 48 around planted-foot moments.
+- Diagnose contact and motion issues: compare world-space foot locations during planted frames.
+
+Extracted facts:
+
+| Frame | Fact | Evidence |
+| --- | --- | --- |
+| 18 | Left foot is planted | `foot.L min_z = 0.004`, toe and heel both near floor |
+| 24 | Left foot slides while planted | `foot.L x = 0.21 -> 0.28` over six frames |
+| 30 | Pelvis keeps moving forward | `pelvis y = 1.14 -> 1.31` |
+
+Verdict: fail for render readiness. The motion needs foot-lock cleanup or retargeting constraint review; the body mesh does not need proportion changes.
+
+### Backwards Imported Character
+
+Scenario: a character looks correct in a still frame, but the animation moves opposite the expected travel direction.
+
+Apply the workflow:
+- Determine forward, up, and side axes: compare head, chest, feet, and root motion.
+- Sample animation frames: inspect frame 1 and the midpoint of the travel path.
+- Report facts before opinions: include the root heading and model-facing direction separately.
+
+Extracted facts:
+
+| Frame | Fact | Evidence |
+| --- | --- | --- |
+| 1 | Character face points toward world `-Y` | head/chest vector from `neck` to `head` resolves to `-Y` |
+| 72 | Root motion travels toward world `+Y` | `root y = 0.0 -> 2.8` |
+| 72 | Feet remain visually forward-facing opposite travel | toe bones point `-Y` while displacement is `+Y` |
+
+Verdict: likely backwards import or retargeting forward-axis mismatch. Fix the import/retarget axis mapping before editing animation curves.
+
+## Practical Thresholds
+
+- Assume Blender's default meter-scale units unless the scene unit scale says otherwise.
+- Treat ground penetration above 1-2 cm as visible unless the floor is soft or intentionally stylized.
+- Treat a sudden scale change above 5% as a likely rig, constraint, or transform inheritance problem.
+- Treat left/right ankle side-order flips during airborne inverted motion as leg crossover risk even if it recovers later.
+- Treat root heading jumps above 30 degrees per frame as suspicious unless the source motion includes a snap turn.
+
+## Anti-Patterns
+
+- Do not modify body proportions to force pose matching unless the task is explicitly mesh repair.
+- Do not bake away the clean baseline before recording it.
+- Do not use one rendered camera angle as proof that a pose is correct.
+- Do not delete helper objects until you have recorded why they are not part of the character.
+- Do not assume an avatar faces +Y, -Y, +X, or -X without checking head, feet, torso, and root motion together.
+
+## Tooling Notes
+
+If a Blender state exporter is available, prefer JSON that includes meshes, armatures, pose bones, materials, contacts, bounding boxes, and sampled animation frames. If no exporter exists, run a small Blender Python script through Blender itself, for example `blender --background scene.blend --python collect_motion_state.py`, because `bpy` is not available in a normal system Python interpreter.

package/src/harness_context/skills/ecc/blueprint/LICENSE.ecc

@@ -0,0 +1,21 @@
+MIT License
+
+Copyright (c) 2026 Affaan Mustafa
+
+Permission is hereby granted, free of charge, to any person obtaining a copy
+of this software and associated documentation files (the "Software"), to deal
+in the Software without restriction, including without limitation the rights
+to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
+copies of the Software, and to permit persons to whom the Software is
+furnished to do so, subject to the following conditions:
+
+The above copyright notice and this permission notice shall be included in all
+copies or substantial portions of the Software.
+
+THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
+AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
+OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
+SOFTWARE.

package/src/harness_context/skills/ecc/blueprint/SKILL.md

@@ -0,0 +1,106 @@
+---
+name: blueprint
+description: >-
+  Turn a one-line objective into a step-by-step construction plan for
+  multi-session, multi-agent engineering projects. Each step has a
+  self-contained context brief so a fresh agent can execute it cold.
+  Includes adversarial review gate, dependency graph, parallel step
+  detection, anti-pattern catalog, and plan mutation protocol.
+  TRIGGER when: user requests a plan, blueprint, or roadmap for a
+  complex multi-PR task, or describes work that needs multiple sessions.
+  DO NOT TRIGGER when: task is completable in a single PR or fewer
+  than 3 tool calls, or user says "just do it".
+metadata:
+  origin: community
+---
+
+# Blueprint — Construction Plan Generator
+
+Turn a one-line objective into a step-by-step construction plan that any coding agent can execute cold.
+
+## When to Use
+
+- Breaking a large feature into multiple PRs with clear dependency order
+- Planning a refactor or migration that spans multiple sessions
+- Coordinating parallel workstreams across sub-agents
+- Any task where context loss between sessions would cause rework
+
+**Do not use** for tasks completable in a single PR, fewer than 3 tool calls, or when the user says "just do it."
+
+## How It Works
+
+Blueprint runs a 5-phase pipeline:
+
+1. **Research** — Pre-flight checks (git, gh auth, remote, default branch), then reads project structure, existing plans, and memory files to gather context.
+2. **Design** — Breaks the objective into one-PR-sized steps (3–12 typical). Assigns dependency edges, parallel/serial ordering, model tier (strongest vs default), and rollback strategy per step.
+3. **Draft** — Writes a self-contained Markdown plan file to `plans/`. Every step includes a context brief, task list, verification commands, and exit criteria — so a fresh agent can execute any step without reading prior steps.
+4. **Review** — Delegates adversarial review to a strongest-model sub-agent (e.g., Opus) against a checklist and anti-pattern catalog. Fixes all critical findings before finalizing.
+5. **Register** — Saves the plan, updates memory index, and presents the step count and parallelism summary to the user.
+
+Blueprint detects git/gh availability automatically. With git + GitHub CLI, it generates full branch/PR/CI workflow plans. Without them, it switches to direct mode (edit-in-place, no branches).
+
+## Examples
+
+### Basic usage
+
+```
+/blueprint myapp "migrate database to PostgreSQL"
+```
+
+Produces `plans/myapp-migrate-database-to-postgresql.md` with steps like:
+- Step 1: Add PostgreSQL driver and connection config
+- Step 2: Create migration scripts for each table
+- Step 3: Update repository layer to use new driver
+- Step 4: Add integration tests against PostgreSQL
+- Step 5: Remove old database code and config
+
+### Multi-agent project
+
+```
+/blueprint chatbot "extract LLM providers into a plugin system"
+```
+
+Produces a plan with parallel steps where possible (e.g., "implement Anthropic plugin" and "implement OpenAI plugin" run in parallel after the plugin interface step is done), model tier assignments (strongest for the interface design step, default for implementation), and invariants verified after every step (e.g., "all existing tests pass", "no provider imports in core").
+
+## Key Features
+
+- **Cold-start execution** — Every step includes a self-contained context brief. No prior context needed.
+- **Adversarial review gate** — Every plan is reviewed by a strongest-model sub-agent against a checklist covering completeness, dependency correctness, and anti-pattern detection.
+- **Branch/PR/CI workflow** — Built into every step. Degrades gracefully to direct mode when git/gh is absent.
+- **Parallel step detection** — Dependency graph identifies steps with no shared files or output dependencies.
+- **Plan mutation protocol** — Steps can be split, inserted, skipped, reordered, or abandoned with formal protocols and audit trail.
+- **Zero runtime risk** — Pure Markdown skill. The entire repository contains only `.md` files — no hooks, no shell scripts, no executable code, no `package.json`, no build step. Nothing runs on install or invocation beyond Claude Code's native Markdown skill loader.
+
+## Installation
+
+This skill ships with Everything Claude Code. No separate installation is needed when ECC is installed.
+
+### Full ECC install
+
+If you are working from the ECC repository checkout, verify the skill is present with:
+
+```bash
+test -f skills/blueprint/SKILL.md
+```
+
+To update later, review the ECC diff before updating:
+
+```bash
+cd /path/to/everything-claude-code
+git fetch origin main
+git log --oneline HEAD..origin/main       # review new commits before updating
+git checkout <reviewed-full-sha>          # pin to a specific reviewed commit
+```
+
+### Vendored standalone install
+
+If you are vendoring only this skill outside the full ECC install, copy the reviewed file from the ECC repository into `~/.claude/skills/blueprint/SKILL.md`. Vendored copies do not have a git remote, so update them by re-copying the file from a reviewed ECC commit rather than running `git pull`.
+
+## Requirements
+
+- Claude Code (for `/blueprint` slash command)
+- Git + GitHub CLI (optional — enables full branch/PR/CI workflow; Blueprint detects absence and auto-switches to direct mode)
+
+## Source
+
+Inspired by antbotlab/blueprint — upstream project and reference design.

package/src/harness_context/skills/ecc/brand-discovery/LICENSE.ecc

@@ -0,0 +1,21 @@
+MIT License
+
+Copyright (c) 2026 Affaan Mustafa
+
+Permission is hereby granted, free of charge, to any person obtaining a copy
+of this software and associated documentation files (the "Software"), to deal
+in the Software without restriction, including without limitation the rights
+to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
+copies of the Software, and to permit persons to whom the Software is
+furnished to do so, subject to the following conditions:
+
+The above copyright notice and this permission notice shall be included in all
+copies or substantial portions of the Software.
+
+THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
+AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
+OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
+SOFTWARE.