New: 98,000+ skills indexed from GitHub repos with 100+ stars · every skill safety-checkedBrowse top skillsTop skills
Esc to closeBrowse all skills
Submit a skillBrowse skills
Submit a skillBrowse skills

Agent skill

Feature

by aiblueprinthq in aiblueprinthq/ai-blueprint

Turn the next, named, or numbered build-plan feature into a buildable current-feature.md spec with small steps and done-when criteria.

MITAuto-check passed

Install Feature

skills CLI
$ npx skills add aiblueprinthq/ai-blueprint --skill feature -a claude-code

Project install by default; add -g for ~/.claude/skills/.

GitHub CLI
$ gh skill install aiblueprinthq/ai-blueprint feature --agent claude-code

Project scope by default; add --scope user for a personal install. Needs GitHub CLI 2.90.0 or later (public preview).

Manual copy
$ git clone --depth 1 https://github.com/aiblueprinthq/ai-blueprint.git skills-src && mkdir -p .claude/skills && cp -r skills-src/.agents/skills/feature .claude/skills/feature && rm -rf skills-src

Use ~/.claude/skills/ instead of .claude/skills for a personal install. The folder must contain SKILL.md.

Claude Code skills documentation · loads skills from .claude/skills/

Facts

Skill name
feature
GitHub stars
463
Token cost
~2.8k tokens
SKILL.md length
1,546 words
Files
3
Skills in repo
20
Repo updated
First seen
Licence
MIT

At a glance

Turn the next, named, or numbered build-plan feature into a buildable current-feature.md spec with small steps and done-when criteria.

  • Works in 4 steps: Search… → Inspect the repository once, starting… → Use the Commands section already loaded… → …
  • Planning a feature
  • SKILL.md covers Start, Build one authoritative…, New feature not in the plan and Write the final spec once, plus 1 more section
  • Instructions only: no scripts, shell commands, URLs or credentials in SKILL.md

What it does

Feature is an agent skill from aiblueprinthq/ai-blueprint. Turn the next, named, or numbered build-plan feature into a buildable current-feature.md spec with small steps and done-when criteria. Use for /feature, planning a feature, or starting planned work.

Its SKILL.md is about 2.8k tokens, which your agent loads only when the skill is triggered. The skill folder holds 3 other files (for example `reference/build-history.md` and `reference/feature-spec-template.md`).

The repository describes itself as: A file-backed, spec-driven AI coding workflow framework for building real software while staying in control. The licence is MIT.

When your agent uses it

  • Planning a feature
  • Starting planned work

Example prompts

  • “/feature”

Workflow steps

4 steps, taken from the first numbered list in SKILL.md.

  1. Search blueprint/context/project-overview.md for the feature number, title,
  2. Inspect the repository once, starting from paths named by those passages.
  3. Use the Commands section already loaded from AGENTS.md. Read it from disk
  4. Run the declared Verify command once when it exists. Record only observed

What it can do on your machine

Read from SKILL.md and the folder at commit 96222b7. It shows what the files ask for, not the result of running them.

  • Tool permissions

    Pre-approves nothing: there is no allowed-tools line, so your agent's usual permission prompts apply.

    From allowed-tools in the SKILL.md frontmatter.

  • Runs code

    No scripts in the folder and no shell commands in SKILL.md (its code samples are markdown).

    From the folder's file list and the shell code blocks in SKILL.md.

  • Network

    No URLs in SKILL.md.

    From URLs in SKILL.md, links to its own repository left out.

  • Credentials

    Names no API keys, tokens, secrets or passwords.

    From names ending in _API_KEY, _TOKEN, _SECRET, _KEY or _PASSWORD in SKILL.md.

Context cost

Feature loads about 2.8k tokens when it runs. Until then it costs about 52 tokens; SKILL.md has 1,546 words of instructions outside code blocks.

Always · name and description, kept in context so the agent knows when to use it
~52
When it runs · the whole SKILL.md, loaded when a task matches
~2.8k

Estimates: characters ÷ 4, the usual rule of thumb; real counts depend on the model's tokenizer. Scripts and assets cost tokens only if the agent reads them.

Safety

Auto-check passed

The automated check found no risky patterns in SKILL.md.

