Dev/code style

.agents/skills/company-creator/SKILL.md

@@ -194,6 +194,7 @@ The `.taskcore.yaml` file is the Taskcore vendor extension. It configures adapte
 **Do not specify an adapter unless the repo or user context warrants it.** If you don't know what adapter the user wants, omit the adapter block entirely — Taskcore will use its default. Specifying an unknown adapter type causes an import error.
 
 Taskcore's supported adapter types (these are the ONLY valid values):
+
 - `claude_local` — Claude Code CLI
 - `codex_local` — Codex CLI
 - `opencode_local` — OpenCode CLI
@@ -203,18 +204,21 @@ Taskcore's supported adapter types (these are the ONLY valid values):
 - `openclaw_gateway` — OpenClaw gateway
 
 Only set an adapter when:
+
 - The repo or its skills clearly target a specific runtime (e.g. gstack is built for Claude Code, so `claude_local` is appropriate)
 - The user explicitly requests a specific adapter
 - The agent's role requires a specific runtime capability
 
 ### Env Inputs Rules
 
 **Do not add boilerplate env variables.** Only add env inputs that the agent actually needs based on its skills or role:
+
 - `GH_TOKEN` for agents that push code, create PRs, or interact with GitHub
 - API keys only when a skill explicitly requires them
 - Never set `ANTHROPIC_API_KEY` as a default empty env variable — the runtime handles this
 
 Example with adapter (only when warranted):
+
 ```yaml
 schema: taskcore/v1
 agents:
@@ -231,6 +235,7 @@ agents:
 ```
 
 Example — only agents with actual overrides appear:
+
 ```yaml
 schema: taskcore/v1
 agents:

.agents/skills/company-creator/references/from-repo-guide.md

@@ -30,50 +30,59 @@ metadata:
 ```
 
 To get the commit SHA:
+
 ```bash
 git ls-remote https://github.com/owner/repo HEAD
 ```
 
 Only vendor (copy) skills when:
+
 - The user explicitly asks to copy them
 - The skill is very small and tightly coupled to the company
 - The source repo is private or may become unavailable
 
 ## Handling Existing Agent Configurations
 
 If the repo has agent configs (CLAUDE.md, .claude/ directories, codex configs, etc.):
+
 - Use them as inspiration for AGENTS.md instructions
 - Don't copy them verbatim - adapt them to the Agent Companies format
 - Preserve the intent and key instructions
 
 ## Repo-Only Skills (No Agents)
 
 When a repo contains only skills and no agents:
+
 - Create agents that would naturally use those skills
 - The agents should be minimal - just enough to give the skills a runtime context
 - A single agent may use multiple skills from the repo
 - Name agents based on the domain the skills cover
 
 Example: A repo with `code-review`, `testing`, and `deployment` skills might become:
+
 - A "Lead Engineer" agent with all three skills
 - Or separate "Reviewer", "QA Engineer", and "DevOps" agents if the skills are distinct enough
 
 ## Common Repo Patterns
 
 ### Developer Tools / CLI repos
+
 - Create agents for the tool's primary use cases
 - Reference any existing skills
 - Add a project maintainer or lead agent
 
 ### Library / Framework repos
+
 - Create agents for development, testing, documentation
 - Skills from the repo become agent capabilities
 
 ### Full Application repos
+
 - Map to departments: engineering, product, QA
 - Create a lean team structure appropriate to the project size
 
 ### Skills Collection repos (e.g. skills.sh repos)
+
 - Each skill or skill group gets an agent
 - Create a lightweight company or team wrapper
 - Keep the agent count proportional to the skill diversity