llopresto87
- 14 skills
- 0 followers
- 6 hours ago last updated
- ▌ Humanizer · llopresto87 bundleDraft or revise prose a person will read (documentation, README text, ADR and spec bodies, runbooks, pull-request descriptions, commit messages, delivery summaries, briefs and reports for the owner) so it reads as deliberate writing by a competent author, without changing what it says. Use when a draft came out of a model and shows the tells (empty contrasts, staged openers, one-line closers, forced triads, dash dependence, inflated significance, bold labels on every item, chatbot residue), when drafting finished prose from notes, or as the last pass before such text is handed off. Preserves facts, numbers, conditions, requirement levels, citations and voice; adds no fact; never fakes a human author or chases a detector score. The doctrine is method.prose-posture; docs/graph/prose-lint.py is the mechanical floor and the fact-preservation check.
- ▌ Adr Writer · llopresto87Author an Architecture Decision Record that captures a non-obvious technical choice — its context, the decision, the consequences, the rejected alternatives, and the reversibility cost. Use whenever a non-trivial dependency is picked, a framework is chosen, a one-way door is opened, two specialists disagree and the orchestrator must pick, or anyone in a future session would ask "why did we do this?" An ADR exists so the answer is on disk, not in someone's head. Its lifecycle status lives in frontmatter in the schema's one vocabulary (proposed, accepted, open, deferred, hotfix, rejected, superseded, closed); superseding is a new ADR plus a status flip on the old — never an edit of its body.
- ▌ Test First · llopresto87The test-SHAPING technique applied inside the test-first protocol — pick the lowest test level that exercises the behavior (unit, integration, contract, e2e, golden, property-based, evaluation), name the test after the spec contract, and assert one outcome per test. The workflow itself (entry conditions, RED-GREEN-REFACTOR-COMMIT gates, variants, exceptions) is the test-first protocol.
- ▌ Spec Author · llopresto87Write an executable specification under docs/graph/specs/ that turns a clear goal into testable contracts. Use whenever a feature, endpoint, job, significant function, or AI interaction needs a contract that the tester can encode and the implementer can satisfy. Coordinates product (§3, §9), architect (§4, §6, §7), and tester (§10 testability review) into a single signed-off document. Specs are the source of truth for behavior; do not write code without one.
- ▌ Library Wiki · llopresto87Maintain a project-local, version-pinned wiki of every external dependency. Use whenever a new library is being added, an existing one is being upgraded, an idiom for using a library is being adopted, a pitfall is being discovered, or a wiki page is missing for code that already uses a library. The wiki is the source of truth this project consults BEFORE writing code that touches a library; agent memory of library APIs is unreliable across versions, so always check or build the wiki first.
- ▌ Grill Planner · llopresto87The authoring discipline for the project's plan-of-record at docs/graph/plans/grill.md — what a worker filling any section carries, and the audit that says whether the plan is still consistent with the specs, the wiki, and the decisions. Use whenever a brief produces or updates grill.md, or grill.md needs a consistency pass. The pass itself (which section, which owner, in which order) is protocol.grill; this skill is how each section is written well.
- ▌ Adopt Existing · llopresto87Source-first growth of an existing single- or multi-repository project into CYPRESS's unified docs/graph knowledge system. Use from initialize when code already exists, or for a graph refresh after material code changes. Scout executable evidence, model subsystem nodes, build project-specific architecture/product/API/data/dependency/prompt/operations leaves, connect them for progressive discovery, and validate navigation. Never trust centralized prose without source corroboration, invent specs or ADRs, modify application files, run application builds, or push Git.
- ▌ Context Router · llopresto87Resolve the minimum set of knowledge-graph nodes needed for a task before reading any source file. Use at the START of every non-trivial task once a project has a knowledge graph — when changing a subsystem, tracing a bug, planning work, answering a question about how something works, or onboarding. This is the mechanism that keeps a large or multi-repo codebase inside a context window: it decides what to load, what to deliberately skip, and forces the agent to declare both before working. Pairs with the knowledge-graph skill, which builds and lints the graph this one traverses.
- ▌ Knowledge Graph · llopresto87Build and maintain the project's knowledge graph — a tiered set of nodes under docs/graph/ that lets an agent load only the few facts a task needs instead of the whole codebase. Use when adopting a project, when a fact changes, when a node grows too large, or when a task should have matched a node's triggers and didn't. Enforces one home per fact (dedup), honest per-node budgets, cite-don't-fabricate, and a mechanical linter. The library wiki (docs/graph/libraries/) is a leaf tier of this graph, not a separate system.
- ▌ Holistic Editing · llopresto87The discipline for any change, fix, refactor, or review whose unit of work is larger than a trivial one-liner. Use whenever you edit existing code or a knowledge page — the unit of work is the whole file or module, never the smallest diff that satisfies the request. A change is complete only when the file reads as if the requirement had existed from the beginning: no bolted-on functions, no _v2 wrappers, no special-case branches around logic that should itself change, no now-dead code left "to be safe." Coherence outranks minimal diffs. Load this before editing a file of any substance; it governs how implementer, reviewer, and every specialist touch existing files.
- ▌ Validate Knowledge · llopresto87Prove that a knowledge base actually works before trusting it — after building or adopting docs, a knowledge graph, or a wiki, verify it can orient a fresh agent and resist false premises. Use at the end of an adoption, after a large docs change, or before relying on the graph to route work. Two methods: clean-context test agents answering known-answer and adversarial questions, and enforcement tests that plant a violation and confirm the linter catches it. A smoke test proves code runs; this proves the knowledge is correct, navigable, and honest.
- ▌ Brainstorm Socratic · llopresto87The Socratic questioning technique that converges a vague goal — question selection, one-to-three-per-turn pacing, the reflect-every-two-answers cadence, the nine-question hard cap, and the eight-point convergence checklist that defines "converged". Applied whenever the brainstorm protocol is entered; the protocol owns entry/exit conditions and where output lands, this skill owns how to converge.
- ▌ Research And Ingest · llopresto87Find authoritative sources on the web (or via documentation MCP servers like Context7/DeepWiki), download or snapshot them when allowed, normalize them into clean Markdown, and stage them for the library-wiki. Use whenever a new library/spec/API/standard is being added, a wiki page is stale, an ADR needs current evidence, or a behavior best practice needs verification. Always prefer official upstream sources and version-pinned content over training data.
- ▌ From Scratch Bootstrap · llopresto87Stand up a brand-new project from an empty (or near-empty) repo through the nine-phase from-scratch protocol — brainstorm, skeleton, grill, research, architecture, verification baseline, specify first slice, test-first the first slice, deliver. Use whenever a project does not yet exist, the repo is empty, no docs/graph/plans/grill.md exists, or you are about to write `mkdir my-project && cd`. The first day disproportionately shapes the project; this skill prevents skipping the load-bearing steps.