extract-standards

Files (1)

• SKILL.md

SKILL.md (first lines)

# Extract Standards

Use this workflow inside a source repo (yours or a client's) to pull out real, opinionated
conventions so they can later be merged into the Day One Agent Kit. This does not require the
kit to be installed in the target repo.

## Goal

Produce a portable folder of concrete, evidenced standards, categorized to match kit lane and
adapter names, ready to copy into `incoming/<repo-name>/` in the kit repo.

## Output

`.ai/extracted-standards/<repo-name>/` containing:

- `meta.md` — repo name, detected stack, date extracted.
- One file per relevant **lane**: `frontend-ui.md`, `backend-api.md`, `database.md`,
  `auth-security.md`, `ai-logic.md`, `deployment.md`, `testing.md`, `observability.md`,
  `refactor.md`, `bugfix.md` (skip lanes with no evidence — do not force content).
- One file per relevant **adapter/tech**: e.g. `nextjs.md`, `react.md`, `typescript.md`,
  `supabase.md`, `<provider>.md`. Create a new adapter file for any stack piece not already in
  the kit's adapter list.

## Sources To Scan (priority order)

1. Root docs: `README`, `CONTRIBUTING`, `ARCHITECTURE.md`, style guides, ADRs, `/docs`.
2. Config that encodes conventions: `eslint`/`prettier`/`tsconfig` strictness, lint rule
   overrides with comments explaining why.
3. Repeated implementation patterns actually observed across 3+ files (e.g. "every API route
   imports the same validation helper").
4. Any freeform standards text the user pastes directly into this session.

## Extraction Rules

- Extract only **specific, opinionated, repeatable** rules — skip generic engineering advice a
  competent agent would already default to. Bad: "validate inputs." Good: "all API inputs are
  validated via the shared `validateRequest(schema)` helper in `lib/validation.ts`; no inline
  checks in route handlers."
- Every rule must cite evidence: concrete file paths for code-observed patterns, or "documented
  only, not observed in code" for doc-only rules.
- Do not invent conventions that aren't evidenced somewhere.
- Use "always/never" phrasing over vague guidance.
- If a doc says one thing and the code does another, flag the contradiction explicitly instead
  of silently picking one.
- Tag each rule with confidence: `high` (3+ code occurrences), `medium` (1-2 occurrences),
  `doc-only` (written standard, no code evidence found), `user-provided` (pasted directly by
  the user, not found in repo).

## Steps

1. Detect stack/tech (framework, language, package manager, deployment target, key providers).
2. Read all doc sources listed above.
3. Grep for repeated per-domain patterns: auth checks, input validation, error handling,
   response shapes, state management, styling/component conventions, testing conventions,
   CI/deployment steps, env variable handling, AI/LLM call patterns if present.
4. For each domain with enough evidence, write entries as:

   ```
   ### <rule name>
   Rule: <always/never statement>
   Evidence: <file paths, or "doc: <source>", or "user-provided">
   Confidence: high | medium | doc-only | user-provided
   ```

5. Incorporate any freeform text the user pastes in this session, tagged `user-provided`.
6. Write everything to `.ai/extracted-standards/<repo-name>/`.

## Rules

- Do not edit product code.
- Do not fabricate patterns without evidence.
- Keep each file short — a list of concrete rules, not prose essays.
- This output is ephemeral, not a living doc: copy `.ai/extracted-standards/<repo-name>/` into
  the kit repo's `incoming/` folder, then delete it from this repo. Do not commit it long-term
  here — see `policy/output-contract.md`.

## Done Check

- Every file contains only concrete, evidenced, opinionated rules.
- Every rule has an evidence tag.
- Output folder is self-contained and copyable into another repo's `incoming/` directory.

From JahacksV1/day-one-agent-kit, MIT.

More from JahacksV1/day-one-agent-kit