agentsclimarketplace
Sign in

Kantan start feature

Skill marvs/kantan-dev/skills/kantan-start-feature

Use when starting a new feature or building something new in a Rails + React app. Trigger on messages like "I want to build a new feature", "let's add X", or "new feature" — even in plan mode, and even if branches are already set up or requirements are provided inline. Always use this before kantan-plan-feature. Confirms the feature name and working branch, then captures detailed initial requirements as an IDEA document before any planning or code.From its SKILL.md

Install
npx -y skills add marvs/kantan-dev --skill kantan-start-feature

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

One thing to look at

  • 4 stars4 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.

SKILL.md

2.6 KB, as published. Nobody here has run it

Start a Feature

Begin every new feature here. This establishes the feature's identity and requirements before planning or code.

Steps

  1. Get the feature name. Ask for a short name (e.g. "Task Uploads") if not given. Derive a slug YYYYMMDD_feature_name using today's date (UTC) and the snake_cased name (e.g. 20260624_task_uploads). Reuse this same slug for the plan and docs later.

  2. Locate the roots.

    • Backend: if a .kantan-dev/ directory already exists in a workspace root, use that root; otherwise use the root containing a Gemfile (Rails backend, e.g. has config/application.rb). All artifacts live under <backend-root>/.kantan-dev/.
    • Frontend: find roots with a package.json that depends on react. If more than one React frontend is present, ask the user which one this feature targets — do not guess. Record the chosen frontend root. (Trust package.json/lockfile over any prose in docs for stack/version facts.)

  3. Confirm the branches. Report the current branch of each involved root (backend and the chosen frontend) and confirm with the user before proceeding. Call it out explicitly if a root is on a main branch (master/main), since work will land there directly. Work happens on the current branch: do NOT create git worktrees, and do NOT create or switch branches unless the user explicitly asks.

  4. Capture the IDEA (user-provided). The requirements come from the user — this step records them, it does not author them. Ask the user to provide the requirements/description for the feature if they haven't already. Save what they give you to <backend-root>/.kantan-dev/ideas/YYYYMMDD_feature_name.md, preserving their content.

    • You may organize their input under light headings (e.g. problem, behavior, constraints, open questions) and fix obvious typos/formatting.
    • Do NOT invent, expand, or embellish requirements, and do not add implementation detail. If something important is missing or unclear, ask the user — do not fill it in yourself.

  5. Hand off to planning. Once the IDEA is written, plan the feature (see kantan-plan-feature). Do not write code yet.

Keep looking

Skills are one crate of 627,801. Ordering is by how many stacks a row turns up in, so the top of any crate is what has actually been picked rather than what has the most stars.