From bcae4850a2f9f42c4be754c4bcaae18902878c0d Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Ra=C3=BAl=20Pedraza=20Le=C3=B3n?= Date: Fri, 24 Apr 2026 07:59:38 +0200 Subject: [PATCH] chore: move shared workflow skills out of titan-cli --- .../titan-capability-discovery/SKILL.md | 66 --------- .../references/ctx-textual-capabilities.md | 11 -- .../project-inspection-checklist.md | 16 --- .../references/public-titan-capabilities.md | 12 -- .../titan-project-workflow-builder/SKILL.md | 127 ------------------ .../assets/extends-workflow-template.yaml | 11 -- .../assets/new-workflow-template.yaml | 11 -- .../assets/workflow-design-checklist.md | 9 -- .../references/step-authoring-basics.md | 21 --- .../references/workflow-antipatterns.md | 10 -- .../references/workflow-decision-flow.md | 13 -- .../references/workflow-final-review.md | 12 -- .../SKILL.md | 76 ----------- .../references/project-vs-plugin-workflow.md | 14 -- .../public-plugin-stability-rules.md | 9 -- .../public-plugin-step-registration.md | 10 -- .../public-plugin-workflow-layout.md | 16 --- .../titan-workflow-architecture/SKILL.md | 95 ------------- .../assets/client-template.py | 8 -- .../assets/operation-template.py | 4 - .../assets/project-step-template.py | 16 --- .../references/layer-boundaries.md | 14 -- .../plugin-like-project-architecture.md | 24 ---- .../project-vs-plugin-architecture.md | 14 -- .../references/when-to-create-client.md | 16 --- .../references/when-to-create-operation.md | 15 --- .../references/when-to-use-command-vs-step.md | 14 -- AGENTS.md | 6 +- 28 files changed, 1 insertion(+), 669 deletions(-) delete mode 100644 .claude/skills/titan-capability-discovery/SKILL.md delete mode 100644 .claude/skills/titan-capability-discovery/references/ctx-textual-capabilities.md delete mode 100644 .claude/skills/titan-capability-discovery/references/project-inspection-checklist.md delete mode 100644 .claude/skills/titan-capability-discovery/references/public-titan-capabilities.md delete mode 100644 .claude/skills/titan-project-workflow-builder/SKILL.md delete mode 100644 .claude/skills/titan-project-workflow-builder/assets/extends-workflow-template.yaml delete mode 100644 .claude/skills/titan-project-workflow-builder/assets/new-workflow-template.yaml delete mode 100644 .claude/skills/titan-project-workflow-builder/assets/workflow-design-checklist.md delete mode 100644 .claude/skills/titan-project-workflow-builder/references/step-authoring-basics.md delete mode 100644 .claude/skills/titan-project-workflow-builder/references/workflow-antipatterns.md delete mode 100644 .claude/skills/titan-project-workflow-builder/references/workflow-decision-flow.md delete mode 100644 .claude/skills/titan-project-workflow-builder/references/workflow-final-review.md delete mode 100644 .claude/skills/titan-public-plugin-workflow-builder/SKILL.md delete mode 100644 .claude/skills/titan-public-plugin-workflow-builder/references/project-vs-plugin-workflow.md delete mode 100644 .claude/skills/titan-public-plugin-workflow-builder/references/public-plugin-stability-rules.md delete mode 100644 .claude/skills/titan-public-plugin-workflow-builder/references/public-plugin-step-registration.md delete mode 100644 .claude/skills/titan-public-plugin-workflow-builder/references/public-plugin-workflow-layout.md delete mode 100644 .claude/skills/titan-workflow-architecture/SKILL.md delete mode 100644 .claude/skills/titan-workflow-architecture/assets/client-template.py delete mode 100644 .claude/skills/titan-workflow-architecture/assets/operation-template.py delete mode 100644 .claude/skills/titan-workflow-architecture/assets/project-step-template.py delete mode 100644 .claude/skills/titan-workflow-architecture/references/layer-boundaries.md delete mode 100644 .claude/skills/titan-workflow-architecture/references/plugin-like-project-architecture.md delete mode 100644 .claude/skills/titan-workflow-architecture/references/project-vs-plugin-architecture.md delete mode 100644 .claude/skills/titan-workflow-architecture/references/when-to-create-client.md delete mode 100644 .claude/skills/titan-workflow-architecture/references/when-to-create-operation.md delete mode 100644 .claude/skills/titan-workflow-architecture/references/when-to-use-command-vs-step.md diff --git a/.claude/skills/titan-capability-discovery/SKILL.md b/.claude/skills/titan-capability-discovery/SKILL.md deleted file mode 100644 index b2ca3629..00000000 --- a/.claude/skills/titan-capability-discovery/SKILL.md +++ /dev/null @@ -1,66 +0,0 @@ ---- -name: titan-capability-discovery -description: Inspect a project, plugin package, and Titan public docs to discover reusable workflow capabilities before creating new workflow code. Use when you need to know what workflows, steps, integrations, registration patterns, or ctx.textual capabilities already exist for a project or plugin. -disable-model-invocation: false -user-invocable: false ---- - -# Titan Capability Discovery - -Inspect before inventing. - -## Goal - -Identify what can be reused from: - -1. the current project's `.titan/` -2. a plugin package if the task targets a plugin -3. Titan public docs -4. existing workflow and step structure - -## Modes - -Choose the right inspection mode first: - -1. `project` - Inspect `.titan/`. -2. `plugin` - Inspect the plugin package and its registration flow. -3. `public-plugin` - Inspect the external or community plugin package layout and registration flow. - -## Inspection Order - -### Project mode - -1. Review `.titan/workflows/*.yaml`. -2. Review `.titan/steps/**/*.py`. -3. Review `.titan/operations/`, `.titan/clients/`, and `.titan/services/` if present. - -### Plugin mode - -1. Review the plugin package root. -2. Review `plugin.py`. -3. Review workflow files under the plugin package. -4. Review step registration modules if present. -5. Review steps, operations, clients, services, and models. - -### Shared - -1. Review relevant public Titan docs when local package or project context is not enough. - -## Output - -Return: - -1. Existing workflows worth extending or calling. -2. Existing steps worth reusing. -3. Existing project domains or integrations worth building on. -4. Existing plugin registration patterns worth preserving. -5. Missing pieces that actually need new code. - -## References - -1. `references/project-inspection-checklist.md` -2. `references/public-titan-capabilities.md` -3. `references/ctx-textual-capabilities.md` diff --git a/.claude/skills/titan-capability-discovery/references/ctx-textual-capabilities.md b/.claude/skills/titan-capability-discovery/references/ctx-textual-capabilities.md deleted file mode 100644 index a74eea31..00000000 --- a/.claude/skills/titan-capability-discovery/references/ctx-textual-capabilities.md +++ /dev/null @@ -1,11 +0,0 @@ -# ctx.textual Capabilities - -When creating a project step, remember `ctx.textual` can support: - -1. step lifecycle messages -2. normal, dim, success, warning, and error text -3. loading indicators -4. prompts and confirmations -5. mounted widgets such as panels and tables - -Do not add a custom UI layer when `ctx.textual` already covers the workflow need. diff --git a/.claude/skills/titan-capability-discovery/references/project-inspection-checklist.md b/.claude/skills/titan-capability-discovery/references/project-inspection-checklist.md deleted file mode 100644 index dfc5d06c..00000000 --- a/.claude/skills/titan-capability-discovery/references/project-inspection-checklist.md +++ /dev/null @@ -1,16 +0,0 @@ -# Project Inspection Checklist - -Inspect in this order: - -1. `.titan/workflows/*.yaml` -2. `.titan/steps/**/*.py` -3. `.titan/operations/**/*.py` -4. `.titan/clients/**/*.py` -5. `.titan/services/**/*.py` - -Look for: - -1. extendable workflows -2. reusable step names -3. domain folders already present -4. existing integration code diff --git a/.claude/skills/titan-capability-discovery/references/public-titan-capabilities.md b/.claude/skills/titan-capability-discovery/references/public-titan-capabilities.md deleted file mode 100644 index 458d2138..00000000 --- a/.claude/skills/titan-capability-discovery/references/public-titan-capabilities.md +++ /dev/null @@ -1,12 +0,0 @@ -# Public Titan Capabilities - -Use public Titan docs to confirm user-facing concepts and built-in capabilities when local context is missing. - -Useful pages: - -1. home page for product framing -2. workflow concepts for YAML semantics -3. plugin overview pages for built-in plugin capabilities -4. architecture page for the public 5-layer model - -Prefer local project evidence over generic assumptions. diff --git a/.claude/skills/titan-project-workflow-builder/SKILL.md b/.claude/skills/titan-project-workflow-builder/SKILL.md deleted file mode 100644 index a1e0a902..00000000 --- a/.claude/skills/titan-project-workflow-builder/SKILL.md +++ /dev/null @@ -1,127 +0,0 @@ ---- -name: titan-project-workflow-builder -description: Design and create Titan workflows for a specific project under .titan/. Use when the user wants a workflow in .titan/workflows, project steps under .titan/steps, or project-scoped operations, clients, and services. -disable-model-invocation: false ---- - -# Titan Project Workflow Builder - -Build Titan workflows for the current project under `.titan/` while teaching briefly as you go. - -## Goal - -Turn user requirements into a complete project workflow that: - -1. Reuses existing Titan and project capabilities first. -2. Chooses the smallest correct architecture. -3. Produces working files under `.titan/`. -4. Respects Titan semantics for hooks, params, result types, and cleanup. - -## Scope - -This skill is only for project workflows and project-local reusable code. - -Target outputs: - -1. `.titan/workflows/*.yaml` -2. `.titan/steps/**` -3. `.titan/operations/**`, `.titan/clients/**`, `.titan/services/**` when justified - -Do not use this skill for plugin package workflows. Use the plugin workflow builders instead. - -## Workflow - -### 1. Clarify the task - -Capture: - -1. What the workflow should automate. -2. Whether this should extend an existing workflow or create a new one. -3. Whether the workflow is simple or introduces a reusable project domain integration. - -Keep questions minimal. If the repo already makes the answer clear, do not ask. - -### 2. Discover before creating - -Use `titan-capability-discovery` behavior before writing code. - -Check: - -1. Existing `.titan/workflows/*.yaml` files. -2. Existing `.titan/steps/**/*.py` files. -3. Existing reusable code under `.titan/operations/`, `.titan/clients/`, `.titan/services/`. -4. Relevant public Titan docs if local project context is insufficient. - -Prefer: - -1. Extending an existing workflow. -2. Calling an existing workflow. -3. Reusing an existing step. -4. Using a command step. -5. Creating new code only when necessary. - -### 3. Decide the implementation shape - -Follow `references/workflow-decision-flow.md`. - -Choose between: - -1. Pure YAML orchestration. -2. YAML + project step. -3. YAML + project step + operation. -4. Plugin-like project layout for reusable domains. - -Use `titan-workflow-architecture` rules when that choice is not obvious. - -### 4. Generate the workflow - -Create files under `.titan/` using these rules: - -1. Workflows always live in `.titan/workflows/`. -2. Project step entrypoints must remain discoverable under `.titan/steps/**`. -3. Extra code may be organized by domain under `.titan/operations/`, `.titan/clients/`, `.titan/services/`. - -Useful templates: - -1. `assets/new-workflow-template.yaml` -2. `assets/extends-workflow-template.yaml` -3. `references/step-authoring-basics.md` - -### 5. Validate the result - -Review the generated design against `references/workflow-final-review.md` and `references/workflow-antipatterns.md`. - -Always verify: - -1. `Skip` vs `Exit` -2. `on_error` usage -3. cleanup guarantees -4. parameter flow via `ctx.get()` and metadata -5. whether new code is justified - -## Output expectations - -When the user wants implementation, finish with: - -1. A workflow file. -2. Any required step, operation, client, or service files. -3. A short explanation of key decisions. - -When the user wants guidance only, provide: - -1. The recommended architecture. -2. The file layout. -3. The workflow shape. - -## References - -1. `references/workflow-decision-flow.md` -2. `references/workflow-final-review.md` -3. `references/workflow-antipatterns.md` -4. `references/step-authoring-basics.md` - -## Assets - -1. `assets/new-workflow-template.yaml` -2. `assets/extends-workflow-template.yaml` -3. `assets/workflow-design-checklist.md` diff --git a/.claude/skills/titan-project-workflow-builder/assets/extends-workflow-template.yaml b/.claude/skills/titan-project-workflow-builder/assets/extends-workflow-template.yaml deleted file mode 100644 index 1fb119a0..00000000 --- a/.claude/skills/titan-project-workflow-builder/assets/extends-workflow-template.yaml +++ /dev/null @@ -1,11 +0,0 @@ -name: "Extended Workflow Name" -description: "What this workflow adds" -extends: "plugin:git/commit-ai" - -hooks: - before_commit: - - id: example_step - name: "Example Step" - plugin: project - step: example_step - on_error: continue diff --git a/.claude/skills/titan-project-workflow-builder/assets/new-workflow-template.yaml b/.claude/skills/titan-project-workflow-builder/assets/new-workflow-template.yaml deleted file mode 100644 index 7c5e9157..00000000 --- a/.claude/skills/titan-project-workflow-builder/assets/new-workflow-template.yaml +++ /dev/null @@ -1,11 +0,0 @@ -name: "Workflow Name" -description: "What this workflow automates" - -params: - example_flag: false - -steps: - - id: example_step - name: "Example Step" - plugin: project - step: example_step diff --git a/.claude/skills/titan-project-workflow-builder/assets/workflow-design-checklist.md b/.claude/skills/titan-project-workflow-builder/assets/workflow-design-checklist.md deleted file mode 100644 index aad373e2..00000000 --- a/.claude/skills/titan-project-workflow-builder/assets/workflow-design-checklist.md +++ /dev/null @@ -1,9 +0,0 @@ -# Workflow Design Checklist - -1. Reuse existing workflow if possible. -2. Prefer `command` over new Python when safe. -3. Create `plugin: project` steps only when needed. -4. Keep step entrypoints under `.titan/steps/**`. -5. Extract operations if logic stops being trivial. -6. Use `Exit` only for early clean termination. -7. Keep cleanup reachable. diff --git a/.claude/skills/titan-project-workflow-builder/references/step-authoring-basics.md b/.claude/skills/titan-project-workflow-builder/references/step-authoring-basics.md deleted file mode 100644 index 88c3c020..00000000 --- a/.claude/skills/titan-project-workflow-builder/references/step-authoring-basics.md +++ /dev/null @@ -1,21 +0,0 @@ -# Step Authoring Basics - -Project step entrypoints must be discoverable under `.titan/steps/**`. - -Step contract: - -```python -from titan_cli.engine import WorkflowContext, WorkflowResult, Success, Error, Skip, Exit - - -def my_step(ctx: WorkflowContext) -> WorkflowResult: - value = ctx.get("key", "default") - return Success("Done", metadata={"result": value}) -``` - -Rules: - -1. Function name must match the workflow `step:` value. -2. Steps orchestrate UI and workflow flow. -3. Steps should not own complex business logic. -4. Use metadata to pass values to later steps. diff --git a/.claude/skills/titan-project-workflow-builder/references/workflow-antipatterns.md b/.claude/skills/titan-project-workflow-builder/references/workflow-antipatterns.md deleted file mode 100644 index b7e2563d..00000000 --- a/.claude/skills/titan-project-workflow-builder/references/workflow-antipatterns.md +++ /dev/null @@ -1,10 +0,0 @@ -# Workflow Antipatterns - -Avoid these mistakes: - -1. Creating a brand new workflow when extending an existing one would do. -2. Creating a project step when a command step is enough. -3. Returning `Exit` from an intermediate step and skipping cleanup. -4. Putting parsing, filtering, or orchestration logic directly inside a complex step. -5. Creating a client for a one-off local action. -6. Hiding parameter flow instead of making it explicit via workflow params and metadata. diff --git a/.claude/skills/titan-project-workflow-builder/references/workflow-decision-flow.md b/.claude/skills/titan-project-workflow-builder/references/workflow-decision-flow.md deleted file mode 100644 index 6af06427..00000000 --- a/.claude/skills/titan-project-workflow-builder/references/workflow-decision-flow.md +++ /dev/null @@ -1,13 +0,0 @@ -# Workflow Decision Flow - -Use this order when designing a project workflow: - -1. Is there already a workflow that does most of the job? -2. If yes, can it be extended with hooks? -3. If not, can the workflow call an existing workflow as a nested step? -4. If not, can a `command` step solve the missing piece safely? -5. If not, create a `plugin: project` step. -6. If that step starts to carry business logic, extract an operation. -7. Only create clients and services when the integration is reusable. - -Default to the smallest option that cleanly solves the requirement. diff --git a/.claude/skills/titan-project-workflow-builder/references/workflow-final-review.md b/.claude/skills/titan-project-workflow-builder/references/workflow-final-review.md deleted file mode 100644 index ee90910d..00000000 --- a/.claude/skills/titan-project-workflow-builder/references/workflow-final-review.md +++ /dev/null @@ -1,12 +0,0 @@ -# Workflow Final Review - -Before finishing, confirm: - -1. The workflow lives in `.titan/workflows/.yaml`. -2. It uses `extends` only when a real base workflow exists. -3. Each step is one of: `plugin`, `command`, or `workflow`. -4. Params are passed with `${key}` only where needed. -5. `Error` handling is explicit when failure should not stop execution. -6. `Exit` is only used before resources requiring cleanup are created. -7. Cleanup steps are still reachable if intermediate work is skipped or fails. -8. New Python code exists only where orchestration alone is insufficient. diff --git a/.claude/skills/titan-public-plugin-workflow-builder/SKILL.md b/.claude/skills/titan-public-plugin-workflow-builder/SKILL.md deleted file mode 100644 index 8ada79ca..00000000 --- a/.claude/skills/titan-public-plugin-workflow-builder/SKILL.md +++ /dev/null @@ -1,76 +0,0 @@ ---- -name: titan-public-plugin-workflow-builder -description: Design and create workflows for public or community Titan plugins intended for external users. Use when adding workflows to a plugin package that will be distributed outside its current repository. -disable-model-invocation: false ---- - -# Titan Public Plugin Workflow Builder - -Build workflows for distributed Titan plugins intended for external consumers. - -## Goal - -Create or update plugin workflows that become part of a public plugin package. - -## Scope - -Use this skill when the workflow belongs inside a plugin package that will be consumed outside the current repository. - -Examples: - -1. community plugins -2. external plugin repositories -3. plugin packages organized by feature, domain, or category - -## Required process - -### 1. Inspect the plugin package structure - -Check: - -1. `plugin.py` -2. workflow directories -3. step registration strategy -4. feature, domain, or category layout -5. existing operations, clients, and services - -### 2. Preserve the plugin's public contract - -Treat the plugin as a public capability surface. - -Prefer: - -1. stable workflow naming -2. stable step names -3. reuse of existing client APIs -4. clear layout by category and layer - -### 3. Follow plugin-specific registration rules - -Do not assume project-step discovery. - -Public plugins expose steps through plugin registration, often via: - -1. `plugin.py -> get_steps()` -2. one or more step registry modules - -### 4. Keep the layout reusable - -When the plugin already organizes by feature, domain, or category first, respect that structure. - -Example: - -1. `/steps/...` -2. `/operations/...` -3. `/clients/...` - -### 5. Think like a public plugin author - -Prefer changes that stay maintainable for external users and future releases. - -## References - -1. `references/public-plugin-workflow-layout.md` -2. `references/public-plugin-step-registration.md` -3. `references/public-plugin-stability-rules.md` -4. `references/project-vs-plugin-workflow.md` diff --git a/.claude/skills/titan-public-plugin-workflow-builder/references/project-vs-plugin-workflow.md b/.claude/skills/titan-public-plugin-workflow-builder/references/project-vs-plugin-workflow.md deleted file mode 100644 index c2d8b6b9..00000000 --- a/.claude/skills/titan-public-plugin-workflow-builder/references/project-vs-plugin-workflow.md +++ /dev/null @@ -1,14 +0,0 @@ -# Project vs Plugin Workflow - -Project workflow: - -1. lives in `.titan/workflows/` -2. uses `plugin: project` for local steps -3. is local to the project - -Plugin workflow: - -1. lives in the plugin package -2. uses the plugin's registered step names -3. is part of the plugin capability surface -4. must respect plugin registration and package structure diff --git a/.claude/skills/titan-public-plugin-workflow-builder/references/public-plugin-stability-rules.md b/.claude/skills/titan-public-plugin-workflow-builder/references/public-plugin-stability-rules.md deleted file mode 100644 index a76d760b..00000000 --- a/.claude/skills/titan-public-plugin-workflow-builder/references/public-plugin-stability-rules.md +++ /dev/null @@ -1,9 +0,0 @@ -# Public Plugin Stability Rules - -For distributed plugins, prefer: - -1. stable workflow names -2. stable exposed step names -3. clear category-based organization -4. reusable client APIs where justified -5. minimal breaking changes to plugin consumers diff --git a/.claude/skills/titan-public-plugin-workflow-builder/references/public-plugin-step-registration.md b/.claude/skills/titan-public-plugin-workflow-builder/references/public-plugin-step-registration.md deleted file mode 100644 index 6ef0ed2a..00000000 --- a/.claude/skills/titan-public-plugin-workflow-builder/references/public-plugin-step-registration.md +++ /dev/null @@ -1,10 +0,0 @@ -# Public Plugin Step Registration - -Public plugin steps are not discovered via `.titan/steps/**`. - -They must be exposed through the plugin package's registration mechanism, typically: - -1. `plugin.py -> get_steps()` -2. one or more `step_registry/*.py` files - -Any new step must be implemented and then registered explicitly. diff --git a/.claude/skills/titan-public-plugin-workflow-builder/references/public-plugin-workflow-layout.md b/.claude/skills/titan-public-plugin-workflow-builder/references/public-plugin-workflow-layout.md deleted file mode 100644 index 94231459..00000000 --- a/.claude/skills/titan-public-plugin-workflow-builder/references/public-plugin-workflow-layout.md +++ /dev/null @@ -1,16 +0,0 @@ -# Public Plugin Workflow Layout - -Public plugin workflows live under the plugin package, not under `.titan/`. - -A common pattern is category first, then layers: - -```text -titan_plugin_example/ -├── category_a/ -├── category_b/ -├── category_c/ -├── step_registry/ -└── workflows/ -``` - -When that structure exists, keep new workflows consistent with it. diff --git a/.claude/skills/titan-workflow-architecture/SKILL.md b/.claude/skills/titan-workflow-architecture/SKILL.md deleted file mode 100644 index 7150073f..00000000 --- a/.claude/skills/titan-workflow-architecture/SKILL.md +++ /dev/null @@ -1,95 +0,0 @@ ---- -name: titan-workflow-architecture -description: Choose the correct Titan architecture for new workflow code. Use when deciding between command steps, project steps, operations, clients, services, plugin registration, or project versus plugin layout, or when the user asks how much architecture is justified. -disable-model-invocation: false -user-invocable: false ---- - -# Titan Workflow Architecture - -Decide the smallest correct architecture for workflow-related code. - -## Goal - -Prevent both under-design and over-design. - -## Target Types - -Decide which target you are designing for first: - -1. `project` - Workflow and supporting code under `.titan/`. -2. `plugin` - Workflow and supporting code inside a plugin package. - -## Decision Rules - -### 1. Prefer orchestration first - -Use: - -1. workflow extension -2. nested workflow -3. command step - -before adding Python. - -### 2. Add a project step when orchestration is not enough - -Create a project step when the workflow needs: - -1. branching logic -2. prompts or `ctx.textual` -3. metadata flow -4. Python-only integration code - -### 3. Extract operations when logic becomes reusable - -Create an operation when you see: - -1. parsing -2. filtering -3. ranking -4. validation -5. domain orchestration - -that would clutter the step. - -### 4. Create clients only for real reusable integrations - -Use `references/when-to-create-client.md`. - -Do not create a client unless there is a stable domain or integration worth reusing. - -### 5. Use plugin-like project layout when the domain deserves it - -For reusable domains, prefer a project layout that resembles a plugin while staying compatible with Titan project-step discovery. - -See `references/plugin-like-project-architecture.md`. - -### 6. Distinguish project discovery from plugin registration - -For projects: - -1. runtime entrypoints for project steps stay under `.titan/steps/**` - -For plugins: - -1. steps are exposed through plugin registration -2. workflow files live under the plugin package -3. registration structure is part of the architecture, not an implementation detail - -## References - -1. `references/when-to-use-command-vs-step.md` -2. `references/when-to-create-operation.md` -3. `references/when-to-create-client.md` -4. `references/plugin-like-project-architecture.md` -5. `references/layer-boundaries.md` -6. `references/project-vs-plugin-architecture.md` - -## Assets - -1. `assets/project-step-template.py` -2. `assets/operation-template.py` -3. `assets/client-template.py` diff --git a/.claude/skills/titan-workflow-architecture/assets/client-template.py b/.claude/skills/titan-workflow-architecture/assets/client-template.py deleted file mode 100644 index 05b9a561..00000000 --- a/.claude/skills/titan-workflow-architecture/assets/client-template.py +++ /dev/null @@ -1,8 +0,0 @@ -class ExampleClient: - """Reusable project-level client facade for a stable integration.""" - - def __init__(self, token: str) -> None: - self.token = token - - def fetch_items(self) -> list[dict]: - raise NotImplementedError diff --git a/.claude/skills/titan-workflow-architecture/assets/operation-template.py b/.claude/skills/titan-workflow-architecture/assets/operation-template.py deleted file mode 100644 index a46e0f48..00000000 --- a/.claude/skills/titan-workflow-architecture/assets/operation-template.py +++ /dev/null @@ -1,4 +0,0 @@ -def transform_items(items: list[str]) -> list[str]: - """Example operation: pure, reusable business logic.""" - - return [item.strip() for item in items if item and item.strip()] diff --git a/.claude/skills/titan-workflow-architecture/assets/project-step-template.py b/.claude/skills/titan-workflow-architecture/assets/project-step-template.py deleted file mode 100644 index c7253325..00000000 --- a/.claude/skills/titan-workflow-architecture/assets/project-step-template.py +++ /dev/null @@ -1,16 +0,0 @@ -from titan_cli.engine import WorkflowContext, WorkflowResult, Success, Error - - -def example_step(ctx: WorkflowContext) -> WorkflowResult: - if not ctx.textual: - return Error("Textual UI context is not available for this step.") - - ctx.textual.begin_step("Example Step") - - try: - value = ctx.get("value") - ctx.textual.end_step("success") - return Success("Step completed", metadata={"value": value}) - except Exception as exc: - ctx.textual.end_step("error") - return Error(str(exc), exception=exc) diff --git a/.claude/skills/titan-workflow-architecture/references/layer-boundaries.md b/.claude/skills/titan-workflow-architecture/references/layer-boundaries.md deleted file mode 100644 index 37b9ac22..00000000 --- a/.claude/skills/titan-workflow-architecture/references/layer-boundaries.md +++ /dev/null @@ -1,14 +0,0 @@ -# Layer Boundaries - -In project workflow code: - -1. Steps orchestrate UI, context, and result handling. -2. Operations hold business logic. -3. Clients expose reusable domain APIs. -4. Services sit below clients only when integration complexity justifies them. - -Do not: - -1. put complex business logic in a step -2. create services without a real client-level API need -3. mimic all 5 plugin layers for trivial project automation diff --git a/.claude/skills/titan-workflow-architecture/references/plugin-like-project-architecture.md b/.claude/skills/titan-workflow-architecture/references/plugin-like-project-architecture.md deleted file mode 100644 index 8c45bda4..00000000 --- a/.claude/skills/titan-workflow-architecture/references/plugin-like-project-architecture.md +++ /dev/null @@ -1,24 +0,0 @@ -# Plugin-like Project Architecture - -For reusable project domains, use a plugin-like layout while keeping Titan compatibility. - -Recommended pattern: - -```text -.titan/ -├── workflows/ -├── steps/ -│ └── slack/ -├── operations/ -│ └── slack/ -├── clients/ -│ └── slack/ -└── services/ - └── slack/ -``` - -Notes: - -1. Workflow files remain under `.titan/workflows/`. -2. Project-step entrypoints remain under `.titan/steps/**`. -3. Supporting code can be separated into domain folders under other top-level `.titan/` directories. diff --git a/.claude/skills/titan-workflow-architecture/references/project-vs-plugin-architecture.md b/.claude/skills/titan-workflow-architecture/references/project-vs-plugin-architecture.md deleted file mode 100644 index 943d094b..00000000 --- a/.claude/skills/titan-workflow-architecture/references/project-vs-plugin-architecture.md +++ /dev/null @@ -1,14 +0,0 @@ -# Project vs Plugin Architecture - -Project workflow architecture: - -1. workflows live in `.titan/workflows/` -2. project step entrypoints live in `.titan/steps/**` -3. supporting layers may live under `.titan/operations/`, `.titan/clients/`, `.titan/services/` - -Plugin workflow architecture: - -1. workflows live in the plugin package -2. steps are exposed by plugin registration -3. supporting layers live inside the plugin package -4. package structure is part of the contract for maintainers diff --git a/.claude/skills/titan-workflow-architecture/references/when-to-create-client.md b/.claude/skills/titan-workflow-architecture/references/when-to-create-client.md deleted file mode 100644 index d040beaa..00000000 --- a/.claude/skills/titan-workflow-architecture/references/when-to-create-client.md +++ /dev/null @@ -1,16 +0,0 @@ -# When To Create Client - -Create a client only when the project is introducing a reusable integration or domain API. - -Good signals: - -1. multiple operations target the same external system -2. multiple workflows will reuse that integration -3. a coherent public API helps keep steps simple -4. the integration may later become a plugin - -Bad signals: - -1. one-off script behavior -2. purely local file edits -3. shell commands that already solve the problem cleanly diff --git a/.claude/skills/titan-workflow-architecture/references/when-to-create-operation.md b/.claude/skills/titan-workflow-architecture/references/when-to-create-operation.md deleted file mode 100644 index 1054bb3c..00000000 --- a/.claude/skills/titan-workflow-architecture/references/when-to-create-operation.md +++ /dev/null @@ -1,15 +0,0 @@ -# When To Create Operation - -Create an operation when a step contains logic that is: - -1. not UI -2. not context access -3. more than trivial -4. likely reusable or easier to test separately - -Examples: - -1. parsing input into structured values -2. validating domain constraints -3. combining multiple client calls -4. filtering and ranking returned data diff --git a/.claude/skills/titan-workflow-architecture/references/when-to-use-command-vs-step.md b/.claude/skills/titan-workflow-architecture/references/when-to-use-command-vs-step.md deleted file mode 100644 index 50c7fcb2..00000000 --- a/.claude/skills/titan-workflow-architecture/references/when-to-use-command-vs-step.md +++ /dev/null @@ -1,14 +0,0 @@ -# When To Use Command vs Step - -Use a command step when: - -1. the action is a straightforward shell command -2. no `ctx.textual` interaction is needed -3. no custom branching logic is needed -4. no reusable Python behavior is being introduced - -Use a project step when: - -1. the workflow needs prompts, UI, or metadata handling -2. the shell form would be hard to read or unsafe -3. the logic needs Python conditionals or composition diff --git a/AGENTS.md b/AGENTS.md index d10a425f..94e96cb1 100644 --- a/AGENTS.md +++ b/AGENTS.md @@ -38,13 +38,9 @@ For high-level architecture overview, see [DEVELOPMENT.md](DEVELOPMENT.md). Project-maintained agent skills now live in `.claude/skills/`. -- Use `.claude/skills/titan-project-workflow-builder/` for end-to-end project workflow creation under `.titan/`. - Use `.claude/skills/titan-official-plugin-workflow-builder/` for workflows that belong to official plugins inside this repository. -- Use `.claude/skills/titan-public-plugin-workflow-builder/` for workflows that belong to public or community plugin packages. -- Use `.claude/skills/titan-workflow-architecture/` for deciding the minimum correct architecture. -- Use `.claude/skills/titan-capability-discovery/` to inspect what Titan, the current project, or the target plugin already provide before creating new code. -These skills generate project artifacts under `.titan/`, but `.titan/skills/` is no longer the canonical location for workflow-authoring skills. +Shared workflow-authoring skills are maintained outside this repository. In `titan-cli`, keep only the official-plugin skill here. ---