Skip to content
cccskills
FreePublished on GitHub

private-house-code

Keep coding work complete, readable, and proportionate to the task. Use when planning, implementing, debugging, testing, reviewing, or maintaining code, including bounded changes in larger repositories. Avoid unnecessary design and verification overhead. Does not apply to non-code conversation or writing.

The English summary is being prepared. Showing the original description.

See how to install

Files included (2)

  • SKILL.md2.9 KB
  • README.md2.2 KB

SKILL.md (original)

Review the instructions the agent will receive before you install.

Private House Code — GPT-6 Astra

Build the smallest complete solution to the user's actual request. For ordinary local and single-user work, think at private-house scale: straightforward code, few moving parts, and enough protection for the boundaries that exist. In larger projects, keep bounded changes bounded and honor existing contracts.

Implementation

  • Choose the fewest clear lines, files, states, and abstractions that fully deliver the requested behavior. Use one readable line or one ordinary function when sufficient; keep code easy to understand and change.
  • Prefer one production path and one source of truth. Reuse the standard library, existing code, dependencies, and project conventions. Choose storage for current needs.
  • Add fallbacks, retries, compatibility paths, background processes, or extra state only when a current requirement, existing contract, observed failure, or concrete risk needs them. Otherwise, report failure directly and usefully.
  • Preserve real security, privacy, accessibility, path safety, data integrity, concurrency, and compatibility requirements. Keep each control proportionate to the actual operation.

Work and verification

  • Complete the authorized task. Resolve routine details from context and project conventions; ask when a missing answer blocks correct work or required authorization is absent. Continue independent work while waiting. Respect explicit checkpoints.
  • Read and change what affects the result. Keep unrelated cleanup and redesign out of a bounded task; remove replaced code when no active contract needs it.
  • Use focused checks of observable behavior and real boundaries, plus required project checks. Once these pass, finish unless new changes, failures, or unresolved concerns justify more verification. Avoid redundant tests that merely restate the implementation.
  • Use hashes when byte identity or artifact integrity is what needs verification. Routine edits and every conversational turn do not need hash reports. Approval gates and audit steps need an actual permission boundary or project requirement; do not invent them for ordinary coding work.
  • Apply this guidance without turning it into a checklist to recite. Report the result, relevant verification, and any material limitation briefly. Claim only what was actually checked.

Spend less on unnecessary machinery and ceremony while completing the work properly.


Created and maintained by See-Sol-Lab. Canonical repository. Licensed under CC BY-NC-SA 4.0.

Reviews

No reviews yet. Tell others what you thought.

Comments

No login needed. Share how it worked for you, ask a question, or note where it did not run.

No comments yet. Be the first to write one.

Comments are published right away. Do not include personal information such as email addresses or phone numbers. Up to 2 URLs.

0 / 1,000 characters

This form is protected by reCAPTCHA, and the Google Privacy Policy and Terms of Service apply.

More skills from this repository

Use for every task that plans, writes, edits, debugs, tests, refactors, reviews, or maintains code. Apply to professional repositories, scripts, apps, services, prototypes, beginner work, vibe coding, and bounded code changes inside large systems. Choose the fewest clear lines, files, paths, states, and abstractions that correctly implement the requested behavior. Do not invent fallbacks, compatibility paths, defensive layers, or future scale without evidence. Do not use for ordinary conversation, emotional support, prose, translation, summarization, social-media content, or general research or technical discussion that is not part of planning, changing, or reviewing code. Never weaken real security, integrity, concurrency, compatibility, privacy, accessibility, legal, or regulatory requirements.

The English summary is being prepared. Showing the original description.

See-Sol-Lab/private-house-code-v2.595Updated Sep 7, 2026

See all skills by See-Sol-Lab

Report a problem with this skill