@hatchway/cli 0.50.55 → 0.50.57
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/README.md +2 -2
- package/dist/index.js +289 -758
- package/dist/index.js.map +1 -1
- package/dist/instrument.js +1 -0
- package/dist/instrument.js.map +1 -1
- package/dist/lib/skills/platform-plugin/.claude-plugin/plugin.json +5 -0
- package/dist/lib/skills/platform-plugin/skills/architectural-thinking/SKILL.md +36 -0
- package/dist/lib/skills/platform-plugin/skills/build-verification/SKILL.md +54 -0
- package/dist/lib/skills/platform-plugin/skills/communication-style/SKILL.md +28 -0
- package/dist/lib/skills/platform-plugin/skills/context-awareness/SKILL.md +36 -0
- package/dist/lib/skills/platform-plugin/skills/dependency-management/SKILL.md +41 -0
- package/dist/lib/skills/platform-plugin/skills/design-excellence/SKILL.md +35 -0
- package/dist/lib/skills/platform-plugin/skills/template-originality/SKILL.md +34 -0
- package/dist/lib/skills/platform-plugin/skills/todo-workflow/SKILL.md +44 -0
- package/dist/lib/skills/platform-plugin/skills/todo-workflow-codex/SKILL.md +53 -0
- package/package.json +5 -5
package/dist/instrument.js
CHANGED
|
@@ -20,6 +20,7 @@ Sentry.init({
|
|
|
20
20
|
// eslint-disable-next-line @typescript-eslint/no-explicit-any
|
|
21
21
|
integrations: integrations,
|
|
22
22
|
tracesSampleRate: 1.0,
|
|
23
|
+
enableLogs: true,
|
|
23
24
|
debug: false,
|
|
24
25
|
sendDefaultPii: false,
|
|
25
26
|
// Configure trace propagation (Runner → Broker communication)
|
package/dist/instrument.js.map
CHANGED
|
@@ -1 +1 @@
|
|
|
1
|
-
{"version":3,"file":"instrument.js","sources":["../src/instrument.ts"],"sourcesContent":["import * as Sentry from \"@sentry/node\";\n\n// Debug logging for instrumentation (enabled via DEBUG_SENTRY=1)\nconst debugSentry = process.env.DEBUG_SENTRY === '1';\nconst log = (msg: string) => debugSentry && console.log(`[sentry-instrument] ${msg}`);\n\n// Build integrations array\nconst integrations: unknown[] = [];\n\n// Add http integration for request tracing\nif (typeof Sentry.httpIntegration === \"function\") {\n integrations.push(Sentry.httpIntegration());\n log('Added httpIntegration');\n}\n\nlog(`Total integrations configured: ${integrations.length}`);\n\nSentry.init({\n dsn: process.env.SENTRY_DSN,\n // eslint-disable-next-line @typescript-eslint/no-explicit-any\n integrations: integrations as any[],\n tracesSampleRate: 1.0,\n debug: false,\n sendDefaultPii: false,\n // Configure trace propagation (Runner → Broker communication)\n tracePropagationTargets: [\n // Local development\n \"localhost\",\n \"localhost:3000\",\n \"localhost:4000\",\n /^https?:\\/\\/localhost:\\d+$/,\n\n // Production domains\n \"hatchway.sh\",\n \"hatchway.app\",\n \"hatchway.up.railway.app\",\n \"broker.hatchway.sh\",\n \"broker.hatchway.app\",\n \"broker.up.railway.app\",\n\n // Wildcard patterns for Railway\n /^https?:\\/\\/.*\\.railway\\.app/, // Railway deployments\n /^https?:\\/\\/.*\\.up\\.railway\\.app/, // Railway preview deployments\n /^https?:\\/\\/.*\\.hatchway\\.app/, // Custom domain subdomains\n ],\n});\n"],"names":[],"mappings":";;;;;;AAEA;AACA,MAAM,WAAW,GAAG,OAAO,CAAC,GAAG,CAAC,YAAY,KAAK,GAAG;AACpD,MAAM,GAAG,GAAG,CAAC,GAAW,KAAK,WAAW,IAAI,OAAO,CAAC,GAAG,CAAC,uBAAuB,GAAG,CAAA,CAAE,CAAC;AAErF;AACA,MAAM,YAAY,GAAc,EAAE;AAElC;AACA,IAAI,OAAO,MAAM,CAAC,eAAe,KAAK,UAAU,EAAE;IAChD,YAAY,CAAC,IAAI,CAAC,MAAM,CAAC,eAAe,EAAE,CAAC;IAC3C,GAAG,CAAC,uBAAuB,CAAC;AAC9B;AAEA,GAAG,CAAC,CAAA,+BAAA,EAAkC,YAAY,CAAC,MAAM,CAAA,CAAE,CAAC;AAE5D,MAAM,CAAC,IAAI,CAAC;AACV,IAAA,GAAG,EAAE,OAAO,CAAC,GAAG,CAAC,UAAU;;AAE3B,IAAA,YAAY,EAAE,YAAqB;AACnC,IAAA,gBAAgB,EAAE,GAAG;AACrB,IAAA,KAAK,EAAE,KAAK;AACZ,IAAA,cAAc,EAAE,KAAK;;AAErB,IAAA,uBAAuB,EAAE;;QAEvB,WAAW;QACX,gBAAgB;QAChB,gBAAgB;QAChB,4BAA4B;;QAG5B,aAAa;QACb,cAAc;QACd,yBAAyB;QACzB,oBAAoB;QACpB,qBAAqB;QACrB,uBAAuB;;AAGvB,QAAA,8BAA8B;AAC9B,QAAA,kCAAkC;AAClC,QAAA,+BAA+B;AAChC,KAAA;AACF,CAAA,CAAC"}
|
|
1
|
+
{"version":3,"file":"instrument.js","sources":["../src/instrument.ts"],"sourcesContent":["import * as Sentry from \"@sentry/node\";\n\n// Debug logging for instrumentation (enabled via DEBUG_SENTRY=1)\nconst debugSentry = process.env.DEBUG_SENTRY === '1';\nconst log = (msg: string) => debugSentry && console.log(`[sentry-instrument] ${msg}`);\n\n// Build integrations array\nconst integrations: unknown[] = [];\n\n// Add http integration for request tracing\nif (typeof Sentry.httpIntegration === \"function\") {\n integrations.push(Sentry.httpIntegration());\n log('Added httpIntegration');\n}\n\nlog(`Total integrations configured: ${integrations.length}`);\n\nSentry.init({\n dsn: process.env.SENTRY_DSN,\n // eslint-disable-next-line @typescript-eslint/no-explicit-any\n integrations: integrations as any[],\n tracesSampleRate: 1.0,\n enableLogs: true,\n debug: false,\n sendDefaultPii: false,\n // Configure trace propagation (Runner → Broker communication)\n tracePropagationTargets: [\n // Local development\n \"localhost\",\n \"localhost:3000\",\n \"localhost:4000\",\n /^https?:\\/\\/localhost:\\d+$/,\n\n // Production domains\n \"hatchway.sh\",\n \"hatchway.app\",\n \"hatchway.up.railway.app\",\n \"broker.hatchway.sh\",\n \"broker.hatchway.app\",\n \"broker.up.railway.app\",\n\n // Wildcard patterns for Railway\n /^https?:\\/\\/.*\\.railway\\.app/, // Railway deployments\n /^https?:\\/\\/.*\\.up\\.railway\\.app/, // Railway preview deployments\n /^https?:\\/\\/.*\\.hatchway\\.app/, // Custom domain subdomains\n ],\n});\n"],"names":[],"mappings":";;;;;;AAEA;AACA,MAAM,WAAW,GAAG,OAAO,CAAC,GAAG,CAAC,YAAY,KAAK,GAAG;AACpD,MAAM,GAAG,GAAG,CAAC,GAAW,KAAK,WAAW,IAAI,OAAO,CAAC,GAAG,CAAC,uBAAuB,GAAG,CAAA,CAAE,CAAC;AAErF;AACA,MAAM,YAAY,GAAc,EAAE;AAElC;AACA,IAAI,OAAO,MAAM,CAAC,eAAe,KAAK,UAAU,EAAE;IAChD,YAAY,CAAC,IAAI,CAAC,MAAM,CAAC,eAAe,EAAE,CAAC;IAC3C,GAAG,CAAC,uBAAuB,CAAC;AAC9B;AAEA,GAAG,CAAC,CAAA,+BAAA,EAAkC,YAAY,CAAC,MAAM,CAAA,CAAE,CAAC;AAE5D,MAAM,CAAC,IAAI,CAAC;AACV,IAAA,GAAG,EAAE,OAAO,CAAC,GAAG,CAAC,UAAU;;AAE3B,IAAA,YAAY,EAAE,YAAqB;AACnC,IAAA,gBAAgB,EAAE,GAAG;AACrB,IAAA,UAAU,EAAE,IAAI;AAChB,IAAA,KAAK,EAAE,KAAK;AACZ,IAAA,cAAc,EAAE,KAAK;;AAErB,IAAA,uBAAuB,EAAE;;QAEvB,WAAW;QACX,gBAAgB;QAChB,gBAAgB;QAChB,4BAA4B;;QAG5B,aAAa;QACb,cAAc;QACd,yBAAyB;QACzB,oBAAoB;QACpB,qBAAqB;QACrB,uBAAuB;;AAGvB,QAAA,8BAA8B;AAC9B,QAAA,kCAAkC;AAClC,QAAA,+BAA+B;AAChC,KAAA;AACF,CAAA,CAAC"}
|
|
@@ -0,0 +1,5 @@
|
|
|
1
|
+
{
|
|
2
|
+
"name": "hatchway-platform",
|
|
3
|
+
"version": "2.0.0",
|
|
4
|
+
"description": "Hatchway platform skills for building production-ready applications. Provides procedural knowledge for task tracking, communication style, dependency management, design excellence, build verification, context awareness, and architectural thinking."
|
|
5
|
+
}
|
|
@@ -0,0 +1,36 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: architectural-thinking
|
|
3
|
+
description: "Pre-planning procedure for new tasks. Visualize end state, identify structure, and anticipate problems before coding. Use when starting a new feature, scaffolding a project, or planning a multi-file change."
|
|
4
|
+
user-invocable: false
|
|
5
|
+
---
|
|
6
|
+
|
|
7
|
+
# Architectural Thinking
|
|
8
|
+
|
|
9
|
+
Spend 30 seconds thinking before writing code. Plan the shape of the solution first.
|
|
10
|
+
|
|
11
|
+
## Before Creating Your Todo List
|
|
12
|
+
|
|
13
|
+
1. **Visualize the end state** -- What files will exist? What's the component hierarchy? How does data flow?
|
|
14
|
+
2. **Anticipate problems** -- What could break? (types, imports, circular dependencies) Are there conflicting patterns in the codebase?
|
|
15
|
+
3. **Design the experience** -- What's the visual identity? What makes this feel polished rather than generic?
|
|
16
|
+
4. **Order the work** -- Create todos in dependency order. Group related changes. Put configuration and setup first.
|
|
17
|
+
|
|
18
|
+
## Example
|
|
19
|
+
|
|
20
|
+
Task: "Build a product catalog with filtering"
|
|
21
|
+
|
|
22
|
+
Think first:
|
|
23
|
+
```
|
|
24
|
+
Files needed: ProductCard, ProductGrid, FilterSidebar, useProducts hook, types.ts
|
|
25
|
+
Data flow: useProducts fetches → FilterSidebar updates query → ProductGrid re-renders
|
|
26
|
+
Risk: Filter state and URL sync could cause re-render loops
|
|
27
|
+
Order: types → hook → ProductCard → ProductGrid → FilterSidebar → integration
|
|
28
|
+
```
|
|
29
|
+
|
|
30
|
+
Then create the todo list and execute confidently.
|
|
31
|
+
|
|
32
|
+
## Avoid
|
|
33
|
+
|
|
34
|
+
- Jumping straight into coding without understanding the full scope
|
|
35
|
+
- Creating files in random order, discovering missing dependencies mid-build
|
|
36
|
+
- Designing components in isolation without thinking about how they compose
|
|
@@ -0,0 +1,54 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: build-verification
|
|
3
|
+
description: "Fix-verify iteration loop for dependency, build, and runtime errors. Use when installing packages, running dev servers, fixing build errors, or verifying that code compiles and runs."
|
|
4
|
+
user-invocable: false
|
|
5
|
+
---
|
|
6
|
+
|
|
7
|
+
# Build Verification
|
|
8
|
+
|
|
9
|
+
Every code change must be verified. Never declare success without seeing clean output.
|
|
10
|
+
|
|
11
|
+
## The Loop
|
|
12
|
+
|
|
13
|
+
```
|
|
14
|
+
1. Make a fix
|
|
15
|
+
2. Run the build or dev server
|
|
16
|
+
3. Read the output
|
|
17
|
+
4. If errors remain → go to 1
|
|
18
|
+
5. If clean → move on
|
|
19
|
+
```
|
|
20
|
+
|
|
21
|
+
## Dependency Failures
|
|
22
|
+
|
|
23
|
+
Read the full error. Fix package.json (version conflicts, missing peers). Re-run install. Verify before writing any source code.
|
|
24
|
+
|
|
25
|
+
## Build / TypeScript Errors
|
|
26
|
+
|
|
27
|
+
Fix errors top-to-bottom (earlier errors often cause later ones). Re-run after each fix. Target zero warnings.
|
|
28
|
+
|
|
29
|
+
## Dev Server Verification
|
|
30
|
+
|
|
31
|
+
Start the dev server once at the end for final verification. Check for:
|
|
32
|
+
- "compiled successfully" or "ready in X ms"
|
|
33
|
+
- No red error text or stack traces
|
|
34
|
+
- Correct port binding
|
|
35
|
+
|
|
36
|
+
Stop the server after verification -- do not leave it running.
|
|
37
|
+
|
|
38
|
+
## Example
|
|
39
|
+
|
|
40
|
+
```
|
|
41
|
+
$ npm run build
|
|
42
|
+
Error: Cannot find module './utils/helpers'
|
|
43
|
+
|
|
44
|
+
→ Read imports, discover file was moved to lib/helpers.ts
|
|
45
|
+
→ Update import path
|
|
46
|
+
→ Re-run npm run build
|
|
47
|
+
→ "compiled successfully" ✓
|
|
48
|
+
```
|
|
49
|
+
|
|
50
|
+
## Never
|
|
51
|
+
|
|
52
|
+
- Declare "fixed" without running verification
|
|
53
|
+
- Skip re-running after a change
|
|
54
|
+
- Leave a failing dev server and move on
|
|
@@ -0,0 +1,28 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: communication-style
|
|
3
|
+
description: "Concise output formatting for the Hatchway platform UI. Use when generating any response during task execution."
|
|
4
|
+
user-invocable: false
|
|
5
|
+
---
|
|
6
|
+
|
|
7
|
+
# Communication Style
|
|
8
|
+
|
|
9
|
+
Keep output minimal so the Hatchway UI stays clean and scannable.
|
|
10
|
+
|
|
11
|
+
## During Execution
|
|
12
|
+
|
|
13
|
+
- Work silently -- no narration of what you're about to do
|
|
14
|
+
- After completing each task, write ONE short summary sentence
|
|
15
|
+
|
|
16
|
+
## On Completion
|
|
17
|
+
|
|
18
|
+
- Provide a 2-3 sentence summary of everything that was done
|
|
19
|
+
- Format all responses in Markdown
|
|
20
|
+
|
|
21
|
+
## Example
|
|
22
|
+
|
|
23
|
+
Bad (verbose):
|
|
24
|
+
> I'm going to start by reading the package.json to understand the dependencies.
|
|
25
|
+
> Now I'll install the missing packages. Let me check if tailwind is configured...
|
|
26
|
+
|
|
27
|
+
Good (concise):
|
|
28
|
+
> Added Tailwind CSS with the brand color palette and updated all components to use utility classes.
|
|
@@ -0,0 +1,36 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: context-awareness
|
|
3
|
+
description: "Read-before-write discipline. Search for patterns and understand existing code before modifying files. Use when editing existing files, adding features to an existing codebase, or creating new components."
|
|
4
|
+
user-invocable: false
|
|
5
|
+
---
|
|
6
|
+
|
|
7
|
+
# Context Awareness
|
|
8
|
+
|
|
9
|
+
Understand the codebase before changing it. Read first, write second.
|
|
10
|
+
|
|
11
|
+
## Before Modifying Any File
|
|
12
|
+
|
|
13
|
+
1. **Search** -- Use Grep to find similar patterns (naming conventions, import style, component structure)
|
|
14
|
+
2. **Read** -- Open related files to understand data flow and dependencies
|
|
15
|
+
3. **Assess** -- Will this change break imports elsewhere? Is there an existing utility to reuse?
|
|
16
|
+
4. **Change** -- Make targeted edits that match existing code style
|
|
17
|
+
|
|
18
|
+
## Example
|
|
19
|
+
|
|
20
|
+
Task: "Add a user avatar component"
|
|
21
|
+
|
|
22
|
+
Before creating `UserAvatar.tsx`:
|
|
23
|
+
```
|
|
24
|
+
Grep: "Avatar" → find existing avatar usage
|
|
25
|
+
Grep: "component" in src/components/ → see naming pattern (PascalCase folders? flat files?)
|
|
26
|
+
Read: src/components/Button.tsx → see how components are structured (props interface, export style)
|
|
27
|
+
Read: src/lib/utils.ts → check for existing image/URL helpers
|
|
28
|
+
```
|
|
29
|
+
|
|
30
|
+
Then create `UserAvatar.tsx` matching the patterns found.
|
|
31
|
+
|
|
32
|
+
## Never
|
|
33
|
+
|
|
34
|
+
- Blindly modify files without reading surrounding context
|
|
35
|
+
- Create a new utility when one already exists in the codebase
|
|
36
|
+
- Ignore the project's established patterns in favor of your own preferences
|
|
@@ -0,0 +1,41 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: dependency-management
|
|
3
|
+
description: "Install all project dependencies upfront in a single operation. Use when starting a new feature, scaffolding a project, or when any npm/pnpm package installation is needed."
|
|
4
|
+
user-invocable: false
|
|
5
|
+
---
|
|
6
|
+
|
|
7
|
+
# Dependency Management
|
|
8
|
+
|
|
9
|
+
Identify every package the feature needs before writing source code. Install once, then build.
|
|
10
|
+
|
|
11
|
+
## Workflow
|
|
12
|
+
|
|
13
|
+
1. Read the requirements and identify ALL needed packages
|
|
14
|
+
2. Add them all to package.json in one edit
|
|
15
|
+
3. Run install once (`pnpm install` or `npm install`)
|
|
16
|
+
4. Begin writing source code
|
|
17
|
+
|
|
18
|
+
## Example
|
|
19
|
+
|
|
20
|
+
Task: "Add a chart dashboard with date filtering"
|
|
21
|
+
|
|
22
|
+
Identify upfront: recharts, date-fns, @types/recharts
|
|
23
|
+
|
|
24
|
+
```json
|
|
25
|
+
// One package.json edit with all three
|
|
26
|
+
"dependencies": {
|
|
27
|
+
"recharts": "^2.12.0",
|
|
28
|
+
"date-fns": "^3.6.0"
|
|
29
|
+
},
|
|
30
|
+
"devDependencies": {
|
|
31
|
+
"@types/recharts": "^2.0.0"
|
|
32
|
+
}
|
|
33
|
+
```
|
|
34
|
+
|
|
35
|
+
Then one `npm install`, then start coding.
|
|
36
|
+
|
|
37
|
+
## Avoid
|
|
38
|
+
|
|
39
|
+
- Writing code, discovering a missing import, installing, repeat
|
|
40
|
+
- Running multiple install commands throughout the build
|
|
41
|
+
- Installing packages one at a time as you discover them
|
|
@@ -0,0 +1,35 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: design-excellence
|
|
3
|
+
description: "Visual design thinking for production-ready UI. Use when building new pages, components, or styling any user-facing interface."
|
|
4
|
+
user-invocable: false
|
|
5
|
+
---
|
|
6
|
+
|
|
7
|
+
# Design Excellence
|
|
8
|
+
|
|
9
|
+
Before writing CSS or choosing colors, decide on a clear aesthetic direction and commit to it.
|
|
10
|
+
|
|
11
|
+
## Design Thinking
|
|
12
|
+
|
|
13
|
+
- **Purpose**: What problem does this interface solve? Who uses it?
|
|
14
|
+
- **Tone**: Pick a direction -- minimal, bold, editorial, playful, luxury, brutalist, organic. Commit fully.
|
|
15
|
+
- **Differentiation**: What makes this memorable? What's the one thing a user will notice?
|
|
16
|
+
|
|
17
|
+
## Principles
|
|
18
|
+
|
|
19
|
+
- **Color discipline**: Pick a small, intentional palette (primary + neutrals + accent). Define as CSS custom properties. Dominant colors with sharp accents outperform timid, evenly-distributed palettes.
|
|
20
|
+
- **Typography hierarchy**: Pair a distinctive heading font with a readable body font. Use weight and size to create clear visual hierarchy.
|
|
21
|
+
- **Spatial composition**: Use an 8pt spacing system. Be generous with whitespace. Consider asymmetry and grid-breaking elements where appropriate.
|
|
22
|
+
- **Motion**: Focus on high-impact moments (page load reveals, hover states) rather than scattered micro-interactions. Keep transitions 200-300ms.
|
|
23
|
+
- **Accessibility**: Semantic HTML, 4.5:1 contrast ratio, keyboard navigation, 44px touch targets.
|
|
24
|
+
|
|
25
|
+
## Mobile First
|
|
26
|
+
|
|
27
|
+
Design for 375px, then enhance for 768px and 1440px. Use CSS Grid/Flexbox for fluid layouts. Cap content width at 1200-1440px.
|
|
28
|
+
|
|
29
|
+
## Avoid
|
|
30
|
+
|
|
31
|
+
- Generic AI aesthetics (purple gradients on white, Inter/Roboto defaults, cookie-cutter card layouts)
|
|
32
|
+
- Decorative filler with no purpose (random gradient circles, blurry blobs, geometric noise)
|
|
33
|
+
- Copying the template's visual identity -- create something original
|
|
34
|
+
|
|
35
|
+
Every interface should feel intentionally designed for its specific context.
|
|
@@ -0,0 +1,34 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: template-originality
|
|
3
|
+
description: "Replace template scaffolding with original design. Use ONLY when building a new project from a template scaffold, not when editing existing projects."
|
|
4
|
+
user-invocable: false
|
|
5
|
+
---
|
|
6
|
+
|
|
7
|
+
# Template Originality
|
|
8
|
+
|
|
9
|
+
The template is a scaffold -- it provides structure, build tooling, and routing. Its visual design is disposable.
|
|
10
|
+
|
|
11
|
+
## What to Replace
|
|
12
|
+
|
|
13
|
+
- Delete or completely rewrite template example components (hero sections, sample cards, "Welcome to X" pages)
|
|
14
|
+
- Replace the template's color scheme and typography with choices specific to this app
|
|
15
|
+
- Design layouts that serve this app's actual content, not the template's demo content
|
|
16
|
+
|
|
17
|
+
## How to Think About It
|
|
18
|
+
|
|
19
|
+
- What is this app's personality? (playful, serious, minimal, bold)
|
|
20
|
+
- What colors represent this specific brand or purpose?
|
|
21
|
+
- What layout structure serves these specific features?
|
|
22
|
+
|
|
23
|
+
## Example
|
|
24
|
+
|
|
25
|
+
Template ships with: purple gradient hero, 3-column feature cards, "About" and "Features" pages.
|
|
26
|
+
|
|
27
|
+
For a recipe app: Warm earth-tone palette, editorial food photography layout, ingredient-focused navigation, full-bleed recipe cards. Nothing from the template survives visually.
|
|
28
|
+
|
|
29
|
+
## Avoid
|
|
30
|
+
|
|
31
|
+
- Keeping template hero sections with just the text swapped
|
|
32
|
+
- Reusing the template's default color scheme (especially purple/indigo)
|
|
33
|
+
- Copying template navigation structure when the app needs something different
|
|
34
|
+
- Leaving template example pages like "About" or "Features" with placeholder content
|
|
@@ -0,0 +1,44 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: todo-workflow
|
|
3
|
+
description: "Step-by-step task tracking using the TodoWrite tool. Use when executing any multi-step task, follow-up request, or build workflow."
|
|
4
|
+
user-invocable: false
|
|
5
|
+
---
|
|
6
|
+
|
|
7
|
+
# Todo Workflow
|
|
8
|
+
|
|
9
|
+
The Hatchway UI tracks progress via TodoWrite. Without it, users see nothing happening.
|
|
10
|
+
|
|
11
|
+
## Workflow
|
|
12
|
+
|
|
13
|
+
For each todo:
|
|
14
|
+
|
|
15
|
+
1. Mark it `in_progress` via TodoWrite
|
|
16
|
+
2. Do the work
|
|
17
|
+
3. Mark it `completed` via TodoWrite
|
|
18
|
+
4. Write one sentence about what you did
|
|
19
|
+
5. Move to the next todo
|
|
20
|
+
|
|
21
|
+
Update after every single todo -- never batch multiple completions into one call.
|
|
22
|
+
|
|
23
|
+
## Follow-ups
|
|
24
|
+
|
|
25
|
+
Even simple follow-up requests get at least one todo. Create it, mark in_progress, do the work, mark completed.
|
|
26
|
+
|
|
27
|
+
## Example
|
|
28
|
+
|
|
29
|
+
Task: "Add a dark mode toggle"
|
|
30
|
+
|
|
31
|
+
```
|
|
32
|
+
TodoWrite → [{content: "Add theme context provider", status: "in_progress"}, ...]
|
|
33
|
+
→ Create ThemeContext.tsx
|
|
34
|
+
TodoWrite → [{content: "Add theme context provider", status: "completed"}, ...]
|
|
35
|
+
Added ThemeProvider with light/dark state and localStorage persistence.
|
|
36
|
+
TodoWrite → [{content: "Add toggle component to header", status: "in_progress"}, ...]
|
|
37
|
+
→ Create DarkModeToggle.tsx, add to Header
|
|
38
|
+
TodoWrite → [{content: "Add toggle component to header", status: "completed"}, ...]
|
|
39
|
+
Added moon/sun icon toggle to the header nav bar.
|
|
40
|
+
```
|
|
41
|
+
|
|
42
|
+
## Autonomous Execution
|
|
43
|
+
|
|
44
|
+
Keep working until 100% complete. Do not pause to ask "Should I continue?" unless you need information only the user can provide or encounter an unrecoverable error.
|
|
@@ -0,0 +1,53 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: todo-workflow-codex
|
|
3
|
+
description: "Task tracking via inline JSON code blocks for the Codex agent. Use when executing any multi-step task or build workflow."
|
|
4
|
+
user-invocable: false
|
|
5
|
+
---
|
|
6
|
+
|
|
7
|
+
# Task Tracking via JSON Code Blocks
|
|
8
|
+
|
|
9
|
+
Track progress by including JSON code blocks in your responses. The system extracts them automatically.
|
|
10
|
+
|
|
11
|
+
## Format
|
|
12
|
+
|
|
13
|
+
```json
|
|
14
|
+
{"todos":[
|
|
15
|
+
{"content":"Task description","status":"completed","activeForm":"Past tense"},
|
|
16
|
+
{"content":"Current task","status":"in_progress","activeForm":"Present continuous"},
|
|
17
|
+
{"content":"Future task","status":"pending","activeForm":"Will do"}
|
|
18
|
+
]}
|
|
19
|
+
```
|
|
20
|
+
|
|
21
|
+
## When to Include
|
|
22
|
+
|
|
23
|
+
- At the start: initial task breakdown
|
|
24
|
+
- After each major step: updated statuses
|
|
25
|
+
- At the end: all tasks completed
|
|
26
|
+
|
|
27
|
+
## Example
|
|
28
|
+
|
|
29
|
+
Task: "Add a contact form"
|
|
30
|
+
|
|
31
|
+
Response 1:
|
|
32
|
+
```json
|
|
33
|
+
{"todos":[
|
|
34
|
+
{"content":"Create form component with validation","status":"in_progress","activeForm":"Creating form component"},
|
|
35
|
+
{"content":"Add API route for form submission","status":"pending","activeForm":"Will add API route"},
|
|
36
|
+
{"content":"Style form with project design system","status":"pending","activeForm":"Will style form"}
|
|
37
|
+
]}
|
|
38
|
+
```
|
|
39
|
+
|
|
40
|
+
Response 2 (after completing form):
|
|
41
|
+
```json
|
|
42
|
+
{"todos":[
|
|
43
|
+
{"content":"Create form component with validation","status":"completed","activeForm":"Created form component"},
|
|
44
|
+
{"content":"Add API route for form submission","status":"in_progress","activeForm":"Adding API route"},
|
|
45
|
+
{"content":"Style form with project design system","status":"pending","activeForm":"Will style form"}
|
|
46
|
+
]}
|
|
47
|
+
```
|
|
48
|
+
|
|
49
|
+
This is NOT a tool call -- simply include the JSON block in your message text.
|
|
50
|
+
|
|
51
|
+
## Autonomous Execution
|
|
52
|
+
|
|
53
|
+
Keep working until 100% complete. Do not pause to ask "Should I continue?" unless you need information only the user can provide or encounter an unrecoverable error.
|
package/package.json
CHANGED
|
@@ -1,6 +1,6 @@
|
|
|
1
1
|
{
|
|
2
2
|
"name": "@hatchway/cli",
|
|
3
|
-
"version": "0.50.
|
|
3
|
+
"version": "0.50.57",
|
|
4
4
|
"description": "Hatchway CLI - Build AI-powered apps with Claude. Just run: npx @hatchway/cli runner",
|
|
5
5
|
"private": false,
|
|
6
6
|
"type": "module",
|
|
@@ -41,15 +41,15 @@
|
|
|
41
41
|
"homepage": "https://github.com/codyde/hatchway#readme",
|
|
42
42
|
"preferGlobal": true,
|
|
43
43
|
"scripts": {
|
|
44
|
-
"dev": "RUNNER_WS_URL=ws://localhost:3000/ws/runner tsx --import ./src/instrument.ts src/index.ts",
|
|
44
|
+
"dev": "RUNNER_WS_URL=ws://localhost:3000/ws/runner RUNNER_SHARED_SECRET=${RUNNER_SHARED_SECRET:-dev-secret} tsx --import ./src/instrument.ts src/index.ts",
|
|
45
45
|
"dev:cli": "tsx --import ./src/instrument.ts src/cli/index.ts",
|
|
46
|
-
"build": "rollup -c && cp templates.json dist/",
|
|
46
|
+
"build": "rollup -c && cp templates.json dist/ && rm -rf dist/lib/skills/platform-plugin && mkdir -p dist/lib/skills && cp -R src/lib/skills/platform-plugin dist/lib/skills/platform-plugin",
|
|
47
47
|
"build:tsc": "tsc -p tsconfig.json",
|
|
48
|
-
"start": "RUNNER_WS_URL=ws://localhost:3000/ws/runner node --import ./dist/instrument.js dist/index.js",
|
|
48
|
+
"start": "RUNNER_WS_URL=ws://localhost:3000/ws/runner RUNNER_SHARED_SECRET=${RUNNER_SHARED_SECRET:-dev-secret} node --import ./dist/instrument.js dist/index.js",
|
|
49
49
|
"cli": "node --import ./dist/instrument.js dist/cli/index.js"
|
|
50
50
|
},
|
|
51
51
|
"dependencies": {
|
|
52
|
-
"@anthropic-ai/claude-agent-sdk": "^0.2.
|
|
52
|
+
"@anthropic-ai/claude-agent-sdk": "^0.2.45",
|
|
53
53
|
"@hatchway/droid-sdk": "^1.0.0",
|
|
54
54
|
"@clack/prompts": "^0.11.0",
|
|
55
55
|
"@openai/codex-sdk": "^0.93.0",
|