Incubate LET Specs into Production Tool Repos

Where this fits

A maintainer approves an RFC for a new Linux Engineering Tools (LET) repository, but the repo shouldn't be created until every prerequisite exists. incubate-tool walks an agent through the five gates—requirements, public spec, upstream check, RFC approval, and desktop contract—so a new repo is a deliberate act, not an impulse. This fits developers who delegate board-to-repo transitions to agents.

Why agents benefit

• It reads the five gates from the skill definition and stops before repo creation if any gate is missing, so agents avoid generating premature repositories.
• It can check requirement issues for capability language and ip:clean, making board state machine traceable.
• It validates public specs under specs/<name>/ for problem, standards, CLI, tests, and license sections.
• It verifies upstream checks by looking for a named project, a Forge URL, and a decline reason, reducing duplicate tooling.
• It enforces Apache-2.0 and the Wayland desktop-contract requirements when a spec contains a GUI, preserving org policies in the scaffolded repo.

Practical scenarios

Moving a requirement off the board

A developer runs /incubate-tool after an issue is marked ip:clean. Instead of creating a repository immediately, the skill reviews the requirement and returns 'missing public spec' with the exact path to create.

A GUI spec reaches maintainer approval

The RFC is approved, but the desktop contract is absent. The agent stops the repository creation and asks the maintainer to add Wayland and keybinding details to the spec, preventing an incomplete GUI contract from becoming the repo's baseline.

Upstream workflow is unclear

A spec says 'no existing tool found' but doesn't say who was asked or on which Forge. incubate-tool treats this as a missing gate, so the agent files the upstream check rather than silently scaffolding a new project.

Add it to your agent workflow

Install the skill and let the agent invoke it when the board signals a repo is ready:

npx skills add linux-engineering-tools/community --skill incubate-tool

Once installed, an agent can respond to /incubate-tool specs/lint-dashboard by running the gate checks and, if all pass, preparing a repository under github.com/linux-engineering-tools/<name>. The repo gets Apache-2.0 licensing and a README that links community TERMS.md rather than inventing new terminology. To inspect the skill metadata and see how it fits other agent workflows, see the OpenAgentSkill listing: https://www.openagentskill.com/skills/linux-engineering-tools-incubate-tool

Compare before adopting

Compare skill quality signals: does the README actually define gates rather than vague instructions? Check maintenance freshness, including last commits and issue tracking in the community repo. Alternatives include general-purpose repo-scaffolding agents or shell scripts using GitHub CLI; they are faster but lack governance checks. Also assess workflow fit: incubate-tool expects LET-style requirements, RFC approval, and spec directories, so teams outside that process will need to adapt it.

Why it is worth tracking

incubate-tool is an emerging reference for turning org policy into agent-checkable gates. At 11 stars and under linux-engineering-tools/community, it is early but signals a real need: agents should not create repos unless the governance record says it's safe. Track it if your agent orchestration touches issue boards and GitHub orgs; re-evaluate when the community demonstrates more commits, new skill versions, or adoption beyond LET. The OpenAgentSkill URL above is a stable place to watch that evolution.