← all publishers

huguryildiz

@huguryildiz source repo

16 published skills

  1. Ieee Acm Paper Writing · huguryildiz bundle
    Draft, rewrite, compress, structure, calibrate, humanize, or audit engineering manuscripts for IEEE and ACM Transactions, journals, and conferences, with optional self-contained HTML audit maps. Use for abstracts, introductions, related work, system models, mathematical formulations, algorithms, experimental methods, results, discussions, conclusions, contribution lists, notation and claim audits, evidence-grounded peer-review reports, venue adaptation, machine-idiom humanization of AI-flavored prose, or landmark-paper calibration in communications, signal processing, energy systems, robotics, optimization, simulation, ML-assisted engineering, and computer systems. Do not use for general documentation, grant proposals, marketing copy, or editorial accept/reject advocacy detached from manuscript evidence.
    0
    installs
  2. Lit Anchor · huguryildiz
    Use when assembling or adding to a bibliography, citing prior work, or making a novelty or absence claim — especially with AI assistance, which fabricates plausible-but-fake DOIs, titles, and authors. Governs DOI-verified, small-step literature anchoring so no unverified citation enters the record. Trigger phrases: "add a citation", "find references for", "cite prior work", "is this novel", "no one has done", "the literature says", "build the bibliography", "related work".
    0
    installs
  3. Canonical Params · huguryildiz
    Use when a change would touch the project's canonical operating point — the protected default parameter values that all results are reported against — or when a "let's just try X" probe risks editing a default instead of passing a script-level argument. Trigger phrases: "change the default", "try a different value", "tweak the operating point", "why is this parameter frozen", "can I edit the constants".
    0
    installs
  4. Correctness Gate · huguryildiz
    Use when a change touches any critical module — the modules whose silent breakage would corrupt the project's results — before claiming the change is done, ready, or working. Also use when the named gate test goes red and the bug-or-intentional-change call must be made. Trigger phrases: "run the gate", "is the correctness gate green", "I changed the core model", "the gate is red", "can I say this is done", "update the gate tolerance".
    0
    installs
  5. Skill Library Generator · huguryildiz
    Use when adopting the Aletheia discipline in a new or existing research repository — discovering the project's actual conventions, interviewing the maintainer to fill the config bindings, extracting the project's own recurring failure modes into project-local skills, and scaffolding the record surfaces (decision log, build log, evidence dirs) after approval. Trigger phrases: "adopt aletheia here", "set up the research discipline", "generate skills for this repo", "bind the pack to this project", "run the adoption interview".
    0
    installs
  6. Evidence Convention · huguryildiz
    Use when launching any computational campaign whose results will be kept, cited, or decided upon — sweeps, batch runs, Monte Carlo draws, precomputes — and when auditing for "dark runs" (results that exist only in caches, scratch dirs, or chat logs). Defines where evidence lands and what a run must record. Trigger phrases: "where do the results go", "record this run", "write the meta file", "dark run", "promote these results", "run report".
    0
    installs
  7. External Positioning · huguryildiz
    Use when a claim is about to face the outside world — classifying what is novel versus known, scoping claims to what the evidence supports, holding the figure-regeneration bar (every kept figure rebuilds from one command), and holding the reproducibility bar before anything enters a draft. Trigger phrases: "is this novel", "position against the literature", "are we over-claiming", "regenerate the figure", "can we rebuild all figures", "ready for submission", "what's our contribution". (Citation verification lives in `lit-anchor`.)
    0
    installs
  8. Numerical Determinism · huguryildiz
    Use when the same code and same seed still produce different numbers — pinning thread counts, parallel reduction order, GPU kernels, and engine-level nondeterminism — and when a claim requires bit-reproducibility or a timing result requires hardware context. Also defines the hardware-context fields every run's meta file should record. Trigger phrases: "same seed different result", "pin the threads", "deterministic mode", "results differ across machines", "record the hardware", "timing needs the machine specs".
    0
    installs
  9. Statistical Reporting · huguryildiz
    Use when a numeric result is about to be reported, compared, or put in a paper — enforcing replication counts, uncertainty intervals, paired comparisons on matched instances, and visible denominators. Also use when designing how many runs a claim needs. Trigger phrases: "is this difference real", "how many replications", "report with confidence intervals", "single run result", "compare method A vs B", "is N=3 enough".
    0
    installs
  10. Negative Results Ledger · huguryildiz
    Use when an idea, approach, or experiment fails, dead-ends, or gets abandoned — recording it in one line so it is never re-attempted from scratch and never silently buried. Also use when a negative or infeasibility result might itself be a finding, and when auditing a project for unrecorded dead ends. Trigger phrases: "that didn't work", "abandon this approach", "record the dead end", "why didn't we try X" , "we tried that before", "the result was negative".
    0
    installs
  11. Build Log · huguryildiz
    Use when a phase completes or a sanity-gate result is being fixed as permanent evidence — writing a new numbered entry under the build-log directory. The bar is high; single-module additions and small changes do not get entries. Trigger phrases: "phase N is done, log it", "the gate passed, record it", "write a build log entry", "completion note", "fix this result as evidence".
    0
    installs
  12. Layer Sync · huguryildiz
    Use when checking whether the project's knowledge layers agree — the decision log, the spec/docs, the code, and the notebooks/reports — after a decision lands, after a refactor, before a phase closes, or when the user asks "is there drift", "did that decision propagate", "are docs and code in sync". Also use to register an explicit doc-to-source anchor link for point-precise checking. Trigger phrases: "sync check", "drift audit", "is the spec up to date with the code", "did D-numbers propagate", "link this doc to this source file".
    0
    installs
  13. Phase Gate · huguryildiz
    Use when closing a project phase or milestone gate — the user believes the phase's acceptance criteria are met and wants it closed formally, with evidence verified item by item. Runs the closure ritual in strict order and blocks on any open item. Trigger phrases: "close the phase", "close the gate", "is the phase done", "phase-gate check", "milestone closure", "can we call this phase complete".
    0
    installs
  14. Decision Log · huguryildiz
    Use when a project decision is made or changed — a modeling assumption, a default value, a method choice, a scope cut, a rejected alternative — and it must be recorded as a numbered ADR-lite entry, or when an existing decision is superseded, or when the user asks "why did we choose X" / "is there a decision for this". Trigger phrases: "record this decision", "write an ADR", "add a D-number", "supersede D12", "why is this the default", "log the rationale".
    0
    installs
  15. Project Layout · huguryildiz
    Use when starting a new computational-science project, restructuring an existing one, or deciding where a new module, script, notebook, dataset, or document belongs — including whether a piece of work is a notebook one-off or a reusable script, and maintaining the notebook series. Also use when reviewing whether a repository's layout still matches its documented map. Trigger phrases: "where should this file go", "set up the project structure", "scaffold the repo", "folder layout", "project organization", "does this belong in scripts or notebooks", "notebook or script", "should this be a notebook or a script", "make this rerunnable", "the notebook is stale", "promote this to a script".
    0
    installs
  16. Run Provenance · huguryildiz
    Use when a kept run must be attributable to exactly what produced it — the environment it ran under (interpreter, locked packages, domain engines, system layer, native architecture), the input bytes it consumed (datasets, external files, config/constants), and the random draws it made (seeds recorded and re-derivable). Everything `results/<name>_<date>/meta.json` must record about a run, and how to make each field true. Also use before any campaign whose results will be kept, when two machines disagree on a result, and when asking "did the data change between these two runs". Trigger phrases: "pin the environment", "lockfile", "which versions produced this", "works on my machine", "environment drift", "hash the inputs", "did the data change", "which dataset version", "fingerprint the config", "data provenance", "record the seeds", "which seed produced this", "unseeded randomness", "make this run reproducible", "what produced this number".
    0
    installs