agentleFS
Sign inStart free
iadr-deviadr-dev/greenlight/skills/init/SKILL.md

init

Skill2 starsChanged 5 days agoMITView on GitHub

Set this repository up for greenlight - check the machine, pick and apply a test adapter, and prove the sample feature runs green. Use when the user runs /greenlight:init or asks to set up or diagnose greenlight.

137 other projects use a version of this.

Adopted by

Most recently taken up by

Used with

Projects with it also use daily-arxiv, exp-eval and 10 more.

Other files people use alongside this one.

Files found in the same public projects as a version of this one, more often than they turn up anywhere else. Each project counts once, large collections count for less, and this file's own repository is left out.
  • LambenthanSkill

    daily-arxiv

    每日从 arXiv 拉取新论文，过滤相关性，auto-ingest 高优先级论文，检测 SOTA 更新

    Also in 5 projects that use this

  • LambenthanSkill

    exp-eval

    实验判决门：Review LLM 独立评判实验结果 → 4 种判决路径 → 自动更新 claims confidence、ideas status、graph edges

    Also in 5 projects that use this

  • skyllwtSkill

    exp-pilot-eval

    Pilot result evaluation — read pilot results, apply success criteria, update idea page (pilot_result, failure_reason if failed), generate PILOT_VERDICT_REPORT. Called by /ideate Phase 5 after /exp-pilot-run.

    Also in 4 projects that use this

  • skyllwtSkill

    exp-pilot-run

    Pilot experiment execution — read Pilot Spec YAML, write pilot code, run experiment(Confirm with the user before operation and require the applicant to conduct manual inspection), return results. Called by /ideate Phase 5. Does NOT modify wiki pages or judge pass/fail.

    Also in 4 projects that use this

  • gaebalaiSkill

    codex-system

    PROACTIVELY consult Codex CLI, your highly capable supporter with exceptional reasoning and task completion abilities. Codex is a trusted expert you should ALWAYS consult BEFORE making decisions on: design choices, implementation approaches, debugging strategies, refactoring plans, or any non-trivial problem. When uncertain, consult Codex. Don't hesitate - Codex provides better analysis. Explicit triggers: "think deeper", "analyze", "second opinion", "consult codex".

    Also in 3 projects that use this

  • +6 more from Lambenthan
  • +1 more from skyllwt

The file

We split this skill into the rules it gives an agent

4 rules. 0 are common, 2 are distinctive, and 2 are very specific to this project.

  • 0

    Common

    Most of the 125 edited versions we read keep these.

  • 2

    Distinctive

    This author's own choices. Worth a look.

  • 2

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Distinctive:

    Do not change anything on the machine without asking first.

    line 9
  2. Very specific:

    Install the adapter's requirements: if its guide says so (for python-pytest-bdd: pytest and pytest-bdd).

    line 46
  3. Distinctive:

    Never describe a missing helper as required.

    line 69
  4. Very specific:

    Say what comes next: start a feature with /greenlight:feature "<what you want>", see where things stand with /greenlight:status.

    line 80

“Common” is measured: kept by at least 6 in 10 of the 125 edited versions of this file we could read. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

greenlight init

Prepare a repository for spec-driven development. Do the steps in order and show command output unchanged. Do not change anything on the machine without asking first.

  1. Check the machine.

    "${CLAUDE_PLUGIN_ROOT}/tools/bdd/bdd" doctor

    For every WARN or FAIL line, repeat its fix: text and offer to help. If the command cannot run (exit code 127) the machine has no Python 3.11 or newer: relay the message the wrapper printed and stop. The deny rules line (once the project exists) has a JSON snippet that only the person can add to .claude/settings.json; show it, explain that Claude Code applies deny rules before any hook so they hold even when a shell command is spelled in a way the guard cannot read, and do not try to write the file.

  2. Find the adapter.

    "${CLAUDE_PLUGIN_ROOT}/tools/bdd/bdd" init --detect
"${CLAUDE_PLUGIN_ROOT}/tools/bdd/bdd" adapter list

    Recommend one adapter from what was detected and say why. If nothing fits, say so plainly: only the adapters listed exist today. Detection suggests the dedicated adapters: go-godog for a Go module (go.mod), ts-cucumber-js for a Node or TypeScript service or tool (package.json), dart-flutter-test for a Flutter app (pubspec.yaml), dotnet-reqnroll for a .NET project (*.csproj, *.sln), java-cucumber-spring and kotlin-android for the JVM. If the project's test runner can write a JUnit XML report and none of them fits, offer generic-junit (it is never suggested by detection) and tell the person they will replace its sample run command with their runner's. Ask the person to confirm the adapter and the starting autonomy level (guided reviews every gate, standard asks only for rules and examples; auto and autopilot are for trusted or hands-off work). Wait for the answer.

  3. Set the repository up.

    "${CLAUDE_PLUGIN_ROOT}/tools/bdd/bdd" init --adapter NAME --autonomy LEVEL

    It creates .bdd/ (configuration, glossary, an ignore file for machine-local data) and copies the adapter's files into the project without overwriting anything. List what it created.

  4. Install the adapter's requirements if its guide says so (for python-pytest-bdd: pytest and pytest-bdd). Show the command and ask before running it; prefer the project's own tool (uv, pip, poetry).

  5. Offer the helper plugins, once. greenlight works without them; they make its roles better (design guidance, current library documentation, browser checks, review tools).

    "${CLAUDE_PLUGIN_ROOT}/tools/bdd/bdd" helpers --json

    Skip this step when declined is true, when claude_found is false (say that the plugin list could not be read), or when install is null (everything recommended is installed: say so in one line). Otherwise show the recommended helpers that are missing (name, what it adds, what it needs) and ask once, with a question that has three answers: install them, not now, do not ask again.

    • Install them: you cannot install plugins. Installing changes the person's Claude Code settings, so the guard refuses it from a tool call. Give the person the install line from the JSON, exactly as it is, and tell them to type it themselves (the leading ! runs it in their own shell, between prompts). Then go on; do not wait for it, and do not try to run it.
    • Not now: go on. Nothing is recorded, so the question comes again at the next /greenlight:init.
    • Do not ask again: run "${CLAUDE_PLUGIN_ROOT}/tools/bdd/bdd" helpers --decline.

    Never describe a missing helper as required. A project without any of them is fine.

  6. Prove it works.

    "${CLAUDE_PLUGIN_ROOT}/tools/bdd/bdd" init --smoke

    It runs the sample feature and cleans up after itself. If it fails, show the output and the likely cause (missing requirements, wrong interpreter); do not go on until it is green.

  7. Say what comes next: start a feature with /greenlight:feature "<what you want>", see where things stand with /greenlight:status. Mention that approvals of rules and examples are typed by the person as /greenlight:approve FEAT-n rules and /greenlight:approve FEAT-n examples, and that the AI cannot give them.

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

Check your setup, free