Добавлено описание проекта, структура и требования к текстам в README.md; создан файл AGENTS.md с правилами работы и стандартами для агентов.
This commit is contained in:
@@ -0,0 +1,83 @@
|
||||
# AGENTS
|
||||
|
||||
## Purpose
|
||||
|
||||
This repository is used to turn fragmented owner notes about a residential property into publication-ready Russian sale listings.
|
||||
|
||||
Agents working here should optimize for factual accuracy, clear buyer appeal, owner-like tone, and fast export of final texts into result/.
|
||||
|
||||
## Source Of Truth
|
||||
|
||||
- draft/ contains the primary property facts;
|
||||
- result/ contains generated and reviewed listing variants;
|
||||
- .github/copilot-instructions.md contains the detailed workspace rules;
|
||||
- .github/agents/ contains specialized agent modes for drafting and reviewing listings;
|
||||
- .github/skills/ contains reusable workflow instructions.
|
||||
|
||||
If there is any conflict, prefer explicit facts from draft/ over marketing wording from generated files.
|
||||
|
||||
## Core Workflow
|
||||
|
||||
1. Read all relevant files in draft/ before writing or reviewing anything.
|
||||
2. Consolidate the property into one coherent object unless the notes clearly describe multiple different properties.
|
||||
3. Separate information into three buckets:
|
||||
- verified facts;
|
||||
- soft interpretations grounded in facts;
|
||||
- open questions or contradictions.
|
||||
4. Write or improve listing text only from supported information.
|
||||
5. Save publication-ready plain text outputs in result/.
|
||||
|
||||
## Writing Rules
|
||||
|
||||
- Write final listing outputs in Russian.
|
||||
- Use the owner's perspective, not an agency voice.
|
||||
- Favor concrete specifics over generic praise.
|
||||
- Keep the copy readable on Avito and CIAN without special formatting.
|
||||
- Avoid inventing distances, legal claims, renovation details, infrastructure, or technical specs.
|
||||
- Avoid stale real-estate cliches unless the wording is strongly justified by the object.
|
||||
|
||||
## Expected Outputs
|
||||
|
||||
For a normal generation task, create three versions:
|
||||
|
||||
- aggressive;
|
||||
- calm;
|
||||
- classic.
|
||||
|
||||
For a review-and-optimization task, compare variants, choose the strongest one, and create an improved best version if the task requires it.
|
||||
|
||||
## Review Standard
|
||||
|
||||
When reviewing listing quality, evaluate:
|
||||
|
||||
- opening hook;
|
||||
- clarity of the offer;
|
||||
- specificity;
|
||||
- buyer lifestyle appeal;
|
||||
- trust and honesty;
|
||||
- differentiation;
|
||||
- objection handling;
|
||||
- scanability;
|
||||
- call to action;
|
||||
- expected response potential.
|
||||
|
||||
## File Naming
|
||||
|
||||
Use Latin slug filenames based on location and object type.
|
||||
|
||||
Recommended pattern:
|
||||
|
||||
location-object-type-variant.txt
|
||||
|
||||
If a target filename already exists, create a versioned alternative instead of overwriting it silently.
|
||||
|
||||
## Editing Policy
|
||||
|
||||
- Keep edits minimal and task-focused.
|
||||
- Do not rewrite strong source material without a reason.
|
||||
- Do not remove factual caveats that improve trust.
|
||||
- Distinguish copy problems from source-information gaps.
|
||||
|
||||
## Practical Rule
|
||||
|
||||
The best listing in this repository is not the most emotional one. It is the one that makes a buyer quickly understand the object, trust the owner, imagine living there, and feel ready to message or call.
|
||||
Reference in New Issue
Block a user