SuperAPI AI Directory
Partner中文AI newsFavorites
Skillswtf.steer-tech

wtf.steer-tech

Writing & research

View repository

Updated 10-16 02:07

About this skill

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. Do not ask the user for things you can 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.json scripts, Makefile, justfile, CI config
  • ADRs: any docs/adr/, docs/decisions/, or inline decision records
  • Conventions: naming patterns, import paths, test file locations
  • CLAUDE.md and any existing architectural docs

Produce a concrete draft of Stack, Commands, and Code Conventions from research alone. These sections should need no user input.

Step 3 — Gap-topic list

Ask only about items research could not determine. For each unanswered item, call AskUserQuestion (per ../references/questioning-style.md):

  1. Key constraints — question: "Are there non-negotiables every implementer must respect?" / header: "Key constraints" / options: pre-fill with constraints from CLAUDE.md or existing docs.
  2. Architecture decisions — question: "Are there decisions that shaped the architecture but aren't documented yet?" / header: "Architecture decisions" / options: pre-fill with patterns inferred from the codebase structure.
  3. Known pain points — question: "Are there areas of the codebase that need special care?" / header: "Known pain points" / options: pre-fill with anything flagged in README or comments.

Step 4 — Writing rules

  • Apply strict STE per ../references/ste-writing.md before you write any durable body (shared process Step 4 also requires this).
  • Commands must be exact and tested. Stale commands are worse than no commands.
  • Architecture description reflects what the codebase actually does. It does not state 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"}