plugins/gateflow/skills/gf-project/SKILL.md
Manages .gateflow/project.yaml for project-specific configuration. Auto-detects project settings or prompts user for board, HDL, and target. Used internally by other skills — not typically invoked directly.
npx skillsauth add codejunkie99/gateflow-plugin gf-projectInstall this skill globally with one command. Works with Claude Code, Cursor, and Windsurf.
3 of 9 scanners reported clean
Some scanners were skipped, did not run, or reported a non-clean status. Review each row below.
.gateflow/project.yaml in the project root.
name: my-project
top_module: top
hdl: systemverilog # systemverilog | verilog | vhdl
target:
board: null # arty-a7-35t, icebreaker, etc.
device: null # xc7a35ticsg324-1L, ice40hx8k, etc.
clock_freq: null # 100MHz, 12MHz, etc.
sources: [] # auto-populated by gf-scan
constraints: null # path to constraint file
ip_blocks: [] # installed IP block names
When this skill is invoked, it:
.gateflow/project.yaml exists.sv = systemverilog, .v = verilog, .vhd = vhdl)**/*.sv, **/*.v, **/*.vhdAny skill that needs project context should:
cat .gateflow/project.yaml 2>/dev/null
If the file doesn't exist, invoke this skill to create it.
When a user mentions a board name in natural language (e.g., "I'm using an Arty A7"),
persist it to .gateflow/project.yaml under target.board. Do not ask again unless
the user switches boards or starts a new project.
Board memory is per-project, not global. Different projects target different boards.
---GATEFLOW-RESULT---
STATUS: CREATED | UPDATED | VALID | INVALID | ERROR
PROJECT: <name>
FILE: .gateflow/project.yaml
BOARD: <board or null>
HDL: systemverilog | verilog | vhdl
TOP_MODULE: <module>
SOURCES: <count>
DETAILS: <summary>
---END-GATEFLOW-RESULT---
simulation:
tool: verilator # verilator | iverilog | vcs
timeout: 100000 # max cycles
trace_format: fst # vcd | fst
defines: [] # compile-time defines
synthesis:
tool: yosys # yosys | vivado | quartus
target_family: null # ice40 | ecp5 | gowin | xilinx
optimization: area # area | speed | balanced
verification:
formal_engine: sby
formal_depth: 50
coverage_goal: 90
lint_tool: verilator
name: my-project
top_module: top
hdl: systemverilog
target: {board: icebreaker, device: ice40up5k-sg48, clock_freq: 12MHz}
simulation: {tool: verilator, trace_format: fst}
synthesis: {tool: yosys, target_family: ice40, optimization: area}
name: sim-project
top_module: top
hdl: systemverilog
target: {board: null}
simulation: {tool: verilator, timeout: 500000, trace_format: fst, defines: [SIMULATION, DEBUG]}
synthesis: {tool: null}
| Check | Pass Condition |
|---|---|
| Schema valid | name, top_module, hdl exist |
| Sources exist | All listed files found |
| Top module found | grep for module <top> in sources |
| Constraints match target | .xdc for Xilinx, .pcf for iCE40, .lpf for ECP5, .cst for Gowin |
| Tools installed | which <sim_tool>, which <synth_tool> |
tools
GateFlow release readiness workflow. Validates plugin manifests, marketplace metadata, docs index coverage, root mirrors, release notes, and component counts before a version tag is created. Use when preparing, checking, or cutting a GateFlow plugin release.
testing
Testbench verification best practices and patterns. This skill should be used when the user needs testbench architecture guidance, verification methodology, or wants to write professional-quality testbenches. Example requests: "testbench best practices", "how to structure TB", "verification patterns"
testing
Primary SystemVerilog/RTL orchestrator for GateFlow. Routes to specialist agents, runs verification, and iterates until working. Use when the user wants to create, test, fix, or implement any RTL design — FIFO, UART, AXI, state machines, or any digital hardware module.
development
Terminal visualization for GateFlow codebase maps. Renders module hierarchies, FSM state diagrams, and module detail cards as interactive ASCII/Unicode art. Example requests: "visualize the codebase", "show hierarchy", "show FSM", "show module detail"