wtf.steer-tech
Steer Tech
Generate or refine docs/steering/TECH.md — the technical guidelines document. This document is the canonical reference for the stack, architectural patterns, and constraints every implementer must follow.
The shared steering-doc flow (exists-check → research → interview → draft → review → write → wiki sync → continue) lives in ../references/steering-doc-process.md. Follow that process with the skill-specific inputs below.
- Doc path:
docs/steering/TECH.md - Template:
references/tech-template.md - Display name / wiki page:
WTF-Tech.md - Commit message:
docs: add technical guidelines steering document
Step 2 — Research checklist
Use the Agent tool to extract technical facts directly. Do not ask the user for things that can be read:
- Stack:
package.json,pyproject.toml,go.mod,Cargo.toml,*.csproj, or equivalent — languages, frameworks, versions - Architecture: module structure, folder layout, layer separation patterns
- Test framework: existing test files, test scripts in
package.json - Commands:
package.jsonscripts,Makefile,justfile, CI config - ADRs: any
docs/adr/,docs/decisions/, or inline decision records - Conventions: naming patterns, import paths, test file locations
CLAUDE.mdand any existing architectural docs
Produce a concrete draft of Stack, Commands, and Code Conventions from research alone — these sections should require no user input.
Step 3 — Gap-topic list
Apply ../references/questioning-style.md for questions in this step. Ask only about items research could not determine:
- Key constraints — "Are there non-negotiables every implementer must respect?" Pre-fill with constraints from
CLAUDE.mdor existing docs. - Architecture decisions — "Are there decisions that shaped the architecture but aren't documented yet?" Pre-fill with patterns inferred from the codebase structure.
- Known pain points — "Are there areas of the codebase that need special care?" Pre-fill with anything flagged in README or comments.
Step 4 — Writing rules
- Commands must be exact and tested — stale commands are worse than no commands.
- Architecture description reflects what the codebase actually does, not aspirations.
- Constraints are written as imperatives ("No synchronous I/O on the request path").
- ADRs link to source files where they exist; inline only the decision and rationale.
Step 8 — Continue options
{label: "Create DESIGN.md", description: "Run wtf.steer-design to document the design guidelines"}{label: "Create QA.md", description: "Run wtf.steer-qa to document the QA standards"}{label: "Create VISION.md", description: "Run wtf.steer-vision to document the product vision"}{label: "Stop here", description: "Exit — no further action"}
More from xiduzo/wtf
wtf.write-feature
This skill should be used when a user wants to create a GitHub Feature issue, break down an Epic into user-facing capabilities, write user stories in domain language, or capture what a domain actor can do — for example "create a feature", "write a feature for this epic", "add a feature to an epic", "break this epic into features", "write user stories for this feature", or "describe what this actor can do". Use this skill to write a single Feature; use `wtf.epic-to-features` to generate the full set of Features for an Epic at once. Not applicable to Tasks, Epics, or bug reports.
38wtf.write-task
This skill should be used when a user wants to create a task, write a ticket, decompose a feature into implementable work, break down a story, define a vertical slice for development, or write Gherkin scenarios — for example "create a task", "write a task for this feature", "break this feature into tasks", "define implementation work", or "add a sub-issue to this feature". Guides creation of a GitHub Task issue linked to a parent Feature and Epic, derives Gherkin acceptance scenarios from the Feature's ACs, enforces DDD ubiquitous language in scenarios, and checks for vertical-slice integrity and task dependencies.
38wtf.write-epic
This skill should be used when a user wants to create, draft, or plan a GitHub Epic issue — for example "write an epic", "I want to define a new initiative", "scope out this strategic project", "turn this idea into an epic", "plan work that spans multiple features", or "start from a bounded context". Also use when the user asks to define domain outcomes, capture a large initiative before breaking it into features, or describe work in terms of business goals rather than technical tasks.
38wtf.steer-design
This skill should be used when a team wants to create or refine the design guidelines document — for example "create the design steering doc", "document our design system", "write the design principles", "document our component patterns", "set up the design guidelines", or "update the design doc". Generates docs/steering/DESIGN.md as a living document capturing design principles, the design system, tokens, component patterns, and accessibility standards. Generated once and refined — not regenerated from scratch.
37wtf.reflect
This skill should be used when a developer wants to capture learnings from a difficult session, record what Claude got wrong, save implementation gotchas, or update the steering docs with hard-won knowledge — for example "let's reflect", "capture what we learned", "that was painful, save this", "update the steering docs with what went wrong", "I need to debrief", "what went wrong today", "log this lesson", "save this gotcha", "document this mistake", "I want to write this down before I forget", "add this to the steering docs", or when prompted by the intervention tracker after multiple corrections. Routes each learning into the right steering doc (TECH, QA, DESIGN, or VISION) under a "Hard-Won Lessons" section.
37wtf.steer-tech
This skill should be used when a team wants to create or refine the technical guidelines document — for example "create the tech steering doc", "document our tech stack", "write the technical guidelines", "document our architecture decisions", "set up the tech steering", or "update the tech doc". Generates docs/steering/TECH.md as a living document capturing the stack, architecture patterns, constraints, commands, and ADRs. Generated once and refined — not regenerated from scratch.
36