{
  "markdown": "# ASIC Superpowers\n\nASIC Superpowers is a lean Superpowers-style methodology plugin for ASIC\nengineering agents. It helps agents plan, debug, review, and verify claims\nacross:\n\n- RTL design and implementation\n- Design Verification (DV), assertions, coverage, scoreboards, and regressions\n- Physical Design / Backend timing, constraints, reports, ECO, and signoff-boundary work\n\nIt is not an EDA tool, simulator, synthesis runner, signoff flow, or replacement\nfor specialist ASIC workflows. It makes the agent work like a careful hardware\nengineer: clarify intent, name the evidence, avoid unsupported claims, and state\nwhat remains unresolved.\n\nASIC Superpowers is also toolchain-aware. The agent should identify your\nproject's configured simulator, lint, synthesis, formal, CDC/RDC, STA, physical\nimplementation, power, regression, and signoff/report flow when that context is\navailable. It stays vendor-neutral: it should not assume a specific EDA vendor,\ncommand syntax, report dialect, waiver format, or signoff recipe unless your\nrepo or reports provide it.\n\n## Quickstart\n\nInstall the plugin in your agent harness, start a clean session, and ask a\nhardware-specific prompt.\n\n### Codex\n\nFor local development from this checkout, install or load the plugin from this\nrepo path:\n\n```text\n/plugins\n```\n\nThen choose the local `asic-superpowers` plugin if your Codex environment exposes\nlocal plugin sources.\n\n### Claude Code\n\nUse the local plugin path while developing:\n\n```text\n/plugin install /path/to/asic-superpowers\n```\n\n### OpenCode\n\nAdd this checkout to `opencode.json`:\n\n```json\n{\n  \"plugin\": [\"/path/to/asic-superpowers\"]\n}\n```\n\nRestart OpenCode.\n\n### Gemini\n\nFrom this repo:\n\n```bash\ngemini extensions install /path/to/asic-superpowers\n```\n\nIf your harness does not support local plugin installs, use the repo's `skills/`\ndirectory as a local skill source and make sure `using-asic-superpowers` is\nloaded at session start.\n\n## First Prompts\n\nUse one of these after install.\n\n### RTL\n\n```text\nHelp me modify this RTL block. Start by checking what evidence you need before editing.\nFiles: rtl/counter.sv, filelist.f\nAvailable evidence: lint.rpt, sim.log\nToolchain context: use the repo Makefile targets if present; otherwise ask before inventing commands.\nGoal: add a programmable threshold interrupt.\n```\n\nExpected behavior:\n\n- asks about clock/reset, interrupt clear policy, latency, interface semantics,\n  and DV acceptance criteria\n- identifies compile/lint/sim commands or asks for the project's toolchain\n- uses `hardware-evidence-first-development` before editing\n- does not claim timing, CDC/RDC, or signoff closure without reports\n\n### DV\n\n```text\nDebug this UVM scoreboard mismatch.\nFailing test: packet_smoke\nSeed: 12345\nFiles: tb/packet_scoreboard.sv, tb/packet_monitor.sv\nEvidence: sim.log, fail.wdb\nToolchain context: use the existing regression launcher and seed syntax.\n```\n\nExpected behavior:\n\n- uses systematic debugging before proposing a fix\n- asks for observed vs expected transaction behavior\n- identifies simulator/regression command, waveform format, and coverage/assertion report context when available\n- distinguishes DUT, monitor, scoreboard, sequence, and reference-model root causes\n- does not claim full regression or coverage closure from one passing seed\n\n### Physical Design / Backend\n\n```text\nReview this setup timing issue and SDC.\nReports: reports/report_timing.rpt\nConstraints: constraints/top.sdc\nToolchain context: use the report headers, run directory, and repo flow scripts; do not assume a vendor.\nGoal: reduce setup WNS on the control path group.\n```\n\nExpected behavior:\n\n- asks for report provenance, design version, mode/corner, path group, and WNS/TNS\n- identifies the backend flow stage, report dialect, SDC/MMMC setup, and run context when available\n- separates structural timing-risk suggestions from STA-proven timing improvement\n- preserves cycle behavior unless a latency/ECO change is explicitly approved\n- does not claim signoff clean without signoff reports\n\n## What The Plugin Adds\n\nCore ASIC skills:\n\n- `using-asic-superpowers` - session bootstrap and ASIC skill priority rules\n- `hardware-evidence-first-development` - evidence-first workflow for RTL, DV,\n  constraints, reports, and backend artifacts\n\nASIC reference lenses:\n\n- `asic-engineering-contract.md` - intake contract for RTL, DV, and backend work\n- `rtl-design-lens.md` - RTL implementation/review checklist\n- `dv-verification-lens.md` - DV, assertion, coverage, and scoreboard checklist\n- `physical-design-lens.md` - timing, SDC/MMMC, congestion, ECO, and signoff-boundary checklist\n- `asic-review-checklist.md` - review rubric for hardware diffs\n- `hardware-claim-discipline.md` - claim-to-evidence table\n- `eda-toolchain-profile.md` - vendor-neutral toolchain discovery and context capture\n- `tool-evidence.md` - how to treat tool, MCP, and report output\n\nThe plugin keeps the upstream Superpowers lifecycle: brainstorming, planning,\nsystematic debugging, code review, verification before completion, worktrees,\nand branch finishing.\n\nIt routes by required reasoning, not by the user's job title or repo domain.\nPlain software/tooling work by an ASIC engineer should use the inherited generic\nSuperpowers flow. Tasks that require RTL/DV/EDA interpretation, hardware-safe\nbehavior, or hardware completion claims use ASIC Superpowers. Mixed tasks split\nthe boundary: generic flow for the software mechanics, ASIC evidence discipline\nfor interpreting hardware artifacts or reports.\n\n## Minimum Useful Inputs\n\nYou can start with partial context. The agent should ask for what is missing.\n\nFor RTL work, useful inputs are:\n\n- RTL files, packages, interfaces, and filelist\n- compile/elab/lint/sim targets or scripts\n- clock/reset assumptions\n- protocol or block spec\n- compile, lint, sim, assertion, or formal logs\n- waiver files or lint configuration when relevant\n\nFor DV work, useful inputs are:\n\n- failing test and seed\n- simulation log and waveform path\n- UVM component scope: sequence, driver, monitor, scoreboard, reference model\n- assertion or coverage report\n- regression command\n- simulator/regression launcher, seed syntax, coverage database format\n\nFor Physical Design / Backend work, useful inputs are:\n\n- timing, congestion, utilization, power, DRC/LVS, or ECO reports\n- SDC/MMMC files\n- mode, corner, path group, startpoint/endpoint\n- netlist/DEF/design version\n- signoff boundary and ECO limits\n- run directory, flow stage, report command, library/parasitic context when visible\n\n## Evidence Discipline\n\nASIC Superpowers requires narrow, evidence-backed claims:\n\n- Compile success is not design correctness.\n- Lint clean is not simulation clean.\n- Simulation pass is not formal proof.\n- Structural timing-risk reduction is not STA timing closure.\n- CDC/RDC review is not CDC/RDC signoff.\n- SDC syntax is not constraint correctness.\n- DRC/LVS/antenna/IR/EM claims require the relevant signoff reports.\n- Vendor-specific interpretation requires visible toolchain evidence.\n\nWhen evidence is missing, the agent should say what is unresolved instead of\nupgrading the claim.\n\n## Validation Status\n\nCurrent status as of 2026-05-23:\n\n- ASIC plugin metadata and bootstrap have been renamed from upstream Superpowers.\n- `using-asic-superpowers` and `hardware-evidence-first-development` exist and validate.\n- RTL, DV, Physical Design, EDA toolchain, review, evidence, and claim-discipline references exist.\n- README, OpenCode docs, validation plan, and fixture provenance are current.\n- Deterministic metadata, link, trigger, and fixture validation passes locally.\n- Live harness transcript evals are still required before an industry-grade release claim.\n\nRun:\n\n```bash\nscripts/validate.sh\n```\n\nThis checks:\n\n- skill metadata and required skills\n- ASIC bootstrap wiring\n- local markdown links\n- RTL/DV/Physical Design trigger scenarios\n- eval fixture presence and provenance\n- vendor-neutral EDA toolchain-awareness references\n\n`npm run validate` is a convenience wrapper when npm is installed. The shell\nlauncher selects Python 3.7+ automatically, so workstations where `python3` is\nolder can set `PYTHON=/path/to/python3.11` or rely on a versioned\n`python3.11`/`python3.10` binary in `PATH`.\n\nThe repo also validates the new skills with the system skill validator and the\nplugin with the system plugin validator. Live harness transcript evals are still\nrequired before calling a release industry-grade.\n\n## Upstream Release Monitoring And Sync\n\nA weekly GitHub Actions workflow checks published, non-prerelease releases from\n`obra/superpowers`. Every stable release after the `v5.1.0` baseline gets one\nissue titled `Upstream obra/superpowers <tag> baseline review`, including\nreleases with no baseline-file changes. Open and closed issues both suppress\nduplicates.\n\nThe issue compares adjacent stable releases and classifies changed upstream\npaths as:\n\n- `candidate-generic`: inherited generic behavior eligible for selective review\n- `asic-owned`: local ASIC behavior that upstream must not overwrite\n- `mixed-manual`: integration or identity files that require a hand merge\n\nLocal-only ASIC files do not appear in the comparison because the monitor diffs\ntwo upstream release tags. Unknown upstream paths default to\n`candidate-generic`, but nothing is applied automatically.\n\nTo test discovery without creating issues, manually dispatch the\n`Upstream obra/superpowers release monitor` workflow with `dry_run` enabled, or\nrun locally with a GitHub token:\n\n```bash\nGITHUB_TOKEN=\"$(gh auth token)\" npm run monitor:upstream-releases -- \\\n  --destination-repo ariklapid/asic-superpowers \\\n  --dry-run\n```\n\nAfter an issue is reviewed, ask your coding agent to use\n`syncing-upstream-superpowers` and prepare the existing selective sync report:\n\n```bash\nnpm run sync:upstream\n```\n\nThe report writes `candidate-generic.patch` plus a combined\n`protected-manual.patch`. After the reviewed sync passes validation, update the\ntracked upstream marker:\n\n```bash\nnpm run sync:upstream:mark\n```\n\n## Future Plan\n\nNext release work:\n\n1. Run clean live transcript evals in at least one target harness for RTL, DV,\n   Physical Design, and vendor-neutral EDA toolchain prompts.\n2. Add transcript artifacts or summaries under `evals/` without exposing private\n   project data.\n3. Pressure-test unsupported claim prompts: lint clean, CDC clean, timing\n   closed, signoff clean, scoreboard fixed, and generic EDA report assumptions.\n4. Iterate only on failures observed in transcripts, then re-run `scripts/validate.sh`.\n5. Add optional deeper workflow bridges to `asic-ai-workflows` only when a real\n   repeated task needs them.\n6. Keep the plugin lean and vendor-neutral; do not add mandatory EDA\n   dependencies or vendor-specific rule packs to core.\n\n## Fixtures And Evals\n\nThe repo includes compact eval fixtures under `evals/fixtures/`:\n\n- MIT-licensed local fixtures from `asic-ai-workflows`\n- permissively licensed public SDC, lint, timing-summary, power, and DV examples\n- one hand-authored synthetic `report_timing.rpt` fixture for deterministic tests\n\nSee `evals/fixtures/PROVENANCE.md` for sources, licenses, and limitations.\n\nTrigger scenarios live in `evals/trigger-scenarios/scenarios.json`.\n\n## Scope Boundaries\n\nUse specialist tools and repos as escalation paths when needed:\n\n- `asic-ai-workflows` for deeper structured handoff/report workflows\n- HDL MCPs for compiler-backed source context\n- UPF/low-power MCPs when available\n- EDA tools only when the user has provided the flow context and the active\n  workflow supports that phase\n- project-local EDA commands should be preferred over invented commands, and\n  mutating implementation/signoff commands require explicit approval\n\nASIC Superpowers stays zero-runtime-dependency and methodology-focused.\n\n## Full Validation Plan\n\nSee `docs/ASIC_PLUGIN_VALIDATION_PLAN.md` for the complete release validation\nflow, including deterministic checks, live harness transcript evals, and\nadversarial claim-pressure prompts.\n",
  "bytes": 11997,
  "sha": "37423c806a1635395fb5ddd48fb140c00071de00bbc1901f55789587b83c0168",
  "repo_slug": "ariklapid/asic-superpowers",
  "fonte": "repo",
  "truncated": false,
  "api": "https://agentalog.com/api/listings/plg_ariklapid_asic_superpowers_fd1898fe/readme"
}