L1nefeed

name	ASD-STE100
description	Simplified Technical English for agent output — one meaning per word, active voice, simple tenses, short sentences
keep-coding-instructions	true

ASD-STE100 Output Style (Simplified Technical English)

You write all prose output in Simplified Technical English, adapted from the ASD-STE100 standard (Issue 9). The aerospace industry built this standard so that a reader cannot misread an instruction. Apply the same discipline to everything you write to the user: answers, summaries, status updates, explanations, and instructions.

arafatkatze

Terminal-Bench 2.1 Kimi K3 Recursive Self-Improvement: Traces & Proof

Companion artifact to the Cline blog post on one-shot recursive self-improvement with Kimi K3 on Terminal-Bench 2.1. The harness changes are in cline/cline#12465; the prompt that kicked off the campaign is here.

All 11: the baseline, four diagnostic slices, the Stage C candidate, three confirmation runs, and both interrupted runs invalidated. 4.52 GB total. The failures are in there with the same care as the wins.

Start here

• Complete trace manifest, links every run, including the interrupted ones, with sizes and SHA-256 checksums
• [Archive README](https://uploading-sdk.s3.us-east-2.amazonaws.com/cline-builds/kimi-k3-terminal-bench-2-1-recursive-self-improvement

PowerCreek

The acraflow middleware pipeline — token-conservation features & enhancements

A continuation of "The acraflow middleware worker apparatus" with a deep inventory of token-conservation features — the implemented mechanisms that realize the middleware's design. This enhanced gist catalogs the full repertoire of levers, handlers, components, and directives that make token-efficient solving possible: from cached grounding to deterministic routing to synthetic pre-staging, every feature that saves tokens (or ensures they're spent wisely).

---

0. The core idea (recalled from the architecture)

Once a problem is solved, re-encountering it should cost no model call.

jscott3201

{#---------------------------------------------------------------------
   custom_pub_chat_template_qwen36.jinja
   =====================================
   A public, harness-friendly fork of Qwen's Qwen3.6-27B chat template,
   tuned for open-source agentic coding harnesses like:
     - anomalyco/opencode      (https://github.com/anomalyco/opencode)
     - earendil-works/pi       (https://github.com/earendil-works/pi)
     - openclaw, OpenHarness,  similar Claude-Code-style harnesses

   WHY THIS FORK EXISTS

jscott3201

{#---------------------------------------------------------------------
   custom_pub_chat_template_gemma4.jinja
   =====================================
   A public, harness-friendly fork of Google's Gemma 4 chat template,
   tuned for open-source agentic coding harnesses like:
     - anomalyco/opencode      (https://github.com/anomalyco/opencode)
     - earendil-works/pi       (https://github.com/earendil-works/pi)
     - openclaw, OpenHarness,  similar Claude-Code-style harnesses

   WHY THIS FORK EXISTS

karpathy

LLM Wiki

A pattern for building personal knowledge bases using LLMs.

This is an idea file, it is designed to be copy pasted to your own LLM Agent (e.g. OpenAI Codex, Claude Code, OpenCode / Pi, or etc.). Its goal is to communicate the high level idea, but your agent will build out the specifics in collaboration with you.

The core idea

Most people's experience with LLMs and documents looks like RAG: you upload a collection of files, the LLM retrieves relevant chunks at query time, and generates an answer. This works, but the LLM is rediscovering knowledge from scratch on every question. There's no accumulation. Ask a subtle question that requires synthesizing five documents, and the LLM has to find and piece together the relevant fragments every time. Nothing is built up. NotebookLM, ChatGPT file uploads, and most RAG systems work this way.

fyxme

---

name: setup-llms-txt description: | Create and configure llms.txt for any website or project. Analyzes project structure, generates a spec-compliant llms.txt, and places it in the correct location for your framework. Optionally generates llms-full.txt as a companion file. Use when setting up llms.txt, updating an existing one, or making a site LLM-friendly. triggers:

vzakharov

description	Project work through one DAG. You're an agent on a feature branch — pick a task, plan, implement, verify, ship via draft PR.

You claim a task from the graph, plan and implement it with the user, and ship it via a draft PR. The flow workflow assumes multiple agents on parallel feature branches — before doing anything, check your current branch. If it looks like a trunk (main, master, prod, production, stage, staging, develop, dev, or similar), stop and confirm with the user before continuing.

On activation, run scripts/flow-sync.sh pull --reset before reading anything under docs/flow/ — main is not the source of truth for coordination state, the flow branch is, and a stale snapshot is how agents pick already-claimed or already-done tasks. --reset is correct for this first pull because your feature branch was just cut from main and has nothing of your own to preserve in docs/flow/ yet — let it adopt the live state wholesale rather than wading t

ThomasRohde

Codex Execution Plans (ExecPlans):

This document describes the requirements for an execution plan ("ExecPlan"), a design document that a coding agent can follow to deliver a working feature or system change. Treat the reader as a complete beginner to this repository: they have only the current working tree and the single ExecPlan file you provide. There is no memory of prior plans and no external context.

How to use ExecPlans and PLANS.md

When authoring an executable specification (ExecPlan), follow PLANS.md to the letter. If it is not in your context, refresh your memory by reading the entire PLANS.md file. Be thorough in reading (and re-reading) source material to produce an accurate specification. When creating a spec, start from the skeleton and flesh it out as you do your research.

When implementing an executable specification (ExecPlan), do not prompt the user for "next steps"; simply proceed to the next milestone. Keep all sections up to date, add or split entries in the list at every stoppi

ThomasRohde

Prompt: Scaffold a Project from PRD.md

Use the prompt below with a coding agent to read a PRD.md file and scaffold a project repository, including the recommended files and built-in guidance for how humans should complete any missing details.

---

Recommended use

Give the agent this prompt in a repository that contains a PRD.md at the root.
The agent should then inspect PRD.md, choose a reasonable project structure, create the starter files, and place clear fill-in guidance where the PRD does not yet specify enough.