60 lines
2.7 KiB
Markdown
60 lines
2.7 KiB
Markdown
Follow this workflow for all work in this repository.
|
|
|
|
## Goal
|
|
|
|
Produce publication-ready IETF draft packages from existing `ietf-draft-analyzer` data with minimal token use and strong role separation.
|
|
|
|
## Roles
|
|
|
|
- `researcher`: synthesize current evidence, identify missing evidence, and propose follow-up investigation
|
|
- `architect`: convert research into a precise spec strategy and section plan
|
|
- `author`: write the draft from the approved architecture
|
|
- `security-reviewer`: find protocol, trust, abuse, privacy, and threat-model flaws
|
|
- `software-reviewer`: find implementability, state-machine, testing, and operational gaps
|
|
- `architecture-reviewer`: find scope drift, internal inconsistency, and design weakness
|
|
- `ietf-senior-reviewer`: find IETF process, document-shape, terminology, and publishability issues
|
|
- `review-lead`: synthesize specialist reviews into one prioritized revision plan
|
|
|
|
## Token Discipline
|
|
|
|
- Read the current cycle files first, not the whole repository.
|
|
- Prefer `references/analyzer-integration.md` to rediscovering source locations.
|
|
- Load only the specific analyzer outputs needed for the current question.
|
|
- Keep handoff files short, factual, and structured.
|
|
- Reuse filenames and templates; avoid free-form notes outside the cycle folder.
|
|
|
|
## Cycle Files
|
|
|
|
Each cycle lives in `cycles/<slug>/` and uses these files:
|
|
|
|
- `00-user-spec.md`: user intent, constraints, success criteria
|
|
- `10-research-brief.md`: evidence summary, gaps, new data to fetch
|
|
- `20-architecture-brief.md`: scope, design, requirements, risks, outline
|
|
- `30-outline.md`: draft outline and section-level writing guidance
|
|
- `40-draft-v1.md`: first full draft
|
|
- `50-reviews-v1/`: specialist review folder
|
|
- `55-review-synthesis-v1.md`: merged findings and priority order
|
|
- `60-revision-plan-v1.md`: concrete changes for next draft
|
|
|
|
Continue with `v2`, `v3`, and so on.
|
|
|
|
## Operating Rules
|
|
|
|
- Do not skip the architecture step before drafting.
|
|
- Do not let the author invent core requirements that are absent from the research or architecture brief.
|
|
- Do not let specialist reviewers rewrite the whole draft when targeted changes are sufficient.
|
|
- Escalate contradictions between user specs, research evidence, and draft text.
|
|
- Track assumptions explicitly.
|
|
- Treat Security Considerations, Privacy Considerations, and IANA Considerations as first-class work items.
|
|
- Prefer parallel specialist review after each draft, then one synthesis pass.
|
|
|
|
## Done Criteria
|
|
|
|
A draft is ready for user sign-off only when:
|
|
|
|
- the architecture brief and the draft agree on scope
|
|
- major claims are backed by cited evidence or marked as hypotheses
|
|
- open issues are either resolved or explicitly listed
|
|
- specialist review findings are addressed or consciously deferred
|
|
- publishability risks are called out plainly
|