Building an Image-Slicing Tool with an AI Coding Assistant: Comparing Design-Spec Prompts with Plain Prompts

1. Why This Comparison Matters

In everyday work, content teams and social media creators often encounter small but urgent tool requirements. One common example is splitting a large image into a 3×3 grid, a 2×2 grid, or several vertical slices before publishing it on social platforms.

If handled through a traditional development process, these requests may not receive high priority. With the help of an AI coding assistant, however, a developer with basic front-end knowledge—or even a non-technical operations specialist—can generate a fully local web tool on demand.

Anyone who has used an AI coding assistant has probably seen the same pattern: when the prompt is vague, the generated page may have the correct functionality, but the visual design and interaction often feel usable rather than polished. When design experience is captured in a structured Skill—a predefined set of design rules, visual constraints, and interaction standards—and provided to the coding assistant, the quality of the output can improve significantly.

To verify this, we designed a controlled comparison. The same image-slicing requirements were used to generate two versions of the tool: one with a plain prompt and one with a prompt that included a design Skill. The differences provide several reusable lessons for prompt engineering.

2. Requirements: A Practical Local Image-Slicing Tool

Defining the scope is itself an important part of prompt engineering. Instead of asking an assistant to “build an image-slicing tool,” the request should be expressed as a specification that can be tested and accepted.

Core features:

1. Upload one image by dragging and dropping it or selecting it through a file picker.
2. Choose one of three common slicing modes:
   • 3×3 grid
   • 2×2 grid
   • Three vertical slices in a 3×1 layout
3. Preview every resulting piece directly in the browser, with sequence numbers.
4. Download each piece individually or download all pieces as a ZIP archive.

Hard constraints:

• The tool is designed for full-screen desktop browser use and must run by opening a single HTML file.
• All image processing must happen locally in the browser. The tool should use Canvas for slicing and Blob objects for downloads, without uploading images to external services. This is the baseline privacy and compliance requirement.
• The page must not include unrelated decorative images, fake testimonials, fabricated statistics, or filler marketing copy. The first screen should immediately present the tool’s operation area.

This specification serves two important purposes. First, it removes ambiguity. For example, the local-processing requirement directly determines the technical approach: use the Canvas API instead of a cloud-based image-processing service. Second, the negative requirements prevent the model from automatically adding promotional placeholders or unrelated content.

3. Version One: Output from a Plain Prompt

Without providing any design Skill, we supplied the requirements above to an AI coding assistant and generated the first version, index-v1.html.

The result typically meets the functional requirements. The underlying logic is relatively straightforward: read the local file as an Image object, crop it on a canvas according to the selected row and column counts, export each piece as a Blob, use URL.createObjectURL for previews, and create the ZIP archive in browser memory with a general-purpose front-end compression library.

A simplified version of the core logic looks like this:

async function sliceImage(img, rows, cols) {
  const pieces = [];
  const w = img.width / cols, h = img.height / rows;
  for (let r = 0; r < rows; r++) {
    for (let c = 0; c < cols; c++) {
      const canvas = document.createElement('canvas');
      canvas.width = w; canvas.height = h;
      canvas.getContext('2d').drawImage(
        img, c * w, r * h, w, h, 0, 0, w, h
      );
      pieces.push(await new Promise(res =>
        canvas.toBlob(res, 'image/jpeg', 0.92)
      ));
    }
  }
  return pieces;
}

However, the usability problems become obvious:

• Rough visual design: The page uses the default system font, lacks a consistent spacing rhythm, relies on native-looking buttons, and has weak color hierarchy. It feels more like an internal debugging page than a finished tool.
• Unclear information architecture: The upload area, slicing controls, and preview section do not have a clear visual priority. Users may not know what to do first.
• Insufficient state feedback: Large images may take time to process, but there is no loading indicator. Downloads may succeed or fail without any visible feedback.
• Limited handling of edge cases: Non-square images may produce distorted-looking results, while very small images may be divided into blurry fragments.

