Skip to content

Add brownfield-import mode to init-project for projects with existing docs #18

@lx-0

Description

@lx-0

The gap

ytstack:init-project has two paths:

  1. Pitch present (OFFICE-HOURS.md exists) → consume it, populate PROJECT.md.
  2. No pitch → write placeholder PROJECT.md and tell the user to run office-hours.

The most common real-world case — an existing codebase with its own README.md, docs/, runbooks, CHANGELOG.md, sometimes docs/adr/ — is treated as case 2. The skill ships a useless placeholder, even though 80% of the answers (one-liner, runtime services, env vars, deploy target, decisions, runbooks) are already in the repo. Running office-hours against a shipped product to retroactively "validate the premise" is theater.

This bites the moment anyone adopts ytstack on a project they didn't start with it. We just hit it on a Next.js app that's been in production for months — full details + a written-up gap list at .ytstack/FRICTION-NOTES.md in that repo.

Proposal: third mode brownfield-import

Additive. No behavior change for existing greenfield users.

Detection

In the preamble, count brownfield signals:

_BROWNFIELD_SIGNALS=0
[ -f README.md ] && [ "$(wc -l < README.md)" -gt 30 ] && _BROWNFIELD_SIGNALS=$((_BROWNFIELD_SIGNALS+1))
[ -d docs ] && [ "$(ls docs/*.md 2>/dev/null | wc -l)" -gt 2 ] && _BROWNFIELD_SIGNALS=$((_BROWNFIELD_SIGNALS+1))
[ -f CHANGELOG.md ] && _BROWNFIELD_SIGNALS=$((_BROWNFIELD_SIGNALS+1))
[ -d docs/adr ] && _BROWNFIELD_SIGNALS=$((_BROWNFIELD_SIGNALS+1))
[ -f package.json ] && [ "$(git log --oneline 2>/dev/null | wc -l)" -gt 50 ] && _BROWNFIELD_SIGNALS=$((_BROWNFIELD_SIGNALS+1))

If BROWNFIELD_SIGNALS >= 2 AND PITCH = none → route to brownfield-import instead of greenfield-placeholder.

Backfill behavior

  • PROJECT.md one-liner — first non-heading paragraph of README.md as candidate.
  • KNOWLEDGE.md — auto-link every docs/*.md with a one-line summary read from the H1.
  • RUNTIME.md — derive from package.json scripts, .env.example keys, docker-compose.yml services, .github/workflows/deploy-*.yml target.
  • DECISIONS.md — if docs/adr/ or docs/DECISIONS.md exists, link/inherit instead of overwriting.

Other small things in scope

  • The "Anti-Pattern" section at the top of the skill currently only addresses "too small for ytstack". Add a sibling clause: too mature for greenfield ceremony — use brownfield-import instead.
  • Add a tracker: annotation in STATE.md so projects whose issue-level execution lives elsewhere (Linear, GitHub Projects, Paperclip, Jira) don't get pestered by plan-milestone / reassess-roadmap to create milestones for BAU work.

Out of scope but worth a follow-up

The init-project sentinel ~/.ytstack/.init-project-<slug>-completed is keyed by basename(cwd), not by repo remote URL — two repos with the same folder name on the same machine collide. Edge case but real for collection directories (e.g. monorepo-of-repos layouts).


Happy to PR this if there's interest. The detection + backfill is mechanical, the bigger question is whether you want brownfield-import as a parallel third path or as a flag on the existing flow (--brownfield).

Real-world artifact: https://github.com/lx-0/SunoFlow/blob/main/.ytstack/FRICTION-NOTES.md

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type
    No fields configured for issues without a type.

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions