openhermes 4.0.1 → 4.3.0
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/ETHOS.md +6 -3
- package/LICENSE +21 -21
- package/README.md +111 -81
- package/bootstrap.ts +405 -0
- package/harness/agents/openhermes.md +45 -55
- package/harness/codex/AUTOPILOT.md +126 -0
- package/harness/codex/CONSTITUTION.md +14 -11
- package/harness/codex/ROUTING.md +35 -69
- package/harness/commands/oh-log.md +18 -0
- package/harness/instructions/RUNTIME.md +27 -51
- package/harness/skills/oh-builder/SKILL.md +27 -16
- package/harness/skills/oh-caveman/SKILL.md +9 -0
- package/harness/skills/oh-expert/SKILL.md +6 -0
- package/harness/skills/oh-facade/SKILL.md +298 -0
- package/harness/skills/oh-freeze/SKILL.md +9 -0
- package/harness/skills/oh-full-output/SKILL.md +81 -0
- package/harness/skills/oh-fusion/SKILL.md +314 -0
- package/harness/skills/oh-gauntlet/SKILL.md +10 -6
- package/harness/skills/oh-grill/SKILL.md +9 -5
- package/harness/skills/oh-guard/SKILL.md +9 -0
- package/harness/skills/oh-handoff/SKILL.md +9 -0
- package/harness/skills/oh-health/SKILL.md +8 -4
- package/harness/skills/oh-init/SKILL.md +80 -13
- package/harness/skills/oh-investigate/SKILL.md +57 -8
- package/harness/skills/oh-issue/SKILL.md +9 -0
- package/harness/skills/oh-learn/SKILL.md +81 -8
- package/harness/skills/oh-manifest/SKILL.md +55 -11
- package/harness/skills/oh-plan-review/SKILL.md +15 -8
- package/harness/skills/oh-planner/SKILL.md +18 -8
- package/harness/skills/oh-prd/SKILL.md +9 -0
- package/harness/skills/oh-refactor/SKILL.md +426 -0
- package/harness/skills/oh-retro/SKILL.md +9 -0
- package/harness/skills/oh-review/SKILL.md +12 -5
- package/harness/skills/oh-security/SKILL.md +4 -0
- package/harness/skills/oh-ship/SKILL.md +10 -0
- package/harness/skills/oh-skill-craft/SKILL.md +88 -0
- package/harness/skills/oh-skills-link/SKILL.md +9 -0
- package/harness/skills/oh-skills-list/SKILL.md +9 -0
- package/harness/skills/oh-triage/SKILL.md +11 -0
- package/index.ts +3 -0
- package/lib/{harness-resolver.mjs → harness-resolver.ts} +16 -12
- package/lib/logger.ts +75 -0
- package/package.json +16 -10
- package/tsconfig.json +16 -0
- package/bootstrap.mjs +0 -174
- package/harness/instructions/CONVENTIONS.md +0 -206
- package/index.mjs +0 -3
- package/lib/logger.mjs +0 -62
- package/test/plugins-behavioral.test.mjs +0 -64
- package/test/plugins.test.mjs +0 -62
|
@@ -0,0 +1,298 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: oh-facade
|
|
3
|
+
description: "Full UI pipeline: from concept to production frontend. Design system generation, premium component architecture, production-grade implementation, structured audit. Use when building any user-facing interface, component system, or visual application."
|
|
4
|
+
tier: 4
|
|
5
|
+
benefits-from: [oh-planner, oh-gauntlet, oh-review]
|
|
6
|
+
triggers:
|
|
7
|
+
- "build a frontend for"
|
|
8
|
+
- "create a design system"
|
|
9
|
+
- "build a landing page"
|
|
10
|
+
- "build a dashboard"
|
|
11
|
+
- "build a web app"
|
|
12
|
+
- "visual design for"
|
|
13
|
+
- "make this look good"
|
|
14
|
+
- "redesign this page"
|
|
15
|
+
- "redesign this app"
|
|
16
|
+
- "theme the application"
|
|
17
|
+
- "layout this page"
|
|
18
|
+
- "responsive layout"
|
|
19
|
+
- "user interface design"
|
|
20
|
+
- "improve the UX"
|
|
21
|
+
- "aesthetic design"
|
|
22
|
+
- "style the component"
|
|
23
|
+
- "polish the UI"
|
|
24
|
+
- "frontend component"
|
|
25
|
+
- "interface design for"
|
|
26
|
+
- "build a component for"
|
|
27
|
+
route:
|
|
28
|
+
pass:
|
|
29
|
+
- oh-review
|
|
30
|
+
- oh-manifest
|
|
31
|
+
fail: oh-facade
|
|
32
|
+
blocker: surface
|
|
33
|
+
---
|
|
34
|
+
|
|
35
|
+
# oh-facade
|
|
36
|
+
|
|
37
|
+
The complete UI pipeline: from concept to production frontend. A closed-loop system that plans, designs, builds, verifies, and iterates on user-facing interfaces.
|
|
38
|
+
|
|
39
|
+
Architecture of the visible. Engineering, not decoration.
|
|
40
|
+
|
|
41
|
+
## When to Use
|
|
42
|
+
|
|
43
|
+
- Building any user-facing interface from scratch
|
|
44
|
+
- Adding a design system to an existing project
|
|
45
|
+
- Redesigning or upgrading existing UIs
|
|
46
|
+
- The task involves anything visual: pages, components, dashboards, themes, layouts
|
|
47
|
+
- `oh-manifest` delegates to `oh-facade` when UI work is detected in a full build
|
|
48
|
+
|
|
49
|
+
## Pipeline
|
|
50
|
+
|
|
51
|
+
The 5-phase closed loop:
|
|
52
|
+
|
|
53
|
+
```
|
|
54
|
+
Concept → Design System → Build → Audit → Iterate
|
|
55
|
+
↓
|
|
56
|
+
(loop until pass)
|
|
57
|
+
```
|
|
58
|
+
|
|
59
|
+
Output at each phase: brief → DESIGN.md → code → report → final code.
|
|
60
|
+
|
|
61
|
+
---
|
|
62
|
+
|
|
63
|
+
## Phase 1: Concept
|
|
64
|
+
|
|
65
|
+
Input: vague idea, brief, or "make this look good"
|
|
66
|
+
Output: structured design brief with direction
|
|
67
|
+
|
|
68
|
+
### 1a. Understand the Context
|
|
69
|
+
|
|
70
|
+
- What is the product/feature? Who uses it?
|
|
71
|
+
- What problem does this interface solve?
|
|
72
|
+
- Are there technical constraints? (framework, viewport targets, accessibility requirements)
|
|
73
|
+
- Is this a new build or an existing project to redesign?
|
|
74
|
+
|
|
75
|
+
### 1b. Set the Direction
|
|
76
|
+
|
|
77
|
+
Choose an archetype. **Commit to it. Do not hedge.**
|
|
78
|
+
|
|
79
|
+
| Archetype | Best for | Substrate | Density |
|
|
80
|
+
|---|---|---|---|
|
|
81
|
+
| Minimal Editorial | Content sites, portfolios, docs | Light (warm off-white) | Low (1-3) |
|
|
82
|
+
| Premium SaaS | Web apps, dashboards, B2B tools | Light or Dark (zinc-based) | Medium (4-7) |
|
|
83
|
+
| Industrial/Data | Analytics, monitoring, internal tools | Dark (charcoal) | High (7-10) |
|
|
84
|
+
| Creative/Expressive | Marketing, agency sites, showcases | Dark or Light | Variable |
|
|
85
|
+
|
|
86
|
+
### 1c. Set Metric Dials
|
|
87
|
+
|
|
88
|
+
Three measurable controls that drive all downstream decisions. Default baseline, adapt based on context.
|
|
89
|
+
|
|
90
|
+
| Dial | Range | 1-3 | 4-7 | 8-10 |
|
|
91
|
+
|---|---|---|---|---|
|
|
92
|
+
| VARIANCE | 1-10 | Symmetric, predictable | Offset, asymmetric | Chaotic, artsy |
|
|
93
|
+
| MOTION | 1-10 | Static, CSS only | Fluid CSS + spring | Cinematic choreography |
|
|
94
|
+
| DENSITY | 1-10 | Gallery, airy | Standard app | Cockpit, packed |
|
|
95
|
+
|
|
96
|
+
**Default baseline:** VARIANCE=6, MOTION=5, DENSITY=4
|
|
97
|
+
|
|
98
|
+
### 1d. Output Design Brief
|
|
99
|
+
|
|
100
|
+
Single paragraph capturing: archetype, substrate (light/dark), metric dials, and key differentiator.
|
|
101
|
+
|
|
102
|
+
If the brief is clearly wrong or self-contradictory → surface to user.
|
|
103
|
+
Otherwise → Phase 2. Do not ask for approval.
|
|
104
|
+
|
|
105
|
+
---
|
|
106
|
+
|
|
107
|
+
## Phase 2: Design System
|
|
108
|
+
|
|
109
|
+
Input: design brief with direction + dials
|
|
110
|
+
Output: `DESIGN.md` — encoded design system as single source of truth
|
|
111
|
+
|
|
112
|
+
Generate a complete `DESIGN.md` file. This is the blueprint consumed by Phase 3. Every value must be specific — no vagueness, no "use a nice font."
|
|
113
|
+
|
|
114
|
+
### 2a. Color Palette
|
|
115
|
+
|
|
116
|
+
- **Neutral base**: Zinc or Slate family. Pick one (warm or cool). Never mix.
|
|
117
|
+
- **Accent**: Exactly one. Saturation < 80%. No purple/blue "AI aesthetic."
|
|
118
|
+
- **Surface**: Background, card, border, elevated. Specific hex codes.
|
|
119
|
+
- **Text**: Primary, secondary, muted, inverse. Specific hex codes.
|
|
120
|
+
- **Semantic**: Success, warning, error, info. Specific hex codes.
|
|
121
|
+
- **Dark substrate**: Never pure `#000000`. Use `#0a0a0a` or `#121212`.
|
|
122
|
+
|
|
123
|
+
### 2b. Typography Architecture
|
|
124
|
+
|
|
125
|
+
- **Display/Headline**: Premium sans-serif (Geist, Satoshi, Cabinet Grotesk, Outfit, Switzer). Tight tracking (`-0.03em` to `-0.05em`). Fluid scale via `clamp()`.
|
|
126
|
+
- **Body**: Relaxed leading (`1.6-1.8`). Max 65 characters per line. Off-black, not `#000`.
|
|
127
|
+
- **Monospace**: JetBrains Mono, Geist Mono, or SF Mono. Required for all data/number contexts when DENSITY > 5.
|
|
128
|
+
- **Serif**: Only for editorial/creative contexts and only distinctive modern serifs (Fraunces, Instrument Serif, Editorial New). **Never in dashboards or software UIs.**
|
|
129
|
+
- **BANNED**: Inter, Roboto, Arial, Open Sans, Helvetica, Georgia, Times New Roman.
|
|
130
|
+
|
|
131
|
+
### 2c. Component System
|
|
132
|
+
|
|
133
|
+
Define every component with structure, states, and interaction behavior:
|
|
134
|
+
|
|
135
|
+
**Buttons:**
|
|
136
|
+
- Primary: solid background, off-black or accent. Hover: lift or darken. Active: `scale(0.98)`. Focus ring.
|
|
137
|
+
- Secondary: outline or ghost. Same interaction physics.
|
|
138
|
+
- Icon button: square, matching radius system.
|
|
139
|
+
- Button-in-Button pattern (from high-end-visual-design): nested icon in its own pill inside the button.
|
|
140
|
+
|
|
141
|
+
**Cards:**
|
|
142
|
+
- Double-Bezel architecture: outer shell (subtle background, hairline border, large radius) + inner core (content background, inset highlight, smaller radius).
|
|
143
|
+
- OR border-only: `border-t` or `divide-y` for high-density contexts.
|
|
144
|
+
- Cards used ONLY when elevation communicates hierarchy. Not as default container.
|
|
145
|
+
|
|
146
|
+
**Forms/Inputs:**
|
|
147
|
+
- Label above input. Helper text optional. Error text below.
|
|
148
|
+
- Focus state: ring or border color shift.
|
|
149
|
+
- Touch targets: minimum 44px.
|
|
150
|
+
|
|
151
|
+
**Loading states:**
|
|
152
|
+
- Skeleton loaders matching exact layout dimensions. Never circular spinners.
|
|
153
|
+
|
|
154
|
+
**Empty states:**
|
|
155
|
+
- Composed illustration or icon, short message, single action button.
|
|
156
|
+
|
|
157
|
+
**Navigation:**
|
|
158
|
+
- Based on density dial: glass floating pill (low), sidebar (medium/high), or minimal top bar.
|
|
159
|
+
- Active state on current section.
|
|
160
|
+
- Mobile: clean collapse, not hamburger-only.
|
|
161
|
+
|
|
162
|
+
### 2d. Layout Principles
|
|
163
|
+
|
|
164
|
+
- **Grid**: CSS Grid. Never `calc()` or flexbox percentage math for multi-column layouts.
|
|
165
|
+
- **Container**: 1200-1440px max-width with auto margins. Wider for editorial/creative archetypes.
|
|
166
|
+
- **Section spacing**: Based on DENSITY dial. Low = `py-32 md:py-48`. Medium = `py-24`. High = `py-16`.
|
|
167
|
+
- **Responsive**: All multi-column layouts collapse to single column below 768px. No exceptions. Verify with `md:` breakpoints.
|
|
168
|
+
- **Full-height**: Always `min-h-[100dvh]`. Never `h-screen` (iOS Safari viewport bug).
|
|
169
|
+
- **BANNED**: centered hero when VARIANCE > 4, 3-equal-card feature rows, edge-to-edge content on wide screens.
|
|
170
|
+
|
|
171
|
+
### 2e. Motion Philosophy
|
|
172
|
+
|
|
173
|
+
- **Spring physics**: Default `cubic-bezier(0.32, 0.72, 0, 1)` or Framer Motion `spring(stiffness: 100, damping: 20)`. Never linear easing.
|
|
174
|
+
- **Scroll entry**: Elements fade up gently (`translateY(12-24px)` + `opacity: 0` → resolved over 600-800ms). Use IntersectionObserver or CSS scroll-driven animations. Never `window.addEventListener('scroll')`.
|
|
175
|
+
- **Staggered reveals**: Lists and grids cascade via `animation-delay` or Framer Motion `staggerChildren`.
|
|
176
|
+
- **Hover physics**: Scale, translate, shadow shift, or color transition on interactive elements. Duration 200-300ms.
|
|
177
|
+
- **Active feedback**: Every clickable element must provide tactile response — `scale(0.98)` or `translateY(1px)`.
|
|
178
|
+
- **Performance**: Animate exclusively via `transform` and `opacity`. Never `top`, `left`, `width`, `height`. Use `will-change: transform` sparingly.
|
|
179
|
+
- **Backdrop-blur**: Only on fixed/sticky elements (navbars, overlays). Never on scrolling containers.
|
|
180
|
+
|
|
181
|
+
### 2f. Anti-Patterns Registry
|
|
182
|
+
|
|
183
|
+
Explicit rules encoded into DESIGN.md. These are hard failures.
|
|
184
|
+
|
|
185
|
+
- No emojis in code, content, alt text, or markup
|
|
186
|
+
- No `Lorem Ipsum` — write real draft copy
|
|
187
|
+
- No "Elevate", "Seamless", "Next-Gen", "Unleash", "Game-changer" copy
|
|
188
|
+
- No generic names (John Doe, Acme Corp) — use realistic, specific content
|
|
189
|
+
- No rocket ship for "launch" or shield for "security" icons
|
|
190
|
+
- No purple/blue neon gradients
|
|
191
|
+
- No dark section in a white page (or vice versa) without committed dark mode
|
|
192
|
+
- No animated `top`, `left`, `width`, `height`
|
|
193
|
+
- No `window.addEventListener('scroll')`
|
|
194
|
+
- No `h-screen` for full-height sections
|
|
195
|
+
|
|
196
|
+
---
|
|
197
|
+
|
|
198
|
+
## Phase 3: Build
|
|
199
|
+
|
|
200
|
+
Input: DESIGN.md
|
|
201
|
+
Output: production code implementing the full system
|
|
202
|
+
|
|
203
|
+
### 3a. Set Up Foundations
|
|
204
|
+
|
|
205
|
+
1. CSS custom properties for colors, spacing, typography scale, shadows, border-radii
|
|
206
|
+
2. Tailwind config extensions (if using Tailwind) — map design tokens to utility classes
|
|
207
|
+
3. Theme provider or global stylesheet
|
|
208
|
+
4. Component directory structure
|
|
209
|
+
|
|
210
|
+
### 3b. Build Component Library
|
|
211
|
+
|
|
212
|
+
Implement every component defined in Phase 2 with ALL states:
|
|
213
|
+
- Default, hover, active, focus-visible, disabled
|
|
214
|
+
- Loading (skeleton matching layout)
|
|
215
|
+
- Empty (composed illustration + message + action)
|
|
216
|
+
- Error (inline messaging)
|
|
217
|
+
|
|
218
|
+
Apply performance guardrails to every component:
|
|
219
|
+
- Animations use `transform` and `opacity` only
|
|
220
|
+
- No layout-triggering properties in transitions
|
|
221
|
+
- `backdrop-blur` only on fixed/sticky elements
|
|
222
|
+
- Z-index follows systemic scale (no arbitrary `z-50` or `z-[9999]`)
|
|
223
|
+
|
|
224
|
+
### 3c. Build Pages/Screens
|
|
225
|
+
|
|
226
|
+
1. Implement the full interface using the component system
|
|
227
|
+
2. Responsive: verify single-column collapse below 768px
|
|
228
|
+
3. All viewports filled: loading → populated → empty → error states
|
|
229
|
+
4. Navigation wired with active states and mobile collapse
|
|
230
|
+
|
|
231
|
+
### 3d. Technical Requirements
|
|
232
|
+
|
|
233
|
+
- Check `package.json` before importing any dependency. Never assume a library exists.
|
|
234
|
+
- Use framework-appropriate patterns: Server Components in Next.js, client isolation for interactive islands
|
|
235
|
+
- Semantic HTML: `<nav>`, `<main>`, `<section>`, `<article>`, `<aside>`, `<header>`, `<footer>`
|
|
236
|
+
- Accessibility: visible focus rings, skip-to-content link, alt text, aria labels on interactive elements
|
|
237
|
+
- Meta tags: `<title>`, `description`, `og:image`, viewport
|
|
238
|
+
|
|
239
|
+
---
|
|
240
|
+
|
|
241
|
+
## Phase 4: Audit
|
|
242
|
+
|
|
243
|
+
Input: built code + DESIGN.md
|
|
244
|
+
Output: audit report with pass/fail per check + ranked fix list
|
|
245
|
+
|
|
246
|
+
Run the full structured audit. Checks are grouped and priority-ranked.
|
|
247
|
+
|
|
248
|
+
### Priority 1 — High Impact, Low Risk (do first)
|
|
249
|
+
|
|
250
|
+
- **Typography**: font choice matches DESIGN.md? scale correct? tracking applied? no orphan lines? body max-width limited?
|
|
251
|
+
- **Color**: single accent? saturation < 80%? no AI purple? warm/cool consistent? dark not pure black?
|
|
252
|
+
- **Layout**: grid not flexbox math? max-width container? `min-h-[100dvh]` everywhere? responsive at 768px?
|
|
253
|
+
|
|
254
|
+
### Priority 2 — Makes it Feel Alive
|
|
255
|
+
|
|
256
|
+
- **Interactivity**: hover states on all clickables? active feedback (`scale(0.98)` or translate)? focus rings? transitions smooth (200-300ms)?
|
|
257
|
+
- **States**: every component has loading, empty, error states? skeleton loaders (not spinners)?
|
|
258
|
+
- **Motion**: scroll entry animations present? staggered reveals? spring physics (not linear)?
|
|
259
|
+
|
|
260
|
+
### Priority 3 — Content Polish
|
|
261
|
+
|
|
262
|
+
- **Content**: no lorem ipsum? no cliche copy? realistic names and data? no generic placeholders?
|
|
263
|
+
- **Emojis**: zero emojis in code or content?
|
|
264
|
+
- **Anti-patterns**: no "Elevate", no rocket icons, no purple gradients?
|
|
265
|
+
|
|
266
|
+
### Priority 4 — Production Hardening
|
|
267
|
+
|
|
268
|
+
- **Components**: Double-Bezel or appropriate card architecture? button-in-button pattern where applicable? navigation active states?
|
|
269
|
+
- **Iconography**: consistent stroke width? no default library? no emoji substitutions?
|
|
270
|
+
- **Code quality**: semantic HTML? no div soup? no inline styles? no orphaned imports?
|
|
271
|
+
- **Strategic**: 404 page? skip-to-content? meta tags? cookie consent consideration?
|
|
272
|
+
|
|
273
|
+
### Phase 5: Iterate
|
|
274
|
+
|
|
275
|
+
1. Apply fixes in Priority order — do not skip ahead
|
|
276
|
+
2. Re-run audit after each priority level
|
|
277
|
+
3. Continue until all Priority 1-3 checks pass
|
|
278
|
+
4. Priority 4 is target-state — surface remaining items as recommendations
|
|
279
|
+
5. If blocked on a specific check → narrow scope, try alternative approach, or surface
|
|
280
|
+
|
|
281
|
+
## Design Principles
|
|
282
|
+
|
|
283
|
+
These govern all decisions across all phases:
|
|
284
|
+
|
|
285
|
+
1. **Intentionality over intensity** — Bold maximalism and refined minimalism both work. The key is commitment to a direction, not how loud it is.
|
|
286
|
+
2. **Engineering over decoration** — A button is not "styled" — it has a physical structure, interaction physics, and accessible states.
|
|
287
|
+
3. **Consistency over variety** — One palette, one font system, one component architecture. Consistency beats every single creative choice.
|
|
288
|
+
4. **Performance is a feature** — A beautiful UI that lags is not a beautiful UI. Hardware acceleration, transform-only animation, guarded backdrop-blur.
|
|
289
|
+
5. **Ship every state** — Default-only is not production. Loading, empty, error, hover, active, focus, disabled. Every state designed and implemented.
|
|
290
|
+
|
|
291
|
+
## Routing
|
|
292
|
+
|
|
293
|
+
| Outcome | Route |
|
|
294
|
+
|---|---|
|
|
295
|
+
| all phases pass | -> oh-review (design review) or back to oh-manifest |
|
|
296
|
+
| audit fails Priority 1-2 | -> Phase 5 (iterate — fix and re-audit) |
|
|
297
|
+
| audit fails Priority 3-4 only | -> Phase 5 (recommendations), route to oh-review |
|
|
298
|
+
| blocker | -> surface to user |
|
|
@@ -1,6 +1,15 @@
|
|
|
1
1
|
---
|
|
2
2
|
name: oh-freeze
|
|
3
3
|
description: "Restrict file edits to a specific directory for the session"
|
|
4
|
+
tier: 2
|
|
5
|
+
triggers:
|
|
6
|
+
- "freeze directory"
|
|
7
|
+
- "restrict edits to"
|
|
8
|
+
- "lock edits to"
|
|
9
|
+
route:
|
|
10
|
+
pass: mode
|
|
11
|
+
fail: mode
|
|
12
|
+
blocker: surface
|
|
4
13
|
---
|
|
5
14
|
|
|
6
15
|
# oh-freeze
|
|
@@ -0,0 +1,81 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: oh-full-output
|
|
3
|
+
description: "Override LLM truncation behavior. Enforce complete code generation, ban placeholder patterns (// ..., /* ... */, TODO, 'rest of code'), and handle token-limit splits cleanly. Use when generating long files, multi-component output, or any task where partial output would be a broken deliverable."
|
|
4
|
+
tier: 2
|
|
5
|
+
triggers:
|
|
6
|
+
- "full output"
|
|
7
|
+
- "complete code"
|
|
8
|
+
- "no truncation"
|
|
9
|
+
- "dont skip"
|
|
10
|
+
- "no placeholders"
|
|
11
|
+
- "banned patterns"
|
|
12
|
+
- "generate everything"
|
|
13
|
+
- "dont abbreviate"
|
|
14
|
+
- "dont use ..."
|
|
15
|
+
- "no etc"
|
|
16
|
+
- "write it all"
|
|
17
|
+
- "exhaustive"
|
|
18
|
+
- "unabridged"
|
|
19
|
+
- "long file"
|
|
20
|
+
- "large output"
|
|
21
|
+
- "many files"
|
|
22
|
+
- "all components"
|
|
23
|
+
- "stop truncating"
|
|
24
|
+
route:
|
|
25
|
+
pass: done
|
|
26
|
+
fail: surface
|
|
27
|
+
blocker: surface
|
|
28
|
+
---
|
|
29
|
+
|
|
30
|
+
# oh-full-output
|
|
31
|
+
|
|
32
|
+
Override default LLM truncation behavior. Enforce complete generation, ban placeholder patterns, and handle token-limit splits cleanly.
|
|
33
|
+
|
|
34
|
+
## Baseline
|
|
35
|
+
|
|
36
|
+
Treat every task as production-critical. A partial output is a broken output. Do not optimize for brevity -- optimize for completeness. If the user asks for a full file, deliver the full file. If the user asks for 5 components, deliver 5 components. No exceptions.
|
|
37
|
+
|
|
38
|
+
## Banned Output Patterns
|
|
39
|
+
|
|
40
|
+
The following patterns are hard failures. Never produce them:
|
|
41
|
+
|
|
42
|
+
**In code blocks:** `// ...`, `// rest of code`, `// implement here`, `// TODO`, `/* ... */`, `// similar to above`, `// continue pattern`, `// add more as needed`, bare `...` standing in for omitted code, `// same as above`
|
|
43
|
+
|
|
44
|
+
**In prose:** "Let me know if you want me to continue", "I can provide more details if needed", "for brevity", "the rest follows the same pattern", "similarly for the remaining", "and so on" (when replacing actual content), "I'll leave that as an exercise"
|
|
45
|
+
|
|
46
|
+
**Structural shortcuts:** Outputting a skeleton when the request was for a full implementation. Showing the first and last section while skipping the middle. Replacing repeated logic with one example and a description. Describing what code should do instead of writing it.
|
|
47
|
+
|
|
48
|
+
## Execution Process
|
|
49
|
+
|
|
50
|
+
1. **Scope** -- Read the full request. Count how many distinct deliverables are expected (files, functions, sections, answers). Lock that number.
|
|
51
|
+
2. **Build** -- Generate every deliverable completely. No partial drafts, no "you can extend this later."
|
|
52
|
+
3. **Cross-check** -- Before output, re-read the original request. Compare your deliverable count against the scope count. If anything is missing, add it before responding.
|
|
53
|
+
|
|
54
|
+
## Handling Long Outputs
|
|
55
|
+
|
|
56
|
+
When a response approaches the token limit:
|
|
57
|
+
|
|
58
|
+
- Do not compress remaining sections to squeeze them in.
|
|
59
|
+
- Do not skip ahead to a conclusion.
|
|
60
|
+
- Write at full quality up to a clean breakpoint (end of a function, end of a file, end of a section).
|
|
61
|
+
- End with:
|
|
62
|
+
```
|
|
63
|
+
[PAUSED -- X of Y complete. Send "continue" to resume from: next section name]
|
|
64
|
+
```
|
|
65
|
+
- On "continue", pick up exactly where you stopped. No recap, no repetition.
|
|
66
|
+
|
|
67
|
+
## Quick Check
|
|
68
|
+
|
|
69
|
+
Before finalizing any response:
|
|
70
|
+
- No banned patterns from the list above appear anywhere in the output
|
|
71
|
+
- Every item the user requested is present and finished
|
|
72
|
+
- Code blocks contain actual runnable code, not descriptions of what code would do
|
|
73
|
+
- Nothing was shortened to save space
|
|
74
|
+
|
|
75
|
+
## Routing
|
|
76
|
+
|
|
77
|
+
| Outcome | Route |
|
|
78
|
+
|---|---|
|
|
79
|
+
| pass | -> continue current task |
|
|
80
|
+
| truncation still happens | -> oh-expert (diagnose attention/context issues) |
|
|
81
|
+
| blocker | -> surface to user |
|