Automated static check — not a guarantee. Review scripts before installing. It scans the text of SKILL.md for risky patterns (piping downloads into a shell, reading credential files, hidden Unicode, destructive commands); files beside SKILL.md are not scanned.

SKILL.md

The full file from aiblueprinthq/ai-blueprint at commit 96222b7, republished under its MIT licence (© aiblueprinthq). 1,546 words, ~2,795 tokens.

Download SKILL.mdSave it as .claude/skills/feature/SKILL.md (or your agent's skills folder). This skill also uses 2 other files; get the full folder from GitHub.
name
feature
description
Turn the next, named, or numbered build-plan feature into a buildable current-feature.md spec with small steps and done-when criteria. Use for /feature, planning a feature, or starting planned work.

feature - create the active implementation spec

Context reuse: Reuse any required file already loaded in project instructions or the current session. Read it again only if absent, changed, or exact current bytes or line references are needed.

This skill plans one feature and stops before implementation. Its output is blueprint/context/current-feature.md.

Start

First action: Before project inspection, preflight, or any other tool call, publish the feature activity as running when blueprint/.state/ exists. Combine that write with the first context-gathering tool batch when the adapter supports it.

Read blueprint/config.json only for settings that affect the spec. Invalid configuration stops mutating work and points to /doctor.

Confirm that blueprint/context/current-feature.md is the empty stub. If it contains active work, stop and direct the user to resume or complete it. Never replace another worker's active spec. Parallel work uses one clone or Git worktree per work item, with a separate branch in each checkout.

Resolve the target from blueprint/build-plan.md:

  • Use the requested number or name when it matches a checklist item.
  • With no argument, use the first unchecked leaf item.
  • Read only the matching checklist line, its parent, and nearby text needed to understand the hierarchy.
  • If a plain list has no checkboxes, treat its first item as unchecked and offer to convert the plan after the spec review.

State the selected feature in one sentence.

Build one authoritative feature packet

Gather the smallest packet that can answer what must be built:

  1. Search blueprint/context/project-overview.md for the feature number, title, and distinctive nouns from the target line. Read the matching feature passage plus only the usage-model, data-model, stack, UI, security, or deployment passages it directly depends on. Do not read the whole overview by default.
  2. Inspect the repository once, starting from paths named by those passages. Follow only relevant imports, callers, tests, schemas, and configuration. Batch related searches and reads when supported.
  3. Use the Commands section already loaded from AGENTS.md. Read it from disk only when it is absent or changed. Read only applicable sections of blueprint/context/coding-standards.md.
  4. Run the declared Verify command once when it exists. Record only observed results. Do not start a dev server.

Finish context gathering in at most four tool rounds after this skill starts: target and overview matches, one batched repository inspection, applicable standards only if needed, and Verify. Combine or skip rounds when possible. Do not inspect other skill directories, ai-interaction.md, findings, review records, or templates during normal planned-feature work. The only history exception is this skill's reference/build-history.md and the selected feature's archive metadata, exact rollback records, and Git evidence needed to freeze its build attempt below; batch this with the target lookup, without loading unrelated history. Do not create scratch code or run implementation probes while writing a spec. Put a check in the relevant build step when a repository detail cannot be confirmed from existing evidence.

The plans and overview define product intent. The repository defines current reality. Do not invent presets, defaults, limits, permissions, money rules, destructive behavior, stored fields, or API contracts. A familiar label is not a complete contract when it has multiple reasonable meanings. Put unresolved material choices under an Open questions heading and in the review handoff. Stop without writing the spec when implementation cannot begin safely until one is answered. Do not block on a reversible internal implementation detail with no user-visible, security, persisted-data, or interoperability consequence. Choose the simplest repository-native option, record it in the spec, and require a test seam when the value is nondeterministic. Planned future persistence alone does not make a current in-memory representation a product decision when no stored data or external compatibility exists yet.

Apply proportional engineering before drafting: add an abstraction, dependency, service, configuration surface, compatibility layer, or security mechanism only when an established requirement needs it now. Prefer existing code, the standard library, native platform features, and installed dependencies. Unknown scale or future extensibility defaults to the smaller reversible design. Treat a trust or data-integrity boundary as established when the repository exposes network or untrusted input, auth/session/ownership, shared persisted data, destructive operations, secrets, or sensitive data, even when the plans do not name it.

If project-overview.md is 20,000 bytes or larger, stop and ask for /overview instead of loading it. If the target is too large for one reviewable branch, propose sub-features and wait for approval before editing the user-owned build plan. After approval, add lettered checklist items under the parent and spec only the first one.

New feature not in the plan

Do not silently add scope. Search for a duplicate, then propose one checkbox line and its placement. Include a project-plan.md edit only when the request changes the product direction, users, data, stack, monetization, UI, or deployment. Wait for approval, update the plans, run the installed overview skill, and then resume this skill. Bugs and small unplanned changes belong in /fix.

Show full SKILL.md (743 more words)Show less

Write the final spec once

Before review, allocate the selected stable feature ID's build attempt using reference/build-history.md: first build 1, otherwise one greater than the maximum proven prior attempt after all prior builds were reversed. Preserve the ID across renamed titles and lettered sub-items. Stop on ambiguous history; never infer attempts from a title suffix, file count, or timestamps.

Draft and critique in context, then write blueprint/context/current-feature.md once. A later write is only for a mechanical correction or user-requested revision. Record **Branch:** with the full configured feature branch. The first heading and build-plan identity must use this canonical form:

markdown
# Feature: <title>

**From build-plan:** feature <id>
**Build attempt:** <positive integer>

Then use these section headings:

  • Goal
  • Design reference, only for visual or replication work
  • In scope
  • Out of scope
  • Build loop
  • Build steps
  • Files / areas
  • Data / contracts
  • Testing
  • Notes for the AI
  • Open questions, only when a product decision remains unresolved

Build steps are ordered checklist items. Each step must leave the project working, stay small enough to review, and end with a concrete Done when that names observable behavior and the relevant check. Follow workflow.stepReview and workflow.checkpointCommits from config in the Build loop. /complete creates the final feature commit.

The spec must preserve every explicit contract in the feature packet, including applicable project-wide UX and security requirements. Do not discard a required state because the current fixture cannot trigger it yet. Keep later features out, define authorization and tenant boundaries only when the feature packet or reachable code establishes them, identify client and server responsibilities, and name exact files or areas supported by repository evidence. Add focused tests for logic when a test command exists. Add browser coverage only when a Browser tests command exists and it is proportionate. Do not claim live, visual, persisted-data, or integration evidence that was not run.

Build the branch value from the configured feature prefix plus the feature title in lowercase kebab-case. Replace each run of characters other than ASCII letters and digits with one hyphen and trim edge hyphens. For attempt N > 1, append --build-N to that slug before recording the full branch, for example feature/export-reports--build-2. The reserved double hyphen distinguishes the attempt from a title ending in Build 2. Before freezing the new spec, check the exact archive path and branch availability using reference/build-history.md. Stop on filesystem entries, disallowed refs, or prior Git use of that archive path; never auto-bump the attempt. The reference permits only one existing-ref case: the pristine current branch of a pre-created parallel worktree. Freeze both fields before review; completion and resume reuse them rather than allocating again.

For visual replication, require an existing screenshot or reference. Store a provided image under blueprint/reference/ and link it. If prototypes/ exists, use its relevant HTML and theme.css; port shared tokens before feature UI.

Critique gate

Before the single write, check these failure classes:

  • Missing happy, loading, empty, invalid, denied, and unexpected-error behavior that applies to the feature.
  • A product contract from the packet that was omitted, weakened, or contradicted.
  • Scope added from guesswork or pulled forward from a later feature.
  • A proposed abstraction, dependency, service, configuration surface, compatibility layer, or security mechanism lacks a current requirement, or duplicates existing code, the standard library, the platform, or an installed dependency. Untuned stack-specific standards in coding-standards.md are not established requirements.
  • An oversized or incorrectly ordered build step.
  • When an established persisted-data or external API boundary requires it, the contract leaves a material type, format, encoding, generator, uniqueness rule, default, lifecycle, serialization, or stable result and error shape implicit.
  • When an established security, tenant, concurrency, destructive-operation, payment, or sensitive-data boundary requires it, the trusted actor source, repository-first tenant scope, atomicity, idempotency, or redaction behavior remains implicit.
  • User-controlled text lacks a safe rendering rule, or validation and error feedback lacks the relevant label, association, announcement, focus, or clearing behavior.
  • A new file, asset, import, or route is not reachable through the current runtime and server behavior.
  • An authorization or URL shape later work would have to reinterpret.
  • A done-when that cannot be observed or a test claim the repository cannot run.
  • A prerequisite that makes the final Verify gate impossible.

If a prerequisite is absent, incomplete, untracked, or unverified, say which one the evidence shows. Do not bury repair inside this feature. Stop with the exact /fix or user decision required.

Otherwise write the tightened spec, update activity to ready, and stop for review. Lead with a short note naming what the critique changed, or say that it found no material change. Never implement from this skill.

© aiblueprinthq, MIT. Rendered from Markdown: HTML in the file is shown as text, images as links, and headings moved down two levels. Raw file

Files

SKILL.md and 2 other files in .agents/skills/feature of aiblueprinthq/ai-blueprint.

  • SKILL.md
  • reference/build-history.md
  • reference/feature-spec-template.md

Open the folder on GitHubat commit 96222b7

Compare with similar skills

Feature next to the 5 skills that share the most tags, products or categories with it. Stars are the repository's; “used in” counts other GitHub owners with a copy.

Feature compared with similar skills
SkillStarsUsed inTokensAuto-checkLicenceRepo updated
Feature this skillaiblueprinthq/ai-blueprint463—~2.8kAutomated safety check: PassMIT
Git Branch Namingmakeplane/plane61k—~594Automated safety check: PassAGPL-3.0
Naming Conventionsthedaviddias/Front-End-Checklist74k—~481Automated safety check: PassMIT
Button Namethedaviddias/Front-End-Checklist74k—~488Automated safety check: PassMIT
Select Namethedaviddias/Front-End-Checklist74k—~451Automated safety check: PassMIT
Naminggridaco/grida2.7k—~2.5kAutomated safety check: PassApache-2.0

Similar skills

  • Git Branch Naming

    makeplane/plane

    Names a new Git branch with a type prefix, the lowercased work item ID and a short kebab-case description, so the ID can be extracted later from the branch name.

    61k GitHub stars~594 tokensUpdated yesterday
    DevelopmentAuto-check passed

  • Naming Conventions

    thedaviddias/Front-End-Checklist

    A skill your agent uses when reviewing stylesheets, component styles, and responsive behavior related to Use consistent CSS naming conventions.

    74k GitHub stars~481 tokensUpdated 3 days ago
    Frontend & DesignAuto-check passed

  • Button Name

    thedaviddias/Front-End-Checklist

    A skill your agent uses when reviewing rendered HTML, interactive components, or design-system patterns related to Provide accessible names for buttons.

    74k GitHub stars~488 tokensUpdated 3 days ago
    Frontend & DesignAuto-check passed

  • Select Name

    thedaviddias/Front-End-Checklist

    A skill your agent uses when reviewing rendered HTML, interactive components, or design-system patterns related to Provide accessible names for select elements.

    74k GitHub stars~451 tokensUpdated 3 days ago
    Frontend & DesignAuto-check passed

  • Naming

    gridaco/grida

    How to think about names in the Grida repo — not conventions, but what a name commits you to, reveals about the system, and costs to change.

    2.7k GitHub stars~2.5k tokensUpdated yesterday
    Auto-check passed

  • Speculative Naming

    sgl-project/sglang

    Naming conventions for SGLang speculative decoding identifiers.

    37k GitHub starsUsed in 2 repos~1.6k tokens
    DevOps & CloudAuto-check passed

More from aiblueprinthq/ai-blueprint

All 20 skills in this repo

  • Adopt

    aiblueprinthq/ai-blueprint

    Adopt Blueprint into an existing brownfield codebase by surveying shipped behavior and generating plans, standards, commands, adapter choices, and visibility setup.

    463 GitHub stars~2.7k tokensUpdated yesterday
    Auto-check passed

  • CI

    aiblueprinthq/ai-blueprint

    Set up or normalize one project Verify command and matching GitHub Actions checks while preserving existing CI, with an optional local pre-push hook.

    463 GitHub stars~2.2k tokensUpdated yesterday
    Auto-check passed

  • Doctor

    aiblueprinthq/ai-blueprint

    Run a Blueprint health and context check covering setup, adapters, commands, visibility, plans, overview freshness, configuration, dashboard state, and workflow drift.

    463 GitHub stars~4.5k tokensUpdated yesterday
    Auto-check: notes

  • Onboard

    aiblueprinthq/ai-blueprint

    Onboard a fresh or early scaffold after Blueprint is overlaid by tuning commands, standards, adapters, visibility, and context loading.

    463 GitHub stars~4.5k tokensUpdated yesterday
    Auto-check passed

  • Overview

    aiblueprinthq/ai-blueprint

    Validate and normalize project-plan.md and build-plan.md, then generate the durable project-overview.md used by agents.

    463 GitHub stars~3.8k tokensUpdated yesterday
    Auto-check passed

  • Brief

    aiblueprinthq/ai-blueprint

    Brief an upcoming build-plan feature without writing files. An agent skill from aiblueprinthq/ai-blueprint.

    463 GitHub stars~1.3k tokensUpdated yesterday
    Auto-check passed

Questions about Feature

What does Feature do?

Turn the next, named, or numbered build-plan feature into a buildable current-feature.md spec with small steps and done-when criteria. Feature is an agent skill from aiblueprinthq/ai-blueprint.md spec with small steps and done-when criteria.

When should I use Feature?

Feature fits situations like: planning a feature; starting planned work.

How do I install Feature in Claude Code?

Run `npx skills add aiblueprinthq/ai-blueprint --skill feature -a claude-code`. Or copy the skill folder (.agents/skills/feature in aiblueprinthq/ai-blueprint) into .claude/skills/feature in your project. Claude Code loads it when a task matches its description.

How do I install Feature in Codex?

Run `npx skills add aiblueprinthq/ai-blueprint --skill feature -a codex`. Or copy the skill folder (.agents/skills/feature in aiblueprinthq/ai-blueprint) into .agents/skills/feature in your project. Codex loads it when a task matches its description.

Can I use Feature in Cursor, Gemini CLI or GitHub Copilot?

Cursor, Gemini CLI, GitHub Copilot and OpenCode also load SKILL.md folders. With the skills CLI, run `npx skills add aiblueprinthq/ai-blueprint --skill feature -a cursor` (or -a gemini-cli, github-copilot or opencode for the others). To copy it by hand, put the folder in .cursor/skills/feature, .gemini/skills/feature, .github/skills/feature and .opencode/skills/feature in your project.

What does Feature need to run?

SKILL.md names no scripts, command-line tools or credentials: Feature is instructions for the agent only.

Does Feature access the network?

SKILL.md contains no URLs. Any network use would come from the scripts or tools the agent runs. This is read from the text; nothing was executed.

Is Feature safe to install?

Our automated static check of SKILL.md found no risky patterns, such as piping downloads into a shell, reading credential files or hidden Unicode. It is not a guarantee. Review the folder before installing.

What licence does Feature use?

Feature is published under the MIT licence (the repository's licence). It allows redistribution, so the full SKILL.md is shown on this page.

How many tokens does Feature use?

About 2.8k tokens (SKILL.md is roughly 11k characters). Agents keep only the skill's name and description in context until a task matches; then they load SKILL.md in full.

What are the alternatives to Feature?

Skills that share tags, products or a category with Feature: Git Branch Naming (makeplane/plane, 61k stars), Naming Conventions (thedaviddias/Front-End-Checklist, 74k stars), Button Name (thedaviddias/Front-End-Checklist, 74k stars) and Select Name (thedaviddias/Front-End-Checklist, 74k stars). The comparison table on this page puts their stars, adoption, token cost, safety result and licence side by side.

Who maintains Feature?

aiblueprinthq (a GitHub organization) maintains it in aiblueprinthq/ai-blueprint, which has 463 GitHub stars. The repository holds 20 skills in this directory. The repository was last updated on October 8, 2026.

Source: aiblueprinthq/ai-blueprint on GitHub. Facts on this page come from the repository at the commit we read; the author's words are quoted as theirs.