From harness
Use when the user says "/harness:ground", "spec this out", "what would it actually take", "ground this", "reality check this", or wants to transform a brief or idea into a technical specification grounded against the actual codebase.
npx claudepluginhub lukaleskovsek/makers-and-breakers-claude-marketplace --plugin harnessThis skill uses the workspace's default tool permissions.
<span data-proof="authored" data-by="ai:claude">Transform a brief or idea into a specification that is reality-checked against the actual codebase — data models, API patterns, jobs, and UI components. The "Codebase Reality Check" section is the differentiator.</span>
Guides Next.js Cache Components and Partial Prerendering (PPR) with cacheComponents enabled. Implements 'use cache', cacheLife(), cacheTag(), revalidateTag(), static/dynamic optimization, and cache debugging.
Migrates code, prompts, and API calls from Claude Sonnet 4.0/4.5 or Opus 4.1 to Opus 4.5, updating model strings on Anthropic, AWS, GCP, Azure platforms.
Automates semantic versioning and release workflow for Claude Code plugins: bumps versions in package.json, marketplace.json, plugin.json; verifies builds; creates git tags, GitHub releases, changelogs.
Transform a brief or idea into a specification that is reality-checked against the actual codebase — data models, API patterns, jobs, and UI components. The "Codebase Reality Check" section is the differentiator.
Check for .harness/kb/stack-profile.md. If missing, tell the user to run /harness:init first.
Load ALL KB files from .harness/kb/ for comprehensive grounding:
stack-profile.md — framework conventions, project structure
data-layer.md — tables, relationships, constraints
api-surface.md — endpoint patterns, middleware, auth
async-jobs.md — background jobs, triggers, schedules
ui-patterns.md — component patterns, state management
integrations.md — external services, SDKs
Also search the live codebase — KB files are summaries, not exhaustive. For specific questions, grep/read the actual source files.
documents/shapings/ or target_dirIf a brief exists, read it and confirm: "Grounding the brief from [date] about [topic]. Correct?"
For each aspect of the feature, systematically check:
| Question | Where to Look |
|---|---|
| What data entities exist? | data-layer.md + actual schema/model files |
| What columns/relationships? | ORM models, migration files, schema definitions |
| What jobs/async processes relate? | async-jobs.md + job definition files |
| What API endpoints exist? | api-surface.md + route/controller files |
| What middleware/auth pattern? | api-surface.md + middleware source files |
| What UI components exist? | ui-patterns.md + actual component directories |
| What integrations are relevant? | integrations.md + SDK/client source files |
Structure:
Summary — One paragraph: what this builds and why
Codebase Reality Check
What exists and can be reused (with file paths)
What conflicts with existing patterns
What's completely new
Data Model Changes
New tables/collections/models
Column additions to existing tables
New relationships, indexes, constraints
Migration plan
API Changes
New endpoints following existing conventions
Modified handlers
Auth requirements
UI Changes
New components/pages
Modified existing components
Which existing patterns to follow
Async/Job Changes
New jobs or triggers
Modified schedules
Event handling changes
Integration Changes
New external service connections
Modified existing integrations
Implementation Order
Ordered phases with dependencies
What can be parallelized
Test Scenarios
Happy paths
Edge cases
Error paths
Save to {target_dir}/spec-{slug}-{date}.md with frontmatter:
---
title: "{spec title}"
type: spec
date: {ISO date}
tags: [{relevant}, {tags}]
source-brief: "{brief filename if applicable}"
next-skill: design
---
Also store via MCP: call harness_add_skillflow_step with skill_type: "ground".
Every claim about "what exists" must include a file path
Never propose a pattern that conflicts with existing conventions without flagging the conflict
If the spec requires changes to shared code, call it out explicitly with impact analysis
Migration plans should be safe — backward compatible where possible