agentleFS
BSSE23047BSSE23047/nauraiz-dev/skills/init/SKILL.md

init

Skill2 starsChanged 13 days agoMITView on GitHub

Set up nauraiz-dev in this project: detect the stack and gate commands, write .claude/nauraiz-dev.json, a CLAUDE.md under 200 lines and the memory scaffold. Use once per repo, or to re-detect. Pass --local to try it in a shared repo without changing any tracked file, or --print to show every file instead of writing it. Not for day-to-day tasks.

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

11 rules. 0 are common, 3 are distinctive, and 8 are very specific to this project.

  • 0

    Common

    Most of the 125 edited versions we read keep these.

  • 3

    Distinctive

    This author's own choices. Worth a look.

  • 8

    Very specific

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

  • Common
  • Distinctive
  • Very specific
  1. Distinctive:

    If a project hook blocks a step, stop and say which.

    line 18
  2. Very specific:

    Run node "${CLAUDE_PLUGIN_ROOT}/scripts/init/detect.mjs" .

    line 36
  3. Distinctive:

    Ask the user these questions in one message, each with a recommendation:

    line 39
  4. Very specific:

    Only if offeredGate or testOneShot is non-empty (both modes): offer each offeredGate entry as an extra gate command, and testOneShot in …

    line 46
  5. Very specific:

    Write .claude/nauraiz-dev.json from templates/nauraiz-dev.json.

    line 50
  6. Very specific:

    If the user named a mockup root or another machine-specific path, write it as mockupRoot to .claude/nauraiz-dev.local.json, never to the …

    line 65
  7. Very specific:

    If claudeMd.exists is false, write CLAUDE.md from templates/CLAUDE.md.

    line 77
  8. Distinctive:

    If it is true, never replace it.

    line 78
  9. Very specific:

    Keep the {{#scaffold}} or the {{#none}} block to match state, delete the other, and delete the marker lines themselves.

    line 91
  10. Very specific:

    If state is scaffold, create whichever of these are missing, copied from the templates of the same name, and leave existing ones alone: …

    line 94
  11. Very specific:

    If existingPreToolUseHook is true, set "scopeAsk": false and say why (the project's own edit hook already asks.

    line 99

“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

init

Adopt nauraiz-dev in the current repo. Get each template's text with node "${CLAUDE_PLUGIN_ROOT}/scripts/show.mjs" templates/<name> (e.g. templates/CLAUDE.md). Never Read plugin files directly: project hooks may deny it.

Three limits apply to every step:

  • Show a diff and wait for a yes before changing any file that already exists (not in --print, which writes nothing). New files can be written directly.
  • Touch nothing outside .claude/, CLAUDE.md and .gitignore; --local is narrower (below).
  • If a project hook blocks a step, stop and say which; never work around it.

Modes

The mode comes from the arguments typed (/nauraiz-dev:init --local, --print); they combine, and with neither it is project mode.

  • --local: for a shared repo whose tracked files you must not change. Touch only .claude/nauraiz-dev.local.json, .claude/settings.local.json and git's exclude file (through the script below); never CLAUDE.md, .gitignore, .claude/settings.json or any tracked file. Skip steps 4 and 5. State is always none. Then run node "${CLAUDE_PLUGIN_ROOT}/scripts/init/exclude.mjs" .claude/nauraiz-dev.local.json .claude/settings.local.json .work/ so git ignores all three (the plan folder .work/ too).
  • --print: do every step, but write nothing and run no exclude; print each file's path and full content instead, plus the patterns that would go to exclude.mjs (it makes them repo-root-relative). For headless runs.

Steps

  1. Run node "${CLAUDE_PLUGIN_ROOT}/scripts/init/detect.mjs" . and show the JSON it prints. Do not guess past it: if gate is empty, say so; never invent gate commands.
  2. Ask the user these questions in one message, each with a recommendation:
    • state (not in --local): scaffold (state files in .claude/state/, plans in docs/superpowers/plans/) or none (no state files; plans in .work/tasks/ carry a Handoff). Recommend none if hasWorkTasks is true, otherwise scaffold.
    • enforcement: advisory (context only, never blocks), guided (blocks protected paths, asks outside the plan, warns once) or strict (blocks instead of warning). Recommend guided.
    • Only if offeredGate or testOneShot is non-empty (both modes): offer each offeredGate entry as an extra gate command, and testOneShot in place of the test command, which would watch forever. Use only what the user accepts.
  3. Write .claude/nauraiz-dev.json from templates/nauraiz-dev.json. In --local with no tracked config, write the whole config (state none) to .claude/nauraiz-dev.local.json, no $comment:
    • state and enforcement from step 2; gate, protectedPaths and sharedPaths from detect; branch.base = baseBranch; plan.dir = docs/superpowers/plans for scaffold, .work/tasks for none.
    • Re-detecting (the file exists): start from it. gate, protectedPaths and sharedPaths are the union of existing and detected entries; never remove or rewrite an existing gate command or protected path. Show the diff.
    • --local with a tracked .claude/nauraiz-dev.json: never edit it, and do not write the whole config. Write to the local file (merged into an existing one) only the keys that differ from the tracked file: mockupRoot, an accepted extra gate entry, enforcement if chosen differently. Never copy protectedPaths, sharedPaths or gate entries the tracked file already has: local arrays replace the team's, so a copy would freeze them.
    • scopeAsk: see step 6.
    • No {{ may remain. Keep $comment (project mode).
    • If the user named a mockup root or another machine-specific path, write it as mockupRoot to .claude/nauraiz-dev.local.json, never to the committed file: merged into the existing keys, and in --local as one key of the full config.
    • --local: merge into .claude/settings.local.json, keeping every existing key: set enabledPlugins["nauraiz-dev@nauraiz-dev"] to true and extraKnownMarketplaces["nauraiz-dev"] to { "source": { "source": "github", "repo": "BSSE23047/nauraiz-dev" } }.
    • Project mode: make sure .gitignore ignores *.local.json; add the line if missing.
    • Project mode: if .claude/settings.json enables nauraiz-dev@nauraiz-dev but has no extraKnownMarketplaces.nauraiz-dev, propose adding it (GitHub repo BSSE23047/nauraiz-dev) so teammates who pull the settings can install it.
  4. CLAUDE.md:
    • If claudeMd.exists is false, write CLAUDE.md from templates/CLAUDE.md.
    • If it is true, never replace it. Propose a diff that adds only the "Commands and gate" and "Session discipline" sections from the template (skip any the file already covers). If the result would pass 200 lines, say so and suggest what to move into .claude/knowledge/.
    • {{stack}}, {{baseBranch}}, {{enforcement}} and {{planDir}} are the values from detect and step 3. Fill the rest from the repo, not from guesses: {{projectName}} and {{description}} (one or two sentences) come from the README or manifest; {{layout}} is a short list of the top-level folders that matter, one line each; {{gate}} is one line per gate entry: - `name`: `command`, or "None yet: add commands to gate in .claude/nauraiz-dev.json."; {{protectedPaths}} are the config's paths in backticks; {{rules}} is one line per file in .claude/rules/ other than README.md (- `.claude/rules/<file>` — <its heading>), or "None yet."
    • Keep the {{#scaffold}} or the {{#none}} block to match state, delete the other, and delete the marker lines themselves. No {{ may remain.
  5. If state is scaffold, create whichever of these are missing, copied from the templates of the same name, and leave existing ones alone: .claude/knowledge/README.md, .claude/rules/README.md, .claude/state/session.md, .claude/state/backlog.md, .claude/state/completed.md. For none, create none.
  6. If existingPreToolUseHook is true, set "scopeAsk": false and say why (the project's own edit hook already asks; protected paths are still denied). Otherwise leave "scopeAsk": true.
  7. Print every file written, changed or left alone, and anything still to fill in by hand. Next steps: commit these setup files on their own, through the base branch and before any task branch (a task's scope check would count them), then start a new session. In --local nothing needs committing: say so, that the files are excluded locally, and that the gate reaches Claude through session start.
  8. Last, not in --print and not when AskUserQuestion is unavailable (headless): ask ONE yes/no question with it: "Suggest skills for this project's stack now? It needs network and never installs anything." Yes: invoke /nauraiz-dev:find-skills (Skill tool, skill nauraiz-dev:find-skills). No: say one line, "Run /nauraiz-dev:find-skills any time."

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.