Skip to content
Lytos

Lytos Workflow

Lytos doesn’t replace your process. It adds a technical layer between the product need and the code generated by the AI. Below, two typical workflows — solo and in a team — show where Lytos fits in and where nothing changes.

  1. Dev
    Sets the frame

    Manifest (identity, stack, constraints), rules (quality thresholds), skills (procedures for recurring tasks). An initial investment that serves every session afterwards.

  2. Dev
    Writes an issue

    Technical description of the need, instead of a throwaway prompt. The issue lives in the repo with YAML frontmatter (priority, type, references).

  3. Dev + AI
    Executes

    The AI reads the frame (manifest + rules + skills + memory) and the issue, then produces code in the project's style — not generic.

  4. Dev
    Validates and adjusts

    Challenges the proposal, corrects drift, verifies the skill checklist.

  5. Dev
    Captures to memory

    What deserves to persist (architectural decisions, patterns, bugs avoided) goes to memory/. Next session, the context is already there.

  6. Dev
    Commits and closes

    Commit with issue reference, board updated, issue moved to review/, then to done after explicit validation. No traceability loss.

How the roles evolve

Section titled “How the roles evolve”

Dev — Less boilerplate, more formalization of the technical need. Their artifact is no longer only the code, but also the issue that describes it. A developer remains a developer, with an added framing skill — prompt engineering applied to the project.

Lead Dev — Retains architecture responsibilities. Adds guardianship of the shared context: manifest, rules, skills. The equivalent of a style guide — but executable by AI, not just read in review.

PO / Scrum Master — Role unchanged. Lytos operates at the technical layer; product ticketing and team methodology stay intact.

Emerging surface — On advanced teams, a cross-functional skills and memory curation role can appear. It can be carried by the lead dev, a staff engineer, or a dedicated profile. Nothing mandatory — just an observation.

What this changes for a technical leader

Section titled “What this changes for a technical leader”
  • Reproducible AI output — rules + skills = verifiable frame. Two devs with the same issue produce comparable code.
  • Accelerated onboarding — a new dev reads the manifest and knows the project. No more implicit context transfer that never fully happens.
  • Junior ramp-up — a junior or new hire produces within the project’s frame from their very first issues. Manifest, rules, skills, and memory act as silent senior guidance — framing the work without tying up senior time.
  • Traceability — each issue has YAML frontmatter, each skill is explicit, each commit references its issue.
  • Auditable AI output — unlike a private AI chat that leaves nothing behind, every line generated via Lytos rests on a versioned issue, explicit rules, and a referenced skill. The why of the code is readable cold, in the repo — compliance and audit reviews made simpler.
  • Model portability — switching AI providers doesn’t break anything. The context is in the repo, not in a third-party SaaS.
  • Reduced debt — today’s generated code matches yesterday’s. Conventions no longer slip between sessions or between developers.

This workflow is not a revolution — it’s a formalization of what many teams already do implicitly, made explicit and versioned in the repo. Nothing prevents you from starting small: a manifest, two skills, a few rules. The rest builds at the project’s pace.