- 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
2.2 KiB
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:
- Acknowledge in one line.
- Re-answer the original question in one line.
- Capture it as an anti-pattern in the Examples section above.