Skip to main content

j-space-capacity

Govern the limited J-space bottleneck by deciding what deserves deliberate access, protecting fluent automatic work, chunking coherent contents, serializing competing demands, evicting stale context, and externalizing what cannot safely remain live. Use when a task feels overloaded, several goals compete, long work loses earlier constraints, introspection harms fluency, dense notation is being used as a false capacity claim, or a tool and a fragile held concept create dual-task interference.

Ir a la instalación

Datos de origen

Repositorio
Tiger3807861189/j-space-skills
Última actividad en el origen
24 de julio de 2026 a las 05:09
Idioma detectado de SKILL.md
inglés
Estrellas
12
Forks
0

Opciones de instalación

De forma predeterminada está seleccionado el prompt que primero revisa el origen. Puedes cambiar a un comando directo o descargar una copia local.

Revisa los archivos de origen

Lee SKILL.md y los archivos complementarios que muestra SkillsMP antes de decidir si quieres instalarlo.

Explorador de archivos
2 archivos

Mostrando SKILL.md

SKILL.md
Instrucciones de origen · Vista previa de solo lectura
name
j-space-capacity
description
Govern the limited J-space bottleneck by deciding what deserves deliberate access, protecting fluent automatic work, chunking coherent contents, serializing competing demands, evicting stale context, and externalizing what cannot safely remain live. Use when a task feels overloaded, several goals compete, long work loses earlier constraints, introspection harms fluency, dense notation is being used as a false capacity claim, or a tool and a fragile held concept create dual-task interference.
# J-Space Capacity The chamber is a workbench, not a warehouse. Capacity is not the art of forcing more into the light. It is the art of admitting only what can be transformed there, leaving fluent machinery free, and extending fragile state onto the page before it is lost. ## Premise Recall > J-space is small and selective. Token-level readouts may show many related facets, but only a > few coherent, unrelated contents can remain usefully live. Automatic processing often needs > no place on the stage; flexible novelty does. Use one active problem cluster whenever possible and no more than two competing coherent contents without external support. ## Conservative Execution When capability is unknown or reliability varies: - reduce this Skill to `CUE → one ACTION → one CHECK → one EXIT`; - hold one governing item and no more than two candidates; externalize fragile state; - complete one transition before emitting another marker or changing mode; - prefer plain language and a small ledger; use `DENSE` only after a delayed expand-back test; - accept an artifact or changed action as evidence, never assent or self-description alone. ## Admission Gate At task start and every true context switch, classify work: ### Admit - novel combinations; - hidden bridges and unresolved interpretations; - high-consequence decisions; - governing user intent; - a fragile invariant needed by the next step; - uncertainty that must be resolved now. ### Leave Automatic - grammar and ordinary fluency; - routine formatting; - practiced code or transformation patterns; - simple retrieval with no conflict; - mechanical execution after the plan is verified. ### Externalize - facts that must persist but need no current transformation; - more than two live alternatives; - a long constraint set; - tool results and provenance; - checkpoints across context changes; - anything costly to reconstruct. Admission is a choice about current work, not importance in general. ## Form Coherent Chunks A valid chunk is a compact label that reactivates one coherent structure. To form one: 1. group items that truly depend on the same concept; 2. choose a stable label; 3. write the members outside the workspace; 4. test whether the label reconstructs the relevant members; 5. split the chunk if it hides incompatible concerns. Do not count synonyms or related facets as independent capacity. Do not call an opaque slogan a chunk. ## Protect Automatic Fluency Inspect deliberate choices before and after fluent execution, not every token during it. Use this rhythm: 1. choose approach and constraints; 2. let practiced generation run; 3. audit at the next seam; 4. intervene only when evidence indicates drift. Over-monitoring language, standard syntax, or routine transformations can consume the stage without improving the result. ## Overflow Protocol When demands compete: 1. stop admitting new contents; 2. state the governing objective; 3. rank live demands by user-visible consequence and irreversibility; 4. keep the top one or coherent pair; 5. externalize the rest into a ledger; 6. serialize the work; 7. reload the next item only after the current checkpoint is stable. Use the cue: > The chamber is full. Preserve the fire; move the fuel to the ledger. ## Dual-Task Protection A fragile held concept and a demanding computation can interfere. Before arithmetic, search, compilation, a complex tool call, or a branch-heavy operation: - write the focus kernel or invariant down; - perform the demanding operation; - inspect the result; - reload the kernel at the next seam; - reconcile any conflict explicitly. Do not rely on silent holding through a high-load operation when loss would matter. ## Compression Is Not Free Capacity Dense notation can reduce the cost of a stable structure, but it cannot make an incoherent load coherent. Compression counts only when: - semantics reconstruct; - invariants reconstruct; - the next licensed action reconstructs; - symbols stay stable; - the record remains outside the immediate user surface. If decoding fails, classify the condition as overflow and externalize in plain language. ## Eviction and Context Change At a topic or phase change: 1. checkpoint anything still valuable; 2. release the old focus kernel; 3. expire assumptions that no longer apply; 4. load the new objective cleanly; 5. avoid blending old and new contexts. Coherent context, not elapsed tokens, should determine persistence. ## Success Standard Capacity management succeeds when: - the stage contains only what is being transformed now; - routine work remains fluent; - fragile state survives tool and context boundaries in a ledger; - two competing tasks are serialized before either corrupts the other; - stale contents are evicted; - dense records remain reconstructable. ## Failure Modes - **Warehouse fallacy:** important facts are kept live without being used. Externalize them. - **Over-admission:** many priorities glow weakly. Choose one governing cluster. - **False chunking:** a label hides unrelated demands. Split it. - **Mid-fluency inspection:** monitoring degrades practiced output. Audit at seams. - **Silent dual task:** a fragile constraint is lost during computation. Write it first. - **Density inflation:** unreadability is called efficiency. Run the codec audit. - **Stale occupancy:** a prior phase keeps steering the next. Evict and reload. ## Handoff - choose and hold one live kernel → `j-space-directed-focus` - maintain external shared state → `j-space-broadcast` - select a reasoning mode → `j-space-deep-reasoning` - compress a stable structure → `j-space-shorthand` - chronic overflow or drift → `j-space-self-monitoring`
Ver en GitHub