istm-craft

name	istm-craft
allowed-tools	Bash, Read, Grep, Glob, Write, Edit, Agent, AskUserQuestion
description	Run /istm-craft to design and architect a new feature. It strictly reads the global .istm-context/ blueprints and generates a detailed build spec in .istm-context/specs/, perfectly adhering to the established UI tokens, motion logic, and system constraints.

Documentation & URL Handling

• Bleeding-Edge Frameworks: If the user provides a URL to official documentation in their prompt (e.g., Next.js 16 updates, Langchain docs), you MUST use your web reading tools to fetch and read that URL before writing any code.
• Override Training Data: The syntax and patterns found in the provided URLs absolutely override your internal training data.
• Cache for the Future: If you learn a critical breaking change from a URL, document it in a markdown file inside .istm-context/docs/ (create the folder if it doesn't exist) so you and other agents can reference it in future sessions without re-fetching.
• When in Doubt: If you are building with a framework and are unsure about the latest syntax, ask the user to provide the official documentation link.

What this skill does

This is the Day-to-Day Feature Architect. When the engineer requests a new feature, /istm-craft interviews them, weighs the options, and writes a detailed feature specification into .istm-context/specs/.

Unlike standard AI generation, /istm-craft is strictly bound to the project's global blueprints. It enforces the pre-existing design tokens, motion logic, and architecture.

Execution Flow

Step 1: The Context Lock

Before asking any questions, you MUST silently read the global blueprints to understand the constraints you are working under:

• Read .istm-context/.istm-context/architecture.md (for the database, backend, and API constraints).
• Read .istm-context/.istm-context/design.md (for typography, color tokens, and the Dual Motion standard).
• Read .istm-context/project-overview.md (for business logic context).

Step 2: The Hyper-Focused Interview

Ask the engineer targeted questions to design ONE specific feature.

• CRITICAL RULE (One Spec At A Time): You must refuse to design multiple features simultaneously. If the user asks for a dashboard, auth, and billing, you must say: "I am writing the Auth spec first. We will write the Dashboard spec after Auth is built."
• INFER what you can from the global blueprints.
• ASK for business requirements and edge cases.

Step 3: Spec Generation

Write the feature design into a new file: .istm-context/specs/NNNN-feature-name.md. The spec must include:

• Summary & Requirements: What the feature does and acceptance criteria.
• Step 1: Global Setup (CSS & Layouts): The very first step of the Build Plan must dictate setting up the global CSS (globals.css or index.css) with the design tokens, fonts, and configuring the root layout wrapper (layout.tsx).
• UI & Architecture:
  • How it implements .istm-context/design.md.
  • Component Rule: It is perfectly acceptable to use shadcn/ui components (do not hardcode everything from scratch), but they MUST be styled using the design.md tokens.
• Strict Typing & Constants: Explicitly mandate that all types go in a dedicated types/ folder, and constants go in a constants/ folder. Absolutely forbid the use of any types.
• Build Plan: The step-by-step implementation guide.

Step 4: Completion

Do not write application code. Once the spec is written, instruct the user to run /istm-develop (or equivalent) to begin the implementation phase based on your spec.