The plain-prompt version demonstrates that the tool is functionally feasible, but it is still far from something real users would want to use regularly. This gap is precisely where a designer’s contribution has traditionally been valuable in software development.

4. Version Two: Adding a Design Skill

A design Skill is essentially a structured design specification provided to the coding assistant before code generation. A typical Skill should include four types of constraints.

1. Visual direction

The Skill defines the color system—for example, a neutral gray background with a single accent color for primary actions—as well as the type scale for page titles, section headings, and body text. It can also establish a spacing system based on fixed increments, such as multiples of 8.

These rules prevent the model from generating a visually inconsistent interface through arbitrary styling choices.

2. Layout and information architecture

The Skill should prioritize the user workflow:

Upload → Choose a slicing mode → Preview results → Download

The first screen should follow this sequence from top to bottom. The upload area should use a large dashed drop zone to encourage drag-and-drop interaction. The preview section should display the slices in a grid and place numbered badges on top of them.

3. Interaction and feedback standards

The Skill should require the following behaviors:

• Every asynchronous operation must display a loading state.
• Every clickable element must have hover and active states.
• Successful downloads must trigger a lightweight toast notification.
• Invalid uploads must show an error message instead of failing silently.

4. Engineering practices

The generated implementation should centralize styling through CSS variables, use semantic HTML structure, and include comments for important logic so that people can adjust the code manually later.

After injecting the Skill, we generated the second version, index-v2.html. The difference is immediately visible:

• The page has a clearer visual hierarchy, and the primary action is easy to identify. Users can understand where to start without learning the interface.
• The preview grid is orderly, and numbered slices match the real-world workflow of uploading images in sequence.
• Empty, loading, and error states are all represented, which makes the tool feel more reliable.
• Because the styling is centralized in CSS variables, an operations specialist can change the theme color in one place.

The improvement is also significant in terms of iteration efficiency. After generating the plain version, teams typically need several rounds of vague feedback, such as “the buttons look bad” or “the spacing feels wrong.” With the second version, the design constraints are established before generation. The first output can reach a usable quality level, allowing later iterations to focus on functional details instead of repeated visual rework.

5. Reusable Lessons and Best Practices

The results of this comparison apply well beyond an image-slicing tool.

1. A Skill moves experience earlier in the process

By default, an AI coding assistant tends to optimize for functionally correct code. A design Skill converts a designer’s judgment—visual hierarchy, spacing, feedback, and state handling—into rules the model can directly follow.

This moves much of the cost that would normally be spent on iterative refinement into the prompt-preparation stage.

2. Constraints are more effective than descriptions

A request such as “make the page look good” is difficult for a model to interpret consistently. Verifiable requirements are much more effective:

• Use multiples of 8 pixels for spacing.
• Allow only one primary button.
• Provide hover states for interactive elements.
• Include loading, error, and success feedback.

When writing a Skill, use testable requirements whenever possible instead of relying on general adjectives.

3. Structured requirements are the foundation of quality

Whether or not a design Skill is used, a clear feature list, hard constraints, and negative requirements can significantly reduce the model’s freedom to make unsuitable assumptions.

Non-functional requirements must also be explicit. For example, the privacy requirement that all processing happen locally should be stated directly in the prompt.

4. Small tools are ideal for developing Skills

A single-file, front-end-only tool with no external dependencies is fast to iterate on and easy to validate. This makes tools such as an image slicer a practical testing ground for refining a team’s design Skills and prompt templates.

Once the templates are reliable, the same approach can be extended to more complex product development tasks.

For individual developers and operations teams, the productivity benefit is concrete. Preparing a design Skill of roughly one hundred lines can help future small, temporary tools achieve near-professional quality in their first generated version. In the age of AI coding assistants, this kind of reusable design knowledge is a meaningful leverage point for individual productivity.