devs/cproof-context
SHA256
2
0
Fork 0
Code Issues Pull Requests 1 Actions Packages Projects Releases Wiki Activity
Files
draft/split-context
cproof-context/SKILL.md
jabber.developer2 22977846a3 docs: split context into layered, agent-oriented files 
Replace the single file-structure.md with a stratified layout designed
for AI/agent skill consumption: tables and concrete identifiers over
prose, files loaded on demand, content separated by churn rate.

Layers:
- architecture/  stable structural reference (overview, source-map,
                 test-map, data-flow)
- patterns/      memory, commands, autocomplete, events, xmpp,
                 encryption, ui, plugins
- testing/       unit-tests, stubs, functional-tests, bench
- build/         local, docker, ci
- playbooks/     add-command, add-test, add-autocomplete,
                 add-event-handler, add-encryption
- gotchas.md     append-only dated entries (seven seed entries)
- wip/           branch-specific notes; deleted on merge to master

Stable layers describe cproof on master only. In-flight feature
branches (currently feat/ai) get a single file under wip/.

INDEX.md is the entry map with churn labels; SKILL.md is the
always-loaded skill hint pointing to it.
2026-04-30 20:52:06 +03:00

1.5 KiB
Raw Permalink Blame History

name, description
name description
cproof-context Architectural and conventional context for the cproof XMPP terminal client. Load INDEX.md first; pull individual files on demand based on the task at hand.

cproof skill entry

cproof is a terminal-based XMPP client in C, fork of Profanity (renaming WIP). Build: autotools + GLib. Tests: cmocka (unit) + custom runner (functional) + custom benches.

How to use this context

  1. Read INDEX.md for the full file map and churn labels.
  2. For any non-trivial task, pull only the files relevant to it:
    • Touching commands? → patterns/commands.md, patterns/autocomplete.md, playbooks/add-command.md.
    • Touching tests? → testing/unit-tests.md, testing/stubs.md, playbooks/add-test.md.
    • Touching XMPP? → patterns/xmpp.md.
    • Building? → build/docker.md (canonical) or build/local.md.
  3. Always consult gotchas.md before finishing — it lists known pitfalls.
  4. If the task is on a feature branch listed under wip/, load the matching WIP file as well — the stable layers describe master only.
  5. Treat path/identifier references in this context as claims to verify against cproof HEAD before acting on them.

Hard rules

  • Build inside Docker (Dockerfile.debian). Do not run autogen.sh / ./configure / make on the host.
  • Do not mix architecture, patterns, status, and gotchas in a single doc — each has its own home.
  • Do not duplicate what ls / grep would answer cheaper. This context exists for invariants, decisions, and "why".