writers-loop
Use when working on substantial writing artifacts where structure, audience fit, critique, revision, translation, style learning, or decision-backed preference learning matters; also when learning reusable writing style from the user's own writing or permitted reference samples.
- License 许可
- Apache-2.0
- 最近更新
- 2026-11-14
- Stars
- ★ 1.6k
- Forks
- 490
01 前言 Front Matter
- name
- writers-loop
- description
- Use when working on substantial writing artifacts where structure, audience fit, critique, revision, translation, style learning, or decision-backed preference learning matters; also when learning reusable writing style from the user's own writing or permitted reference samples.
02 资源文件 15
- 参考文档agents/openai.yaml346 B
- 参考文档references/artifact-types.md2.6 KB
- 参考文档references/business-writing.md3.5 KB
- 参考文档references/checkpoints.md3.5 KB
- 参考文档references/critique-rubrics.md3.7 KB
- 参考文档references/fiction-narrative.md2.8 KB
- 参考文档references/multi-agent.md5.2 KB
- 参考文档references/preference-journal.md4.8 KB
- 参考文档references/preference-signals.md4.1 KB
- 参考文档references/style-distillation.md8.6 KB
- 参考文档references/technical-writing.md2.1 KB
- 参考文档references/translation.md7.2 KB
- 参考文档references/validation-scenarios.md11.4 KB
- 脚本scripts/journal.mjs8.4 KB
- 脚本scripts/style-pack.mjs5.6 KB
03 SKILL.md 正文
Writer's Loop
Core Rule
Extract preferences only from explicit user decisions:
- Approved or rejected plans
- Accepted, rejected, or undone edits
- Manual rewrites that change style, voice, or structure (not fact corrections)
- Explicit standing preferences declared by the user
Never extract preferences from unreviewed drafts, one-off comments, fact corrections, or current-task constraints. Learn from decisions, not raw drafts.
When to Use
Use for writing where quality depends on structure, audience fit, correctness, style, or iteration — typically 300+ words or any writing where feedback and refinement are expected:
- Coding plans, implementation plans, and technical proposals
- Business reports, research summaries, executive updates, and memos
- Product specs, design docs, documentation, and tutorials
- Fiction chapters, essays, scripts, speeches, and narrative outlines
- Poetry (limited support — use custom rubric; see
references/artifact-types.md) - Academic papers and whitepapers (limited support — adapt to venue requirements)
- Brand-governed or legally constrained writing (legal, clinical, regulatory, corporate)
- Style learning or style distillation from the user's own writing, permitted reference samples, files, pasted text, chapters, reports, docs, or codebase prose
- Translation where meaning, source-language writing style, voice, rhythm, formatting, terminology, or cultural effect matters
Do not use for tiny one-off text edits unless the user asks for a reusable process or preference learning.
Core Loop
Follow the loop in order. Do not emit a later-stage section before its gate has passed:
- Frame: Identify artifact type, audience, purpose, constraints, success criteria, and desired tone.
- Question Gate: Ask only blocking questions. If context is enough, state assumptions and continue.
- Plan: Create the outline, argument, task sequence, scene plan, or section structure before drafting.
- Plan Checkpoint: Stop and wait for the user to approve or request changes before drafting. ⚠ Do not draft before approval. Exception: fast draft path (see Entry Modes).
- Replan: If the plan is rejected, revise only the criticized parts, reissue the full plan, and ask again.
- Draft: Write from the approved plan. Preserve declared constraints.
- Critique: Evaluate against the artifact-specific rubric. Every critique must point to a specific location and name a concrete problem — not a generic observation.
- Propose: Suggest targeted revisions with reason and expected improvement. Stop and wait for the user's decision on each. ⚠ Do not apply changes before the user responds.
- Decide: Record the user's apply, reject, or adjust response. Do not skip this step — preference learning depends on explicit decisions.
- Revise: Apply accepted changes. Keep rejected changes out.
- Evaluate: Check the revised artifact against the original success criteria.
- Learn: Extract preference signals from decisions collected above. Record the signal type, applies-to scope, and evidence.
- Distill: Promote repeated, high-confidence patterns into reusable rules.
- Reuse: Apply stable rules in later tasks, scoped to artifact type and stage.
Entry Modes
- New artifact: start at
Frame, thenQuestion Gate, thenPlan. - Fast draft (questions waived): Frame → state Assumptions → compact inline Plan → Draft → Learning Status. Use only when the user clearly waives questions and asks for an immediate draft. Do not use this path when the user asks to bypass, ignore, or override a known plan checkpoint; in that case, present the plan and stop at
PLAN CHECKPOINT. Skipped questions are weak signals and will not become preferences. - Multi-agent: default to single-agent. Use multi-agent only for high-stakes, long, ambiguous, or multi-audience artifacts where independent planning or critique would materially improve quality. Read
references/multi-agent.mdfirst. - Existing draft: start at
Frame, thenCritique; plan only if structure is unclear. If source text is missing or placeholder-only, ask for it and use this wording: "preserve user intent, voice, plot facts, and continuity." - Targeted revision: start at
Frame, thenPropose; keep changes at sentence or paragraph level unless the user explicitly asked for section-scale changes. - Style learning: start at
Frame, then readreferences/style-distillation.md. OutputFrame,Style Versus Content,Style Pack, andStorage Decision. If the user wants to clone another person's style, confirm permission or keep the pack session-only. - Using a learned style: before asking artifact questions or drafting, load the style pack from the conversation or from
.writers-loop/styles/only when the user opted into local storage. State which pack is loaded. Draft with it, then critique content quality and style match separately. Do not copy source passages or facts from the style pack evidence. If the style pack is missing, unavailable, or the user says not to load it first, use the missing-style-pack template inreferences/style-distillation.mdexactly, includingStyle Pack Status,Content Plan, andStyle Application Plan. Do not draft and do not outputQUESTION GATEor general artifact questions yet. - Translation: start at
Frame, then readreferences/translation.md. OutputFrame,Translation,Review, andLearning Status; preserve source formatting inside theTranslationsection, not by omitting the loop metadata. - Preference update: start at
Learn. For storage-mode requests, confirm whether.writers-loop/,journal.jsonl,prefs.md, or style packs will be created before asking artifact questions. Treat tone, length, detail level, or storage mode set for the current task as a constraint, not a learned preference, unless the user says it applies in future work.
Planning Gates
Ask up to five questions only when the answer would materially change the plan. If the user skips questions, state working assumptions and continue. Skipped questions are weak or neutral signals, not strong preferences.
Fast draft exception: if the user clearly waived questions while asking for a
draft, show a compact Plan inline and draft immediately. Do not pause for plan
approval. End with Learning Status.
Checkpoint pressure override: if the user asks to bypass, ignore, or override a
known plan checkpoint, the checkpoint still applies. Output a plan, explain that
fast draft only waives blocking questions, then stop at PLAN CHECKPOINT.
After presenting a plan in the standard path, output the checkpoint format
(see references/checkpoints.md) and wait. Do not draft until the user
replies. If the user's response is ambiguous, ask: "Does that mean approve,
or would you like changes?"
Constraint vs. Preference
A constraint applies to one artifact ("for this memo, use short sentences"). A preference applies to future artifacts ("I always prefer short sentences in memos"). Do not convert a constraint into a learned preference unless the user explicitly says it applies in future work. When unsure, ask.
If the current request conflicts with an older preference, output Preference Handling: say that the current explicit instruction wins for this task, keep
the older preference scoped, and do not archive it without repeated
contradictory evidence.
Signal Rules
Extract preferences only from:
- Approved plans (
plan_approved) - Rejected plans with reasons (
plan_revision_requested) - Accepted edits (
proposal_applied) - Rejected edits (
proposal_rejected) - Undone edits (
proposal_undone) - Manual rewrites that change style, voice, or structure (
manual_rewrite) - Explicit standing preferences (
preference_declared)
Discard for preference learning:
- Unreviewed drafts
- Model-generated text that was never reviewed
- One-off style comments or ambiguous praise
- Fact, date, citation, or domain corrections
- Current-task constraints ("this time", "for this memo", storage mode, tone, length, or detail level) unless the user says it is a standing preference
Distillation Rules
Promote a pattern into a reusable rule only when:
- It repeats across at least two meaningful decisions, or the user explicitly declared it
- It is specific enough to guide future output
- It is not contradicted by more recent or stronger evidence
Format:
Rule: [short imperative instruction]
Applies to: [artifact-type/stage, e.g. coding-plan/planning or report/critique]
Evidence: [accepted/rejected/manual decision summary]
Confidence: low | medium | high
Apply only medium or high confidence rules without asking. Ask before
applying low confidence rules. Do not promote a single current-task
constraint into Learned Preferences.
Reference Loading
Load only the references needed for the current task. State which reference you are reading before using it. If the artifact type is not found in a reference, use the Universal Rubric and ask if it is sufficient — do not invent rules not in the file.
references/artifact-types.md: routing index for artifact-specific referencesreferences/technical-writing.md: coding plans, technical docs, design docs, and product specsreferences/business-writing.md: reports, memos, proposals, academic/whitepaper, and constrained writingreferences/fiction-narrative.md: fiction, narrative, essays, speeches, and poetryreferences/critique-rubrics.md: artifact-specific critique criteriareferences/preference-signals.md: signal examples and weighting guidancereferences/checkpoints.md: checkpoint formats for question, plan, proposal, and closereferences/style-distillation.md: learning reusable style packs from samplesreferences/translation.md: translating while preserving source stylereferences/multi-agent.md: optional multi-agent workflowreferences/preference-journal.md: optional durable journal formatreferences/validation-scenarios.md: pressure tests for validating this skill
Release validation includes tools/validate-skill.mjs through npm run validate.
Optional Tool
Use bundled scripts only when the user opts into durable local preferences or durable local style packs:
scripts/journal.mjs: initialize.writers-loop/, append decision events, and deriveprefs.md.scripts/style-pack.mjs: initialize.writers-loop/styles/, save reviewed style packs, list saved style packs, and show a selected style pack.
Common Mistakes
- Drafting before framing audience and success criteria
- Using multi-agent by default for ordinary tasks
- Applying broad rewrites when targeted edits preserve intent better
- Treating a single accepted edit as a permanent global rule
- Converting "this time" or session-only storage into a durable preference
- Reusing fiction style preferences in coding plans or reports without evidence
- Loading a style pack without stating which one is loaded
- Judging only content quality when a style-match review is also required
- Treating a fact-correction rewrite as a style preference signal
- Copying source passages or content facts into a reusable style pack
- Flattening source-language voice or rhythm into generic target-language prose
- Translating code, commands, file paths, URLs, or IDs
04 同仓库更多 Skills
migrate-to-e2e
Moves an existing Playwright, Cypress, Selenium, Appium, Detox, Maestro, or TesterArmy suite to e2e one slice at a time, with the old suite running beside the new one until each ported test is proven. Keeps a MIGRATION.md progress file so any later session resumes where the last stopped. Optionally plants a defect to show both suites catch it. Use for /migrate-to-e2e, "migrate our tests to e2e", "port these Maestro flows", "move our TesterArmy tests", or when a project has an e2e config and an older suite still running.
e2e
Writes, runs, and debugs end-to-end tests for web and mobile apps with e2e, the agentic test runner, which mixes agent.act goals with exact locator assertions on a Playwright browser or an iOS or Android device. Also drives a project's running app live over the e2e MCP server to look at a screen, check a UI change, take a screenshot or record a video, and try a locator; and runs bug bashes, parallel e2e explore runs with each bug proven by a repro test. Use when a project depends on e2e or has an e2e.config.ts, when asked for end-to-end, browser, mobile, or agentic UI tests, to check a change in the running app, to QA or bug bash an app or branch, or when an e2e run fails.
create-verification-skill
Generate a project-local verify-<app> skill on top of e2e, so any coding agent can launch the app, check it is worth driving, exercise a feature the way a user does, keep evidence, and bug bash it. Writes the skill, a feature map with one explore charter per feature, and proves it once. Use for /create-verification-skill, "make a verification skill for this repo", or when a project has no scripted way to prove UI behavior.
deja-search
deja-vu memory — search the user's past AI coding sessions with the deja CLI. Holds what they already settled and never wrote into the repo (naming rules, banned or already-tried tools, required checks before merge, preferred values, who owns what). Use before your first edit in a task, before you call a change done or ready to merge, before you recommend a tool, library, design or reviewer, before re-debugging an error that may already be solved, when they say 'didn't we fix this before', 'what did we decide about X' or 'I already have that', and before telling them something on this machine does not exist.
deja-reflect
End-of-session reflection and memory curation with deja-vu. Review what was decided, what commands broke and what repaired them, and record durable project rules or decisions with deja remember so the next session starts with them.
revid
Make, edit, export and post AI videos with Revid (revid.ai) through the Revid MCP server. Use whenever the user wants a short-form or long-form video made (from an idea, a script, a URL, an article, a PDF, a tweet, a product page, their own clips, or a song), wants to find what is going viral on TikTok, YouTube, Instagram or X before making something, wants to edit or re-export an existing Revid project, generate a standalone AI image or clip, make a series episode, or publish and schedule a finished video to connected social accounts. Covers setup (hosted MCP with OAuth, or an API key), the 36 tools, credits, polling and the rules for publishing. Routes to the more specific revid-* skills when one fits.