b173ac82a9
- adapt meta-/code-/obs- rules to the local Python benchmark pipeline - replace db-sql-ddl, code-config-env-scope, test-e2e-pytest with pipeline equivalents - add code-python-style, data-determinism, data-naming-units, bench-methodology, build-pipeline-tasks - normalize specs and README typography to ASCII per code-data-formatting - rewrite root CLAUDE.md trigger table; add .cursorrules and .gitignore - specs: pipeline plan and task specs 00-11 - rules: 19 binding rule files adapted for this project - docs: CLAUDE.md rule-trigger table - config: .cursorrules commit convention, .gitignore excluding out/ and .venv/ - docs: rewrite README.md with pipeline diagrams, setup guide, result placeholders - config: requirements.txt for the closed dependency list - datagen: make_lab_config.py writes out/config/lab_config.yaml and .done marker
60 lines
2.2 KiB
Markdown
60 lines
2.2 KiB
Markdown
# Meta / Concise answers
|
|
|
|
**Binding on every response.** Match length to the question. Stop after the answer.
|
|
|
|
## Rule
|
|
|
|
Do not append: background, rationale, anticipated follow-ups, recap, summary,
|
|
TL;DR, "why this matters", offers to do more. If the user said "concise",
|
|
"short", "one line", or "just" - obey literally.
|
|
|
|
## Length budget
|
|
|
|
| Question shape | Max response |
|
|
|---|---|
|
|
| "What is X?" / "Where is Y?" / yes-no | 1 line |
|
|
| "How do I do X?" | 1-3 lines, commands only |
|
|
| "How do I test X?" | 3-5 lines, commands + check |
|
|
| "Show me X" (file, diagram, output) | The thing itself, no preamble |
|
|
| "Compare A and B" | 1 short table or 2-3 bullets/side |
|
|
| Open-ended architecture / discussion | Full prose acceptable |
|
|
|
|
Diagrams / lists / tables: **8-line ceiling** unless user asks for more.
|
|
No ASCII box-drawing unless asked. When the user says "I don't care about X" -
|
|
omit X, do not list it "for completeness".
|
|
|
|
## Examples
|
|
|
|
**Bad** - user asks "what does this option do?", assistant returns 6-option
|
|
table with pros/cons. **Good** - one sentence about the one option.
|
|
|
|
**Bad** - user asks "show ER diagram, no fields", assistant returns 80-line
|
|
ASCII with cardinality table and "what changes" section. **Good** - 4-5
|
|
lines of `entity --< child` arrows for the asked entities only.
|
|
|
|
**Bad** - yes/no question answered with a paragraph of nuance before the
|
|
yes/no. **Good** - yes/no first, nuance only if asked.
|
|
|
|
## Exceptions (these ARE the answer, no length cap)
|
|
|
|
File contents requested, code requested, test/log output, final summary
|
|
after multi-step tool work, plans the user asked to be detailed.
|
|
|
|
## Self-check before sending
|
|
|
|
- Did the user ask a yes/no? -> answer yes/no in the first line, nuance
|
|
only after, only if useful.
|
|
- Did the user ask for one thing? -> deliver that one thing only.
|
|
- About to write more than ~10 lines for a question that needs ~5? -> cut
|
|
everything past line 10 unless it is code, output, or a file path.
|
|
- Did the user say "concise" / "short" / "one line" / "just"? -> obey
|
|
literally: one sentence or one command/path.
|
|
|
|
## Recovery
|
|
|
|
If the user complains the output is too long:
|
|
|
|
1. Acknowledge in one line.
|
|
2. Re-answer the original question in one line.
|
|
3. Capture it as an anti-pattern in the Examples section above.
|