| Context Vigilance | context-vigilance/ | Framework for managing context-v/ directories — directory roles (specs / prompts / blueprints / reminders / explorations / issues), semver, four-part, and Epoch SemVer versioning, YAML frontmatter, wikilinks. AI co-development drowns in unstructured context; this is the team's working contribution to making thinking durable, retrievable, and version-aware across humans and agents. See https://www.lossless.group/projects/gallery/context-vigilance. |
| Pseudomonorepos | pseudomonorepos/ | Coined Lossless pattern: parent repos that aggregate child repos (often submodules) primarily to host a parent-level context-v/. Encodes a search-before-create discipline and a tree-walking routine — without it, the same idea gets started in three places and the team loses to itself. |
| Study Repos First | study-repos-first/ | Discipline of pinning a curated collection of upstream repos (a study) around a domain question before designing or coding in that domain. Encodes "read upstream code, don't paraphrase from training data" — agents reach for plausible-but-stale conventions when real prior art is one cd away. This enforces the search-first habit for conventions, schemas, and protocols, and the setup mechanics for a study (named question, pinned submodules, promote-when-grows). |
| Astro Knots | astro-knots/ | Tech hierarchy (HTML / CSS first, then vanilla JS, then a small package, then a framework), approved frameworks (Astro, Svelte, GSAP, Reveal), and hard prohibitions (React, JSX, Angular) for the family of ~10+ Astro sites. Without it, agents reach for npm install reflexively and the sites drift toward generic React-shaped JAMstack. See https://www.lossless.group/projects/gallery/astro-knots. |
| Changelog Conventions | changelog-conventions/ | How to write changelog/ entries — frontmatter (publish: true, lede, ISO dates), YYYY-MM-DD_NN.md filenames, releases/ subfolder for product-style projects, show-don't-enforce ethos. "Changelog First Development" is the team's working theory: a fast-moving public changelog signals momentum to clients, contributors, and your future self. |
| Git Conventions | git-conventions/ | Commit message conventions — structured headers with action verbs and effort groupings, paragraph-spaced bodies that explain impact before implementation, "Also included" riders for minor changes. Conventional Commits is too narrow; this captures both the change and the reason in a way that reads sensibly a year later. The same four-audience cascade changelog-conventions codifies for README / changelog / release narratives applies here: commit messages surface publicly via the GitHub commits view and the parent pseudomonorepo's rolled-up feed, so the header lands for the general audience and the body tail carries SHAs and Co-Authored-By for the internal team. |
| gh CLI · Projects & Tasks Conventions | gh-cli-projects-tasks-conventions/ | How the team uses gh project (GitHub Projects v2) to manage tasks across the pseudomonorepo tree. Premature on purpose — only two conventions exist today, codified now so they don't drift while the rest emerge: (1) compose with pseudomonorepos to resolve the repo a context-v file actually lives in (a path in the parent monorepo's working tree may belong to a submodule on GitHub, and a parent-monorepo URL 404s); (2) task bodies that reference context-v/ files are primarily the clickable GitHub URL to the file in its own repo on the right branch tier, not a paraphrased summary. Ships a shell recipe for building the URL correctly plus item-create / item-edit / bulk-from-spec / field-edit examples. Open seams (status discipline, priority discipline, project layout, custom fields) are listed for fill-in as use cases write them. |
| Theme System | theme-system/ | Theme and mode architecture for Astro Knots sites: two-tier token system, three-mode contract (light / dark / vibrant), theme.css organization, design-system conventions. Without a shared system every site re-invents tokens, and mode toggles break in ways that are hard to debug after the fact. |
| Maintain DESIGN.md | maintain-design-md/ | How to author and maintain a DESIGN.md file at the project root following Google Stitch's open spec — frontmatter token groups (colors, typography, rounded, spacing, components) plus the eight canonical prose sections, the maintenance triggers (what code changes should bounce back into the doc), the runtime-CSS-is-source-of-truth discipline, and the precedent for off-spec extensions like the imagery: block. The agent-readable contract for a project's visual identity. Composes with theme-system (architecture) and generate-consistent-og-images (which reads the imagery: extension). |
| Deck Iteration Workflow | deck-iteration-workflow/ | Workflow for slides-only Astro sites (fundraise decks, conference talks): variant management, structured iteration cycle, alignment with the calmstorm-decks project patterns. Decks rot fast and agents over-engineer them; this keeps generation cheap and revision discipline tight when timelines are real. |
| Crawl, Fetch, Ingest | crawl-fetch-ingest/ | The team's workflow for filling in team and portfolio metadata for VC firms and the operating companies they back: crawl a firm's site, fetch structured data + brand assets for people and companies referenced in a deck/PDF, ingest as canonical .md files with YAML frontmatter. Supports two starting anchors — firm-anchored (one VC → its team → its portfolio → portco CEOs) and company-anchored (one operating company → its backer firms → each backer's team + portfolio, stopping there) via the investor-credibility-ingest routine, for fundraise-deck credibility cards. Encodes the four-checkpoint cascade, the cross-tool fallback pattern (Firecrawl → Tavily → OpenGraph.io), the global-cache-per-firm convention so the same firm's data is reused across multiple decks/memos. |
| OpenGraph, Share, SEO & GEO | open-graph-share-seo-geo/ | Rules for reliable share-preview unfurls in iMessage, WhatsApp, Slack, Discord, LinkedIn, X — plus traditional SEO and Generative Engine Optimization (GEO). Encodes the JPEG-over-WebP rule, the CDN-not-/public rule, and the ImageKit content-negotiation gotcha (og:image:type must match the bytes the unfurler actually receives, not the URL extension) that cost us a debugging cycle. |
| Generate Consistent OG Images | generate-consistent-og-images/ | How to generate share-imagery (banners, portraits, squares, tall WhatsApp/iMessage cards) for any Lossless site so the resulting images form a coherent visual family — via two coexisting techniques, picked per project or per format. Ideogram illustration locks every parameter on the v3 request except prompt and aspect_ratio, with the rest (style reference, color palette weights, negative prompt, seed, rendering speed) living in the project's DESIGN.md imagery: block; encodes the empty-space-as-first-class-subject prompt structure that defeats the "subject grows up into the SVG overlay zone" failure mode, at the cost of stochastic quality across runs. Hero rasterization turns the project's own hero/specimen component into the OG image directly via macOS's qlmanage+sips (or a Playwright screenshot) — deterministic, and a better fit when the hero already carries real data/copy that illustration would throw away. WhatsApp / iMessage chat-preview is the primary target either way. |
| Lossless Flavored Markdown | lossless-flavored-markdown/ | Polyglot extended-markdown spec — user-configured syntax-triggers drive a render pipeline in a frontend framework, giving plain .md files MDX-class power without MDX's JSX-shaped lock-in. Implemented as @lossless-group/lfm on JSR; source lives in astro-knots/. Use when authoring or rendering content, building components routed from markdown, or co-developing the package itself. |
| Maintain Splash Pages (Draft) | maintain-splash-pages/ | The repo-level splash pattern: small Astro sites at <repo>/splash/ that ship to GitHub Pages on push to main, render the repo's changelog/ + context-v/ alongside curated marketing copy, and stay isolated from any package the repo also publishes. Codifies the proven shape across three reference implementations (memopop-site, content-farm/splash, lfm/splash) and the package-isolation discipline that keeps splashes safe to add to repos that also publish to JSR / npm. |
| OpenPanel Analytics | openpanel-analytics/ | Adding and verifying OpenPanel on any Astro site or splash, on Vercel, GitHub Pages, or both: the production-only Analytics.astro component, OPENPANEL_CLIENT_ID per host (a repo Variable for Pages, an environment variable on Vercel), and the OpenPanel supported domains setting whose absence silently rejects every event with a 401. Ends with a curl-plus-DevTools check. Distilled from the rollout across ten sites, where every failure so far was configuration, not code. |
| Event Prep | event-prep/ | Preparing for, working and recapping a conference or summit: intake questions, lens-based routing to the right content folder and Twenty instance, a ranked prep map with asks and opening lines, then badge photos and cards into CRM records and a recap re-sync. Draft, reverse-engineered from three events and being refined against a live run. |
| Maintain Filemap (loop) | maintain-filemap/ | Loop discipline for keeping a FILEMAP.md at the root of each Lossless repo current with the actual on-disk tree. Each FILEMAP has two parts: a hand-authored curator preface (what each top-level directory IS — purpose, ownership, conventions; edited rarely) and a generated tree -L 3 block spliced between <!-- TREE-START --> / <!-- TREE-END --> sentinels (regenerated by the loop's script every time the discipline fires). Fires on three triggers: directory-shape changes as-it-happens (new top-level dir, submodule mount/unmount, major subsystem rename), weekly cadence, and pre-release. Why both halves: a raw tree dump doesn't tell a newcomer what they're looking at — the curator preface is what makes the file legible, the generated tree is what makes it accurate. Composes with pseudomonorepos (parent FILEMAP stops at submodule mounts at depth 3; each submodule carries its own). |
| Chroma Agent Skills (submodule) | chroma-agent-skills/ | Official skills from the Chroma team for integrating Chroma local and Chroma Cloud (CloudClient, schema, hybrid search, cloud CLI). Pinned as a git submodule from chroma-core/agent-skills; we vendor it here so any agent loading the Lossless skills tree gets battle-tested vector-store guidance from upstream rather than paraphrased-from-training-data Chroma usage. |
| Archify (submodule) | archify/ | Upstream skill from tt-a1i/archify (MIT) that turns a small typed JSON spec into a validated, self-contained HTML diagram with inline SVG — architecture / workflow / sequence / dataflow / lifecycle types, dual themes, PNG / JPEG / WebP / SVG / WebM export, and pasted Mermaid accepted as input. Pinned as a git submodule for the same reason as Chroma's. Two unrelated projects ship as "Archify" — this is the CLI / agent-skill one, not Harrison-Yuan/archify-webui; our self-host-stack watchlist had flagged the ambiguity and left it open. Worth vendoring because it answers the standing objection to natural-language diagramming (an LLM drawing a plausible picture is a hand-drawn diagram with extra steps): --repo-root makes the architecture type inspect repository evidence rather than a description, and compare … --receipt diffs two specs so a diagram announces its own staleness instead of rotting quietly. Validation is adversarial — it returns coordinate-level geometry proofs and refuses delivery until they clear. Needs a hand-made symlink into ~/.claude/skills (the skill sits at archify/archify/SKILL.md, one level deeper than sync-skills-symlinks.sh scans), exactly as chroma-local / chroma-cloud do. |
| Graphify (vendored copy) | graphify/ | Upstream skill from safishamsi/graphify (MIT) that turns a folder of code, docs, papers, images, or video into a knowledge graph: graph.json, an interactive graph.html, and a plain-language GRAPH_REPORT.md, with query / path / explain over the result. Fast because its write path has no LLM and no database: tree-sitter parsing for ~30 languages, Leiden clustering, and a NetworkX graph in memory. Every edge is labeled EXTRACTED, INFERRED, or AMBIGUOUS, so an agent knows how far to trust it. It's the default code and context graph for the context-v kit. A copy rather than a submodule, because upstream ships the skill inside its Python package (graphifyy) rather than as a SKILL.md folder; see graphify/VENDORED.md for the version and the refresh steps. |
| Market Capture Analysis | market-capture-analysis/ | Answers the first of the two foundational VC questions — how big can it get? — by walking revenue and EBITDA across an 8-step penetration grid (1%, 3%, 5%, 10%, 25%, 35%, 50%, 60%) for SAM / SOM / TAM at the company's existing pricing and business model. A static if-then picture: the size of the prize at each penetration step with every assumption named so the reader can react to it. Encodes the failure modes (silently picking the optimistic cell, training-data margin assumptions, conflating "unit of sale" with "customer") and the synthesis discipline (3–5 cells in the memo, one named base case, market definition anchored explicitly). Pairs with the sibling skill timeline-scenario-analysis, which answers how fast? — running this skill alone produces a destination with no route. |
| Timeline Scenario Analysis | timeline-scenario-analysis/ | Answers the second of the two foundational VC questions — how fast can it get that big? — by stress-testing the company's current MoM/YoY growth at its actual unit of sale across four scenarios (sustain / improve / plateau / reduce). Operates on the penetration grid produced by market-capture-analysis; sensitivity tables show what it takes to reach each cell and how time-to-base-case shifts with small growth-rate changes. Encodes the failure modes (compounding a recent spike forever, hiding recent deceleration behind YoY, omitting the plateau scenario, skipping the base-case time-to-reach number — that last one is the single most useful sentence the skill produces). Pairs with market-capture-analysis; running this alone produces a growth curve aimed at nothing in particular. |
| Competitive Analysis | competitive-analysis/ | Reference taxonomy for classifying competitors in an investment-memo competitive landscape section. Two orthogonal axes — stage ring (concentric circles outward from the target's own stage: early stage / early scaleup / scaleup / mezzanine / incumbents) and competitor type (direct / adjacent / indirect / noisewashing). Every competitor tagged on both. Encodes the noisewashing-vs-genuine-threat test (coverage doesn't discriminate, but paying users + multi-year capex + earnings-call segment reporting does), the discipline of preferring the looser classification on boundaries (most "direct" candidates are really adjacent), and the exhaustive-vs-synthesized two-artifact pattern shared with the two memo skills above — long classified research file + scannable memo section with a table, grouped list, or ring diagram. |
| Search Lossless Corpus | search-lossless-corpus/ | The discipline of querying The Lossless Group's local Chroma database — populated by context-vigilance-kit with four collections (context-vigilance-corpus, lossless-changelog, claude-code-sessions, claude-code-tool-traces) — before answering questions prior work might already have answered. Encodes the four-step agentic-search loop (decompose → execute → evaluate → synthesize), the five canonical question shapes that trigger retrieval ("what did we decide / when did we ship / why did we choose / has this failed / where did we put"), the metadata-filter patterns that keep queries precise, and the citation discipline (every claim cites source_path + timestamp + source_repo_slug). Lossless layer on top of the upstream chroma-local / chroma-cloud skills — without it the corpus sits there full of high-signal records nobody queries; with it, every "what did we decide about X" becomes grounded recall the user can verify in seconds. |
| Lossless CRM Interface Guidelines | lossless-crm-interface-guidelines/ | Operating manual for reading and writing the operator's Twenty CRM estate over MCP: routing across three workspaces that do not share data, the custom object model (Investment, Deal Source, Deal Prospect, Thesis, Thesis Fit, Events), a forced-choice 0–5 scoring standard with no neutral midpoint, the two-tier profile-links architecture (dedicated fields for sources present on nearly every record, one Profiles LINKS field for the long tail), and the MCP pitfalls worth knowing before the first write. Encodes the provenance discipline that makes a CRM trustable — dedupe before every create, fetch before writing a description, and offer model knowledge rather than smuggling it in, because an empty field is data and a wrong field is damage. First skill built to the public skill / private config pattern below: every operator-specific particular lives in a gitignored config/private.json, and the skill asks rather than guesses when it's missing. |
| HubSpot Interface (Draft) | hubspot-interface/ | Operating a client's HubSpot CRM from Claude through HubSpot's remote MCP server (mcp.hubspot.com): the native connector, a custom MCP connector, or an operator private-app token for REST. Adds what HubSpot's own tools don't: four safety tiers that separate a record edit from a property or pipeline change that hits every user and from publishing anything public, the internal-name-versus-label rule for properties and stages, dedupe rules (contacts dedupe on email, companies don't dedupe on domain, and MCP has no merge), and coverage-first reporting. All 32 MCP tools mapped to a tier. Built from HubSpot's docs, not yet verified on a live portal. Follows the public skill / private config pattern. |
| Cloudflare Artifacts Interface (Draft) | cloudflare-artifacts-interface/ | Operating Cloudflare Artifacts, Git-compatible versioned storage built for agents (one repo per agent, session, or task), from an agent session through the REST API, Wrangler, a Worker binding, or plain git. Covers the three-credential model (API token for control, repo token for git, binding inside a Worker), four safety tiers that put repo deletes, permanent namespace jurisdictions, and long-lived write tokens behind a confirmation, token hygiene (never leave a token in .git/config), collision-proof naming, and the billing and 1 GB-per-repo limits that make bulk creation a decision. Every operation across all surfaces mapped to a tier. Credential behavior tested live; repo writes not yet. Follows the public skill / private config pattern. |
| Augment Speakers and Panelists (Draft) | augment-speakers-panelists/ | Turns a thin event-app bio (usually a screenshot) into a usable speaker profile through web research, in a fixed order: social accounts, then features (coverage about or by them), then mentions (they're quoted or named), then video. Research-tool agnostic: it first resolves which tools this user and organization have (Firecrawl, Tavily, Origami, the client's own web search) and uses them in that order. Encodes identity confirmation before any lookup, the feature-versus-mention distinction, relevance-to-the-session-then-recency selection with a cap of 10, and the rule that only links actually retrieved get reported. Saves to event-hog when connected. Follows the public skill / private config pattern. |
| Obsidian Vault Hygiene (Draft) | obsidian-vault-hygiene/ | Promotes loose notes from the root of the Obsidian vault into their typed folders with standard frontmatter: back up first (the vault root isn't under git), classify high/medium/low and move only high, merge duplicates instead of creating them, verify the URL, fill only-empty OpenGraph fields, edit frontmatter line by line, then move and repair wikilinks. Written from one run that promoted 74 venture-firm notes with every inbound link still resolving. |
| Expense Report Generation | expense-report-generation/ | How to turn raw card and bank statement downloads into a claim a client's finance team can approve without asking a question. Statement data is not an expense report — the gap is identification, categorisation, and disclosure, and each is where a claim gets rejected. Encodes the parent-company descriptor trap (Loom bills as ATLASSIAN, Trae as BYTEDANCE) and the timeline-continuity proof that resolves it, the never-invent-a-product-name rule, the statement-close gap that silently truncates a trip spanning two billing periods, cheap text extraction from bank PDFs (never read the images), cross-card reconciliation, and the BASE/EXTENDED two-section structure that lets a reviewer decline one half without unpicking the other. Financial source data stays in a gitignored private-data/; account-to-card mappings and letterhead details are instance facts, not skill content. |
| Create Contact List from Image or Spreadsheet | create-contact-list-from-image-or-spreadsheet/ | Turns a roster in whatever form it arrived — phone photo of a printed sign-in sheet, screenshot, PDF, CSV, spreadsheet — into a verified contact CSV, vCard 3.0 files importable on both iOS and Android, and a paste-ready E.164 number list. The centre of it is the band-crop transcription discipline, not the vCard generation: never read digits off a downscaled overview (it is legible enough to look right and wrong often enough to poison a roster), crop into overlapping full-resolution bands so a boundary misread reveals itself, and auto-orient first because EXIF orientation lies. A single wrong digit means a stranger in a private group chat. Encodes E.164-always (a formatted TEL matches a messaging account only sometimes, which is worse than never), the fact that vCard 3.0 alone covers iOS / Android / macOS / Outlook so a 4.0 twin adds no reach, the WhatsApp name-prefix trick (its group picker searches contact names only), flag-don't-fix verification, and the observation that numbers.txt is a consumable, not a record — it empties as the user works through it, so a blank file is a finished job rather than corruption. Privacy is structural: deliverables land in ~/Downloads/<group>/, never a working tree, never context-v/. scripts/build-contacts.py is stdlib-only. |
